The HSPC Sandbox is taking steps toward supporting FHIR profile storage, retrieval and validation. Along with this effort comes the storage/hosting of the terminology necessary to accommodate the profiling features. In this blog post I will outline the upcoming features related to profiles, along with some examples of how these features can be useful in the development of SMART on FHIR apps. The efforts are currently focused on support for FHIR STU3, and all examples and documentation are using this FHIR version.
...
Terminology is at the heart of all FHIR resources. Because of this, we've dedicated a sandbox in the HSPC Sandbox Reference API to the storage and retrieval of terminology. This sandbox conforms the the FHIR specification of a Terminology Service, and can be used by clients to "...make use of codes and value sets without having to become experts in the fine details of code system, value set and concept map resources, and the underlying code systems and terminological principles." (source). The HSPC Sandbox Terminology Service contains more than 631,310 concepts and relationships, broken down as follows:
- SNOMED CT International RF2 (336,893 concepts)
- LOINC 1.61 (111,803 concepts)
- HL7 v2 & HL7 v3 codes backing FHIR v3.0.1
...
It's possible to list all members of a particular value set using the $expand operation operation. To illustrate this, lets let's take a very simple value set defined by {{http://hl7.org/fhir/administrative-gender}}. This is the Administrative Gender value set used to define the gender of the base FHIR Patient resource. The resource itself is available making the following call:
...
Notice that we get the definition of the value set, but not the actual members of the value set. To get those, we can use the expand operatorthe $expand operator:
| Code Block |
|---|
GET http://api-v5-stu3.hspconsortium.org/term01/open/ValueSet/administrative-gender/$expand |
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
{
"resourceType": "Parameters",
"parameter": [
{
"name": "result",
"valueBoolean": false
},
{
"name": "message",
"valueString": "Code not found"
}
]
} |
You
...
can
...
read
...
more
...
about
...
the
...
$validate-code
...
operation here.
Code lookup
Another useful task when developing apps is retriving retrieving details about a particular code. Say you have access to the code value, but not the the display value. To look up the the display you can make the request:
...
Profiling is a broad term in FHIR, but generally it is the process adding additional restrictions to base FHIR resources. These additional restrictions often include restricting properties to a particular value set or making properties required (editing cardinality). This type of profiling can increase interopability and is encouraged in the FHIR ecosystem.
These profile specifications are expressed using the StructureDefinition resource, providing a machine readable interpretation of the profiled resource. All base FHIR profiles have a corresponding StructureDefinition resource and the FHIR spec also defines profiled versions of some resources to accomodate common use-cases. Further, it's common for organizations to partner in creating their own StructureDefinitions which expand on the base FHIR defintions in order to accomodate the sharing of data around a particular domain.
The HSPC Terminology Service contains all base FHIR StructureDefinition resources (205) and we are working on support for FPAR profiled resources (141). The FPAR resources are stored in the HSPC Terminology Service, however some value set data in incomplete at this time.
Use Cases
This StructureDefinition information is utilized by the server to implement validation functionality. This is exposed with the $validate operation which can be performed at the resource instance level. Validation uses the HL7 "InstanceValidator", which is able to check a resource for conformance to FHIR profiles (StructureDefinitions, ValueSets, and CodeSystems), including validating fields, extensions, and codes for conformance to their given ValueSets.
...
The response to our request is an OperationOutcome containing the results of the validation. In the above instance, no issues were detected.
This operation can be useful in ensuring that no data is lost in the creation of the resource. If we were to add a field which isn't defined on the server (not contained in the StructureDefinition), it is acceptable behavior for the server to discard this field and save the remiander of the data. To avoid this, your application can call the validate endpoint before each save or update if there is any doubt about the data integrity.
Let's show an example that does just this, adds a field the server isn't prepared to handle:
...
A slightly more advanced use of the $validate operation would be to verify that property values are a member of the correct value set. Let's return to using our example value set, administrative-gener. The FHIR Patient resource specifis specifies that the Patient.gender field MUST be one of the values in this value set. Let's post a validation request containing the value "incorrect" for gender and see what happens.
...