Page tree
Skip to end of metadata
Go to start of metadata

This page will be used to describe the Da Vinci reference implementation for the Payer Data Exchange use case. The goal of this reference implementation is to demonstrate the FHIR interactions defined in the implementation guide. The reference implementation is not intended to reproduce all the functionalities of an EHR. 

Roles:

Tony Benson and Mark Scrimshire  - Use Case Leads

Mark Scrimshire  - IG Author

HealthLX (Will Tesch and Charlie Provenzano ) - RI developers

Viet Nguyen - Technical Director

HSPC Sandbox - Hosting environment -  sandbox.hspconsortium.org

HealthLX SMART/CDS-Hooks Reference Implementation Code: https://github.com/HL7-DaVinci/PDex-Patient-Import-App

HealthLX OAuth2.0 Payer-Payer Reference Implementation Code: TBD 

MITRE Formulary Reference Implementation Code: TBD

MITRE Directory Reference Implementation Code: TBD


During the Connectathon the Zulim Channel we will use is: https://chat.fhir.org/#narrow/stream/179283-DaVinci/topic/Payer.20Data.20Exchange.20(PDEx)

Milestones:

Montreal HL7 Connectathon - 2019-05 Da Vinci - Payer Data Exchange (PDex) Track

Jacksonville, FL Da Vinci Connectathon

DevDays?

PDex IG Balloting

Assumptions

Resources will be built using FHIR R4.

The Target EMR will be supporting FHIR DSTU2 (Argonaut)

CDS-Hooks Appointment-Book Service MUST be able to read EMR Patient Resource in DSTU2, STU3 or R4 format using Argonaut or US Core Profiles as appropriate

SMART-on-FHIR App SHALL NOT convert resources between FHIR versions


Scenario 1 – provider sees a new patient

Actors

Patient:

Lauren Dent is a 62-year-old female, living in Wisconsin but she spends winters in Tampa Bay, FL.

Lauren works on a seasonal basis and has just accepted a new position with her employer and has moved to Madison, WI to live with her daughter, leaving her previous home in La Crosse, WI. As a result of the move she has selected a new Primary Care Provider.

Lauren is in reasonable health but is managing a number of conditions:
* She has been diagnosed as Pre-Diabetic and is being treated with medications.
* She is taking medication for hypertension.
* She had a knee replacement 5 years ago.
* She had a procedure seven years ago to correct a problem with a disc in her lower back.
* A history of a normal colonoscopy 5 years earlier
* A history of a pneumovax and zostavax 4 years earlier.

Payer A:

Physician:

Dr. Jillian is an internist


In this scenario, Lauren has moved into the community and wishes to establish care with Dr. Jillian.the goal of the scenarios to describe the process by which Dr. Jillian receives available clinical data from Lauren's insurer


Assumptions

  1. Payer-provider interactions are covered in TPO 

Preconditions

  1. Patient has preregistered in EHR and provided their payer information and subscriberID
  2. Payer end-point is registered with the EHR
  3. CDS Hook for the payer is registered in the EMR

Out-of-Scope

  1. Directory Services

User Experience

Patient arranges a first visit with the Provider and provides basic demographic information and health plan coverage information. 

The Provider creates a Patient Record, records Health Plan Coverage information that is relevant to the planned visit and creates an Encounter recorded an appointment booking.

Appointment-book

If EMR connection is secure a valid FHIR Authorization object will be supplied as part of the CDS Hooks payload

UserId = Practitioner.Id

PatientId = Patient.id in Provider system

encounterId = Id of Encounter

appointments = Array of appointment bookings

subscriberId (optional) = Member Id in Health Plan System

Appointment-Book
{
  "hookInstance": "d1577c69-dfbe-44ad-ba6d-3e05e953b2ea",
  "fhirServer": "http://fhir.example.com",
  "fhirAuthorization" : {
       "access_token" : "some-opaque-fhir-access-token",
       "token_type" : "Bearer",
       "expires_in" : 300,
       "scope" : "patient/Patient.read patient/Observation.read",
       "subject" : "cds-service4"
     },
  "hook": "appointment-book",
  "user": "Practitioner/example",
  "context": {
    "userId" : "Practitioner/A12365498",
    "patientId" : "EMR1239876",
    "encounterId" : "654",
    "appointments" : {
      "resourceType":"Bundle",
      "entry":[{
          "resource":{
            "resourceType": "Appointment", ...}}]
     },
    "subscriberId" : "HP567123489",
		}
  }

