Short Description

NCPDP is working with HL7 to define FHIR exchanges to help get specialty medications to the patient quicker--by providing pharmacies the information they need to dispense the drug, address insurance needs, and coordinate with the patient and other parties.

Long Description

For Oncology, Rheumatoid Arthritis, Infusion drugs, etc., the current process for exchanging data, including prescription data regarding specialty medications is complex and manual, taking days to weeks to begin a patient on therapy.

There is no industry standard for exchanging clinical data when necessary for dispensing specialty medications by pharmacies as well as facilitating enrollment of patient in programs offered by third parties such as Hub vendors or Pharmaceutical Manufacturers. NCPDP started a task group several years ago focused on the exchange of data needed to help shorten the time to therapy for a patient who has been prescribed a specialty medication and over the past two years have been focused on identifying demographic, clinical and financial information that needs to be exchanged in order to get the patient the therapy they need.

This information is outside of the current e-Prescription that is sent to the pharmacy today. After an extensive analysis of the types of additional information that is required along with the prescription it was determined that developing an implementation guide using HL7 FHIR would be the best approach to support the exchange of this information. 

We are in the process of creating a co-branded FHIR implementation Guide (Co-branded between HL7 and NCPDP) focused on the exchange of data (Demographic, prescription, clinical and financial) for dispensing specialty medications by pharmacies as well as facilitating enrollment of patients in programs offered by third parties such as but not limited to Hub vendors and Pharmaceutical manufacturers. 

Background information on the project is located here: Specialty Medication Prescribing and the draft implementation guide is located here: Specialty Medication DRAFT Imp Guide

The implementation guide was approved by the NCPDP Work Group on 11/6/2020.

Agenda

(Pacific Time)

14 JAN 2021

8-8:30 Track Kickoff

8:30-9:30 Implementation Guide Overview

9:30-10 Using the mock application

10:30-3 General working session and discussion

15 JAN 2021

7:30-4 General working session and discussion continued

12:15 Track Highlight

4 Wrap up session

Type

Test an Implementation Guide

Submitting Work Group/Project/Accelerator/Affiliate/Implementer Group  

Pharmacy

Proposed Track Lead

Frank McKinney frank.mckinney@pocp.com

Maggie Buchinger maggie.buchinger@surescripts.com

Related Tracks

FHIR Version

FHIR R4

Specification(s) this track uses

Specialty Medication DRAFT Implementation Guide

Artifacts of focus

Messaging and RESTful exchange model overview

http://build.fhir.org/ig/HL7/fhir-specialty-rx/systematic-queries.html

Workflow to obtain information requiring human interaction (Task-to-SMART App launch)

http://build.fhir.org/ig/HL7/fhir-specialty-rx/human-interaction.html

Required Searches

http://build.fhir.org/ig/HL7/fhir-specialty-rx/searches.html

All profiles and examples

http://build.fhir.org/ig/HL7/fhir-specialty-rx/branches/master/artifacts.html

Clinical input requested (if any)

Patient input requested (if any)

Expected participants

EHRs, pharmacy organizations, pharmacy technology vendors, hubs, manufacturers, intermediaries

Zulip stream

https://chat.fhir.org/#narrow/stream/235647-Specialty-Medications

https://global.gotomeeting.com/join/475027005

Connectathon Orientation - Specialty Medication Enrollment.ics

Track Orientation Date

Friday December 18th - 10am central

Track Orientation Details

Orientation Session Recording

Track Details

Supported business functions

The implementation guide supports these business functions:

  • Specialty enrollment for programs or services.
  • Request of additional information to facilitate medication dispensing and billing.
  • Facilitation of clinical care management, education, and training

Process flows

Notes:


1. Searching for patient data in the EHR

    1. The Requesting System searches for needed patient clinical and coverage information using RESTful searches or the Specialty Rx Query message.

  • This might be triggered automatically by the Requesting System upon receiving an electronic prescription (NewRx) or 
  • A person using the Requesting System might initiate the request manually, e.g., after receiving a faxed prescription

    2. The Data Source System responds to the RESTful searches (or responds to a Specialty Rx Query messagy by collecting the requested information and returning a Specialty Rx Query Response).

   Notes:

  • The response is typically synchronous.
  • The process may repeat one or more times, for example if the user of the Requesting Party System realizes they need additional information as a follow-up to information received in a previous Specialty Rx Query Response.
  • An alternative, "unsolicited" flow, in which the prescribing system proactively transmits patient information in conjunction with an electronic specialty prescription, is included in the Specialty Rx IG, but will not be tested during this Connectathon.

