Specialty Medication Enrollment, published by HL7 International - Pharmacy. This is not an authorized publication; it is the continuous build for version 2.1.0). This version is based on the current content of https://github.com/HL7/fhir-specialty-rx/ and changes regularly. See the Directory of published versions
Much of the information needed to fulfill a specialty medication can be retrieved systematically from the prescriber’s EHR: allergies, conditions, active medications, and other patient information. This section details those exchange flows.
In all workflow scenarios, Specialty Rx exchanges takes place after the specialty medication prescription has been received by the pharmacy or other party involved in fulfilling the prescription. In the US, electronic prescriptions are typically transmitted using the NCPDP SCRIPT standard, though there are also occasions where prescriptions are received via fax or through other non-electronic methods.
This section…
Note that this guide does not require a given implementer to support both RESTful and messaging approaches. Instead, each may implement one or both depending on their needs and the needs of their partners. Detailed implementation profiles are described in the Capability Statements section of the guide.
In addition, an intermediary may facilitate exchange between RESTful and messaging-based participants, which is described further in the Intermediary Facilitation section of the guide.
The “Solicited Workflow” is one in which a pharmacy or other Data Consumer system “solicits” patient information related to a specialty medication from a Data Source such as an EHR. Below is the sequence of events:
This process may repeat one or more times, for example if the user of the Data Consumer system realizes they need additional information as a follow-up to information received in a previous response. Further, the solicited workflow may occur after an unsolicited workflow (described below).
In the “Unsolicited Workflow”, a Data Source system proactively transmits patient information to a pharmacy or other party involved in fulfilling a specialty medication prescription.
In this flow, patient information is exchanged based on a request from a pharmacy or other party to a Data Source which responds to RESTful requests.
The Data Consumer system employs standard FHIR RESTful searches to retrieve patient information from the Data Source. In this model, the Data Consumer must be able to locate and connect directly with the Data Source, for example when the two are part of the same umbrella organization.
In this model, the Data Consumer system is responsible for…
determining the Data Source holding information about the patient for whom the prescription of interest was written
locating the system endpoint information needed to connect with that Data Source
performing RESTful searches directly against the Data Source.
In this flow, patient information is exchanged based on a request from a pharmacy or other party. The request is transmitted in a Specialty Rx Query request message to the Data Source who collects the requested information, collects it into a Specialty Rx Query Response message and returns it to the Data Consumer.
This guide defines an unsolicited data “push” model that uses FHIR messaging (below). This approach aligns with the current environment in which it is expected that all prescribing systems are able to exchange with all pharmacies in the US, the bulk of prescriptions are transmitted through exchange networks, and direct connections between EHRs and pharmacies are uncommon.
However, the Data Source may leverage an intermediary to enable patient information to be collected and sent to a pharmacy or other party in FHIR message form, with the Data Source interacting solely through standard RESTful requests. The Intermediary Facilitation section describes this approach.
In this flow, the prescribing system proactively sends a Specialty Rx Query Response - Unsolicited message containing patient information related to a prescription.
All messaging flows may be synchronous or asynchronous, as defined in the $process-message operation.