2022-05 Patient Consent for Specialty Medication Enrollment

Frank McKinney fm@frankmckinney.com

Unknown User (joe.kelly@surescripts.com) Joe.Kelly@surescripts.com

Supported business functions

New consent-related resource profiles and guidance in the IG address stakeholders' need to receive evidence that the patient consented to activities that take place during specialty product fulfillment. These consents typically cover:

• release of health information to parties including the pharmacy, other dispenser, specialty HUB, manufacturer-sponsored patient support programs
• contact via text message and other communication methods 
• participation in research programs

This information augments patient clinical and insurance information currently supported by the published Specialty Medication Enrollment implementation guide.

Use case overview

Notes:

• All flows below take place after the specialty medication prescription has been transmitted electronically to the pharmacy system, or received by a user of the system, e.g., by fax
• See Roles, Patient Consent Workflows, Human interaction (Task-to-SMART app launch) workflow, and Query Workflow for additional details about roles and workflows

1. Obtaining consent via a SMART app

During this track, this flow can be simulated using the sandbox application

The guide defines a workflow enabling a requester such as a pharmacy or specialty Hub to obtain information from the clinic after receiving a prescription – by creating a Task that triggers the launch of a SMART application in the prescriber's EHR.

The draft STU2 IG proposes using this method to...

• provide the prescriber / clinic with the consent form that applies to the ordered product
• enable the completed consent form and Consent resource to be returned to the requester.

In short, the requester posts a Task to the prescriber's EHR, which places the request in the appropriate clinic staff's work queue. The EHR launches the specified SMART app when the work item is started by the staff user.

2. Requesting consent by submitting a Task to the EHR

During this track, this flow can be simulated using the sandbox application

Another option in the draft IG is for the requesting pharmacy or Hub to submit a Task to the prescriber's EHR... providing the appropriate consent form attached to a proposed Consent resource. The EHR puts the task and consent form in a staff member's queue and provides a way to attach the completed consent to the Task. The requester retrieves the completed Task and consent when it's ready.

3. Searching for patient consents in the EHR

During this track, this flow will be discussed. Identify conventions, potential challenges and approaches for identifying Consent resources related to a particular prescription 

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 that may initiate a specialty Rx data request include Pharmacy staff, Specialty Hub staff or other third parties. These parties will typically...

• Receive a prescription that requires more information so that it can be dispensed and so that the patient can be enrolled into a related support program
• Request additional information from the prescriber (via their EHR system)

System responsibilities

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

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 are...

• Prescriber
• Prescriber Agent (staff working on behalf of the prescriber)
• EHR System (responds systematically when a search request is received, enable users to launch a SMART application or internal EHR workflow in response to a submitted Task).

System responsibilities

• Data Source / 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)

• Data Source / EHR supporting a consent-request Task workflow
  • • Accept a Task referencing a proposed Consent that contains the applicable consent form for the prescribed product
    • Place the request in a simulated user work queue and enable the user to update the Task with the completed consent
    • Respond to GET requests for Task status information
    • Update Task status to in process (when the task is started) and completed (when the consent has been obtained)

Track scenarios

Scenario 1: Request consent by submitting a Task to the EHR

During this track, this flow can be simulated using the sandbox application

Another option in the draft IG is for 

Discussion points for the Connectathon:

• • How implementable does this method seem... for both EHRs and requesting parties (pharmacies, Hubs)?
  • Does this give a practical way for the requester to provide the appropriate enrollment form to the clinic and notification that the consent is needed?
  • Discuss how this could fit into the patient process during or after the encounter where the prescription is written

Summary: A requesting pharmacy or Hub submits a Task to the prescriber's EHR... providing the appropriate consent form attached to a proposed Consent resource. The EHR puts the task and consent form in a staff member's queue and provides a way to attach the completed consent to the Task. The requester retrieves the completed Task and consent when it's ready. 

Action: The requesting system POSTs a Task containing the unfilled consent form and context information to an EHR. The EHR places a task item in an appropriate user's work queue. A user obtains patient consent using the supplied form and updates the Task status when completed.

This process flow and details of Task population are described in the Specialty Rx Implementation guide at:

• process flow: https://build.fhir.org/ig/HL7/fhir-specialty-rx/consent-workflow.html#process-flow-task-based-consent-request.
• task profile: https://build.fhir.org/ig/HL7/fhir-specialty-rx/StructureDefinition-specialty-rx-task-consent-request.html
• example tasks:
  • request: https://build.fhir.org/ig/HL7/fhir-specialty-rx/Task-specialty-rx-task-consent-request-1.html
  • completed: https://build.fhir.org/ig/HL7/fhir-specialty-rx/Task-specialty-rx-task-consent-request-2-completed.html

Preconditions:

• Requester has identified the applicable consent form for the prescribed product (included in the Task)

Success Criteria: 

• The EHR places a task item in an appropriate user's work queue. A user obtains patient consent using the supplied form and updates the Task status when completed.

Scenario 2: Prescriber's EHR proactively supplies consent at the time of the prescription, using the Specialty Rx Query Response - Unsolicited message

Summary: The prescriber's EHR proactively transmits the patient's consent at the time that the prescription is created. The consent is part of a bundle of patient clinical, insurance and demographic information conveyed using the Specialty Rx Query Response - Unsolicited message.

Specialty enrollment consent profile (completed consent): https://build.fhir.org/ig/HL7/fhir-specialty-rx/StructureDefinition-specialty-rx-consent.html

Example consent: https://build.fhir.org/ig/HL7/fhir-specialty-rx/Consent-specialty-rx-consent-1.html

Discussion points for the Connectathon:

• • What are the practicalities related to the practice's workflows (to obtain the appropriate consents for the prescribed product) and EHR functionality (to record the consent and then include in the message)?
  • Given that the draft R5 Consent appears to make breaking changes to the R4 consent... e.g., combining of Consent.scope into Consent.category, removal of "proposed" from the Consent.status valueset, role-related element changes... What considerations should the IG keep in mind when profiling the R4 Consent within this IG? E.g., elements to populate or avoid so that future transition to R5 is easier?

Scenario 3: Obtain Consent Using a SMART App

During this track, this flow can be simulated using the sandbox application

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

Action: The pharmacy or Hub 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.

Discussion points for the Connectathon:

• • How implementable does this method seem... for both EHRs and requesting parties (pharmacies, Hubs)?
  • Does this give a practical way for the requester to provide the appropriate enrollment form to the clinic and notification that the consent is needed?
  • A challenge to this approach is that it would occur after the prescription is written... and possibly / likely after the patient has left the clinic.
    • Discuss how this could fit into the patient process during or after the encounter where the prescription is written
    • Is there a way to use a similar approach–but presenting the SMART app directly to the patient instead... e.g., from a patient portal?

Connectathon Sandbox

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

Note: Though not being tested in this Connectathon, the sandbox is also capable of performing these roles:

• SMART App that can be Launched from an EHR – prompted by Specialty Rx Task
• Messaging-based Requester
• Messaging-based EHR
• Messaging-to-REST Intermediary.

See instructions here: https://confluence.hl7.org/display/FHIR/2021-01+Specialty+Medication+Enrollment

Sandbox usage:

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 to simulate the consent-request Task workflow...

• Use the sandbox UI to create and submit a consent-request Task to the sandbox EHR, which creates a work queue item for the task, enables the consent form to be downloaded and status to be updated

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

Consent Process Simulator

URL: https://specialty-consent.azurewebsites.net/

This app shows the process from the view of the requester

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