Timelines - FHIR v1.6.0

~~This page is part of the FHIR Specification (v1.0.2: DSTU 2). The current version which supercedes this version is~~

This page is part of the FHIR Specification (v1.6.0: STU 3 Ballot 4). The current version which supercedes this version is 5.0.0 ~~. For a full list of available versions, see the Directory of published versions~~ . For a full list of available versions, see the Directory of published versions ~~. Page versions:~~ . Page versions: R3 R2

1.9 2.13 FHIR Timelines FHIR Timelines

FHIR is a standard. In order to be useful, standards need to evolve. At the same time, the evolution of standards needs to be predictable and manageable for the implementation community. This section provides forward-looking statements about the expected pattern of FHIR releases as well as the degree of stability and change implementers should expect from the standard as it continues to evolve.

~~FHIR Infrastructure~~ FHIR Infrastructure

~~Work Group~~ Work Group

~~Maturity Level : N/A~~ Maturity Level : N/A

~~Ballot Status : DSTU 2~~ Ballot Status : STU 3

1.9.1 Standard Levels 2.13.1 Standard Levels FHIR has three descriptive terms that describe the level of stability and implementation readiness associated with different aspects of the specification. They are as follows: Standard Level

FHIR has three descriptive terms that describe the level of stability and implementation readiness associated with different aspects of the specification. They are as follows:

Standard Level	Description Draft This portion of the specification is not considered to be complete enough or sufficiently reviewed to be safe for implementation. It may have known issues or still in the "in development" stages. It is included in the publication as a place-holder, to solicit feedback from the implementation community and/or to give implementers some insight as to functionality likely to be included in future versions of the specification. Content at this level should only be implemented by the brave or desperate and is very much "use at your own risk". The content that is draft that will usually be elevated to DSTU once review and correction is complete after ballot
Draft Standard for Trial Use (DSTU) This content has been well reviewed and is considered by the authors to be ready for use in production systems. It has been subjected to ballot and approved as an official standard. However, it has not yet seen widespread use in production across the full spectrum of environments it is intended to be used in. In some cases, there may be documented known issues that require implementation experience to determine appropriate resolutions for. For these reasons, DSTU content is not subject to FHIR Inter-version Compatibility Rules . Future versions of FHIR may make significant changes to DSTU-level content that are not compatible with previously published content. See DSTU suggestions for implementation strategies to help manage the risk of non-compatible future changes. DSTU content can have a wide range of stability ranging from never before implemented even in test systems through to widely implemented in production and well reviewed. FHIR makes use of a Maturity rating that provides insight into how well polished a given resource or other artifact is. Artifacts with higher maturity ratings (4 or 5) will be subject to somewhat tighter constraints on non-backward compatible changes, though these are still possible when deemed to be in the best interests of the implementer community. The maturity model is significantly influenced by the degree and type of implementation activity using an artifact. For this reason, we encourage implementers to share with the FHIR Management Group what artihttps://confluence.hl7.org/display/FHIR/Maturity+Model+Analysisartifacts can be found here	This portion of the specification is not considered to be complete enough or sufficiently reviewed to be safe for implementation. It may have known issues or still in the "in development" stages. It is included in the publication as a place-holder, to solicit feedback from the implementation community and/or to give implementers some insight as to functionality likely to be included in future versions of the specification. Content at this level should only be implemented by the brave or desperate and is very much "use at your own risk". The content that is draft that will usually be elevated to DSTU once review and correction is complete after ballot
Standard for Trial Use (STU)	This content has been well reviewed and is considered by the authors to be ready for use in production systems. It has been subjected to ballot and approved as an official standard. However, it has not yet seen widespread use in production across the full spectrum of environments it is intended to be used in. In some cases, there may be documented known issues that require implementation experience to determine appropriate resolutions for. For these reasons, STU content is not subject to FHIR Inter-version Compatibility Rules . Future versions of FHIR may make significant changes to STU-level content that are not compatible with previously published content. See STU suggestions for implementation strategies to help manage the risk of non-compatible future changes. STU content can have a wide range of stability ranging from never before implemented even in test systems through to widely implemented in production and well reviewed. FHIR makes use of a Maturity rating that provides insight into how well polished a given resource or other artifact is. Artifacts with higher maturity ratings (4 or 5) will be subject to somewhat tighter constraints on non-backward compatible changes, though these are still possible when deemed to be in the best interests of the implementer community. The maturity model is significantly influenced by the degree and type of implementation activity using an artifact. For this reason, we encourage implementers to share with the FHIR Management Group what artifacts they have implemented. A detailed analysis of the maturity metrics for FHIR artifacts can be found here . . Note: STU specifications were previously called DSTU (Draft Standard for Trial Use). The name has been changed due to the reluctance of implementers to make use of a "draft" specification - when the whole purpose of the STU phase is for implementers to exercise the specification.
Normative This content has been subject to review and production implementation in a wide variety of environments. The content is considered to be stable and has been 'locked', subjecting it to FHIR Inter-version Compatibility Rules . While changes are possible, they are expected to be infrequent and are tightly constrained. The above statuses can apply to both the standard overall as well as to individual components of the FHIR specification. Specification components cannot ever have a "higher" standard level than the overall specification, but they can have lower levels. For example, at DSTU, FHIR can include draft content. When it reaches Normative, FHIR may include some content that remains at DSTU or draft levels if that content has not yet reached the criteria for normative. All content that is at a different ballot level than the overall specification will be clearly identified.	This content has been subject to review and production implementation in a wide variety of environments. The content is considered to be stable and has been 'locked', subjecting it to FHIR Inter-version Compatibility Rules . While changes are possible, they are expected to be infrequent and are tightly constrained.

