FHIR Conformance Levels Issue Page

Conformance levels

Suggest that we formally define 3 conformance levels for a given profile. Conformance applies to the full semantics of a given profile, including all imported profiles. Conformance can be asserted both against the underlying FHIR specification (i.e. directly to the internationally-defined resources) or to another FHIR profile.

1. FHIR Interoperably conformant

This level means that the profile is both technically compliant with the FHIR specification and also means that no constraints have been introduced that would negatively impact out-of-the-box interoperability with other FHIR implementations. I.e. It should not be necessary to perform any configuration or write any code in order for another interoperably-conformant system to send or receive FHIR instances from another interoperably conformant system.

"Interoperably conformant" should be the target conformance level for all implementers, but may not be achievable for a variety of reasons such as limitations of legacy components, regulatory requirements or development timelines. The extreme looseness of resource definitions at the international level will often require non-interoperable conformance in order to construct profiles that reflect the business requirements of a particular domain. That said, Implementers and policy bodies that define profiles should carefully weigh the long term costs of the resulting interoperability issues as compared to the cost of resolving and removing the requirement driving the non-interoperable constraint.

Examples of non-interoperable constraints includes:

• Introducing “must understand” to an element
• Constraining the use of dataAbsentReason
• Changing the allowed cardinality of an element
• Constraining the value set of allowed instances such that non-supported codes will be rejected

2. FHIR Technically conformant

This level is the same as Interoperably conformant, but introduces at least one constraint that could result in interoperability issues. Technically conformant requires:

• The profile only draws on resources defined by HL7 International
• Instances are schema-compliant and Schematron-compliant with the internationally-defined resources

3. FHIR-aligned

This refers to systems that are not compliant with FHIR but are constructed using the same tooling stack, technical approach and philosophy as FHIR. In general, it will require less work for a FHIR compliant system to interoperate with a FHIR-aligned system than one that is not, but FHIR-alignment is not a desired target state for any implementation. FHIR alignment does not have any formal criteria or standing with HL7.

Vetting

An additional assertion can be made about FHIR profiles based on the extensions referenced. A profile that references only HL7-vetted extensions can be called “strict”. In theory, strict profiles should provide a greater degree of confidence in the RIM mappings and definitions that support the profile as well as non-overlap (or at least well-defined overlap) with other extensions.

Examples

Examples of conformance assertions include:

• Profile XYZ has strict FHIR Interoperability conformance.
• Application ABC is Interoperably Conformant with profile XYZ.
• Profile XYZ is FHIR Technically conformant.
• Application DEF is FHIR-aligned

Discussion

GG:

• Why would we do this? what's the benefit - what actual difference will this make?
  • In part so that expectations are clear. The bulk of profiles *won't* be "Interoperably conformant". Which means that even if both systems are fully technically conformant, they probably won't interoperate out-of-the-box. And it helps identify what sorts of things to be very cautious about introducing into your profiles. There's no question these sort of constraints will often be necessary, but it's wise to avoid any that you can get away with avoiding
• How many profiles are going to be interoperability conformant?
  • Some, but probably not the majority. The more general you want to make a system, the more interoperably conformant it will be
• This sounds like complexity for complexity's sake to me.
  • It's just labelling. It should be possible to render a profile and clearly flag those things that aren't interoperably conformant. When you're working on internal configuration or setting up your interface engine or transforms, these will be the points where the work will be
• I don't actually know how you could write a profile that is only FHIR-aligned at this time.
  • Once you're outside the the bounds of conformance, a profile could look like anything at all. I'm not expecting to see formal conformance profiles from "FHIR-aligned" implementations, though I suppose one variant - those that use a profile based wire format could produce them. The objective with the third category is just to give a common name for everything outside the box.