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
 
(22 intermediate revisions by 3 users not shown)
Line 3: Line 3:
 
<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div>
 
<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div>
 
<div style="background:#F0F0F0">
 
<div style="background:#F0F0F0">
This page documents a [[:category:Pending FHIR IG Proposal|Pending]] [[:category:FHIR IG Proposal|FHIR IG Proposal]]
+
This page documents a [[:category:Approved FHIR IG Proposal|Approved]] [[:category:FHIR IG Proposal|FHIR IG Proposal]]
 
</div>
 
</div>
 
</div>
 
</div>
 
[[Category:FHIR IG Proposal]]
 
[[Category:FHIR IG Proposal]]
[[Category:Pending FHIR IG Proposal]]
+
[[Category:Approved FHIR IG Proposal]]
  
  
Line 32: Line 32:
  
 
==Committee Approval Date:==
 
==Committee Approval Date:==
<i>Please enter the date that the committee approved this IGproposal</i>
+
<I></i>
  
 +
2019-02-19
 
==Contributing or Reviewing Work Groups==
 
==Contributing or Reviewing Work Groups==
  
Line 46: 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==
  
<!-- What is the path within the HL7 github repository (i.e. https://github.com/HL7/xxx) or what is the Simplifier project name? -->
+
https://github.com/HL7/davinci-epdx
  
 
==Proposed IG realm and code==
 
==Proposed IG realm and code==
Line 68: Line 78:
 
==Short Description==
 
==Short Description==
  
<!-- 1-2 sentences describing the purpose/scope of the IG for inclusion in the registry -->
+
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==
  
<!-- 1 paragraph describing who is sponsoring or involved in creating the IG for inclusion in the version history -->
+
This implementation guide has been developed by U.S. EHR and Payer organizations as part of the Da Vinci project.
 
 
  
 
==Expected implementations==
 
==Expected implementations==
Line 87: Line 110:
  
 
==Content sources==
 
==Content sources==
 +
Requirements are drawn from payer and provider organizations as part of the Da Vinci initiative.
 +
 +
==Example Scenarios==
 +
 +
<!-- 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.
  
<!-- List all of the specifications (beyond those in the "standard" (FHIR_Design_Requirements_Sources) list of source specifications) that you’re planning to consult
+
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.
  
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. The following diagram depicts the anticipated scope of the HRex Framework IG.
+
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.
  
==Example Scenarios==
+
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.
  
<!-- 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.) -->
+
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==
  
<!-- Are there any IGs this resource depends on or that depend on this IG? -->
+
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==
 
==Timelines==
 +
  
<!-- Indicate the target date for having the IGcomplete from a committee perspective and ready for vetting and voting -->
+
Submit for STU Ballot (Second Ballot Cycle)
 +
 +
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