Track 3. Standards Development

A Common Language for Better Health

Effective communication allows clinicians and patients to collaborate and ensure better health outcomes. To communicate effectively, all stakeholders in the health landscape need a common language - and the same is true for associated data systems. Unfortunately, too often data systems are siloed with their own local dialects of data, unable to easily communicate with other systems without time consuming data translation efforts. To improve data communications and ultimately patient care, development of data standards guiding the collection, storage, sharing, and use is necessary. The discussion on this page focuses primarily on standards around data sharing, which may or may not also be how data is stored. This allows clinicians, patients, researchers, payers, public health, and software systems unambiguously understand and communicate every piece of data to other entities within the healthcare ecosystem.

The following graphic illustrates key steps that are necessary and/or useful in developing and publishing a quality, HL7 standard, FHIR Implementation Guide. This process is agile (thus the cycles representing steps), with iterations and interactions between each cycle.

Diagram of key steps from defining clinical requirements to FHIR IG development to HL7 standardization — Key steps needed to develop an HL7 standard, FHIR Implementation Guide.

To develop clear standards for data communication, projects need three things:

Clinical Requirements – The target product is a data dictionary, a database documenting a minimal, agreed set of clinical data elements necessary to complete the use case’s workflow. The data dictionary includes the origin of data, criticality to the workflow, relationships between data elements, and data format.
FHIR Implementation Guide (IG) Development – A FHIR IG is an instruction manual for developers on how to send and receive the data necessary to conduct the use case, built from the data dictionary.
HL7 Standardization – Health Level Seven (HL7) has governed medical interoperability standards since 1987. HL7 standardization of proposed Implementation Guides is key to gaining acceptance within the larger medical community, government oversight agencies, and software vendors. Implementers could use IGs that are not HL7 standards, however they would be less likely to gain widespread adoption.

This page provides an executive overview, intended for leadership, of the standards development approach leveraged by MITRE in the CodeX HL7 FHIR Accelerator and other projects. Of course, much of the standards development and implementation work will fall to clinical and technical subject matter experts. Targeted guidance for these experts can be found on the Resources page and on the Technical Deep Dive into FHIR-Based Standards Development page. These pages also include:

Video tutorial on the development of mCODE
More general tutorials on FHIR interoperability standards
Role of United States Core Data for Interoperability (USCDI) and USCDI+ in data Interoperability
Guides for writing IGs including tutorials on FHIR Shorthand (FSH)
Guidance on when to reuse vs create FHIR artifacts such as profiles and extensions

The standards development process can be lengthy. Even seemingly small proposals could take many months to fully progress to standardization, then implementation in software, adoption, and value. A clear understanding of topics presented here can facilitate work towards the ultimate goal of working, impactful specialty software. To further speed progress, it is recommended that Community focus on the minimum set of necessary data elements. This narrow focus allows all aspects of software development: use case planning, interoperability standards development, and implementation and testing to be completed sooner than larger efforts. With software and standards developed faster, the benefits to the larger Community can be demonstrated sooner. Standards and software can always be refined and updated to include additional data and functionality later.

There are several standards for data exchange within the healthcare ecosystem. It is recommended that implementors use the latest data exchange standard, FHIR, though very rarely other domain specific interoperability standards may be needed. Information on for technical experts FHIR data exchange, FHIR IG development tools and processes, and other data standards used in this space can be found on the Resources page and on the Technical Deep Dive into FHIR-Based Standards Development. CodeX and mCODE both utilized FHIR throughout their processes, as a result, the processes described below are directly applicable to FHIR data exchange processes.

Clinical Requirements:
Information Needs and Data Dictionary

Establishing clinical requirements requires converting clinical concepts into discrete data elements to enable standardization of capture and transport of data. To establish these requirements, the community’s clinical experts will need to develop a data dictionary based on the minimum set of data elements necessary to meet the workflow needs of the use case. To streamline the development, it is recommended that the clinical requirement team have:

