DSTU2 STU 3 Ballot
This page is part of FHIR DSTU 2 (v1.0.2) in it's permanent home (it will always be available at this URL). It has been superceded by

This page was published as part of FHIR v1.6.0: FHIR STU3 Ballot + Connectathon 13 (Baltimore). It has been superceded by R4 . 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: R5 R4B R4 R3 R2 See

See below for version history details. for version history details.

1.5 2.10 Version History Version History This is the developmental version of FHIR. The only changes tracked here are the changes made after the publication of the first DSTU release. For earlier changes, see the DSTU #1 Version History

This is the developmental version of FHIR. The only changes tracked here are the changes made after the publication of the first DSTU release. For earlier changes, see the DSTU #1 Version History . Note that a full archive history of everything is available through the HL7 gForge SVN archives . Note that a full archive history of everything is available through the HL7 gForge SVN archives . .

1.5.1 How FHIR Versioning works 2.10.1 How FHIR Versioning works The FHIR version policy is based on Semantic versioning

The FHIR version policy is based on Semantic versioning , but with some differences due to the fact that FHIR is a specification, not a software API. There is a single development version of FHIR. This undergoes cycles of development as managed by HL7. Each major cycle of development is concluded by a formal ballot, and then a new specification is published. In version control terms, each published specification is a branch off the development trunk, which may then itself undergo further change as HL7 maintains the published specification (though such changes are usually extremely minimal). The following kinds of changes may be made to the specification: Non-substantive changes do not cause changes in any conformant application. For example, section renumbering, broken links, style corrections, typos, and clarifications that do not change the meaning. Some corrections may be judged not to create any expectation of change to a conformant application. Substantive changes that are not breaking. These introduce new functionality - changes to the specification that create new capabilities - but would not render existing applications non-conformant if they do not change. Breaking changes would mean that previously conformant applications are no longer conformant Note that the following are, by definition, considered non-breaking changes, even though some implementations (including the reference implementations) may not be able to handle some consequences of these changes without error: creation of new resources adding new elements in an existing resource defining new data types Adding new API operations Also, the examples are never substantive. Every effort is made to ensure that FHIR examples are correct, but changes to the examples in the specification are not considered substantive. Each FHIR version is identified by a string composed from 4 parts: publication.major.minor.revision. , but with some differences due to the fact that FHIR is a specification, not a software API.

There is a single development version of FHIR. This undergoes cycles of development as managed by HL7. Each major cycle of development is concluded by a formal ballot, and then a new specification is published. In version control terms, each published specification is a branch off the development trunk, which may then itself undergo further change as HL7 maintains the published specification (though such changes are usually extremely minimal).

The following kinds of changes may be made to the specification:

  • Non-substantive changes do not cause changes in any conformant application. For example, section renumbering, broken links, style corrections, typos, and clarifications that do not change the meaning. Some corrections may be judged not to create any expectation of change to a conformant application.
  • Substantive changes that are not breaking. These introduce new functionality - changes to the specification that create new capabilities - but would not render existing applications non-conformant if they do not change.
  • Breaking changes would mean that previously conformant applications are no longer conformant

Note that the following are, by definition, considered non-breaking changes, even though some implementations (including the reference implementations) may not be able to handle some consequences of these changes without error:

  • creation of new resources
  • adding new optional elements in an existing resource
  • defining new data types
  • Adding new API operations

Also, the examples are never substantive. Every effort is made to ensure that FHIR examples are correct, but changes to the examples in the specification are not considered substantive.

Each FHIR version is identified by a string composed from 4 parts: publication.major.minor.revision.

publication Incremented when HL7 publishes FHIR as an updated specification, e.g. a DSTU or normative version of FHIR HL7 plans to do this every 1 to 2 years The first DSTU was version 0
  • Incremented when HL7 publishes FHIR as an updated specification, e.g. a DSTU or normative version of FHIR
  • HL7 plans to do this every 1 to 2 years
  • The first DSTU was version 0
major Increments every time a breaking change is made When a new publication is made, this is reset to 0 in the publication, and 1 in the development branch Since HL7 does not make breaking changes as technical corrections to a published specification, these versions of FHIR always have a version number X.0.n.r Because the development version is the subject of ongoing analysis, debate, ballot and repeated alterations, breaking changes are to be expected
  • Increments every time a breaking change is made
  • When a new publication is made, this is reset to 0 in the publication, and 1 in the development branch
  • Since HL7 does not make breaking changes as technical corrections to a published specification, these versions of FHIR always have a version number X.0.n.r
  • Because the development version is the subject of ongoing analysis, debate, ballot and repeated alterations, breaking changes are to be expected