Standard Level

Description Draft This portion of the specification is not considered to be complete enough or sufficiently reviewed to be safe for implementation. It may have known issues or still in the "in development" stages. It is included in the publication as a place-holder, to solicit feedback from the implementation community and/or to give implementers some insight as to functionality likely to be included in future versions of the specification. Content at this level should only be implemented by the brave or desperate and is very much "use at your own risk". The content that is draft that will usually be elevated to DSTU once review and correction is complete after ballot

Draft Standard for Trial Use (DSTU) This content has been well reviewed and is considered by the authors to be ready for use in production systems. It has been subjected to ballot and approved as an official standard. However, it has not yet seen widespread use in production across the full spectrum of environments it is intended to be used in. In some cases, there may be documented known issues that require implementation experience to determine appropriate resolutions for. For these reasons, DSTU content is not subject to FHIR Inter-version Compatibility Rules . Future versions of FHIR may make significant changes to DSTU-level content that are not compatible with previously published content. See DSTU suggestions for implementation strategies to help manage the risk of non-compatible future changes. DSTU content can have a wide range of stability ranging from never before implemented even in test systems through to widely implemented in production and well reviewed. FHIR makes use of a Maturity rating that provides insight into how well polished a given resource or other artifact is. Artifacts with higher maturity ratings (4 or 5) will be subject to somewhat tighter constraints on non-backward compatible changes, though these are still possible when deemed to be in the best interests of the implementer community. The maturity model is significantly influenced by the degree and type of implementation activity using an artifact. For this reason, we encourage implementers to share with the FHIR Management Group what artihttps://confluence.hl7.org/display/FHIR/Maturity+Model+Analysisartifacts can be found here

This portion of the specification is not considered to be complete enough or sufficiently reviewed to be safe for implementation. It may have known issues or still in the "in development" stages. It is included in the publication as a place-holder, to solicit feedback from the implementation community and/or to give implementers some insight as to functionality likely to be included in future versions of the specification. Content at this level should only be implemented by the brave or desperate and is very much "use at your own risk". The content that is draft that will usually be elevated to DSTU once review and correction is complete after ballot

Standard for Trial Use (STU)

This content has been well reviewed and is considered by the authors to be ready for use in production systems. It has been subjected to ballot and approved as an official standard. However, it has not yet seen widespread use in production across the full spectrum of environments it is intended to be used in. In some cases, there may be documented known issues that require implementation experience to determine appropriate resolutions for.

For these reasons, STU content is not subject to FHIR Inter-version Compatibility Rules . Future versions of FHIR may make significant changes to STU-level content that are not compatible with previously published content. See STU suggestions for implementation strategies to help manage the risk of non-compatible future changes.

