Smart Health Checks
0.3.0 - ci-build
Smart Health Checks
0.3.0 - ci-build
Smart Health Checks, published by AEHRC CSIRO. This guide is not an authorized publication; it is the continuous build for version 0.3.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/aehrc/smart-forms-ig/ and changes regularly. See the Directory of published versions
Systems compatible with the Smart Health Checks (SHC) App are required to support healthcare client and provider information conforming to profiles, AND implement the interaction requirements of relevant actor's capability statements defined in this implementation guide.
The requirements of the FHIR standard and FHIR Conformance Rules apply, and define the conformance verbs - SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY.
This page documents how CapabilityStatements declare conformance to the SHC profiles and their FHIR interactions. It also defines the expectations for mandatory and Must Support elements. Authorisation to a healthcare client's record is supported using SMART App Launch v2.2.0 implementation guide.
The Artefacts page lists the SHC profiles defined for this implementation guide. Core profile StructureDefinitions defines the minimum elements, extensions, vocabularies, and value sets which SHALL be present when using the profile. Many profile pages also contain additional guidance.
The profile elements consist of both mandatory and Must Support elements. Mandatory elements are elements with a minimum cardinality of 1 (min=1). The base FHIR Must Support guidance requires specifications to define the support expected for profile elements labeled Must Support. The sections below explain how these elements are displayed and define the rules for interpreting profile elements and sub-elements labeled mandatory and Must Support for SHC Host FHIR Server and SHC App.
The capability statement page lists the capability statements that are to be supported by systems implementing the SHC actors in this IG.
In FHIR, resources are commonly exchanged in multiple formats including JSON and XML. The SHC App is a JavaScript-based app and hence mandates the support of JSON.
The SHC systems support the SHC profiles to represent clinical information and the SHC REST API interactions to access that information. Therefore, the SHC Host FHIR Server must implement and support SHC profiles AND interactions to be compatible with the SHC App.
Profile support refers to the support of the SHC profiles, such that the system exposes FHIR resources that adhere to the SHC profiles' content model. Specifically, a SHC Host FHIR Server with SHC profile support:
Interaction support refers to a system that supports the SHC REST API interactions. Specifically, a server with SHC Interaction support:
In the context of SHC, Obligations defines how an actor (SHC Host FHIR Server or SHC App) must “support” a given element. All Must Support elements in this IG are accompanied by an explicit obligation, which identifies structured expectations for a given actor. If a Must Support element has no obligation for a given actor, that element need not be supported by that actor.
SHC profiles are derived from AU Core profiles, hence any elements flagged as Must Support in AU Core are also Must Support in the SHC profiles of this implementation guide. The SHC Host FHIR Server and SHC App actors are derived from AU Core Responder and AU Core Requester respectively, hence the actor obligations are inherited from AU Core as the default obligations in the SHC profiles. Additional obligations constrain and augment these defaults as required, to support the prepopulation and writeback requirements of each actor in this implementation guide.
The actor obligations of Must Support elements are specified in the element description of each SHC profile.
The Obligation codes are defined in the FHIR Extensions Obligation Codes ValueSet. The Obligation codes used within this implementation guide are summarised below, with descriptions of how the data elements are expected to be supported by each actor.
Obligations are specified for each actor in the context of two sets of interactions defined in the Smart Health Checks Interactions:
The figure below illustrates the relationship between the SHC and AU Core actors, the default Must Support Obligations inherited from AU Core actors, and the additional Obligations of each SHC actor specified for the Prepopulation and Writeback interactions.
A SHC Host FHIR Server actor SHALL support the data usage expectations specified in the Obligations of the SHC Host FHIR Server actor for each Must Support element.
The SHC Host FHIR Server actor derives from AU Core Responder actor, hence the Must Support elements in SHC profiles that are derived from AU Core profiles inherit the default SHALL:populate-if-known obligation for data access interactions. This requires the SHC Host FHIR Server to populate an element if that element is available. There are a few potential reasons why a Must Support element may not be available, for example:
The SHC profiles may specify additional obligations for the SHC Host FHIR Server actor related to data access for prepopulation and writeback interactions. These include:
| Code | Interactions | SHC Host FHIR Server Obligations |
|---|---|---|
| SHALL:populate-if-known | Prepopulation | Indicates the element SHALL be populated where a value is known, it is important for prepopulation, however missing data is allowed. |
| SHALL:populate | Prepopulation | Indicates the element SHALL be capable of being populated when a value is known and allowed to be shared. It is required for search queries or prepopulation and hence always populated. |
| SHALL:persist | Writeback (create) | Indicates where the element is populated, the value SHALL be stored in a persistent store. |
| SHALL:process | Writeback (patch) | Indicates the element SHALL be processed as part of a PATCH interaction, where the element's related parameter value replace the existing stored value. |
The SHC App actor SHALL support the data usage expectations specified in the Obligations of the SHC App actor for each Must Support data element. The SHC App actor derives from the AU Core Requester actor, hence the Must Support elements in SHC profiles that are derived from AU Core profiles inherit the default SHALL:no-error obligation for data access interactions. This requires the SHC App actor to accept resources containing any valid value for the element without error, including missing data and data absent reason codes and extensions.
The SHC profiles may specify additional obligations for the SHC App actor related to data access for prepopulation and writeback interactions, these may include:
| Code | Interactions | SHC App Obligations |
|---|---|---|
| SHALL:process | Prepopulation | Indicates the element SHALL be processed as part of prepopulation. |
| SHALL:populate-if-known | Writeback (create and patch) | Indicates the element SHALL be populated when a value is available, either from prepopulation or user entry. |
| SHALL:populate | Writeback (create and patch) | Indicates the element SHALL be populated as a value will always be known and allowed to be shared. |
Some elements labeled as Must Support reference multiple resource types or profiles (e.g., QuestionnaireResponse.author). SHC Host FHIR Server SHALL support at least one referenced resource or profile for each element listed in the table below. The SHC App SHALL support all referenced resources or profiles listed in the table below.
For example, when claiming conformance to the SHC QuestionnaireResponse profile:
Some elements labeled as Must Support allow different data types (e.g., Observation.effective[x]) for their content. SHC Host FHIR Server SHALL support at least one data type for each element listed in the table below. SHC App SHALL support all data types listed in the table below.
For example, when claiming conformance to the AU Core Diagnostic Result Observation profile:
Observation.effectiveDateTime, Observation.effectivePeriod, or both if the element is available.Observation.effectiveDateTime and Observation.effectivePeriodSystems MAY support populating and processing other choice elements not listed in the table (such as Observation.effectiveInstant), but this is not a requirement.
There are situations when information on a particular data element is missing, and the source system does not know the reason for the absence of data.
If the SHC Host FHIR Server does not have data for an element with a minimum cardinality = 0 (including elements labeled Must Support), the data element SHALL be omitted from the resource.
If the SHC Host FHIR Server does not have data to be included, the reason for the absence has to be specified as follows:
A SHC App SHALL be able to accept resource instances containing data elements asserting missing data without error. This is except for when the Must Support element has an SHC App obligation of SHALL:process and an SHC Host FHIR Server obligation of SHALL:populate, where the SHC App MAY report an error due to not being able to perform the prepropulation process.