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 standard Implementation 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.