Amida/Insights/White Papers/Planning Enterprise FHIR Investment With COTA
Contribute, Observe, Track, Aware

Planning Enterprise FHIR Investment With COTA
Contribute, Observe, Track, Aware

Dark Mode

Ryan M. Harrison
Mike Hiner
Henry Mayen Velasquez

Amida Technology Solutions, Inc.
July 2021


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.


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


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.


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.


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
Figure 1 – Example COTA classification by selected FHIR Implementation Guide.

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


COTA2022: 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 RelevanceAllows 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 DescriptionSMART 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 GroupHL7 FHIR Infrastructure Work Group, Argonaut3
Implementation Guide

FHIR Bulk Data

COTA2022: 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 RelevanceThe 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 DescriptionBulk 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 GroupHL7 FHIR Infrastructure Work Group, Argonaut6
Implementation Guide(s)

Clinical Decision Support (CDS) Hook

COTA2022: 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 RelevanceProvides 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 DescriptionAn 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:
Working GroupIndependent8
Implementation Guide(s)

Clinical Quality Language (CQL)

COTA2022: 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 RelevanceAllows 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 DescriptionComplements 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 GroupDaVinci Project Gaps In Care10
Implementation Guide(s)
1Overview of SMART on FHIR []
3From the January 2022 Connectathon 29 registration []
4CMS Beneficiary Claims Data API []
5FHIR Bulk Data Extracts []
6From the January 2022 Connectathon 29 registration []
7FHIR within a CDS hook should be passed by reference. This avoids excessive payload size, and more importantly, allows for a security enforcement point (when the FHIR resource server is queried to retrieve the FHIR payload).
8The January 2022 Connectathon 29 registration lists “CDS” as the submitting workgroup. []
9Clinical Quality Language []
10From the January 2022 Connectathon 29 registration []