This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Da Vinci PDex FHIR IG Proposal"

From HL7Wiki
Jump to navigation Jump to search
 
(5 intermediate revisions by the same user not shown)
Line 47: Line 47:
  
  
This project will define exchange methods (push, pull, triggers, subscription), use of other interoperability "standards" (e.g. CDS Hooks and SMART on FHIR) and specific use of FHIR resources to effectively exchange payer information regarding the current or previous care, including the provenance of the data, of one or more specific patients/members with a provider responsible for evaluating/specifying/ordering/delivering care for the patient.
+
This project will define exchange methods (push, pull, triggers, subscription), use of other interoperability "standards" (e.g. CDS Hooks and SMART on FHIR) and specific use of FHIR resources to effectively exchange payer information regarding the current or previous care, including the provenance of the data, of one or more specific patients/members with a provider responsible for evaluating/specifying/ordering/delivering care for the patient. The project will also define the exchange methods and interoperability "standards" and specific use of FHIR resources to support Health Plan member-authorized Health Plan to Health Plan exchange of member health history and API access for healthcare directory, pharmacy directory and drug formulary information for members and third-party applications authorized by the member.
  
 
==IG Purpose==
 
==IG Purpose==
  
 
Providers need access to payer information regarding current and prior healthcare services received by the patient/member to more effectively manage the patients care. Currently, no FHIR implementation guide exists to standardize the method of exchange (push, pull, triggers, subscription, etc.) or the formal representation (e.g. Bundles, Profiles and Vocabulary) for specific elements of payer information of interest to providers. This implementation guide will provide a standard for adoption by both payers and providers for the exchange of payer information.
 
Providers need access to payer information regarding current and prior healthcare services received by the patient/member to more effectively manage the patients care. Currently, no FHIR implementation guide exists to standardize the method of exchange (push, pull, triggers, subscription, etc.) or the formal representation (e.g. Bundles, Profiles and Vocabulary) for specific elements of payer information of interest to providers. This implementation guide will provide a standard for adoption by both payers and providers for the exchange of payer information.
 +
 +
The CMS Interoperability Notice for Proposed Rule Making, issued on February 11th, 2019 laid down a series of requirements for which there is no current FHIR implementation guide. The PDex FHIR IG will therefore be expanded to provide standardized methods to support:
 +
 +
1. Member-authorized payer-to-payer exchange of member health history
 +
2. Member-authorized sharing via API of the health plan's Healthcare provider/services network directory
 +
3. Member-authorized sharing via API of the health plan's Pharmacy network directory
 +
4. Member-authorized sharing via API of the health plan's Prescription drug formulary
 +
 +
Member-authorized sharing can be to the Member or Third-Party Applications they have approved.
  
 
==Content location==
 
==Content location==
Line 69: Line 78:
 
==Short Description==
 
==Short Description==
  
Payer data exchange with providers to support care coordination.
+
Payer data exchange with providers to support care coordination. Member-authorized sharing to Third-Party applications of Health Plan's Healthcare Service Network, Pharmacy Network and Prescription Drug Formulary.
  
 
==Long Description==
 
==Long Description==
  
 
<!-- 1 paragraph describing the purpose/scope of the IG in more detail for inclusion in the version history -->
 
<!-- 1 paragraph describing the purpose/scope of the IG in more detail for inclusion in the version history -->
 +
 +
The PDex FHIR IG will support two scenarios:
 +
 +
1. Provider-Payer Exchange of Member History
  
 
Initial use cases are focused on a patient seeing a provider (e.g. PCP) for the first time (relevant payer history) , a repeat visit for the same patient with the same provider (what happened since the last visit that occurred outside of my institution / HIE / ...), and a visit of a patient with specialist (+care team information) . Each of these use cases focuses on a subset of the total payer record for the patient that may be appropriate for the specific setting. Specific guidance will be given for query capability and subsequent filtering of results prior to incorporation of the information into the provider' patient record. The project is focused on identifying patterns of exchange (interaction and content) that are appropriate for establishing implementation guidance to ensure standardization in the request and response across providers and payers.
 