STU content can have a wide range of stability ranging from never before implemented even in test systems through to widely implemented in production and well reviewed. FHIR makes use of a Maturity rating that provides insight into how well polished a given resource or other artifact is. Artifacts with higher maturity ratings (4 or 5) will be subject to somewhat tighter constraints on non-backward compatible changes, though these are still possible when deemed to be in the best interests of the implementer community.

The maturity model is significantly influenced by the degree and type of implementation activity using an artifact. For this reason, we encourage implementers to share with the FHIR Management Group what artifacts they have implemented. A detailed analysis of the maturity metrics for FHIR artifacts can be found here . .

Note: STU specifications were previously called DSTU (Draft Standard for Trial Use). The name has been changed due to the reluctance of implementers to make use of a "draft" specification - when the whole purpose of the STU phase is for implementers to exercise the specification.

Normative This content has been subject to review and production implementation in a wide variety of environments. The content is considered to be stable and has been 'locked', subjecting it to FHIR Inter-version Compatibility Rules . While changes are possible, they are expected to be infrequent and are tightly constrained. The above statuses can apply to both the standard overall as well as to individual components of the FHIR specification. Specification components cannot ever have a "higher" standard level than the overall specification, but they can have lower levels. For example, at DSTU, FHIR can include draft content. When it reaches Normative, FHIR may include some content that remains at DSTU or draft levels if that content has not yet reached the criteria for normative. All content that is at a different ballot level than the overall specification will be clearly identified.

This content has been subject to review and production implementation in a wide variety of environments. The content is considered to be stable and has been 'locked', subjecting it to FHIR Inter-version Compatibility Rules . While changes are possible, they are expected to be infrequent and are tightly constrained.

The above statuses can apply to both the standard overall as well as to individual components of the FHIR specification. Specification components cannot ever have a "higher" standard level than the overall specification, but they can have lower levels. For example, at STU, FHIR can include draft content. When it reaches Normative, FHIR may include some content that remains at STU or draft levels if that content has not yet reached the criteria for normative. All content that is at a different ballot level than the overall specification will be clearly identified.

1.9.2 2.13.2 FHIR timeline FHIR timeline New versions of FHIR will be published on a release cycle of aproximately 18-24 months. This frequency is based on the timelines necessary to develop, implement and review new content as well as the time necessary to undertake the formal balloting and reconciliation processes required for ANSI-approved standards. This release cycle also ensures an opportunity to incorporate implementer feedback from earlier versions of the specification into subsequent versions. In some situations, the FHIR Management Group may authorize a limited-scope release on a shorter timeline where necessary to meet implementer requirements and is achievable with available HL7 resources. This release (DSTU 2) is hoped to be the final publication of the specification at the DSTU level. The subsequent publication of the specification (targeted for 2017) should take the core aspects of the specification and many of the most broadly used resources to Normative level. Whether this timeline will be met will be dependent on uptake and feedback from implementers. This feedback will also govern exactly which resources, profiles and other content become normative. Only content that has been successfully implemented in a wide variety of implementation environments with minimal divergence from the DSTU specification will be candidates for normative. Once FHIR has reached normative status, subsequent publications will continue on the 18-24 month schedule with subsequent releases introducing additional resources, capabilities and other content as well as migrating existing content from draft to DSTU and DSTU to normative, based on the level of implementation. Not all of the intended scope for DSTU 2 was ready in sufficient time to be included in this specification. This includes many resources included in DSTU 2 as draft, as well as refinement of the "request" and "order"-related resources to better flesh out and standardize how workflow occurs. For this reason, an interim release (tentatively labeled 2.1) is planned, likely for publication in Spring, 2016. This release will have a tightly constrained scope and will focus on positioning existing resources for normative ballot in the 2017 release and meeting other urgent implementer requirements.

New versions of FHIR will be published on a release cycle of aproximately 18-24 months. This frequency is based on the timelines necessary to develop, implement and review new content as well as the time necessary to undertake the formal balloting and reconciliation processes required for ANSI-approved standards. This release cycle also ensures an opportunity to incorporate implementer feedback from earlier versions of the specification into subsequent versions.

