Spring breathes new life to the world around us…
During the latter part of 2018, Carequality announced that it would adding FHIR-based exchange to its existing query based document exchange use case model. This would extend Carequality’s governance framework to enable access to, and exchange of data, using FHIR-based APIs.
As a first step towards accomplishing the goal of creating a Draft Outline Implementation Guide for FHIR-based exchange, two workgroups were commissioned in November of 2018. The Technical Workgroup would concentrate on the specifications needed while the Policy Workgroup would focus on the “rules of the road.” Even though the workgroups were faced with obstacles such as taking breaks for the holiday season, and again for HIMSS, the teams kept their eye on the prize throughout and remained steadfastly committed to the cause.
The Technical Workgroup has been laser-focused on creating an “implement once, connect universally” ecosystem. Specific progress of their work are detailed in some critical requirements noted below:
- In order to enable a lookup of Carequality Connections that support HL7® FHIR® based access and exchange, Carequality needs to establish a common place to query for such information. Carequality shall deploy a single Carequality directory covering both FHIR-based and document-based transactions, instead of spinning up a brand new directory for FHIR.
- A Carequality Implementers supporting the FHIR use case shall deploy at least one FHIR Capability Statement that is publicly discoverable.
- To support scaling of authentication, Carequality will deploy a decentralized authentication approach where the Carequality implementer establishes one or more authentication servers to support their connections, or may share an authentication server with one or more other Carequality implementers.
Some noteworthy Policy Workgroup details are listed next:
- Implementers shall take appropriate steps to ensure correct patient match is being surfaced and strive for more consistency on how patient matching is performed.
- Query responders shall default to sending complete data, rather than withholding pieces, while still remaining compliant with applicable law. Once we’ve aligned the seeming conclusion with info blocking, we may need to reconsider the conclusion of whether we just say nothing, or disclose that we have something not shareable.
- FHIR errors shall use the OperationOutcome resource capability to return both human readable and machine processable information with sufficient detail to allow the client to determine if the error can be corrected at the client side, such as a retry operation due to the resource being busy, or is a fatal error. And due to security reasons, it might be wise to obscure some of these details. Additionally, for inquiries that the receiving systems don’t support, there is a DataAbsentReason resource that can be utilized with “unsupported” as the as value to be returned.
As demonstrated above, both teams have made significant progress throughout the winter, and have helped produce an artifact that just that happens to coincide with the spring bloom. A Draft Outline Implementation Guide (IG) is currently being reviewed by the workgroups. After a round or two of edits, and additional follow-up throughout the next couple of week, the document should be in a place where it’s deemed useable by the implementer community. Our goal is to utilize the Draft Outline IG to have a FHIR virtual Connectathon sometime in April. We’ll use this exercise to see how far we’ve gotten and identity any gaps in the Draft Outline IG. It’s not quite the same as seeing the cherry blossoms around the DC Tidal Basin in springtime, but Carequality and its FHIR workgroups, have reason to be excited nonetheless.