With HL7® FHIR® there is a core specification that describes the fundamental ways that FHIR represents and shares health information, and then ‘profiling’ that takes that core and adapts it for a particular use case (or cases). For example, the core specification describes the most common attributes of a patient resource type (name, gender, date of birth and so forth). A profile on a patient for a particular country may remove unwanted elements, change the ValueSet for coded elements and add extensions such as the patient’s ethnicity.
However, most real-world use cases need more than a single resource type. Generally, multiple profiles will be described together in an Implementation Guide – which will also include other material like the descriptive text, supported (and required) searches, security requirements, ValueSets and additional information. The term ‘profile’ can be used ambiguously, commonly ‘a profile’ is the adaptation of a single resource type, and ‘profiling’ is the overall act of creating the Implementation Guide.
As the specification has progressed, quite a number of Implementation Guides have been created (there’s a list of some of them at http://www.fhir.org/guides/registry), but perhaps one of the more interesting that has appeared recently is the HL7 Da Vinci Project.
Da Vinci HL7 FHIR
Da Vinci is a US project that brings together payers, providers and healthcare technology vendors, along with HL7 International. All these stakeholders have a common goal to improve healthcare and reduce wastage in the system, by moving to an outcomes-based model of care rather than a purely transactional ‘fee for service’ model. Commonly referred to as ‘value-based care’, it reflects the importance of the overall value that is delivered by providing improved healthcare outcomes at the lowest cost.
Such a move significantly increases the need for high quality and timely exchange of data between participants that do not typically share data easily. Selecting FHIR as the standard demonstrates the belief in those communities that FHIR has the maturity, acceptance and staying power that is needed to support this exchange.
The project also recognised the importance of the ‘FHIR approach’ to standards development with open collaboration between all participants, development of reference implementations that can be used for testing, and practical testing at Connectathons before the Guides are finalised.
There are a number of use cases (and Implementation Guides) that are part of the overall Da Vinci project. Initially, 12 were identified – of which two were chosen to start with, and three more are in the active phases of development.
Data Exchange for Quality Measures (DEQM)
As described above, value-based care is all about improving quality, and this requires concrete measures to be used. The DEQM Use Case describes a framework for sharing of quality measure data between data sources (such as a provider EHR) and data aggregators (such as a payer). The first example shares information about a medication reconciliation which is performed for a patient by a healthcare provider after discharge from the hospital, and this needs to be completed within 30 days, so the attestation that this activity was performed is time sensitive.
Coverage Requirements Discovery (CRD)
CRD refers to the need to understand what is needed by a payer to authorise payment for particular procedures – whether investigations or treatments. This can be a complex question as it depends on the patient’s insurance plans, the procedure being planned, pre-existing conditions and so forth. Because of this complexity, the CDS Hooks standardImplementation Guide streamlines the process to provide real-time advice. In summary:
- The clinician using the EHR selects a procedure (like a referral to a specialist).
- By using a pre-defined hook, the decision support service is called which receives the required clinical data and determines if this procedure is covered for this patient and if any additional documentation is required.
- The outcome is displayed to the ordering clinician.
All this occurs in real-time, so the clinician and patient can decide whether to proceed with the procedure or to look at alternatives.
New Use Cases
The next 3 Use Cases are new and related to the following diagram. (This diagram is taken from its Project Scope Statement a document that describes the purpose for any FHIR related project). The project is very new, so details are scarce, but the project teams always welcome participation in the projects.
Health Record Exchange (HRex)
The HRex Implementation Guide describes the ‘patterns’ of exchange between payers and providers. For example, the API (direct REST, CDS Hooks, push and so forth) and the ‘packaging’ of resources for the exchanges. Also rules for things like provenance and security measures.
Clinical Data Exchange (CDex)
CDex represents the data flowing from providers to other providers and the payers. It will include profiles on clinical resources for specific use cases
Payer Data Exchange (PDex)
PDex is data travelling from the payers to the providers, such as previous payer history and prior claims.
Da Vinci is still in the early stages, and there has been significant progress made – as evidenced by a demonstration at HIMSS this year. Da Vinci represents a historic level of co-operation between participants in the US healthcare sector and includes participants that are also competitors. This co-operation is in an effort to improve healthcare by moving from a transactional ‘fee for service’ model to a patient-centred outcomes model – value-based care. It’s yet another example of the impact that FHIR is having on our sector that we did not anticipate when we started this journey and the consumer will be the ultimate beneficiary.
To learn more about FHIR, read my white paper Enabling the Ecosystem with FHIR which discusses how healthcare information can be made available where and when it is needed.
