US Core Implementation Guide
STU 2
This page is part of the US Core (v2.0.0: STU2) 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 
This section outlines important definitions and interpretations used in the US Core IG. The conformance verbs used are defined in FHIR Conformance Rules.
Contents
The US Core Profiles are intended to meet the 2015 Edition certification criterion for Patient Selection 170.315(g)(7), and Application Access – Data Category Request 170.315(g)(8). They were created for each of the 2015 Edition Common Clinical Data Set (CCDS). The Location, Organization, and Practitioner Profiles are not called out specifically in the certification criteria but are included because they are directly referenced by other profiles. Where applicable the US Core Profiles are based on the HL7 U.S. [Data Access Framework (DAF)] FHIR DSTU2 Implementation Guide. However, the requirements per resource are a subset of those of the DAF implementation guide.
The table below lists the US Core Profile and FHIR Resources used for the corresponding 2015 Edition Common Clinical Data Set (CCDS) Data elements:
| No | CCDS Data Element | US Core Profile | FHIR Resource |
|---|---|---|---|
| (1) | Patient Name | US Core Patient Profile | Patient |
| (2) | Sex | US Core Patient Profile | Patient |
| (3) | Date of birth | US Core Patient Profile | Patient |
| (4) | Race | US Core Patient Profile | Patient |
| (5) | Ethnicity | US Core Patient Profile | Patient |
| (6) | Preferred language | US Core Patient Profile | Patient |
| (7) | Smoking status | US Core Smoking Status Observation Profile | Observation |
| (8) | Problems | US Core Condition Profile | Condition |
| (9) | Medications | US Core Medication Profile, US Core Medication Statement Profile, US Core Medication Request Profile | Medication, MedicationStatement, MedicationRequest |
| (10) | Medication allergies | US Core Allergies Profile | AllergyIntolerance |
| (11) | Laboratory test(s) | US Core Result Observation Profile, US Core Diagnostic Report Profile | Observation, DiagnosticReport |
| (12) | Laboratory value(s)/result(s) | US Core Result Observation Profile, US Core Diagnostic Report Profile | Observation, DiagnosticReport |
| (13) | Vital signs | Vital Signs Profile (From FHIR Core Profiles for Observation) | Observation |
| (14) | (no longer required) | - | |
| (15) | Procedures | US Core Procedure Profile | Procedure |
| (16) | Care team member(s) | US Core CareTeam Profile | CareTeam |
| (17) | Immunizations | US Core Immunization Profile | Immunization |
| (18) | Unique device identifier(s) for a patient’s implantable device(s) | US Core Implanted Device Profile | Device |
| (19) | Assessment and plan of treatment | US Core CarePlan Profile | CarePlan |
| (20) | Goals | US Core Goal Profile | Goal |
| (21) | Health concerns | US Core Condition Profile | Condition |
In the context of US Core, Must Support on any data element SHALL be interpreted as follows:
US Core Requestors SHALL be able to process resource instances containing data elements asserting missing information.
Many of the profiles in this guide reference other FHIR resources that are also US Core profiles. This is defined in the formal profile definitions. For example, US Core Careteam references US Core Patient. For any other references not formally defined in a US Core profiles, the referenced resource SHOULD be a US Core profile if a US Core profile exists for the resource type. For example, although Condition.asserter is not constrained by this guide, the reference to Patient or Practitioner should be a valid US Core Patient or US Core Practitioner.
Extensible binding to a value set definition for this IG means that if the data type is CodeableConcept, then one of the coding values SHALL be from the specified value set if a code applies, but if no suitable code exists in the value set and no further restrictions have been applied (such as the max valueset binding described in the next section), alternate code(s) may be provided in its place. If only text available, then just text may be used.
For this IG, we have defined the Extensible + Max-ValueSet binding to allow for either a code from the defined value set or text if the code is not available. (for example, legacy data). This means, unlike a FHIR extensible binding, alternate code(s) are not permitted and a text value SHALL be supplied if the code is not available. However, multiple codings (translations) are allowed as is discussed below.
Example: Immunization resource vaccineCode’s CVX coding - the source only has the text “4-way Influenza” and no CVX code.
\{
"resourceType": "Immunization",
...
"vaccineCode": {
"text":"4-way Influenza"
},
...
}
Required binding to a value set definition for this IG means that one of the codes from the specified value set SHALL be used. If only text is available or the local (proprietary, system) code cannot be mapped to one of the required codes the core specification provides guidance which we have summarized:
Note that when a query uses a status parameter, a status will be ambiguous.
Example: AllergyIntolerance resource with a status that is text only or cannot be mapped to the status value set.
\{
"resourceType”:“AllergyIntolerance”,
...
“\_status”:{
“url” : “http://hl7.org/fhir/STU3/StructureDefinition/data-absent-reason”,
“valueCode” : “unsupported”
...
},
}
Required binding to a value set definition means that one of the codes from the specified value set SHALL be used and using only text is not valid. In this IG, we have defined the Extensible + Max-ValueSet binding to allow for either a code from the specified value set or text. Multiple codings (translations) are permitted as is discussed below.
Alternate codes may be provided in addition to the standard codes defined in required or extensible value sets. The alternate codes are called “translations”. These translations may be equivalent to or narrower in meaning to the standard concept code.
Example of multiple translation for Body Weight concept code.
"code": {
"coding": [
{
"system": "http://loinc.org", //NOTE:this is the standard concept defined in the value set//
"code": "29463-7",
"display": "Body Weight"
},
//NOTE:this is a translation to a more specific concept
{
"system": "http://loinc.org",
"code": "3141-9",
"display": "Body Weight Measured"
},
//NOTE:this is a translation to a different code system (Snomed CT)
{
"system": "http://snomed.info/sct",
"code": “364589006”,
"display": "Body Weight"
}
//NOTE:this is a translation to a locally defined code
{
"system": "http://AcmeHealthCare.org",
"code": “BWT”,
"display": "Body Weight"
}
],
"text": "weight"
},
Example of translation of CVX vaccine code to NDC code.
"vaccineCode" : {
"coding" : [
{
"system" : "http://hl7.org/fhir/STU3/sid/cvx",
"code" : "158",
"display" : "influenza, injectable, quadrivalent"
},
{
"system" : "http://hl7.org/fhir/STU3/sid/ndc",
"code" : "49281-0623-78",
"display" : "FLUZONE QUADRIVALENT"
}
]
},
Both the Vital Signs Profile and US Core Result Observation Profile bind the valueQuantity datatypes to the UCUM code system. A FHIR UCUM Codes value set that defines all UCUM codes is in the FHIR specification. This guidance specifies how to represent the Quantity datatype when the correct UCUM units are missing or the units are missing altogether which will likely occur in the real world.
UCUM code provided
"valueQuantity": {
"value": 26.0,
"unit": "g/mL",
"system": "http://unitsofmeasure.org",
"code": "g/mL"
}
free text units only:
unit element. "valueQuantity": {
"value": 26.0,
"unit": "RR",
}
no units
"valueQuantity": {
"value": 26.0
}
Interactions on profile pages are defined with the syntax:
GET [base]/[Resource-type]/[id] {parameters}
For more information see the FHIR RESTful API
In the simplest case, a search is executed by performing a GET operation in the RESTful framework:
GET [base]/[Resource-type]?name=value&…
For this RESTful search (FHIR Search), the parameters are a series of name=[value] pairs encoded in the URL. The search parameter names are defined for each resource. For example, the Observation resource the name “code” for search on the LOINC code. See FHIR Search for more information about searching in REST, messaging, and services.
There are several potential ways to search for resources associated with a specific patient depending on the context and implementation. These searches result in the same outcome.:
There are several variations to this syntax which are listed below:
US Core servers are not required to resolve full URLs that are external to their environment.
In order to manage the number of search results returned, the server may choose to return the results in a series of pages. The search result set contains the URLs that the client uses to request additional pages from the search set. For a simple RESTful search, the page links are contained in the returned bundle as links. See the FHIR Paging for more information.
US Core: 2.0.0 ®© FHIR Version: 3.0.1 generated on Tue, Dec 4, 2018 10:36+1100.
| History
| Propose a change
