Capabilities

While implementers are free to pick and choose useful functionality from this IG as they see fit, in order to claim conformance with this IG, a system must declare that it implements one or more of the four capability statements described on the Workflow page. I.e. All systems that conform with this specification must, at minimum, satisfy the SHALL requirements listed in at least one of the following CapabilityStatement instances:

• Care Manager,
• Patient Engagement App,
• Full Service Provider, and/or
• Light Service Provider

Conventions

This implementation guide documents conformance expectations through declarations in computable artifacts, such as cardinality and vocabulary bindings in IG profiles. However, it also makes use of conformance language in the text of the IG. When expressed in upper-case, the words SHALL, SHOULD, MAY, etc. are to be interpreted as described in the FHIR core specification here.

Must Support

FHIR defines the notion of Must Support to help establish conformance expectations for systems. The specific meaning of "must support" is left to be defined in individual implementation guides. For the purposes of this implementation guide, "must support" shall be interpreted as follows:

• Data Sources SHALL be capable of populating the data element when sharing resources compliant with the profile. I.e. the system must be able to demonstrate the population and sharing of the element, but it is acceptable to omit the element if the system does not have values in a particular instance. A system that is incapable of ever sharing the element would be non-conformant.
• Data Consumers SHALL be capable of processing resource instances containing the data elements and doing something useful with them - i.e. displaying, storing, or any other action a reasonable user would expect the system to take with a 'supported' element of that type.
• If the minimum cardinality of an element is greater than 0 – i.e. the element is ‘required’, then the element SHALL be present in the instance and SHALL have a value unless:
  • The profile explicitly declares the data-absent-reason extension or other extension for the element, in which case an extension can be present in place of the value.
  • The profile is inherited from U.S. Core, in which case a data-absent-reason extension may be sent in place of the value even where data-absent-reason is not explicitly declared in the profile.
• Data Consumers SHALL interpret missing data elements within resource instances as data not being present in the Data Source's systems or was not deemed to be shareable with the Data Consumer for privacy or other business reasons.
• Where the value set for an element includes concepts such as "unknown", "refused to answer", "not available" or where data-absent-reason is explicitly referenced in a profile, then Data Sources SHALL use these values/that extension to communicate the reason for missing data.
• Data Consumers SHALL be able to process resource instances containing data elements that have extensions in place of a value where such extensions are declared as part of the profile.

NOTE: These expectations are largely drawn from those defined in the Da Vinci Health Record Exchange (HRex) IG.

Handling profiles and modifiers

This IG makes significant use of profiles to describe both the expected content of instances, as well as which data elements systems are expected to support. However, not all data hosted by a system will necessarily comply with one of the profiles defined in this IG. Data consumers SHALL tolerate receipt of data in response to queries that does not comply with profiles defined in this IG, though they MAY opt to ignore data that does not conform to the profiles or choose to process it. All resources that declare a Physical Activity category SHOULD conform with their respective profile(s) in this IG.

In addition to potentially receiving non-conformant data, conformant instances MAY contain additional data elements not marked in these profiles as 'mustSupport. So long as the elements found are valid in the base FHIR R4 resource definitions, systems SHALL accept such instances unless the elements present are modifier elements. Non-modifier elements MAY be ignored. Modifier elements will generally cause the instances to be non-conformant with the profiles of this IG and may be either ignored or subject to special processing that takes into account the fact that the meaning of the instances may differ from what is typically expected.

If a system has data with modifier elements that are prohibited by this specification, it is free to send such data. However, these resources will not comply with the profiles defined here and might be ignored by receiving systems.

There is NO expectation that instances conforming with this implementation guide will declare their conformance by asserting a meta.profile value, though systems MAY choose to do so. Systems SHALL NOT depend on the declaration of such profiles when consuming data.

Terminology expectations

This implementation guide makes use of several external terminologies, including LOINC, SNOMED CT and CPT codes. In some places, the IG has identified the need for a code that does not yet exist in any of these external locations, but which probably makes sense to be added to one of those code systems. In this case, we have defined 'temporary' codes in the [temporary-codes](CodeSystem-temporary-codes.html) Code system. The location and value of these codes WILL change in a future release of the specification. Implementers should plan to accommodate this as part of their designs.

Some of the value sets referenced in this IG are not explicitly enumerated. Instead, they are defined by filters on the underlying code systems. Others are maintained outside of the FHIR core specification and this IG. In either case, this may result in the set of codes that are valid changing over time. Systems SHALL allow for this potential evolution and SHALL NOT reject a code that might be valid unless they have an up-to-date copy of the underlying code-system and value set definition. Systems SHOULD ensure that their internal mappings are kept up-to-date as the list of available codes change.