Ryan M. Harrison
Mike Hiner
Henry Mayen Velasquez
Amida Technology Solutions, Inc.
July 2021
Summary
With the accelerating industry-wide adoption of FHIR, federal FHIR mandates, and the proliferation of FHIR Implementation Guides (IGs), healthcare enterprises must choose whether to delay federal FHIR rule compliance, meet the bare minimum required by federal FHIR rules, or proactively invest in the development of the FHIR ecosystem. In 2021, healthcare enterprises faced the additional challenge of balancing longer-term investments in FHIR, trusted exchange, and the realignment towards value-based care (VBC) against the exigent needs of the national COVID-19 response.
In this white paper, we provide a simple framework for organizations to consider their investment in FHIR, as well as two appendices: our 2019 inventory of FHIR working groups, and four example business justifications. By proactively prioritizing organizational investment in FHIR according to the COTA (Contribute, Observe, Track, Aware) scale, enterprises can reap the benefits of FHIR contributions without overextending staff.
Planning FHIR Contributions With COTA
Amida has developed a scale that concisely represents an enterprise’s disposition toward the various FHIR groups and FHIR Implementation Guides. The COTA scale represents the level of activity that an organization should consider. “Aware” requires the least involvement, while “Contribute” necessitates the most.
Contribute
At the “Contribute” tier, we presume that the enterprise will have existing, ongoing, internal implementation projects from which lessons, case studies, or pilots could be shared with the broader community. In other words, this tier marks the transition from “consumer” to “producer” of knowledge for the community.
Organizations that engage at the “Contribute” level would:
- Sharing use cases
- Contributing open-source implementations at Connectathons
- Reviewing Implementation Guides, including reading and writing comments
- Voting on HL7 implementation ballots
Observe
At the “Observe” tier, the enterprise would attend working groups and FHIR-related technology development meetings via teleconference. As an engaged consumer of knowledge, this would allow the enterprise to “keep the pulse” on discussions that involve these standards and Implementation Guides but refrain from making the investment to provide detailed input into them. It is a challenge to follow ongoing meetings without initial context; therefore – before jumping into a weekly or bi-weekly working group meeting – it would behoove staff to attend an in-person educational session at a workgroup meeting or observe a Connectathon.
Track
At the ‘Track” tier, the enterprise would not attend workgroup sessions or technology development meetings, but would periodically skim updates on work products such as Implementation Guides. For example, at this level, it would benefit the enterprise to know the location of specific technical information in an HL7 IG or be able to list the characteristics of a FHIR-related technology product.
Aware
At the “Aware” tier, the enterprise would only be conversant in the major elements of the project (i.e., they might know the names of the group and skim press releases). There is no technical depth at this level of involvement.
Example “Go-Forward” Plan
To reduce the tiers to practice, we provide an example “go-forward plan,” as follows.
- Track: Select two or three technical focus areas appropriate for the “Observe” and ”Contribute” tiers
- Observe: To validate the decision to participate in a technical focus area (without a complete understanding of the discussion)
- Observe: Attend one of the triennial HL7 working group meetings; at the meeting, join education sessions and observe a Connectathon
- Contribute: Present a case study at a community event
- Contribute: Build a demo, or – better yet – contribute a case study implementation at a Connectathon
Appendix A: 2019 Inventory of FHIR Working Groups
Includes short descriptions of more than 100 FHIR working groups at fourteen different organizations, including the CARIN Alliance, The Sequoia Project, and the Workgroup for Electronic Data Interchange (WEDI).
Appendix B: Example Business Justifications
SMART on FHIR
| COTA | 2022: Track Justification: We consider SMART on FHIR “mature” for our enterprise use cases over the next few years (e.g., support simple, coarse-grained role-based access control (RBAC)). |
| Business Relevance | Allows us to buy third-party customer-facing software with less customization Allows third parties to consume our data without customization Reduces the cost of authorization in our customer-facing FHIR applications1 |
| Technology Description | SMART on FHIR specifies how to use Open ID and OAuth with a FHIR server It is used primarily for standardization of EHR systems’ auth for application integration;2 one aspiration is to enable “build once, use anywhere” FHIR-consuming applications FHIR provides consistency to the electronic data that SMART EHR systems access |
| Working Group | HL7 FHIR Infrastructure Work Group, Argonaut3 |
| Implementation Guide | http://hl7.org/fhir/smart-app-launch/ |
FHIR Bulk Data
| COTA | 2022: Track 2023: Observe Justification: Our exchange partners are beginning to replace bulk exchange via FTP with FHIR. Although Bulk FHIR is on the critical path for this transition, we anticipate that the standard will mature faster than our enterprise adoption. Since we will not be an early adopter, start tracking now and begin to actively observe next year. |
| Business Relevance | The Bulk Data specification is important for inbound exchange via FHIR from providers to our enterprise; Bulk FHIR will be required before the primary inbound pathway transitions from C-CDA via FTP to FHIR via resource server Large exports are cumbersome without bulk data, as they require either an extreme number of requests or excessively large response payloads If we do not invest in Bulk FHIR, we will lag our peers in bulk exchange capability |
| Technology Description | Bulk data is an electronic collection of data extracted from a source system composed of information from multiple records that share the same origin of extraction; for example, at BCBSNC, fields are mapped into a structured file (such as a CSV file) and then the files are exchanged via FTP This technology is used to address cases in which information from multiple patients must be extracted from a data source such as an EHR or a FHIR server; it supports obtaining, moving, and extracting data The standard is already in draft and is more technically mature than most other technologies on the R5 roadmap, including an implementation by the CMS Beneficiary Claims Data API4 Many major EHR vendors, as well as other health entities, are involved in the FHIR bulk data extract development5 |
| Working Group | HL7 FHIR Infrastructure Work Group, Argonaut6 |
| Implementation Guide(s) | https://hl7.org/fhir/uv/bulkdata/ |
Clinical Decision Support (CDS) Hook
| COTA | 2022: Aware Justification: We do not anticipate that our enterprise will require this technology for at least three years. The technology will become useful if we resume our clinical workflow integration initiative. CDS hooks would allow our payor applications to trigger alerts within our provider EHR. |
| Business Relevance | Provides the entire care team with consistent and reliable information, without leaving their clinical workflow Enables “clinical workflow integration,” whereby an end user can access information in one place, despite the data being pulled/pushed to multiple systems of record; this may improve our provider utilization and patient throughput |
| Technology Description | An open-source specification focused on user-facing remote clinical-decision support; it can use FHIR to represent patient information and recommendations,7 but is architecturally an independent specification Basic components include: (1) a service support that accepts requests containing patient information and provides responses, (2) a point within the client system’s workflow with well-known contextual information provided as part of the request, (3) an EHR, and (4) a decision support service returned in the form of cards List of adopting organizations: https://cds.ahrq.gov/cdsconnect/community/workgroup |
| Working Group | Independent8 |
| Implementation Guide(s) | https://cds-hooks.hl7.org/1.0/ |
Clinical Quality Language (CQL)
| COTA | 2022: Aware Justification: This technology would be useful for our enterprise data analysts, but it is not along the critical path for our 2020-2023 data management strategic plan. |
| Business Relevance | Allows our data analysts to write more human-readable queries than SQL does Allows logic to be shared between electronic clinical measures and decision controls |
| Technology Description | Complements the standards used for electronic clinical measures Allows data analysts to move between multiple information data models (i.e., Quality Driven Management, FHIR) without re-writing queries Provides the ability to express logic that a human can read but is structured enough for electronic queries Allows for more flexible and thorough logical expression9 |
| Working Group | DaVinci Project Gaps In Care10 |
| Implementation Guide(s) | http://hl7.org/fhir/us/davinci-deqm/ |