Initial use cases are focused on a patient seeing a provider (e.g. PCP) for the first time (relevant payer history) , a repeat visit for the same patient with the same provider (what happened since the last visit that occurred outside of my institution / HIE / ...), and a visit of a patient with specialist (+care team information) . Each of these use cases focuses on a subset of the total payer record for the patient that may be appropriate for the specific setting. Specific guidance will be given for query capability and subsequent filtering of results prior to incorporation of the information into the provider' patient record. The project is focused on identifying patterns of exchange (interaction and content) that are appropriate for establishing implementation guidance to ensure standardization in the request and response across providers and payers.
 +
 +
2. Secure Member-authorized Exchange of information between Payers and to Third-Party Applications
 +
 +
These use cases will use OAuth2.0 and FHIR APIs for information sharing
 +
 +
There are four use cases:
 +
1. Member-authorized sharing of health history between old Health Plan and new Health Plan.
 +
2. Member-authorized sharing of health history to a Third-Party applications,
 +
3. Member-authorized sharing via API of a Health Plan's Healthcare Network Directory.
 +
4. Member-authorized sharing via API of a Health Plan's Pharmacy Network Directory.
 +
5. Member-authorized sharing via API of a Health Plan's Prescription Drug Formulary.
  
 
==Involved parties==
 
==Involved parties==
Line 91: Line 115:
  
 
<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this IG.  They should demonstrate the full scope of the IG and allow exercising of the IG's capabilities (all profiles, different types of applications, etc.) -->
 
<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this IG.  They should demonstrate the full scope of the IG and allow exercising of the IG's capabilities (all profiles, different types of applications, etc.) -->
 +
 +
1. Exchange of Member Health History from a Payer to a Provider. The exchange will be triggered via a CDS Hook. The resulting card MAY enable a SMART-on-FHIR app to be launched that queries the Payer's FHIR API to enable a Provider to select the elements of the member's health history that will be committed to the provider's EMR system via a write-enabled FHIR API.
 +
 +
2. An Authenticated Member at their old Health Plan will be able to use an OAuth2.0 authorization to permit their New Health Plan to access the old Health Plan's FHIR API to access the member's health history using a superset of US Core and Da Vinci Health Record Exchange (HRex) Profiles.
 +
 +
3. An Authenticated Member at a Health Plan will be able to use an OAuth2.0 authorization to permit a Third-Party Application to access the Health Plan's FHIR API to read the Plan's Healthcare Network Directory.
 +
 +
4. An Authenticated Member at a Health Plan will be able to use an OAuth2.0 authorization to permit a Third-Party Application to access the Health Plan's FHIR API to read the Plan's Pharmacy Network Directory.
 +
 +
5. An Authenticated Member at a Health Plan will be able to use an OAuth2.0 authorization to permit a Third-Party Application to access the Health Plan's FHIR API to read the Plan's Prescription Drug Formulary.
  
 
==IG Relationships==
 
==IG Relationships==
Line 97: Line 131:
  
 
==Timelines==
 
==Timelines==
 
 
Ballot for Comment (First Ballot Cycle)
 
 
2019 May Ballot
 
 
   
 
   
  
 
Submit for STU Ballot (Second Ballot Cycle)
 
Submit for STU Ballot (Second Ballot Cycle)
 
   
 
   
2019 Sep Ballot
+
2019 Sep Early Ballot
  
 
==When IG Proposal Is Complete==
 
==When IG Proposal Is Complete==

Latest revision as of 15:41, 23 April 2019



Da Vinci Payer Data exchange (PDex) Implementation Guide


Owning work group name

Financial Management

Committee Approval Date:

2019-02-19

Contributing or Reviewing Work Groups

Attachments

FHIR Development Project Insight ID

Scope of coverage

This project will define exchange methods (push, pull, triggers, subscription), use of other interoperability "standards" (e.g. CDS Hooks and SMART on FHIR) and specific use of FHIR resources to effectively exchange payer information regarding the current or previous care, including the provenance of the data, of one or more specific patients/members with a provider responsible for evaluating/specifying/ordering/delivering care for the patient. The project will also define the exchange methods and interoperability "standards" and specific use of FHIR resources to support Health Plan member-authorized Health Plan to Health Plan exchange of member health history and API access for healthcare directory, pharmacy directory and drug formulary information for members and third-party applications authorized by the member.

IG Purpose

Providers need access to payer information regarding current and prior healthcare services received by the patient/member to more effectively manage the patients care. Currently, no FHIR implementation guide exists to standardize the method of exchange (push, pull, triggers, subscription, etc.) or the formal representation (e.g. Bundles, Profiles and Vocabulary) for specific elements of payer information of interest to providers. This implementation guide will provide a standard for adoption by both payers and providers for the exchange of payer information.

