US Core Implementation Guide
6.1.0-snapshot1 - STU6
US Core Implementation Guide
6.1.0-snapshot1 - STU6
This page is part of the US Core (v6.1.0-snapshot1: STU6 Update) based on FHIR R4. The current version which supercedes this version is 6.0.0. For a full list of available versions, see the Directory of published versions 
The search expectations and US Core Profiles have been developed and tested using logical FHIR ids. Therefore a reference to a US Core resource SHOULD include a logical id (Reference.reference), not an identifier (Reference.identifier).
Many of the profiles in this guide reference other FHIR resources that are also US Core Profiles. These references are defined in the formal profile definitions. For example, US Core CareTeam Profile references US Core Patient. For any other references to base FHIR resources1 or 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. US Core Resources in the differential view and marked as “Must Support” follow the Must Support rules. Other resources allowed in the base FHIR specification may be referenced. For example, RelatedPerson is a permitted target reference in DocumentReference.author.
When responding to a query, servers SHOULD not use inline contained resources to represent the returned data. The only time a contained resource can be used is when the source data exists only within the context of the FHIR transaction. For example, the guidance in the Medication List page describes how a contained Medication in MedicationRequest is used for representing the medication. In addition, if referencing a contained resource in a US Core Profile, the contained resource SHOULD be a US Core Profile if a US Core Profile exists for the resource type. Further guidance about the general use case for contained can be found in the base FHIR specification.
In situations where the specific piece of data is hidden due to a security or privacy reason, using a code from the DataAbsentReason Code System such as masked may exceed the data receiver’s access rights to know. However, masking data SHOULD be handled based on implemented policies. For elements with a minimum cardinality = 0 (including elements labeled Must Support), the element SHOULD be omitted from the resource. For Mandatory elements (in other words, where the minimum cardinality is > 0), use the code “unknown” following the guidance on Missing Data in the Conformance Sections.
SNOMED CT (Systematized Nomenclature of Medicine – Clinical Terms) is a comprehensive clinical terminology widely used in healthcare to support the electronic exchange of clinical health information. US Core uses the US Edition of SNOMED CT, a standalone release that combines the content of the US Extension and the International releases of SNOMED CT. It is used extensively in US CORE for various clinical concepts, including problems, procedures, allergies, and laboratory results. When using SNOMED codes in US Core Profiles, implementers MAY use the default system URI which refers to an unspecified edition/version as shown in option one below. However, for terminology servers to be able to validate US Edition-only codes, implementers SHOULD provide the accompanying system URI to describe both the edition and the version of the edition as shown in option three. At a minimum, the URI SHOULD contain the edition of the SNOMED CT distribution as shown in option two:
Using only the system http://snomed.info/sct which refers to an unspecified edition/version. For example:
"code": {
"coding": [
{
"system": "http://snomed.info/sct,
"code": "763875007",
"display": "Product containing sulfonamide (product)"
}
],
"text": "sulfonamide antibacterial"
},
Using the system plus the unspecified version US Edition URI http://snomed.info/sct/731000124108. For example:
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"version": "http://snomed.info/sct/731000124108",
"code": "763875007",
"display": "Product containing sulfonamide (product)"
}
],
"text": "sulfonamide antibacterial"
},
Using the system plus a specific version US Edition URI http://snomed.info/sct/731000124108/version/[YYYYMMDD]. For example:
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"version": "http://snomed.info/sct/731000124108/version/20220301",
"code": "763875007",
"display": "Product containing sulfonamide (product)"
}
],
"text": "sulfonamide antibacterial"
},
For more details, see Using SNOMED CT with FHIR.
Both the US Core Vital Signs Profile and US Core Laboratory Result Observation Profile bind the valueQuantity datatypes to the UCUM code system. A FHIR UCUM Codes ValueSet 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, 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
}
Clinical information that has been entered in error in the patient’s record needs to be represented by the FHIR Server in a way so that Clients can expose the corrected information to their end users.
Server Recommendations:
entered-in-error or inactive.entered-in-error:
A FHIR Server SHOULD not delete records. If a system supports the deletion of records, they SHOULD refer to the Deletion Safety Checks in the FHIR specification.
The US Core CarePlan Profile requires a narrative summary of the patient assessment and plan of treatment. However, any US Core Profile may include a human-readable narrative containing a summary of the resource and may be used to represent the resource’s content to a human. For further guidance, refer to the Narrative documentation in the FHIR Specification.
There is a basic need to access records in your language, and the data provider SHOULD do their best to translate (safely) to the requested language. Understanding that this will be variably complete depending on the nature of the record. For example, translating the following elements is relatively straightforward:
Coding.displayAttachment.titleThe following guidelines outline requesting and returning a resource in the requested language.
Accept-Language header.language element with a code that is based on the underlying language of record, not the requested language.
Using the Human Language Extension when the language of a display, etc, is known to be different from the stated (or inferred) language.
Example
<?xml version="1.0" encoding="UTF-8"?>
<Patient xmlns="http://hl7.org/fhir">
<id value="language-example-1"/>
<meta>
[...snip...]
</meta>
<language value=" es"/>
<!--0..1 Language of the resource content in this case Spanish-->
<text>
[...snip...]
</text>
<extension url="http://hl7.org/fhir/us/core/StructureDefinition/us-core-race">
<extension url="ombCategory">
<valueCoding>
<system value="urn:oid:2.16.840.1.113883.6.238"/>
<code value=" 2106-3"/>
<display value="White">
<!--Human Language extension-->
<extension url="http://hl7.org/fhir/StructureDefinition/language">
<valueCode value=" en"/>
<!--English is different from stated language-->
</extension>
</display>
</valueCoding>
</extension>
[...snip...]
Using the Translation Extension when the server is providing additional translations by its own choice or in response to a different Accept-Language than what the resource is stored in.
Example
<?xml version="1.0" encoding="UTF-8"?>
<Patient xmlns="http://hl7.org/fhir">
<id value="language-example-2"/>
<meta>
[...snip...]
</meta>
<language value=" en"/>
<!--0..1 Language of the resource content: English-->
<text>
[...snip...]
</text>
<extension url="http://hl7.org/fhir/us/core/StructureDefinition/us-core-race">
<extension url="ombCategory">
<valueCoding>
<system value="urn:oid:2.16.840.1.113883.6.238"/>
<code value=" 2106-3"/>
<display value="White">
<!-- Translation -->
<extension
url="http://hl7.org/fhir/StructureDefinition/translation" >
<extension url="lang"> <!-- 1..1 Code for Language -->
<valueCode value="es"/><!-- 0..1 Value of extension -->
</extension>
<extension url="content"> <!-- 1..1 Content in other Language -->
<valueString value="Blanca">
</extension>
</extension>
</display>
</valueCoding>
</extension>
[...snip...]
Servers SHOULD make it known what languages are supported in their CapabilityStatement(s) using this extension2:
http://hl7.org/fhir/5.0/StructureDefinition/extension-CapablilityStatement.acceptLanguage
For further guidance on language and locale for the generation of the resource narrative, see Multi-Language support in FHIR (Localization/Internationalization) in the core specification.
Fetching resource interactions are defined by the FHIR RESTful API. Guidance is included on the US core Profile pages for conformance and informative purposes:
GET [base]/[Resource-type]/[id] {parameters}
For more information, see the FHIR RESTful API
Searching resources is defined by the FHIR RESTful API and included here for informative purposes. The US Core FHIR RESTful Search API Section documents the server and client rules for the RESTful interactions described in this guide.
All the search interactions in this guide use the GET command with the following syntax:
GET [base]/[Resource-type]?[parameter1]{:m1|m2|...}={c1|c2|...}[value1{,value2,...}]{&[parameter2]{:m1|m2|...}={c1|c2|...}[value1{,value2,...}]&...}
token type searchparameter (how to search by token), the syntax {system|}[code] means that the system value is optional for the client to supply.:reference type searchparameter (how to search by reference), the syntax {Type/}[id] means that the Type value is optional for the client to supply:date type searchparameter (how to search by date), the syntax data={gt|lt|ge|le}[date] means the date comparators “gt”, “lt”, “ge”, and “le” are optional. Date type searches without a comparator prefix are equivalent to searches with the “eq” comparator even if a server does not support the comparator.| {:m1 | m2 | …}: The list of supported search parameter modifiers |
| {c1 | c2 | …}: The list of supported search parameter comparators |
| {¶meter2={:m1 | m2 | …}={c1 | c2 | …}[value1{,value2,…}&…}: Optional multiple ‘AND’ search parameters |
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, 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 has the name “code” for searching on the LOINC code. For more information, see the FHIR RESTful Search API
Note that the patient may be implicit in the context of some implementations (e.g., using SMART). Then the patient parameter can be omitted:
GET [base]/[Resource-type]{?other-parameters}
Currently, most EHRs permit queries that provide a single patient id but do not support the comma-separated query or a query where the patient parameter is omitted, as described in the standard FHIR REST API. Instead, a user-facing app can perform multiple “parallel” queries on a list of patient ids. Alternatively, the FHIR Bulk Data Access (Flat FHIR) specification can be used to perform a “back end” system-level query to access large volumes of information on a group of individuals. It can also be used to identify and query against an unknown population, such as when looking for population-based research data or population-level queries for public health surveillance.
However, neither specification defines how a user-facing provider app is able to seek real-time “operational” data on multiple patients (such as all patients with recent lab results). Opportunities to add this capability to this guide are discussed in Future of US Core
US Core servers are not required to support patient compartment based searches.
US Core servers are not required to resolve absolute URLs that are external to their environment.
Servers may choose to return the results in a series of pages to manage the number of search results returned. The search result set contains the URLs used 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 managing returned resources in the FHIR specification for more information.
Footnotes:
For example, the base Location resource is being referenced by the US Core Encounter and US Core PractitionerRole resources. ↩
This extension is converted from a new element in a future version of CapabilityStatement. ↩
IG © 2023+ HL7 International - Cross-Group Projects. Package hl7.fhir.us.core#6.1.0-snapshot1 based on FHIR 4.0.1. Generated 2023-05-27
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change