US Core Implementation Guide, published by HL7 International / Cross-Group Projects. This guide is not an authorized publication; it is the continuous build for version 10.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/US-Core/ and changes regularly. See the Directory of published versions

US Core Roadmap

Page standards status: Trial-use

The US Core FHIR Profiles are designed to be the base set of requirements for FHIR implementation in the US. All US Realm implementation guides SHALL use the US Core Profiles or SHALL explicitly state why they are unable to use them. Throughout the development of US Core, implementers, the government, and the clinical community have brought forward additional requirements. This section outlines the approach to growth and a place for items that may be added to US Core.

US Core Yearly Updates

Yearly US Core updates reflect U.S. Core Data for Interoperability (USCDI) changes and requests from the US Realm FHIR community.

The following table shows the relationship between each USCDI and US Core Version. The USCDI version links to its respective ONC Standards Bulletin, which provides background and the new data classes and elements for the version.

USCDI Version	US Core Version
v1	3.1.1
v1	4.0.0 (improved Must support guidance)
v2	5.0.1
v3.1	6.1.0
v4	7.0.0
v5	8.0.1
v6	9.0.0
v7	10.0.0

Our yearly road map is outlined in the figure below:

FHIR Version Support

US Core has been based on FHIR Version R4 since US Core version 3.0.0. FHIR Version R4 was released on Dec 27, 2018, and was the first version with Normative content. HL7's US Realm Steering Committee (USRSC) directs US Realm activities, including this guide. In January 2024, the USRSC decided that the next version of FHIR that US Core will be based on will be the upcoming FHIR Version R6. As of the publication date, there is no timeline for this update. When we update to FHIR Version R6, these breaking updates to US Core are under consideration.

• Addition of MedicationStatement
• Mandate supporting PractitionerRole

Growth Path of US Core

The US Core Implementation Guide will grow following these steps:

1. Declare candidacy - this step can be completed by presenting a Project Proposal to the US Realm Steering Committee.
2. Get published - Develop a formal profile, an implementation guide, or get requirements directly published in FHIR Core. The initial publication could be an outside consortium or vendor publication.
3. Pilot—Coordinate an in-person or virtual connectathon with three or more implementers. Testing and piloting are ways to identify issues with the new proposal.
4. Propose candidate for US Core to US Realm Steering Committee - receive formal approval from the US Realm SC to add.
5. Submit formal STU comments or propose through a ballot

A new US Regulatory requirement may skip some of these steps. However, regulators SHOULD be encouraged to complete pilot testing. Pilot testing makes it easier to understand how a change will affect real-world implementation.

Future Candidate Requirements Under Consideration

Past Balloters, STU commenters, and Accelerator Project teams submitted the following items for consideration for adding US Core. Additional requirements gathering is required before testing may occur on these items:

Searching for Multiple Patients

Searching for multiple patients has been called out in the ONC Health IT Certification Program. Defining capabilities for multiple patient access would focus on querying real-time data for a user-facing provider app across patients. Examples of the type of queries that would be addressed include searching for all of a provider's patients:

• with recent lab results
• currently in the Emergency Department
• with an Allergy to X
• being seen by a provider for the day

Record or Update Data

Systems may use operations that create and update resources for any of the profiles in this IG. However, more guidance is needed on writing and updating data in the context of US Core Profiles to support consistency between implementations. Multiple issues will need to be considered when defining expected behavior by the various actors to support updates and writes to the data, including:

• Defining the overall approach
  • direct updates to a particular resource via FHIR RESTful transactions
  • new Profiles to represent the context and issue and request
• Write failure scenarios (e.g., insufficient data to create)
• Recording and updating data in the context of the Must Support fields
• Indicating the source of the update

The Argonaut project has defined:

• Writing Vital Signs for creating and updating vital sign Observations resources from patient-facing and provider-facing applications and expects to develop similar guidance for other Observation categories and resource types.

• Writing Clinical Notes for creating and updating clinical notes using the FHIR R4 DocumentReference resource. This approach includes direct writing from providers and a patient-mediated submission of clinical notes from providers.

  After adequate testing by implementers, we will assess the feasibility of incorporating this guidance into the US Core API.

Subscriptions

FHIR Subscriptions enable real-time data exchange by allowing systems to subscribe to patient-specific or population-level updates, ensuring timely access to critical healthcare information. As US Core continues to evolve, Subscriptions will play a key role in supporting event-driven workflows, such as notifications for lab results, medication changes, or care plan updates. This functionality aligns with the push toward interoperable, proactive care delivery across the US healthcare ecosystem. Future US Core implementations may expand Subscription use cases, improving integration between EHRs, payer systems, and public health platforms.

The Argonaut project has defined the Patient Data Feed as an optional feature for servers implementing US Core. It allows clients to receive FHIR Subscription Notifications when events occur related to US Core content.