The CMS Interoperability Notice for Proposed Rule Making, issued on February 11th, 2019 laid down a series of requirements for which there is no current FHIR implementation guide. The PDex FHIR IG will therefore be expanded to provide standardized methods to support:

1. Member-authorized payer-to-payer exchange of member health history 2. Member-authorized sharing via API of the health plan's Healthcare provider/services network directory 3. Member-authorized sharing via API of the health plan's Pharmacy network directory 4. Member-authorized sharing via API of the health plan's Prescription drug formulary

Member-authorized sharing can be to the Member or Third-Party Applications they have approved.

Content location

https://github.com/HL7/davinci-epdx

Proposed IG realm and code

US/Davinci-PDex

Maintenance Plan

The Da Vinci project intends to provide ongoing support of this implementation guide

Short Description

Payer data exchange with providers to support care coordination. Member-authorized sharing to Third-Party applications of Health Plan's Healthcare Service Network, Pharmacy Network and Prescription Drug Formulary.

Long Description

The PDex FHIR IG will support two scenarios:

1. Provider-Payer Exchange of Member History

Initial use cases are focused on a patient seeing a provider (e.g. PCP) for the first time (relevant payer history) , a repeat visit for the same patient with the same provider (what happened since the last visit that occurred outside of my institution / HIE / ...), and a visit of a patient with specialist (+care team information) . Each of these use cases focuses on a subset of the total payer record for the patient that may be appropriate for the specific setting. Specific guidance will be given for query capability and subsequent filtering of results prior to incorporation of the information into the provider' patient record. The project is focused on identifying patterns of exchange (interaction and content) that are appropriate for establishing implementation guidance to ensure standardization in the request and response across providers and payers.

2. Secure Member-authorized Exchange of information between Payers and to Third-Party Applications

These use cases will use OAuth2.0 and FHIR APIs for information sharing

There are four use cases: 1. Member-authorized sharing of health history between old Health Plan and new Health Plan. 2. Member-authorized sharing of health history to a Third-Party applications, 3. Member-authorized sharing via API of a Health Plan's Healthcare Network Directory. 4. Member-authorized sharing via API of a Health Plan's Pharmacy Network Directory. 5. Member-authorized sharing via API of a Health Plan's Prescription Drug Formulary.

Involved parties

This implementation guide has been developed by U.S. EHR and Payer organizations as part of the Da Vinci project.

Expected implementations

Content sources

Requirements are drawn from payer and provider organizations as part of the Da Vinci initiative.

Example Scenarios

1. Exchange of Member Health History from a Payer to a Provider. The exchange will be triggered via a CDS Hook. The resulting card MAY enable a SMART-on-FHIR app to be launched that queries the Payer's FHIR API to enable a Provider to select the elements of the member's health history that will be committed to the provider's EMR system via a write-enabled FHIR API.

2. An Authenticated Member at their old Health Plan will be able to use an OAuth2.0 authorization to permit their New Health Plan to access the old Health Plan's FHIR API to access the member's health history using a superset of US Core and Da Vinci Health Record Exchange (HRex) Profiles.

3. An Authenticated Member at a Health Plan will be able to use an OAuth2.0 authorization to permit a Third-Party Application to access the Health Plan's FHIR API to read the Plan's Healthcare Network Directory.

4. An Authenticated Member at a Health Plan will be able to use an OAuth2.0 authorization to permit a Third-Party Application to access the Health Plan's FHIR API to read the Plan's Pharmacy Network Directory.

5. An Authenticated Member at a Health Plan will be able to use an OAuth2.0 authorization to permit a Third-Party Application to access the Health Plan's FHIR API to read the Plan's Prescription Drug Formulary.

IG Relationships

This project will reference, where possible the "standards" defined by the Health Record exchange (HRex) Framework Implementation Guide which in turn will utilize prior work from Argonaut, US Core and QI Core effort for FHIR DSTU2, STU3, and R4.

Timelines

Submit for STU Ballot (Second Ballot Cycle)

2019 Sep Early Ballot

When IG Proposal Is Complete

When you have completed your proposal, please send an email to FMGcontact@HL7.org

FMG Notes