2. Obtaining information that requires human intervention

The guide defines a Task-to-SMART app launch workflow enabling an EHR to trigger the launch of a SMART application in response to an external party's request (via a Task resource). In the context of specialty prescription fulfillment, this flow enables a pharmacy to ask the prescriber / clinic for additional information not available by searching the patient's chart–in a way that's integrated into the clinic user's work queue. 

In short, the requester posts a Task to the prescriber's EHR, which places the request in the appropriate user's work queue, and subsequently launches the specified SMART app when the work item is initiated by an EHR user.

System Roles

Requesting system. The requesting system is used by a stakeholder that requires information to perform an activity related to a specialty medication prescription.

The real-world actors below may initiate a specialty Rx data request:

Pharmacy staff

     The pharmacy typically will:

  • Receive the NewRx transaction requiring more information to be provided before it can be dispensed
  • Request additional information from prescriber or their EHR system
  • Determine when additional information necessary to dispense medication has been satisfied

Specialty Hub staff or other third parties (examples include but are not limited to intermediary, hub, manufacturer) 

     These other parties typically will:

  • Request additional information from prescriber or their EHR system
  • Determine when additional information necessary to dispense medication has been satisfied


Data Source System.This system is used by the prescriber of the specialty medication or associated staff.

The real-world actors below may participate in a specialty Rx data request:

Prescriber

     The prescriber typically will:

  • Create a New Prescription using the NCPDP SCRIPT (NewRx) transaction requiring more information to be provided before it can be dispensed
  • Provide appropriate responses to requests for information when human interaction is required

Prescriber Agent

     The prescriber agent can provide responses to requests on behalf of the provider

EHR System

     The EHR system will:

  • Respond systematically when a search request is received
  • Enable users to launch a SMART application to respond to requests requiring human interaction.

Track details

Data Exchange Roles (to be tested during the Connectathon)

  • RESTful Requester (pharmacy): Retrieves data with REST search requests
  • RESTful Data Source (EHR): Responds to REST search requests
  • Messaging Requester (pharmacy): Requests, receives patient info using FHIR messages
  • Messaging Data Source (EHR*): Accepts message requests and transmits patient info in a message response

  • EHR Hosting a SMART Application: Accepts a Task containing information needed to launch a SMART app from a user’s work queue


Connectathon sandbox

  • Acts as a messaging requester

  • Acts as a messaging data source

  • Acts as an EHR hosting a SMART application (Task workflow)

  • Acts as an intermediary…

    • Between two messaging participants
    • Between a messaging requester and RESTful data source

Connectathon scenario 1: Request / Response with RESTful Data Source

Summary: An EHR responds to RESTful search requests made by a pharmacy or intermediary (roles that can be played by the sandbox system during the Connectathon)

