PHIL Transfer Rx Intake API Documentation

The purpose of this API is to intake a prescription transfer request from an originating pharmacy seeking to transfer a prescription to Phil. This API accepts one script per request in the standard NCPDP SCRIPT RxTransferResponse XML format.

When the API is called, it performs key field and schema validations and provides an immediate request acceptance or reject status (with relevant error messages).

Once the transfer script is received we follow the standard pharmacy transfer-in process to validate remaining refills, confirm the originating pharmacy details, and process the transfer.

NOTE: In NCPDP terminology, RxTransferResponse is used because the originating pharmacy sends the full prescription data as its response to the patient's request to transfer to Phil. This is the standard NCPDP SCRIPT 2017 format for pharmacy-to-pharmacy transfer data pushes.

Username: tbd

API Key: tbd

Base64 encoded String: tbd

Content-Type: application/json

Authorization: Basic username:api_key //for Staging you can use the value above

NOTE: the "username:api_key" combined string will need to be base64 encoded. We will share the auth details separately in a secure email for both production environment

NOTE:

1. "transaction_id" should be a unique value to identify each request for tracking purposes

2. The "message" field is a single base64 encoded RxTransferResponse Script XML representing the prescription transfer being requested. Only one script is accepted per API call.

Response has 2 parts. If the http request itself fails then error will be based on http status such as 404 (unauthorized), 400 (client error) or 500 for internal server error

But, if the http request is good and the API call fails because of bad XML data or others, the JSON response will be sent back to the client with http status 200 or 201. But, JSON response has 1 of 2 possible statuses: "OK" or "ERROR"

JSON response body for status "OK":

NOTE: TransactionID is the same id sent by the originating pharmacy system and is used for tracking purposes

JSON response body for status "ERROR":

NOTE: the error value will reference the MessageID from the Script XML to identify which script failed. Example:

erx_message_id is the MessageID value from the Script XML

RxTransferResponse XML - sent as part of the request body (base64 encoded)

NOTE:

• PHIL Rx NCPDP ID: 3685508

• Any tags with the comment //NOTE: can remain same can be static. Meaning can use the exact same value

• Header qualifiers: <To Qualifier="D"> identifies PHIL as the recipient; <From Qualifier="P"> identifies the originating pharmacy by NCPDP ID

• Two <Pharmacy> elements are required. Both use the same tag, differentiated by <TransferType>. Sending pharmacy first (TRANSFER FROM PHARMACY), PHIL second (TRANSFER TO PHARMACY)

• PHIL's <Pharmacist> block inside the second <Pharmacy> uses a flat structure: <Name/> followed by <FirstName> and <LastName> as direct children (not nested under <Name>)

• The medication block is nested inside <MedicationTransferred> with <PrescriptionPreviouslyFilled>: "true" if a LastFillDate exists; "false" if the script was never dispensed

• <BenefitsCoordination> appears BEFORE <MedicationTransferred> in the element ordering

• <HistorySource> inside <MedicationPrescribed> carries the originating pharmacy identity, original Rx number, fill dates, and authorized/remaining refill counts. Required when the Rx number is known.

• <NumberOfRefills> should be RefillsRemaining + 1 to account for the current fill being transferred