| Submitted By: Robert C Dieterle / On behalf of the Da Vinci Project | |
|---|---|
| Data Element Information | |
| Use Case Description(s) | |
| Use Case Description | When payers exchange information received from providers with members, providers, and other payers, there is a need to indicate the source format of the information as it was received. This sets the expectation for the entity receiving the information as to the structure of the contributing information (e.g. claims vs HL7 V2 laboratory transaction) and the scope of the content. Specific examples of scope include: 1) a lab observation derived from a claim Source that will not include a specific result, units or specimen type, 2) the same lab observation derived from a C-CDA Source may include the result and units, but not the specimen type, and 3) a lab observation derived from an hL7 V2 laboratory report transaction (ORU-R01) Source will include all of the information (assuming the specimen was drawn, suitable, and the test was performed). |
| Estimate the breadth of applicability of the use case(s) for this data element | Level 2 – this pertains to all payers covered by the CMS Interoperability Final Rule (approximately 300 of the largest payers in the country), all covered members (approximately 125 Million) and all providers that may wish to receive payer information regarding their shared patients (all 7,000 Hospitals and over 1,000,000 individual providers) |
| Use Case Description | By enabling the exchange of provenance with information that is made available by payers to providers, it will improve the reliable use of this information to reduce the need for unnecessary testing, duplicate therapy and improve significantly the ability to treat a patient by understanding a fuller representation of the patients current condition and previous interaction with other providers. |
| Estimate the breadth of applicability of the use case(s) for this data element | Potentially, all payers and providers will capture, access, use, or exchange this data element along with information for their shared patients. We are seeing use of this type of information by providers that treat Medicare FFS patients via the Data at Point of Care program that CMS has instituted. While this program is focused only on claims and providing the claims information as Blue Button 2.0 EOBs, it points to the interest of providers in obtaining a more complete picture of their patients. By converting the clinical information contained in claims and other data sources to common clinical exchange standards (e.g. FHIR APIs and C-CDA) this information will be more readily consumable by EHRs to incorporate as structured and coded data into the patient’s record. |
| Healthcare Aims |
|
| Maturity of Use and Technical Specifications for Data Element | |
| Applicable Standard(s) | The Da Vinci Project has developed a code system and value set to represent the Source of information as represented in an extension to the FHIR R4.0.1 Provenance resource. It is available as part of the Payer Data Exchange FHIR Implementation Guide https://build.fhir.org/ig/HL7/davinci-epdx/CodeSystem-ProvenancePayerDataSource.html |
| Additional Specifications | The Da Vinci Project has developed a standard extension to the existing FHIR R4.0.1 release Provenance resource to represent Source as a CodableConcept with a specific value set. The specification is available as part of the Payer Data Exchange FHIR Implementation Guide https://build.fhir.org/ig/HL7/davinci-epdx |
| Current Use | Extensively used in production environments |
| Supporting Artifacts |
This data element has been tested in connectathons and is in current production implementations, by a number of the largest payers, to establish the provenance of data the must be exchanged as part of the CMS Interoperability Final Rule. It will be in broad production by the end of the second quarter of 2021. |
| Extent of exchange | 5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders. |
| Supporting Artifacts |
This data element has been tested in connectathons and is in current production implementations by a number of the largest payers to establish the provenance of data that must be exchanged as part of the CMS Interoperability Final Rule. It will be in broad production by the end of the second quarter of 2021 in exchanges with covered plan members and 2022 with other payers under the payer-to-payer exchange requirement of the CMS interoperability Final Rule. In addition, the use of Source will become part of the provenance declaration for exchange of payer data with providers as soon as the payer FHIR APIs are established. |
| Potential Challenges | |
| Restrictions on Standardization (e.g. proprietary code) | None |
| Restrictions on Use (e.g. licensing, user fees) | None |
| Privacy and Security Concerns | In general, none other than specific PHI protection concerns unless the data exchanged requires additional protection due to federal or state regulations. |
| Estimate of Overall Burden | Since implementation of this element will be done by payers to identify the Source of the information that is available through the Patient Access API, there should be no additional implementation burden for other exchanges (e.g. with providers). |
| Other Implementation Challenges | None at this time. |
The metadata, or extra information about data, regarding who created the data and when it was created.
Data Element |
|---|
|
Source
Description
The Source of information received by an organization. The Source defines at a high level the standard used to exchange the information.
|
|
|
Comment