Multi-language FHIR Implementation Guide
1.0.0 - ci-build
Multi-language FHIR Implementation Guide
1.0.0 - ci-build
Provide feedback on this page: File Feedback
Multi-language FHIR Implementation Guide - Local Development build (v1.0.0). See the Directory of published versions
| Official URL: http://fhir.example.com/ImplementationGuide/poster.fhir | Version: 1.0.0 | |||
| Draft as of 2023-11-13 | Computable Name: PosterCore | |||
The Multi-language FHIR Implementation Guide is based on US Core v4.1.0 , FHIR R4, and Structured Data Capture STU3. It defines FHIR profiles, extensions, and additional guidance for FHIR data use within Verily products. It aims to define a FHIR implementation that is useful for improving the efficiency, cost, and clinical outcomes of healthcare delivery. It is maintained by Verily FHIR IG Council with contributions from various Verily teams.
This IG is developed based on the FHIR USCore IG, with further restrictions and extensions for the Verily use cases. Nothing in this IG should contradict UScore or the standard FHIR specification, as it will jeopardize the interoperability when Verily needs to exchange FHIR data with partners. This IG defines a set of FHIR resource profiles and their intended usage. However it does not prevent an implementer to use a resource that’s not profiled in this IG, as long as the use case can not be covered by the profiled resources. In general for any FHIR resource, implementers should seek requirements from this IG, then UScore, then standard FHIR specification.
Each FHIR resource can contain many elements based on the FHIR specification. FHIR defines the cardinality of each element in the format of (min..max), where min is a non-negative integer, and max is either a non-negative integer or “”. For example, a cardinality of (1..1) indicates the element is required (min=1), and can only have a single instance (max = 1), a cardinality of (0..) indicates the element is not required (min=0), and can have as many instances as needed (max=*). For the resource profiles in this IG, if a resource element is labeled as “required”, then it means the cardinaily has min=1.
FHIR itself does not have a notion of a “recommended” field, however, in a FHIR IG, a field can be specified as “must support”, meaning although the field could be missing, it must be supported when it is not missing. We specify “recommended” fields in the FHIR profiles, and use this to also imply that the implementation “must support” these fields.
The general principles are: If a field is required in FHIR standard or UScore, then it’s required in this IG. In addition, if a field is deemed important to almost all major Verily use cases (missing this field will make the data essentially unusable), then it is required. If a field is important only to certain use cases, it is deemed recommended.
A required element is indicated by a minimum cardinality of 1 and the MS (Must
Suppport) flag. If this element is missing then the FHIR resource becomes unusable.
A recommended element has a minimum cardinality of 0 and the MS flag. If a
resource does not provide all MS elements then it may result in degraded functionality or performance. In some situations the exact degradation will be described in the element definition.
For background on cardinality and must support see:
Many resource elements have coded values, the resource profile specifies the value set that these elements should bind to. Each value set is a collection of codes from one or more code systems. There are different binding strength, namely required, extensible, preferred, and example. In this IG, we strive to use the UScore and FHIR standard valueset whenever available, especially when their binding strength is “required”.
However, there are cases where FHIR and USCore only provide an “example” value set for a field which does not satisfy our needs, in which case we need to extend or define new value set/ code systems locally.
FHIR requires that every code system and value set to have a canonical url which can be resolved to a webpage with clear definition and descriptions. For local code systems and value sets defined in this IG, we propose to use the following url convention:
This guide is broken into roughly 2 types of content:
The navigation menu at the top helps explore this content. An exhaustive list of all pages in this implementation guide can be found on the Table of Contents.