HealtheData1 USCDI4 Sandbox
0.0.0 - CI Build
HealtheData1 USCDI4 Sandbox
0.0.0 - CI Build
HealtheData1 USCDI4 Sandbox - Local Development build (v0.0.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
| Page standards status: Informative |
EHR systems with support for writing FHIR vital sign Observation resources from patient-facing apps, provider-facing apps or system apps SHALL include a vitals-write capability in .well-known/smart-configuration capabilities array.
EHR systems providing the ability to write FHIR vital sign Observation resources from patient-facing apps SHALL support the registration and authorization of apps with the patient/Observation.c SMART scope and MAY require limiting this scope to category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signs. Note that read and search capabilities are already implied by US Core Vital Signs profile.
EHR systems providing the ability to write FHIR vital sign Observation resources from patient-facing apps SHOULD also support the registration and authorization of apps with either patient/Observation.u or patient/Observation.u?category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signs SMART scope. Note, systems are allowed to only support limited update capabilities.
When offering a patient write capability, health systems MAY choose to enable or disable this capability in the system based on factors such as the provider, patient, payer, app, and vital type, or MAY choose to enable the capability broadly. If patients and/or apps attempting to write data are not enabled, and this can be discerned during the authorization process, the EHR SHALL omit these unsupported scopes from the resulting access token. If an app uses an access token without the required scopes to submit an Observation or the patient is not enabled to write data, the EHR SHALL return an error and SHOULD include an OperationOutcome in the response body.
Examples:
EHR systems providing the ability to write FHIR vital sign Observation resources from provider-facing apps SHALL support the registration and authorization of apps with the user/Observation.c and system/Observation.c SMART scopes and MAY require limiting these scopes to category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signs. Note that read and search capabilities are already implied by US Core Vital Signs profile.
EHR systems providing the ability to write FHIR vital sign Observation resources from patient-facing apps SHOULD also support the registration and authorization of apps with either user/Observation.u and system/Observation.u SMART scopes, or user/Observation.u?category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signs and system/Observation.u?category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signs SMART scopes. Note, systems are allowed to only support limited update capabilities.
Examples:
EHR systems SHALL support the submission of Observation resources that are not the result of a calculation and validate against a US Core Vital Sign Profile that corresponds to a version used by the EHR for vital sign Observation read requests.
EHR systems MAY support the submission of Observation resources that are the result of a calculation (such as the “US Core Pediatric BMI for Age Observation Profile”) and validate against a US Core Vital Sign Profile that corresponds to a version used by the EHR for vital sign Observation read requests.
EHR systems SHALL respond to supported and valid vital sign Observation creation requests with a status code of 200 OK and a content location header, or with a status code of 202 Accepted. If a content location header is provided, the resources SHALL be visible in subsequent read API calls and accessible within the EHR in the same manner as other patient submitted data. If a content location header is not provided, and EHR systems do not subsequently make the resource accessible in read API calls, the EHR system SHALL have a documented and discoverable reason why it was discarded (e.g., a log entry describing rejection during a review workflow or the applicability of a condition in the “Discarding” section below).
EHR systems SHALL support the creation of a single vital sign through a FHIR create operation and MAY support the creation of multiple vitals signs by submitting a FHIR Batch bundle. When batch creation is supported, clients MAY use this approach to indicate that a set of Observation resources should be reviewed as a group and EHR systems MAY use this information when sending notifications or displaying the data.
EHRs may choose to segregate data that originated from a patient from other vital sign data for the patient (for example, showing it on a separate patient flow sheet).
Workflow for submitted Observations is the responsibility of the receiving system and is out of scope for this version of the IG (e.g., requiring provider review for patient submitted resources before fully integrating them in the chart).
meta.tag
Meta.tag with a system of http://hl7.org/fhir/us/core/CodeSystem/us-core-tags and a value of patient-supplied to indicate that the data was supplied by a patient or patient designee (such as a parent or spouse) rather than by a healthcare provider.patient-supplied tag with vital signs supplied by a patient written through this API, and MAY associate the tag with vital signs supplied by a patient regardless of how they arrive in the EHR. Provider-facing apps writing data supplied by a patient SHALL include this tag in the Observation resources being submitted. The EHR MAY subsequently dissociate the tag from the data through an explicit reconciliation process.encounter
launch/encounter SMART scope.encounter element is required to create a vital sign. When not required, EHRs MAY determine this value based on context if it is omitted.subject
subject reference with a reference to a Patient resource in the EHR. Patient-facing apps SHOULD populate this element based on the value returned as part of the launch/patient SMART scope.device
device reference with a reference to Device resource in the EHR, or a contained Device resource within the Observation. This is the device used to measure the vital sign (e.g., a BP cuff), not the device used to transmit the data (e.g., a phone). Contained device resources SHALL populate at least one deviceName element.device element when returning the Observation.performer
performer element with a reference to a resource in the EHR when the resource exists or the app has the ability to create it. For patient-facing apps, if the app knows that a patient collected this data, the app SHALL set the performer to a reference to the patient based on the the SMART launch context (this should also match the Observation.subject). If the relevant resource does not exist and the app is unable to create it, the app SHOULD populate performer.display.For a given vital sign type, if many Observations are submitted that have effectiveDateTime or effectivePeriod values that are close in time, an EHR MAY choose to discard a portion of these Observations or MAY reject submitted Observations with an appropriate OperationOutcome. EHRs SHALL clearly document this behavior or the ways in which this behavior may be customized by health systems in the APIs documentation.
If an EHR determines that a vital sign is a duplicate of one it has already stored, the EHR MAY ignore the Observation or MAY reject the submitted Observation with an appropriate OperationOutcome. EHRs SHALL clearly document this behavior or the ways in which this behavior may be customized by health systems in the APIs documentation.
EHR systems SHOULD support the ability for patients-facing apps to update the status element of a vital sign resource the user previously wrote to the system from any app to entered-in-error through an update interaction. This capability SHOULD only be used by apps to address data mistakes in data submission.
EHR systems MAY ignore contained Provenance resources in an Observation being submitted, but SHALL not return an error due to their presence.
When writing an Observation that was retrieved from an external organization (e.g., a health system’s EHR or a device manufacturer’s cloud data store):
agent.type = author that the app can pass through. The app SHALL also pass through resources referenced in elements that are labeled as “Must Support” in the USCDI Provenance profile and populated in the Provenance resources, including them as contained resources in the Observation and updating the references to them.agent.type = author is not received from the source system, apps SHALL generate a contained Provenance resource with:
recorded set to date and time recordedagent.type = author that has agent.who set to the organization/provider that authored the content, with at least the who.display element populated.
who.identifier.value should be set to the url where that data was retrieved and who.identifier.system should be set to urn:ietf:rfc:3986agent.type = transmitter with information on the entity that submitted the data. EHR systems MAY store and display this information and/or MAY populate this information based on the SMART context associated with the write.Example:
{
"resourceType": "Observation",
"contained": [{
"resourceType": "Provenance",
"id": "contained_1",
"target": [{"reference": "#"}],
"recorded": "2019-07-09T15:26:23.217+00:00",
"agent": [{
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
"code": "author",
"display": "Author"
}]
},
"who": {
"display": "Saint Luke\'s Hospital of Kansas City",
// identifier could be an url as in Patient Access Brands
"identifier": {
"system": "urn:ietf:rfc:3986",
"value": "https://stlukes.example.org"
}
}
},{
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
"code": "transmitter",
"display": "Transmitter"
}]
},
"who": {
//this is the user submitting the data
//can be populated by the EHR based on the SMART context if omitted
"reference": "Patient/123"
}
}]
}]
// ... other Observation elements
}
When writing an Observation that was not retrieved from an external organization (e.g., transmitted by a home blood pressure cuff, or manually entered by a patient):
App MAY include a contained Provenance resource with agent.type = author with information on the party that wrote the data. EHR systems MAY store and display this information and/or MAY populate this information based on the SMART context associated with the write.
App MAY include one or more contained Provenance resources with agent.type = composer and/or agent.type = assembler with information on the device, app, or apps that captured or passed along the data.
Example:
[{
"resourceType": "Provenance",
"target": [{"reference": "#"}],
"recorded": "2019-07-08",
"agent": [{
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
"code": "composer",
"display": "Composer"
}]
},
"who": {
//this is the app that provided the original data
"display": "OMRON for iOS"
}
},{
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
"code": "author",
"display": "Author"
}]
},
"who": {
"reference": "Patient/123"
}
}]
},{
"resourceType": "Provenance",
"target": [{"reference": "#"}],
"recorded": "2019-07-09T10:26:23.217+00:00",
"agent": [{
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
"code": "assembler",
"display": "Assembler"
}]
},
"who": {
//this is the app that's transmitting the data
"display": "Healthkit"
}
}]
}]