Connectathon Schedule: Meeting times for Specialty medication Prescribing

Specialty Medication Prescribing Zoom Infohttps://zoom.us/j/2356542166235 654 2166

Thursday – May 14th
10:00 AM ET / 7:00 AM PT
1:00 PM ET / 10:00 AM PT
4:30 PM ET / 1:30 PM PT

Friday – May 15th
10:00 AM ET / 7:00 AM PT
3:30 PM ET / 12:30 PM PT

Specialty medication overview deck:

Submitting WG/Project/Implementer Group

Pharmacy Workgroup

Justification and Objectives

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 Enrollment and the draft implementation guide is located here: Specialty Medication DRAFT Imp Guide

We are in the process of developing the implementation guide for this project and we will be using the connectathon to socialize the Implementation Guide and to demonstrate the ability to exchange information between an EHR and pharmacies for the additional clinical information needed to dispense specialty medications. Additional background connectathon track can be found here

Zulip Stream for Specialty medication 


This track will use what version of FHIR.

This track will use the R4 version of FHIR 

Clinical input requested (if any)

No clinical needs at this time

Related tracks

(used to help guide seating arrangements and possibly drive track consolidation)

Proposed Track Lead

Name, email. Track leads must be registered users on http://chat.fhir.org

Frank Mckinney, FM@FrankMckinney.com (Technincal Lead)

Pooja Babbrah, pooja.babbrah@pocp.com (Business Lead)

Expected participants


Contact Name

Email

Organization

Role (Sender, Receiver, Intermediary


Client/Server URL/Endpoint 


















Track Orientation

Additional background connectathon track can be found here

System Roles

Requesting system. In this workflow, the requesting system is used by a stakeholder that requires information to perform an activity related to a specialty medication prescription (generalized as a Third Party System).

The actors below may initiate a specialty Rx data request:

Pharmacy (user of Third Party System)

     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

Other Third Parties (examples include but are not limited to intermediary, hub, manufacturer) (user of Third Party System)

     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


Responding system. The responding system is used by the prescriber of the specialty medication or associated staff (Prescriber System).

The actors below respond to a specialty Rx data request:

Prescriber (Prescriber System)

     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 from other parties

Prescriber Agent (Prescriber System)

     The prescriber agent can:

  • Provide appropriate responses to requests on behalf of the provider

EHR System (Prescriber System)

     The EHR system typically will:

  • Respond automatically when a request from a third party is received
  • Allow users to respond to requests for additional information when requested from other parties


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


Exchange Workflows

"Solicited" Workflow

    1. The Third Party System initiates a Specialty Rx Data Request when additional information relating to a specialty prescription is needed to facilitate dispensing or other activity.

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

    2. The Prescriber System collects the requested information and responds with a Specialty Rx Data Response.

    Notes:

  • The response is typically asynchronous.
  • The process may repeat one or more times, for example if the user of the Third Party System realizes they need additional information as a follow-up to information received in a previous Specialty Rx Data Response.
  • The solicited workflow may follow an unsolicited workflow (described below).
    For example, the Prescriber system transmits a new specialty medication prescription to a pharmacy and also initiates an "unsolicited" Specialty Rx Data Response to the pharmacy, containing related information. Upon review of the prescription and accompanying information, pharmacy staff realizes they need additional information and initiates a Specialty Rx Data Request back to the Prescriber System. 

"Unsolicited" Workflow

    1. At the time that a specialty medication prescription is ordered, the Prescriber System...

  • transmits the prescription to the pharmacy and/or other Third Party System
  • also collects related information and initiates a Specialty Rx Data Response to the Third Party System, to accompany the prescription

In both workflows, Specialty Rx Data exchanges takes place after the specialty medication prescription has been received by the Third Party System (or received by a user of the system, e.g., by fax).


Scenarios

Note: The following is subject to change during the implementation guide's development

Please review the Specialty Medication Prescribing FHIR Implementation Guide (draft in development) for details of the profiles used to convey the information identified in the scenarios below.


Scenario One - "Unsolicited" workflow containing a predefined set of request information

Summary: A Prescriber System sends information related to a specialty medication prescription previously sent to the Third Party System, (One-way exchange initiated by a Prescriber System)

Action: The Prescriber System collects predefined information associated with a specialty medication prescription and initiates a Specialty Rx Data Response containing the information to a Third Party System.

Preconditions:

  • The Prescriber System has previously transmitted a specialty medication prescription to the Third Party System.
  • Clinical and administrative information about the patient resides in the Prescriber System, or can be provided by its users.
  • The Prescriber System knows the address and connection details of the Third Party System endpoint or that of its intermediary.

Success Criteria: 

The Specialty Rx Data Response bundle contains the following resources:

  • MessageHeader
  • MedicationRequest (reflecting the specialty medication prescription)
  • Patient (the subject of the MedicationRequest)
  • Practitioner (the prescriber of the MedicationRequest)
  • Organization (the dispensing pharmacy)
  • QuestionnaireResponse

       Related information, such as...

  • List (referencing requested allergies, conditions, etc.)
  • AllergyIntolerance
  • MedicationStatement
  • Condition
  • Observation
  • Coverage

Bonus points:

  • TBD


Scenario Two - "Solicited" workflow referencing a predefined set of request information

Summary: A Third Party System requests information related to a specialty medication prescription it's received, The request refers to a predefined Questionnaire. (Responder is a Prescriber System)

Action: The Third Party system creates a Specialty Rx Data Request message bundle and submits it to the Prescriber System endpoint using the $process-message operation. The request bundle contains the following resources:

  • MessageHeader
  • MedicationRequest (reflecting the specialty medication prescription)
  • Patient (the subject of the MedicationRequest)
  • Practitioner (the prescriber of the MedicationRequest)
  • Organization (the dispensing pharmacy)
  • reference identifying a predefined Questionnaire

Preconditions:

  • The Prescriber System has access to the predefined Questionnaire identified in the request.
  • Clinical and administrative information about the patient resides in the Prescriber System, or can be provided by its users.
  • The Third Party System knows the address and connection details of the Prescriber System endpoint or that of its intermediary.
  • The Prescriber System knows the address and connection details of the Third Party System endpoint or that of its intermediary.

Success Criteria: 

The Prescriber System collects the information specified in the predefined questionnaire and initiates an asynchronous Specialty Rx Data Response to the requesting Third Party System.

  • The response bundle contains resources as described in Scenario One

Bonus points:

  • TBD


Scenario Three - "Solicited" workflow requesting an ad-hoc set of information

Summary: A Third Party System requests an ad-hoc set of information related to a specialty medication prescription it's received. (Responder is a Prescriber System)

Action: The Third Party system creates a Specialty Rx Data Request message bundle and submits it to the Prescriber System endpoint using the $process-message operation. The request bundle contains the following resources:

Same as Scenario Two above, except...

  • Questionnaire resource containing ad-hoc information requests

Preconditions:

  • Clinical and administrative information about the patient resides in the Prescriber System, or can be provided by its users.
  • The Third Party System knows the address and connection details of the Prescriber System endpoint or that of its intermediary.
  • The Prescriber System knows the address and connection details of the Third Party System endpoint or that of its intermediary.

Success Criteria: 

The Prescriber System collects the information specified in the request's Questionnaire resource and initiates an asynchronous Specialty Rx Data Response to the requesting Third Party System.

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

Bonus points:

  • TBD


TestScript(s)

(to be added)


Security and Privacy Considerations

Only test data and test accounts should be used in this activity, not individual devices, real person information or accounts.

TBD: Identify any expectations around security (e.g. will TLS, mutual-TLS, OAuth, etc. be required to participate


  • No labels