Difference between revisions of "Da Vinci PDex FHIR IG Proposal"
(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== | ||
− | |||
− | |||
− | |||
− | |||
− | |||
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
Contents
- 1 Owning work group name
- 2 Committee Approval Date:
- 3 Contributing or Reviewing Work Groups
- 4 FHIR Development Project Insight ID
- 5 Scope of coverage
- 6 IG Purpose
- 7 Content location
- 8 Proposed IG realm and code
- 9 Maintenance Plan
- 10 Short Description
- 11 Long Description
- 12 Involved parties
- 13 Expected implementations
- 14 Content sources
- 15 Example Scenarios
- 16 IG Relationships
- 17 Timelines
- 18 When IG Proposal Is Complete
- 19 FMG Notes
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