A well-respected chair or co-chairs to guide the team
A team of 5 – 20 subject matter experts whose backgrounds cover the necessary clinical expertise for the Use Case. To ensure that viewpoints are not overlooked, it is recommended that the team represent a diverse set of experts across patient, doctor, nurse, technician, informatician, researchers, software vendors, and payers.
- At least one objective moderator to guide discussion and align diverse views.
- One or more experts have previous experience in clinical data capture, analysis, and data dictionary development
- One or more experts familiar with interoperability standards such as United States Core Data for Interoperability (USCDI), USCDI+, and US FHIR Core profiles to ensure proposed data formats match generally accepted formats used in the wider medical community.
- One or more experts involved in the use case development process.
Tools and techniques for aligning diverse expert opinions to build a consensus across the panel and the larger specialty Community.
Use familiar terminology and medical terms when building the data dictionary
Knowledge of similar use cases and data exchange needs so that the panel’s work can be easily built upon and harmonized with external projects.
A group charter outlining scope, timelines, decision processes, and other key aspects for clinical requirement development. A sample charter can be found on the Resources page, downloadable from here.
Follow the Design Principles.

Further details for clinical experts can be found in the Clinical Requirements Deep Dive resource section of this site.

FHIR IG Development:
Specialty FHIR Data Communication Standards

Once the clinical subject matter expert group has a draft data dictionary, work can begin with incorporating the clinical information into one or more IG(s). The IG development and HL7 standards approval processes are technical, requiring a FHIR IG development team of interoperability experts to complement the clinical requirements expert team. It is recommended that the interoperability team have:

A well-respected chair or co-chairs to guide the team

A team of 3 – 10 technical subject matter experts also have an appreciation for the Use Case. To ensure that viewpoints are not overlooked, it is recommended that the panel is a diverse set of experts including data modelers, FHIR Implementation Guide developers, terminologists, system developers, informaticists, software implementors, and clinical specialty experts.
At least one objective moderator to guide discussion and align diverse views.
Two or more experts familiar with the FHIR data exchange and standards including USCDI, USCDI+, and US FHIR Core profiles to ensure proposed data formats match generally accepted formats used in the wider medical community.

One of these experts should be familiar with FHIR IG development processes including FHIR Shorthand, FHIR profiles and extensions, and similar IG development efforts within HL7

At least one implementor who can guide IG development efforts to enable streamlined software creation and testing.

Tools and techniques for aligning diverse expert opinions to build a consensus across the panel and the larger specialty Community.
Knowledge of similar development efforts within HL7 to enable collaboration and harmonization of efforts with external projects.
Knowledge of similar use cases and data exchange needs so that the panel’s work can be easily built upon and harmonized with external projects.
A group charter outlining scope, timelines, decision processes, and other key aspects for FHIR IG development. A sample charter can be found on the Resources page, downloadable from here.
Follow the Design Principles.

As noted, the clinical expert team needs to work in tandem with the IG development team to ensure the clinical information needs are captured properly in the FHIR IG, that the FHIR IG is implementable in systems and processes. Each group needs feedback from the other to successfully build and implement specialty data exchange software.

To guide implementation, developing a logical model representing the data dictionary is needed. The static graphic below is a representation of mCODE's version 3 (called Standard for Trial Use or STU 3) conceptual model, published in 2023. Conceptual models are notional, loosely represent the actual FHIR model, enable clinical and other SMEs to more easily understand the context and use of elements, and illustrate how data elements relate to each other. Visit the latest version of the mCODE FHIR IG and explore an interactive version of this graphic and dive into the details of this mCODE concept model

mCODE STU3 conceptual modeling diagram — Example conceptual modeling diagram for mCODE STU 3 (2023). draw.io was used to create the mCODE modeling diagram.

Framework for FHIR Implementation Guide Development

A specialty should aim for a single, core IG that represents the minimal clinical requirements for a set of Use Cases concepts that are common within the specialty. The mCODE FHIR IG is an example of a core IG. The core IG can be appended and improved as Use Cases are executed. Supplemental IGs can be built when new data requirements are not considered core, but important for smaller Communities and/or edge applications.

