Mongolian HDIT Implementation guide - Local Development build (v1.0.0). See the Directory of published versions

Versioning

Versioning of the FHIR standard

FHIR is a standard that is still undergoing changes. As with all standards there is a need for evolution in order to be useful. On the other hand, the evolution needs to be predictable and manageable for the implementers and conformers. As a part of this process five levels of stability for implementation readiness associated with different areas of the specification have been defined:

1. Draft
   A section that is not considered to be complete enough to be safe for implementation.
2. Trial Use
   The content has been well reviewed and is deemed ready for use in production systems. It has been approved as an official standard, but has not yet seen enough implementation in production systems across the full spectrum of environments it is intended for. If trial use content is not compatible with future versions of FHIR, significant changes may be made to the content.
3. Normative
   The content is considered stable and has been locked for changes within the FHIR Inter-version Compatibility rules. Meaning changes may be made but are expected to be infrequent, tightly constrained and backwards compatible.
4. Informative
   Content provided for implementer assistance which bears no requirements to follow.
5. Deprecated
   Outdated content which may be withdrawn in future versions of the specification.

FHIR Artifact maturity levels

On an artifact level, each artifact is assigned a maturity level which can be used by implementers to assess how stable the artifact is. The FHIR Maturity levels (FMM) are based on the previously existing Capability Maturity Model (CMM).

The following levels are defined:

1. Draft(0)
   This artifact is published in the current build.
2. FMM 1
   The artifact produces no warnings during the build process and the responsible working group has indicated that they consider the artifact substantially complete and ready for implementation.
3. FMM 2
   Follows the conditions of FMM 1 and the artifact has been tested and proven to successfully support interoperability in at least three independently developed systems leveraging at least 80% of the core data elements using semi-realistic data during a connectathon. These interoperability results must have been reported to and accepted by the FHIR Management Group.
4. FMM 3
   Follows the conditions of FMM 2 and the artifact has been verified to meet the conformance resource quality guidelines by the work group meeting, has been subject to a round of formal balliting, has at least 10 distinct implementer comments recorded in the tracker drawn from at least 3 organizations resulting in at least substantive change.
5. FMM 4
   Follows the conditions of FMM 3 and has been tested across it’s scope, published in a formal publication and implemented in multiple prototype projects. Responsible work group agrees the artifact is stable enough to require implementer consultation for non-backward compatible changes.
6. FMM 5
   Follows the conditions of FMM 4 and has been published in two formal publication release cycles at FMM1+ (i.e. Trial-Use level) and has been implemented in at least 5 independent production systems in more than one country.
7. Normative
   The artifact is now considered stable.

FHIR Releases and versioning

FHIR is expected to have a release cycle of approximately 18-24 months based on the timeliness required to consult with implementers, develop and review new content as well as formal balloting and reconciliation process required for ANSI-approved standards.

The FHIR version policy is based on Semantic versioning but deviates somewhat since FHIR is a standard and not an API.

Each FHIR version is identified by a string consisting of four parts:

publication.major.minor.revision

Publication is incremented when FHIR is published as an updated specification; a Trial Use or Normative version. Note that version 2 was skipped to align major numbers at implementer request.

Major increments every time a breaking change is made and is reset in every new publication.

Minor increments for each official snapshot release that is generated that contains one or more substantive changes and resets every time the major version changes.

Revision is a hash for the GIT version from which the specification was built for tracing publication and tooling issues.

Versioning of the Mongolian national implementation guide

The Implementation guide should be seen as a singular artifact that is versioned as a whole.

This means that as resources are added or changed, the version of the Implementation guide is incremented. Individual resources should not be versioned by themselves, but rather a level of maturity should be defined reflecting how mature the resource is based on the level and types of review it has been subject to. The maturity model defined by HL7, detailed in section 6.2 can be used as inspiration for a national model.

A given version of the Mongolian national implementation guide is always based on a specific version of the FHIR standard.

Further development of the Mongolian national implementation guide

The resource profiles of the mongolian national implementation guide are subject to change as experience is gathered from implementers such as EHR implementers, third party systems and clinicians up to a point where they are considered mature. This is a part of continuous development and maintenance of the national infrastructure.

Releases of new versions of the guide should be made with care and after consultation with the national implementers.

A firm recommendation is to at any given time provide support in HIEP for two published versions of the national implementation; the current version and the previous version.

For future versions a development environment should be made available where implementers can test changes and provide feedback.

New releases of the Mongolian national implementation guide should not be done too frequently. Rather the recommendation is to gather changes and release on a semi-set interval, no more frequently than once every 12 months. Too frequent releases will cause exhaustion from implementers and make adoption harder.

For version numbering of the implementation guide, semantic versioning is used.