FHIR API
Zus's operational data store is based on FHIR. We offer a robust FHIR REST API, as detailed in our API Reference.
Zus uses FHIR's validation framework to evaluate whether resources written to the ZAP meet a minimum threshold of data validity.
Base FHIR Validation
FHIR evaluates validity based on the following aspects of a resource:
- Whether the overall structure of the resource conforms to the structure definition of the resource type
- Whether each property in the resource has the right cardinality (required properties are present, and no property exceeds its maximum allowed number)
- Whether each property conforms to its allowed data types
- Whether data represented as enums or coded values conform their allowed values
The base FHIR resource definitions lay out the allowed structure to which implementers should conform. Here is an example from the FHIR Patient resource.
Annotated snapshot of the base FHIR Patient structure definition
Implementation Guides & Profiles
Depending on the specific use case and context, implementers often have varying needs when it comes to the exact specification they need to enable, e.g.:
- Required and allowed fields
- Search capabilities
- Terminologies
To accommodate this variability, FHIR defines the following concepts and artifacts:
| Artifact | Description | Examples from US Core |
|---|---|---|
| Profile | A structure definition representing a set of constraints on a resource. Constraints can include cardinality, Must Support fields, and value set expectations. | US Core Patient profile C4BB Patient profile |
| Conformance Resource | A single resource in a package that describes how an implementation should work. Conformance resources can include structure definitions, operation definitions, and search parameters. | US Core Birth Sex C4BB Patient Identifier Type |
| Implementation Guide (IG) | A set of profiles and conformance resources that are published as a single package for a given use case. | US Core Implementation Guide CARIN Consumer Directed Payer Data Exchange (C4BB) |
For more detailed information on the conformance specification, visit the FHIR Conformance Module.
Validating Against a Specific Profile
At minimum, Zus will validate each resource you write to ODS against its base FHIR specification. If you want Zus ODS to validate certain resources against an available profile, you must declare the profile in the meta property when writing the resource.
Example of a patient resource with a declared profile in the meta property
If A Resource Fails Validation...
For error-level failures (i.e., against rules that each resource must conform to), ODS will NOT allow the resource to be written. You will receive an OperationOutcome response that has a list of all validation messages, including info, warning, and error level messages. Today, ODS only requires you to fix the validation issues that have an error-level severity.
Implementation Guides Available Today
Zus loads implementation guides into ODS as FHIR packages. Once we load an IG, you can validate your records against its underlying profiles by declaring them in the meta property.
The following implementation guides are available in the Zus ODS today:
- US Core, version 4.0.0
- CARIN-BB, version 1.2.0
- Bulk Data Access, version 1.0.1
Zus ODS also includes all FHIR Definitions that are part of FHIR R4 (version 4.0.1).
Additional implementation guides defined by the FHIR community are listed in the Implementation Guide Registry. If you would like to use an IG that is not currently available on Zus, please submit a support ticket to us here.
Updated about 1 month ago