minor Increments every time a substantive change is made Resets to 0 any time the major version changes
  • Increments every time a substantive change is made
  • Resets to 0 any time the major version changes
revision Incremented any time a change is made to the specification At present, this is the SVN version number (this allows anyone to reconstruct the source from which the version was built) Additional notes: Changes to a formally published specification (except for minor publishing corrections, such as correcting broken links) are only made via announced technical corrections The reference implementations have 2 versions - the version of the specification that they implement, and their own version. Consult the reference implementation documentation for policy regarding this version number The specification published by the continuous integration service (
  • Incremented any time a change is made to the specification
  • At present, this is the SVN version number (this allows anyone to reconstruct the source from which the version was built)

Additional notes:

  • Changes to a formally published specification (except for minor publishing corrections, such as correcting broken links) are only made via announced technical corrections
  • The reference implementations have 2 versions - the version of the specification that they implement, and their own version. Consult the reference implementation documentation for policy regarding this version number
  • The specification published by the continuous integration service ( http://build.fhir.org/ http://build.fhir.org/ ) build may not conform to this version policy, but the versions published on the HL7 web site will (see Directory of published versions ) build may not conform to this version policy, but the versions published on the HL7 web site will (see Directory of published versions ) The first DSTU was published prior to these rules being agreed as v0.80-2286. This has been updated to 0.0.81.2382 as a technical correction to align with this policy on 9-May 2014
  • The first DSTU was published prior to these rules being agreed as v0.80-2286. This has been updated to 0.0.81.2382 as a technical correction to align with this policy on 9-May 2014

1.5.2 Version History since DSTU #1 2.10.2 Version History since DSTU #1 This table lists substantive changes only.

Major Milestones:

Oct 24, 2015 1.0.2 DSTU2 (Second Draft Standard for Trial Use)
Sept 30, 2014 0.0.82 DSTU1 (First Draft Standard for Trial Use)

This table lists substantive changes only.

Version Changes 1.0.2
1.6.0

Security Note, May 15, 2015 FHIR STU3 ballot, Aug 11, 2016

STU 3 ballot version, and also the basis for the Baltimore Sept 2016 Connectathon

Publication Changes:

Technical Correction 1, Oct 24 2015 Technical Changes:

  • RESTful API
    • Change the FHIR mime type to application/fhir+xml|json instead of application/xml|json+fhir ( breaking change , for conformance to W3C+IETF rules)
    • Add new uses for the Prefer header (return OperationOutcome, and manage behavior related to unknown / unsupported search parameters
    • Deprecate use of the OPTIONS command to retrieve the conformance statement
    • Add support for conditional references to the transaction interaction
    • Add reverse chaining
  • Formats: No change to XML + JSON formats. Add Turtle Format , and related validation tools
  • For Data Types and Resources, there is formal difference analysis from DSTU2 (also found throughout the specification)
1.5.0

FHIR Current Build Update, July 8 2016

Update current version to 1.5 to prevent confusion with implementations still running the May 2016 version.

  • There are many changes in this version from 1.4.0, but no formal list is provided. A formal list will be provided for 1.6 (as a diff to 1.4)
1.4.0

FHIR Connectathon 12 Snapshot, Mar 30 2016

Frozen base for Connectathon 12 & For Comment ballots:

1.2.0

FHIR Connectathon 11 Snapshot, Dec 11 2015

Frozen base for Connectathon 11:

Note: this version is temporary, and will be removed after Connectathon 11 is complete

1.1.0

GAO Ballot + technical corrections, Dec 2 2015

A ballot publication for the GAO Ballot that also includes:

1.0.2

Technical Correction 1, Oct 24 2015

A series of technical corrections to the specification following extensive review:

  • Corrections to Extension cardinalities in implementation guides
  • Corrections in the conformance resources that support the specifications
  • Correct several erroneous invariants
  • Various typos, broken links, and fixes in examples
  • For a comprehensive list of corrections, see the Task list for FHIR DSTU2 Technical Correction 1
1.0.1

DSTU 2, Sept 23 2015 DSTU 2, Sept 23 2015 Changes of significance during the QA process: Remove the Clinical Quality Improvement Framework (CQIF) from this published version made fixes to generated schematrons updated generated comformance resources (StructureDefinitions and SearchParameters) so they were consistent with the specification Many spelling / grammar / broken link fixes

Changes of significance during the QA process:

  • Remove the Clinical Quality Improvement Framework (CQIF) from this published version
  • made fixes to generated schematrons
  • updated generated comformance resources (StructureDefinitions and SearchParameters) so they were consistent with the specification
  • Many spelling / grammar / broken link fixes
1.0.0

DSTU 2 QA Preview, Aug 31 2015 DSTU 2 QA Preview, Aug 31 2015 This version had extensive change as a result of the May 2015 DSTU ballot, ongoing testing, and the open change proposals (1317 gForge tasks). The extent of the changes is best illustrated by the number of the list of changes labelled 'breaking change'

This version had extensive change as a result of the May 2015 DSTU ballot, ongoing testing, and the open change proposals (1317 gForge tasks). The extent of the changes is best illustrated by the number of the list of changes labelled 'breaking change' - 158 changes of 1317 total tasks. Below is a list of the most important changes: General: introduced the maturity framework - 158 changes of 1317 total tasks. Below is a list of the most important changes:

0.5.0

DSTU Ballot, May 2015 DSTU Ballot, May 2015 This version had extensive change as a result of the January 2015 Draft ballot, ongoing testing, and the open change proposals (over 800 gForge tasks). The list below is a summary of the major changes to resource content. It shows only a limited number of the overall changes.

This version had extensive change as a result of the January 2015 Draft ballot, ongoing testing, and the open change proposals (over 800 gForge tasks). The list below is a summary of the major changes to resource content. It shows only a limited number of the overall changes.

Enumerations All spaces removed Extensive content changes not noted here

  • All spaces removed
  • Extensive content changes not noted here

New Data Types New Data Types

Changed Data Types Changed Data Types

New Resources New Resources

Removed Resources Removed Resources CarePlan2 -> collapsed into CarePlan FamilyHistory -> broken up into FamilyMemberHistory InstitutionalClaim, OralHealthClaim, PharmacyClaim, ProfessionalClaim, VisionClaim -> collapsed into Claim Other - use Basic instead PendedRequest,Readjudicate, Reversal, StatusRequest, StatusResponse - use ProcessRequest/Response instead SupportingDocumentation - use DocumentManifest instead

  • CarePlan2 -> collapsed into CarePlan
  • FamilyHistory -> broken up into FamilyMemberHistory
  • InstitutionalClaim, OralHealthClaim, PharmacyClaim, ProfessionalClaim, VisionClaim -> collapsed into Claim
  • Other - use Basic instead
  • PendedRequest,Readjudicate, Reversal, StatusRequest, StatusResponse - use ProcessRequest/Response instead
  • SupportingDocumentation - use DocumentManifest instead

Renamed Resources Renamed Resources Alert -> Flag: 'alert' made people think it was an action like an alarm SecurityEvent -> AuditEvent: it wasn't just for security purposes ClinicalAssessment -> ClinicalImpression: people got confused with 'assessment' tools like APGAR score Profile -> StructureDefinition: 'Profile' is the process, a package of statements

  • Alert -> Flag: 'alert' made people think it was an action like an alarm
  • SecurityEvent -> AuditEvent: it wasn't just for security purposes
  • ClinicalAssessment -> ClinicalImpression: people got confused with 'assessment' tools like APGAR score
  • Profile -> StructureDefinition: 'Profile' is the process, a package of statements

Changes Inside Resources Changes Inside Resources

0.4.0

Draft For Comment, January 2015 Ballot Draft For Comment, January 2015 Ballot Breaking Changes (full list): Replace atom and taglist with a native

Breaking Changes (full list):

New Resources:

New Implementation Guides (see discussion of status )

0.3.0 Renamed Namespace to NamingSystem Split
0.2.1 Minor new optional elements on value set for metadata, new extensions for all the rest of the VSD project metadata, formal profile to express basic minimum metadata for value set
  • Minor new optional elements on value set for metadata, new extensions for all the rest of the VSD project metadata, formal profile to express basic minimum metadata for value set
0.2.0 Namespace: adjustments based on Grahame's feedback
  • Namespace: adjustments based on Grahame's feedback
0.1.0 Add Appointment ,

Note: a useful tool for displaying the differences between pages is the W3C HTML Diff engine | Version History | Table of Contents | Compare to DSTU1 .