Manual Call to Launch CDS Hooks

A SMART-on-FHIR app that is registered with the Provider's EMR will be launched to collect the data needed for the CDS-Hooks call. This app could be a Patient on-boarding app.

The app:

  • Collects the Patient record
  • Collects the Encounter record Id
  • Collects any appointment bookings
  • Optionally gets the Subscriber Id from the patient's health plan coverage card
  • Calls the "appointment-book" CDS Hook at the Health Plan providing coverage to the patient.

 Payer CDS Hook actions

If SubscriberId is provided it is used to match the Patient in the Health Plan's system.

If a SubscriberId is not provided the Patient record is fetched from the Provider system. The Demographic data is used to search for a matching patient.

The returned result from these matching steps use appropriate HTML status Codes:

  1. Subscriber Found (200 OK)
  2. Subscriber Not Found (404 Not Found)
  3. Subscriber Not Unique (422 Unprocessable Entity)

If a unique match is found on SubscriberId, or via Patient Demographic search the Hooks Service will create an CDS Hooks information Card to return.

The content of the Card MAY Include:

  • Result of the Subscriber Search in human readable form.
  • Result code for the search result.
  • An Access Token to allow a SMART-on-FHIR App to access the member records via the payer's FHIR API.
  • The URL for the Payer's FHIR API.
  • A Link to a SMART-on-FHIR App that can access the payer's FHIR API and present information about the Subscriber and enable the Provider to select records they want to commit to their EMR system. 

SMART-on-FHIR App

The SMART-on-FHIR app MAY provide default configuration information that can be modified by the provider or their organization to set default search values into the Payer's FHIR API. For example, the Provider MAY create search commands as follows (These are shown as suggestions. A Provider or Organization may provide one or more search queries to get Payer FHIR data for any profiles defined in US Core, Da Vinci HRex or Da Vinci PDex IGs:

  • Search Encounters for Patient id matching Subscriber where META data for date updated or created is within last 12 months and organization does not equal Payer's ID for Provider's organization.
  • Search Procedures for all records for Patient id matching Subscriber.
  • Search MedicationDispense for all records for Patient id matching Subscriber and META date updated or created is within last 6 months.

The SMART App **MAY** save a set of default FHIR Queries that use standard FHIR Query Parameters. Examples are shown in the table below:

Search ExampleFHIR Search Query
Patient RecordPatient?_id=[Health_Plan_Member_ID]
Encounters for Patient updated since a January 1, 2019 and excluding my locationEncounter?subject=Patient/[Health_Plan_Member_ID]&_lastUpdated=gt[TODAY-365]&location=ne[Health_Plan_Location_ID]
MedicationDispense for Patient created/updated in the last 3 monthsMedicationDispense?subject=Patient/[Health_Plan_Member_ID]&_lastUpdated=gt[TODAY-90]

The SMART App **SHOULD** support the following replaceable parameters. These parameters **SHALL** be replaced at run time with the appropriate contextual values:

Replaceable ParameterPurpose
[Health_Plan_Member_ID]The FHIR ID of the Member from the Patient Resource in the Payers system

[Patient_ID]

The FHIR ID of the Patient from the Provider's EMR System
[Health_Plan_Practitioner_ID]The Practitioner ID in the Health Plan's system
[Practitioner_ID]The Practitioner ID in the Provider's EMR System
[Health_Plan_Organization_ID]The Organization ID in the Health Plan's system
[Organization_ID]The Organization ID in the Provider's EMR System
[Health_Plan_Location_ID]The Location ID in the Health Plan's system
[Location_ID]The Location ID in the Provider's EMR System
[TODAY]

Today's Date

[TODAY-NNN]A Calculated Date derived from Today's Date adjusted by a number of Days 


the SMART-on-FHIR app SHOULD provide a method for a Provider to select one or more records that they wish to commit to their EMR system.

The SMART-on-FHIR app:

  • SHOULD receive an access token to enable data to be written to the provider's EMR system.
  • SHOULD retrieve the EMR's meta/capabilityStatement/ConformanceStatement to determine the version of FHIR and the resources that are writeable.
  • IF the EMR System is not using FHIR R4 the App SHOULD determine if a DocumentReference resource is writeable for the Patient
  • IF the EMR System is using FHIR R4 the App SHOULD determine which of the EMRs resources are writeable and IF the provider has selected Payer records that are writeable commit them to the EMR system. Any remaining selected records, where write operations are not permitted by the EMR system’s FHIR API SHOULD take one of the actions identified in the "DocumentReference write" section,  below.
  • If the Provider’s EMR system does not support FHIR R4 the SMART App SHOULD create a DocumentReference record and write the selected records to the Provider’s EMR System using one of the actions identified in the "DocumentReference write" section,  below.