The community’s specialty interests may not be well represented in existing FHIR profiles and standard data elements, similar to the terminology challenges encountered during the data dictionary development. In these cases, existing FHIR artifacts, including profiles and extensions, may need to be developed or updated to better support the community’s data needs. It is critical that specialty communities minimize changes and modification to existing FHIR artifacts to maintain consistency within the larger healthcare data exchange community. This helps ensure the final IG and associated software can be more easily accepted and adopted across all healthcare domains.

During the IG development process and after, updates to the IG are common. Updates to the IG could be motivated by updates to underlying standards (e.g., new FHIR versions, new USCDI/UCSDI versions, US Core FHIR profile updates, terminology code system updates, and others), government mandates and regulation changes, and shifting changes in need, functionality, and technology. Care should be taken to plan long-term upgrade processes to ensure the IG and associated software can be adapted to changing needs and functionality requirements. Further HL7 has established processes for IG updates, becoming more restrictive as the IG meets standardization milestones. It will be necessary to have a system to organize, prioritize, and address requests for changes and other comments during the IG development processes.

Questions for Planning FHIR IG Development

Are there related, external FHIR IG initiatives?

Are there projects being driven by others in government and/or industry that need to be reviewed, consulted, and/or partnered with?

What existing FHIR resources and profiles best fit the data model?

What existing resources and profiles best match the required data elements in the data model?
What existing resources and profiles result in the fewest FHIR extensions that are needed?
What existing FHIR resources and profiles allow for use of the necessary terminologies?
Do the selected FHIR resources and profiles require data elements that may not be present in an exchange?

What FHIR profiles must be created?

Profiles are created when further specifications (extensions or constraints) are needed on a FHIR base resource or an existing dependent FHIR profile.

What FHIR extensions are needed?

Extensions are used to add data elements that may be missing in FHIR resources and profiles to accommodate a business need.
What existing resources and profiles need to be extended to support the required data elements in the data model?

What documentation is needed by senior managers and implementers to understand and effectively implement?
How will the data be accessed?

What requirements are needed for data querying and access?

Change management?

What version control system will be used?

Further details for technical experts can be found in the FHIR Implementation Guide (IG) Development Deep Dive resource section of this site.

HL7 Standardization and Approval:
Path Towards Wider Standards Adoption

To gain wider acceptance Implementation Guides need formal approval from the healthcare interoperability standards body HL7. As the IG is drafted, the IG development team needs to begin processes for eventual HL7 community balloting and approval of the IG. Often the sooner these processes are started, the smoother the HL7 standards processes help ensure harmonization of IG development efforts across projects and communities. This said the standards process is often lengthy and can take many months to over a year from start to publication of an interoperability standard. Specific details about the HL7 process and FHIR development in general can be found in the resources section.

HL7 standards process timeline for new FHIR IGs

It is recommended that the IG development team used to develop the FHIR IG also guide the IG through the HL7 standards processes. To better navigate HL7 processes the IG team should:

Have an advisor who has thorough knowledge of HL7 processes and standardization schedule.
Coordinate with HL7 and HL7 work groups associated with the specialty domain.
Build HL7 standardization throughout the development processes started with the use case development. Allow plenty of time to go through the process.
Build a relationship and coordinate with HL7 Work Groups. Work Groups may not have deep expertise in individual health specialties. However, they will know HL7 standards and processes and may be aware of IG work (past, current, and planned) that is similar. Support from the HL7 Work Group will help smooth the IG standardization process.

It is critical that any proposed new FHIR artifacts, such as FHIR profiles or extensions, be discussed with HL7 and the appropriate HL7 Work Group. They can help harmonize FHIR profiles and extensions to better address both the specialty's and the wider community's needs and interest.

Utilize existing HL7 community to coordinate and harmonize work, especially HL7 FHIR Accelerators who will be knowledgeable and connected closely with HL7 people and processes and ongoing work within their domain.

As stated previously HL7 IG standardization and approval mark the gateway towards broader acceptance of the developing IG and the beginning of implementation and testing processes. Again, all the development steps: use case planning, interoperability standards development, and implementation and testing are cyclic and rely on feedback from other steps to produce valuable software for the specialty community.

Further details for standards experts can be found in the HL7 Standardization Deep Dive resource section of this site.