FHIR Maturity Model

This page describes the 5 level FHIR maturity model for FHIR artifacts. It's based on the CMM (Capability Maturity Model) framework, and the intention is to give implementers a sense of how mature an artifact is based on the level and types of review it has been subject to. These criteria may evolve over time.

Draft

• FMM0 = the artifact has been published on the current build. Artifacts with this level must have a standards status of Draft.

Draft or STU

• FMM1 = FMM0 + the responsible WG has indicated that they consider the artifact substantially complete and ready for implementation. For resources, profiles and implementation guides, the FHIR Management Group has approved the underlying resource/profile/IG proposal.
  • QA expectation is that the artifact produces no unsuppressed warnings during the build process.
• FMM2 = FMM1 + the artifact has been tested and successfully supports interoperability among at least three independently developed systems leveraging most of the scope (e.g. at least 80% of the core data elements) using semi-realistic data and scenarios based on at least one of the declared scopes of the artifact (e.g. at a connectathon, prototype, production, etc.). These interoperability results must have been reported to and accepted by the FMG.

STU

• FMM3 = FMM2 + has passed STU ballot and has evidence of broad review - e.g. at least 10 distinct implementer comments recorded in the tracker drawn from at least 3 organizations resulting in at least one substantive change, or evidence of widespread adoption.
  • QA expectation is that the artifact has been verified by the work group as meeting the Conformance Resource Quality Guidelines (including no unsuppressed 'information' messages in the build process).
• FMM4 = FMM3 + the artifact has been tested across its scope (see below), published in a formal publication (e.g. STU), and implemented in multiple prototype projects. As well, the responsible work group agrees the artifact is sufficiently stable and/or the FMG believes there is sufficient widespread use (implementation or downstream specifications) to require implementer consultation for subsequent non-backward compatible changes.
• FMM5 = FMM4 + the artifact has been published in two formal publication release cycles at FMM1+ (i.e. STU level) and has been implemented in at least 5 independent production systems.  For international specifications, production implementation must have taken place in more than one country.

Normative

• (No declared FMM) = FMM5 + the artifact has passed HL7 normative ballot and the responsible work group and the FMG agree the material is ready to lock down according to the inter-version change rules.

Deprecated

• (No declared FMM) = The work group and FMG have agreed that the artifact should no longer be used and that an appropriate alternative has been documented.  A ballot has passed where the new Deprecated status has been accepted by the community.

Withdrawn

• (No declared FMM) = A deprecated artifact has undergone at least one further ballot cycle and a minimum of 2 years after first being designated as Deprecated.

Notes:

• Any of the criteria can be waived provided the sponsoring WG can convince the FMG that that criteria should not apply in the case of a specific artifact.
• Tested across scope means:
  • The FMG has signed off on the list of "example contexts" defined for the artifact- For each example context, the artifact has either been: reviewed and approved by a domain expert for that scope area, mapped to an existing implemented scope-area-specific standard or tested in an implementation
• In cases where functionality is being moved, renamed, or refactored, the maturity level will typically NOT reset back to zero, but will reflect implementation and review experience from its previous incarnation.  In situations where an artifact is truly "starting from scratch or the scope has been significantly changed", the FMG may agree to the maturity being dropped back down to 0 or 1.
• In most cases, if an artifact is derived from or otherwise depends on another artifact, the derived artifact cannot be more mature than the artifact referenced. However, FMG may make general or specific exceptions to this rule.
• In some cases, an artifact may have components or dependencies that are a lower level than the resource overall. For example, a resource may have been well tested, with the exception of one or two data elements which are "new" or that have limited production use due to the distribution of early adopters. In these cases, a "maturity note" will be provided that highlights areas of the resource that are considered "less mature" than the resource as a whole.
• In most cases artifacts are only marked as Deprecated or Withdrawn if they have already achieved Normative status.  Prior to Normative, artifacts found to no longer be appropriate/necessary are simply removed in the next version.