DocumentReference Write

The format used to write information to a DocumentReference resource in the Provider’s EMR System SHOULD be written in order of descending preference identified below:

  1. Place the remaining selected records in a FHIR bundle and create a Human Readable PDF of those selected records and write both items to a DocumentReference record for the Patient.
  2. Convert the remaining records to an XHTML document and write to a DocumentReference record for the Patient.
  3. Convert the remaining records to an ASCII text document and write to a DocumentReference record for the Patient.

Provenance

Where Provenance resources are provided by the Payer FHIR API that identifies the source of the information and any transformations performed, these Provenance records should also be committed to the EMR, either directly or as part of the DocumentReference resource that is written.

The Provenance record will be populated as follows:

FieldValue
occurredPeriod or occurredDataTimedateTime or Period of the encounter/procedure/medication being provided
recordedTime of this transaction
agent.[0].typeAMENDER (for conversion of claims data to clinical resources) | TRANS (for information taken from manual input)| REVIEWER (for clinical resources)
agent.[0].roleinformant | custodian
agent.[0].whoOrganization resource identifying the health plan
agent.[1].typeSOURCE
agent.[1].roleenterer | performer | author
agent.[1].whoOrganization | Practitioner or other resource identifying the entity providing the source information


Test Functionality

For Testing purposes only: There is a need to test in the HSPC Sandbox (https://sandbox.hspconsortium.org/) a scenario where the receiving EMR is unable to write resources that have been selected by the provider. This will have to be simulated because all sandbox environments support the same sets of resources. The simulation of a restricted set of writeable resources can be accomplished as follows:

  • SMART App **SHALL** read in EMR CapabilityStatement
  • SMART App **MAY** reference an array of FHIR Resource Names that are to be Removed from the Capability Statement.


CapabilityExclusion
{"ResourceExclusion" : ["Patient", "Procedure"],
}

The above elements can also be passed in to the SMART App via a comma-separated environment variable. e.g.

launchsmartapp.sh -ResourceExclusion="Patient,Procedure, ..."

  • SMART App **MAY** iterate over the CapabilityStatement/ConformanceStatement to remove the resources that need to be excluded for testing purposes. THIS FEATURE WOULD NOT BE USED IN PRODUCTION.
  • SMART APP **MAY** display the resources that are writeable in the EMR.


Functionality

  • Patient Matching
  • Data request filter
  • Provider selection of data
  • Reconciliation - probably not for this scenario since they are new to the provider

FHIR Interactions

Security Considerations

  • OAuth2

Data

  • FHIR Resources
    • Encounter
    • Procedures
    • Medications
  • Filter/retrieval criteria - "give me data for the last x months/years"

NOTE: In the diagram above the SMART-on-FHIR Apps identified as steps 1 and 5 MAY be combined into a single App.

Common Elements to Scenarios 2 - 4


Scenario 2 - Member-Mediated Payer-to-Payer Exchange

Actors:

Patient

Arthur Dent is a 68 year old Male. He has recently switched from Medicare Advantage Plan A and enrolled in Medicare Advantage Plan C.

In this scenario, Arthur has signed up for a new  Medicare advantage plan with payer C during the open enrollment period. Before the initiation of his coverage beginning January 1, payer C has established communication with the patient and has provided the patient with a secure log in to the payer C patient portal. Patient continues to have an active login to payer A patient portal.

Medicare Advantage Plan A

A Medicare Advantage plan that has ceased to be Arthur Dent's health plan

Medicare Advantage Plan C

A Medicare Advantage plan that has enrolled Arthur in their plan to replace the services he received from Plan A.


Assumptions:

  • Plan C has registered their App or Portal with Plan A
  • Plan C has an OAuth2.0 scope that enables it to receive up to five years of health history for the ex-member of Plan A


User Experience

Arthur has successfully enrolled in Plan C and signed in to the Patient Portal or App provided by Plan C.

Arthur sees a link to retrieve his health/claim history from Plan A.

He clicks on the link 

The link takes Arthur to Plan A's API. He is asked to login with the userid and password  he used to access his old plan.

After a successful login an Authorization screen is presented to Arthur. 

The Authorization enables Arthur to:

  • Include or exclude Behavioral Health information from the data release
  • Authorize the sharing of information to Plan C.

After successfully being Authorized Plan C receives an Access Token that can be used to request information from Plan A.


Plan C uses the Access Token to query Plan A's FHIR API  for the Subscriber's health history, as provided in USCDI/US Core + Da Vinci HRex profiled resources. These are the same resources used in the Scenario 1 exchange.

This approach parallels current BlueButton 2.0 approach (https://sandbox.bluebutton.cms.gov/)

This same approach will be used for Member-authorized sharing of information with Third-Party applications. 

Each application, whether from a Health Plan or a Third Party Application Development Organization will be registered with the Health Plan that is the data holder for the subscriber. Access to the FHIR API will be via an OAuth2.0 secured endpoint that requires each application to be issued with a unique Client ID and Client Secret.

The OAuth2.0 protocol will, when a member authorizes sharing, issue a unique token that matches the member with a specific Application Client ID.

Technical Considerations

The reference implementation will be vendor neutral with respect to the EHR and payer systems. The functionality of either endpoint is informed by, but not limited by, current real-world implementations of EHR functionality.

Endpoints/FHIR Sandboxes - Hosted by HSPC

  • EHR
  • Payer 

FHIR Version - STU4

  • US-Core resources STU3 based on FHIR R4
  • DSTU2/Argonaut conversion to R4 is labor intensive
  • PDex will use a superset of resources that combines US Core and Da Vinci HRex Profiles.

Additional profiles

  • Use US-Core STU3 as base
  • Create a slice on US-Core Patient profile to support subscriberID as a patient.identifier
    • CDS Hooks doesn't support Coverage for pre-fetch. Therefore, we need to provide the payer with a subscriberID in another way. We could do this by adding the subscriber ID as one of the patient.identifier slice on US-Core. With an R4 implementation, we would use Coverage to link patient with their subscriberID. Awaiting whether US-Core will adopt a Coverage resource.
    • Therefore, system looks for subscriber ID in order:
      •  Coverage.subscriberid
      •  Patient.identifer
    • Subscriber ID along with other demographic data is important for patient matching in payer systems.


CDS Hooks Question - Given the many services registered for a given hook, how does the EHR know which service(s) to initiate. We would need to link the patient-payer relationship to trigger a specific service to the specific payer, instead of all.

This is an important consideration. Sending patient information to multiple payers represents a potential PHI leakage issue.

A potential solution is a Smart-on-FHIR app for appointment booking that collects the Coverage information (subscriber.id and health plan identifier) and uses this to select a specific registered CDS-hooks service and thereby send information only to health plans identified as being involved in providing coverage for the patient for the appointment being booked. 

Test Scripts will need to be developed as well by Richard Ettema

Scenario 3 - Member-Mediated Payer-to-Third Party Directory Access (Healthcare and Pharmacy)

Actors:

Patient

Arthur Dent is a 68 year old Male. He has recently switched from Medicare Advantage Plan A and enrolled in Medicare Advantage Plan B.

In this scenario, Arthur has signed up for a new  Medicare advantage plan with payer C during the open enrollment period. Before the initiation of his coverage beginning January 1, payer C has established communication with the patient and has provided the patient with a secure log in to the payer C patient portal. Patient continues to have an active login to payer B patient portal.

Payer

The Payer will support:

  • Member authentication (using portal credentials via OpenID Connect protocol)
  • HL7 FHIR R4 API using derivative of Validated Healthcare Directory IG resources 
  • Standalone SMART-on-FHIR Application Launch and Authorization
  • FHIR Scopes to enable access to FHIR Resources


Third Party Application (TPA)

TPA will support:

  • SMART-on-FHIR Standalone Application Launch Framework
  • OAuth 2.0 protocol for Access Token Exchange
  • FHIR Scopes and FHIR Capability Statement
  • Access to HL7 FHIR R4 API for access to Directory Resources
  • Member Queries against the Directory API


User Experience:

  • Member will launch SMART-on-FHIR App / Web Site.
  • Member will authorize the app to share data from their payer.
  • App will retrieve data from Payer FHIR API
  • Member will search Directory for Healthcare services
    • Search for providers in a specific specialty
    • Search for providers in a location/area
  • Member will search Directory for Pharmacies
  • App will display results of the search


Assumptions:

  • Mitre is building in Ruby on Rails


Scenario 4 - Member-Mediated Payer-to-Third Party Drug Formulary Access

Actors:

Patient

Arthur Dent is a 68 year old Male. He has recently switched from Medicare Advantage Plan A and enrolled in Medicare Advantage Plan B.

In this scenario, Arthur has signed up for a new  Medicare advantage plan with payer C during the open enrollment period. Before the initiation of his coverage beginning January 1, payer C has established communication with the patient and has provided the patient with a secure log in to the payer C patient portal. Patient continues to have an active login to payer B patient portal.

Payer

The Payer will support:

  • Member authentication (using portal credentials via OpenID Connect protocol)
  • HL7 FHIR R4 API using derivative of PDex Formulary IG resources 
  • Standalone SMART-on-FHIR Application Launch and Authorization
  • FHIR Scopes to enable access to FHIR Resources


Third Party Application (TPA)

TPA will support:

  • SMART-on-FHIR Standalone Application Launch Framework
  • OAuth 2.0 protocol for Access Token Exchange
  • FHIR Scopes and FHIR Capability Statement
  • Access to HL7 FHIR R4 API for access to Formulary Resources
  • Member Queries against the Formulary API


User Experience:

  • Member will launch SMART-on-FHIR App / Web Site.
  • Member will authorize the app to share data from their payer.
  • App will retrieve data from Payer FHIR API
  • Member will search Formulary for one or more specific drugs
  • App will display results of the search
  • Member will Browse Formulary by Drug Tier
  • Member will Browse Formulary by Alphabetical List

Scenario 5 - Payer-to-Payer Exchange under Business, Treatment and Operations

Methods for Scenario 5 follow the flow in Scenario 2 ( Member-Mediated Payer-to-Payer Exchange ) but are originated by Medicare Advantage Plan C without requiring Member authorization. ie. This scenario is a Plan to Plan Oauth2.0 exchange.

Actors:

Patient

Arthur Dent is a 68 year old Male. He has recently switched from Medicare Advantage Plan A and enrolled in Medicare Advantage Plan C.

In this scenario, Arthur has signed up for a new  Medicare advantage plan with payer C during the open enrollment period. Before the initiation of his coverage beginning January 1, payer C has established communication with the patient and has provided the patient with a secure log in to the payer C patient portal. Patient continues to have an active login to payer A patient portal.

Medicare Advantage Plan A

A Medicare Advantage plan that has ceased to be Arthur Dent's health plan

Medicare Advantage Plan C

A Medicare Advantage plan that has enrolled Arthur in their plan to replace the services he received from Plan A.


Assumptions:

  • Plan C has registered their App or Portal with Plan A
  • Plan C has an OAuth2.0 scope that enables it to receive up to five years of health history for the ex-member of Plan A

User Experience

Arthur has successfully enrolled in Plan C and has provided his prior coverage information for Plan A.

Plan C uses Arthur's prior coverage information to identify Plan A.

Plan C connect to Plan A's API. 

Plan C queries Plan A for the member's information.

Plan C retrieves Arthur's health information from Plan A via the FHIR API using the Patient/$Everything operation.

  • excluding Behavioral Health information from the data release


Plan C uses a valid Access Token to query Plan A's FHIR API  for the Ex-member's health history, as provided in USCDI/US Core + Da Vinci HRex profiled resources. These are the same resources used in the Scenario 1 exchange.

This approach parallels current BlueButton 2.0 approach (https://sandbox.bluebutton.cms.gov/) using OAuth2.0 to authorize the exchange but without requiring Member-authorization.


Each application, whether from a Health Plan or a Third Party Application Development Organization will be registered with the Health Plan that is the data holder for the subscriber/member. Access to the FHIR API will be via an OAuth2.0 secured endpoint that requires each application to be issued with a unique Client ID and Client Secret.

The OAuth2.0 protocol will  issue a unique token that enables Plan C to request information for their new member that is tied to their specific Application Client ID.

Technical Considerations

The reference implementation will be vendor neutral with respect to the payer systems. The functionality of either endpoint is informed by, but not limited by, current real-world implementations of FHIR functionality.

Endpoints/FHIR Sandboxes - Hosted by HSPC

  • EHR
  • Payer 

FHIR Version - STU4

  • US-Core resources STU3 based on FHIR R4
  • PDex will use a superset of resources that combines US Core and Da Vinci HRex Profiles.
  • Subscriber ID along with other demographic data is important for patient matching in payer systems.

Test Scripts will need to be developed as well by Richard Ettema



  • No labels