In some situations, the FHIR Management Group may authorize a limited-scope release on a shorter timeline where necessary to meet implementer requirements and is achievable with available HL7 resources.

The forthcoming release (STU 3) may be the final publication of the specification that is entirely at the STU level. The subsequent publication of the specification (targeted for 2018) will hopefully take the core aspects of the specification and many of the most broadly used resources to Normative level. Whether this timeline will be met will be dependent on uptake and feedback from implementers. This feedback will also govern exactly which resources, profiles and other content become normative. Only content that has been successfully implemented in a wide variety of implementation environments with minimal divergence from the STU specification will be candidates for normative.

Once FHIR has reached normative status, subsequent publications will continue on the 18-24 month schedule with subsequent releases introducing additional resources, capabilities and other content as well as migrating existing content from draft to STU and STU to normative, based on the level of implementation.

1.9.3 DSTU Suggestions 2.13.3 STU Suggestions The FHIR specification is a "Draft Standard for Trial Use" (DSTU). It has been subject to significant review through ballot and other HL7 processes and many aspects of it have been implemented and subjected to interoperability testing through Connectathons and early adoption. However, the degree of testing has varied. Some resources have been well tested in a variety of environments. Others have received relatively little real-world exercise. In general, the infrastructure should be considered to be more stable than the resources themselves. In some cases, there are issues on which input is specifically requested during the DSTU period (see the Outstanding Issue List , and known issues will arise after publication (refer to the FHIR Change Request tracker for details.) Guidance from early implementation will help address these areas. Regardless of the degree of prior implementation, all aspects of the FHIR specification are potentially subject to change. These changes may be minor (clarifications of definitions, etc.) or major (refactoring of resources, changes to serialization rules, eliminating or adding data types, etc.) There is no commitment to backward or forward compatibility during the DSTU process. Changes will not be made without cause, however the interests of long-term implementability will generally trump the impact on early adopters when determining what changes should be made. This specification has been promoted to DSTU because it is felt that the specification, as is, is implementable and that more value can be gleaned from implementer experience than from subsequent review as part of the ballot process. Implementers who are willing to accept the risk of change (perhaps for the benefit of early implementation experience, first mover advantage and the ability to leverage FHIR's intrinsic benefits) are encouraged to implement FHIR in real-world systems. However, those implementers should be aware that local adaptations may be necessary to meet real-world requirements. Furthermore, such implementers should architect their solutions to be tolerant of changes to the specification and, where necessary, to manage interoperability with systems that may be using different versions of the specification or different local adaptations. During the DSTU period, requests for change may be submitted using the HL7 gForge tracker which can be found here

The FHIR specification is a "Standard for Trial Use" (DSTU). It has been subject to significant review through ballot and other HL7 processes and many aspects of it have been implemented and subjected to interoperability testing through Connectathons and early adoption. However, the degree of testing has varied. Some resources have been well tested in a variety of environments. Others have received relatively little real-world exercise. In general, the infrastructure should be considered to be more stable than the resources themselves. In some cases, there are issues on which input is specifically requested during the STU period (see the Outstanding Issue List , and known issues will arise after publication (refer to the FHIR Change Request . Where possible, updates to the "development" version of the specification will be made in a timely fashion. A list of these proposed changes will be published as a continuously updated supplement to the official DSTU publication. Implementers should be aware that the changes are not considered "official" until such time as they are balloted and approved as part of a subsequent DSTU or Normative publication. Change requests might be fixes to allow implementation, clarifications or enhancements. In addition, HL7 will be developing and introducing additional resources and profiles as part of the FHIR specification. SDOs and regulatory bodies that are interested in making use of the FHIR specification should feel free to do so, but should consider and plan for the possibility that the specification will evolve and change prior to becoming normative. A key objective of the DSTU process is gaining feedback from implementers making use of the specification. As well, HL7 has a need to monitor which portions of FHIR are being implemented in what sorts of environments so as to make an informed decision on when the specification is ready to proceed to Normative status. For this reason, all FHIR implementers are asked to complete a short survey which can be found here tracker for details.) Guidance from early implementation will help address these areas.

Regardless of the degree of prior implementation, all aspects of the FHIR specification are potentially subject to change. These changes may be minor (clarifications of definitions, etc.) or major (refactoring of resources, changes to serialization rules, eliminating or adding data types, etc.) There is no commitment to backward or forward compatibility during the STU process. Changes will not be made without cause, however the interests of long-term implementability will generally trump the impact on early adopters when determining what changes should be made. This balance will shift more towards early adopters as maturity levels increase. I.e. Impact on existing implementations will be weighted more highly for an FMM-level 5 artifact than they would for an FMM-level 1 artifact.

This specification has been promoted to STU because it is felt that the specification, as is, is implementable and that more value can be gleaned from implementer experience than from subsequent review as part of the ballot process. Implementers who are willing to accept the risk of change (perhaps for the benefit of early implementation experience, first mover advantage and the ability to leverage FHIR's intrinsic benefits) are encouraged to implement FHIR in real-world systems. However, those implementers should be aware that local adaptations may be necessary to meet real-world requirements. Furthermore, such implementers should architect their solutions to be tolerant of changes to the specification and, where necessary, to manage interoperability with systems that may be using different versions of the specification or different local adaptations.

During the STU period, requests for change may be submitted using the HL7 gForge tracker which can be found here . This survey will capture contact and other information that will allow the FMG to perform appropriate monitoring of FHIR DSTU usage. Survey information will be kept confidential unless the participant authorizes inclusion of their project in an HL7-maintained wiki page of early implementers. Confidential submissions will be reported in aggregate only. While implementation of this DSTU release is occurring, development will be progressing on the next (hopefully Normative) release. This next release will include additional resources, profiles and quality enhancements over the current release. It will also incorporate fixes for issues raised with the FHIR change tracker . Where possible, updates to the "development" version of the specification will be made in a timely fashion. A list of these proposed changes will be published as a continuously updated supplement to the official STU publication. Implementers should be aware that the changes are not considered "official" until such time as they are balloted and approved as part of a subsequent STU or Normative publication. Change requests might be fixes to allow implementation, clarifications or enhancements. In addition, HL7 will be developing and introducing additional resources and profiles as part of the FHIR specification.

SDOs and regulatory bodies that are interested in making use of the FHIR specification should feel free to do so, but should consider and plan for the possibility that the specification will evolve and change prior to becoming normative.

A key objective of the STU process is gaining feedback from implementers making use of the specification. As well, HL7 has a need to monitor which portions of FHIR are being implemented in what sorts of environments so as to make an informed decision on when the specification is ready to proceed to Normative status. For this reason, all FHIR implementers are asked to complete a short survey which can be found here . It may be useful for implementers of the DSTU to browse the development release to get a sense of what changes are likely coming and perhaps to find more robust definitions and guidance than are available in the first release. The FHIR development release can be found at hl7.org/fhir-develop .

This survey will capture contact and other information that will allow the FMG to perform appropriate monitoring of FHIR DSTU usage. Survey information will be kept confidential unless the participant authorizes inclusion of their project in an HL7-maintained wiki page of early implementers. Confidential submissions will be reported in aggregate only.

While implementation of this STU release is occurring, development will be progressing on the next (hopefully Normative) release. This next release will include additional resources, profiles and quality enhancements over the current release. It will also incorporate fixes for issues raised with the FHIR change tracker . Some implementers who are dependent on content that exists in a draft release may choose to implement based on a particular snapshot of the development release, though in doing so, they will limit their potential communication partners and would not be considered to be completely FHIR conformant. © HL7.org 2011+. FHIR DSTU2 (v1.0.2-7202) generated on Sat, Oct 24, 2015 07:44+1100. Links: Search . It may be useful for implementers of the STU to browse the development release to get a sense of what changes are likely coming and perhaps to find more robust definitions and guidance than are available in the first release. The FHIR development release can be found at build.fhir.org/ ~~| Version History | Table of Contents | Compare to DSTU1~~ . Some implementers who are dependent on content that exists in a draft release may choose to implement based on a particular snapshot of the development release, though in doing so, they will limit their potential communication partners and would not be considered to be completely FHIR conformant.