Action: The EHR responds to the set of required searches defined in the Specialty Rx Implementation guide (http://build.fhir.org/ig/HL7/fhir-specialty-rx/searches.html)

Preconditions:

  • Clinical and administrative information about the patient resides in the EHR (see test patient defined below)

Success Criteria: 

  • The EHR executes the submitted searches, conforming to the US Core profiles for clinical information and the Specialty Rx Coverage profile


Connectathon scenario 2: Request / Response using FHIR Messaging

Summary: A pharmacy or other Requesting System requests a set of information related to a specialty medication prescription it's received. (See Message Structures and Message Submission in the IG for messaging details.)

Action: The Requesting system creates a Specialty Rx Query Request message bundle and submits it to the Data Source System endpoint using the $process-message operation. (The sandbox system can play the role of either sender or receiver during the Connectathon)

The request bundle contains the following resources:

  • MessageHeader
  • Parameters resource containing search strings and references to:
    • Patient
    • MedicationRequest (optional)
    • Practitioner (optional)
    • Pharmacy Organization (optional)

Preconditions:

  • Clinical and administrative information about the patient resides in the Data Source System (see test patient defined below)
  • The Requesting System knows the address and connection details of the Data Source System endpoint or that of its intermediary.
  • The Data Source System knows the address and connection details of the Requesting System endpoint or that of its intermediary.

Success Criteria: 

The Data Source System executes the searches specified in the request and initiates a Specialty Rx Query Response to the Requesting System.

  • The response bundle contains the resources necessary to supply the requested information.


Connectathon scenario 3: Obtain Additional Information Using a SMART App

Summary: An EHR user provides information using a SMART application, which is launched in response to a Task submitted by a requesting pharmacy. 

Action: The pharmacy system POSTs a Task containing SMART app and context information to an EHR. The EHR places a task item in an appropriate user's work queue, and the EHR user launches the SMART app and responds to the pharmacy's questions. This process flow and details of Task population are described in the Specialty Rx Implementation guide at http://build.fhir.org/ig/HL7/fhir-specialty-rx/branches/master/human-interaction.html. An example task is at http://build.fhir.org/ig/HL7/fhir-specialty-rx/branches/master/Task-specialty-rx-task-smart-launch-1.html

Preconditions:

  • Questions for the EHR user have been staged in the SMART app, and can be accessed by passing an identifier to the SMART app in the appContext parameter during launch.
  • The SMART application has been registered with the EHR

Success Criteria: 

  • An EHR user launches the SMART app based on a work queue item that was created in response to a Task posted by the pharmacy system.


Connectathon Sandbox System

There will be a test sandbox running during the Connectathon that can interact with participants as…


REST Requester and Data Source

  • Submit RESTful FHIR search requests to the sandbox EHR or external EHR

Messaging-based Requester

  • Submit a Specialty Rx Query request to a messaging-based EHR or RESTful EHR
  • Receive the synchronous Specialty Rx Query Response message

Messaging-based EHR

  • Accept a Specialty Rx Query request from a Messaging Requester
  • Respond with a synchronous Specialty Rx Query Response

EHR hosting a SMART application

  • Accept a Task containing information needed to launch a SMART app (app launch URL, app context ID), place a work item in a simulated user work queue, and launch the SMART app
  • Respond to GET requests for Task status information
  • Update Task status when creating the associated work queue item and launching the SMART app
  • Accept PUT update to the Task's status (to 'completed', when the pharmacy system confirms the questions were completed in the SMART app)

SMART App that can be Launched from an EHR – prompted by Specialty Rx Task

  • Submit a Task to an EHR with the sandbox's SMART app URL and app context
  • Launch from the EHR


Sandbox URL

https://specialty-fhir.azurewebsites.net/


Sanbox usage:

To use the sandbox as a mock message-based requester...

  • An EHR processes a request message sent by the Sandbox


To use the sandbox as a mock EHR...

  • A Messaging Requester (Pharmacy) submits a request message and receives a response


To use the sandbox to simulate the Task-to-SMART App workflow...

  • Use the sandbox UI to create and submit a SMART launch Task to the sandbox EHR, which creates a work queue item and launches the SMART app


To use the sandbox as a messaging-to-REST intermediary...

  • A RESTful Data Source (EHR) processes searches submitted by the Sandbox


To use the sandbox's SMART application in a Task-to-SMART app launch process...

  • An EHR hosts the sandbox SMART app and submits a Task from the sandbox that contains the app URL and context ID
  • The app is then launched from the EHR
  • Note: SMART app registration with the EHR will be done beforehand. Contact us prior to the Connectathon

Security and Privacy Considerations

Security

  • The sandbox can be accessed without authentication credentials
  • The sandbox works with an open EHR FHIR server and has an option to manually send an authorization token

Privacy

  • All information accessible through the sandbox is fictional
  • Participants must be sure not expose any real person information in requests or responses exchanged during the connectathon

Test Patient

The mock EHRs provided by the test harness require that the patient's first and last name match exactly

Family name: Doe
Given name: Tim

Phone: 555-555-5555
use: home
email: tim.doe@example.com
gender: male
birthDate 1987-02-20
address
line: 2224 Century Avenue
city: Minnetonka
state: MN
postalCode: 55345
country: US

Test data load scripts (transactions)

tim-doe-data-load.zip




Highlights Deck