US Core Implementation Guide (Release 1.1.0 Ballot )

This page is part of the US Core (v1.1.0: STU2 Ballot 1) based on FHIR R3. The current version which supercedes this version is 5.0.1. For a full list of available versions, see the Directory of published versions

US Core Implementation Guide

This is the US Core Implementation Guide Release 1.1.0 Trial-Use Ballot version, based on FHIR Version 3.0.1. The current version is STU 2. See the Directory of published versions

Note to balloters: For this ballot we are seeking feedback only on the sections marked as "Open for ballot" (see below)

This Implementation Guide is published by the HL7 US Realm Steering Committee. See the HL7 ballotting website to sign up for and submit ballot comments.

Introduction

The US Core Implementation Guide is based on FHIR Version 3.0.1 and defines the minimum conformance requirements for accessing patient data as defined by the Argonaut pilot implementations and the ONC 2015 Edition Common Clinical Data Set (CCDS). These profiles are intended to be the foundation for future US Realm FHIR implementation guides. In addition to Argonaut, they are used by DAF-Research, QI-Core, and CIMI. Under the guidance of HL7 and the HL7 US Realm Steering Committee, the content will expand in future versions to meet the needs specific to the US Realm.

These requirements were originally developed, balloted, and published in FHIR DSTU2 as part of the Office of the National Coordinator for Health Information Technology (ONC) sponsored Data Access Framework (DAF) project. For more information on how DAF became US Core see the US Core change notes.

US Core Actors

The following actors are part of the US Core IG:

  • US Core Requestor: An application that initiates a data access request to retrieve patient data. This can be thought of as the client in a client-server interaction.
  • US Core Responder: A product that responds to the data access request providing patient data. This can be thought of as the server in a client-server interaction.

US Core Profiles

The list of US Core Profiles is shown below. Each profile defines the minimum mandatory elements, extensions and terminology requirements that MUST be present. For each profile requirements and guidance are given in a simple narrative summary. A formal hierarchical table that presents a logical view of the content in both a differential and snapshot view is also provided along with references to appropriate terminologies and examples. In addition each profile has a “Quick Start” section which is intended as an implementer friendly overview of the required search and read operations.

  • US Core AllergyIntolerance Profile
  • US Core CarePlan Profile
  • US Core CareTeam Profile
  • US Core Condition (a.k.a Problem) Profile
  • US Core Device Profile
  • US Core DiagnosticReport Profile
  • US Core DocumentReference Profile Open for ballot
  • US Core Encounter Profile Open for ballot
  • US Core Goal Profile
  • US Core Immunization Profile
  • US Core Location Profile
  • US Core Medication Profile
  • US Core MedicationRequest Profile
  • US Core MedicationStatement Profile
  • US Core Organization Profile
  • US Core Patient Profile
  • US Core Practitioner Profile
  • US Core PractitionerRole Profile Open for ballot
  • US Core Procedure Profile
  • US Core Results Profile
  • US Core Smoking Status Profile

    • US Core adopts the Vitals Signs Profile from FHIR Core.

    Note on Searches based on a date or date range:

    • Allergies, Immunizations, Medications, Problems and Health Concerns, UDI, Smoking Status do not require a date range search since a system should return all relevant resources.
    • Vital Signs, Laboratory Results, Goals, Procedures, and Assessment and Plan of Treatment include date range search requirements in the Quick Start section on the profile page.

    See 2015 Edition Common Clinical Data Set for a mapping to the CCDS.

    US Core Conformance Requirements

    The Capability Statements Section outlines conformance requirements for the US Core Servers and Client applications, identifying the specific profiles that need to be supported, the specific RESTful operations that need to be supported, and the search parameters that need to be supported. Note: The individual US Core profiles identify the structural constraints, terminology bindings and invariants, however, implementers must refer to the conformance requirements for details on the RESTful operations, specific profiles and the search parameters applicable to each of the US Core actors.

    Primary Authors: Brett Marquard, Nagesh Bashyam, Eric Haas

    Secondary Authors: Grahame Grieve, Lloyd McKenzie