We have a request from the international community to clarify policy on adding content to older HL7 V3 code systems where the content may be available elsewhere. This arose relative to some Pharmacy content (email chain with Andrea MacLean, Canada Health Infoway). It seems clear that HL7 needs a policy (at least write down what we believe to be true, and formalize it) justifying reluctance to revise content of older HL7 code systems (V2 and V3) where there are internationally recognized and maintained terminologies with overlapping content and are currently in use.
HL7 needs policy statements to include the following:
- Status of value sets defined by HL7 such as:
- deprecated (may be used to support legacy implementations, but not allowed for new artifacts)
- inactive (available for analysis of historical data)
- active (currently available for use)
- active and mutable (use is allowed and modification of the value set is allowed, with versioning)
- active and immutable (use is allowed, but modifications are not allowed)
- For deprecated and inactive value sets, replacement value sets shall be specified. For example: orderableDrugForm replaced by EDQM Phamaceutical Dose Form
- Do we have the same rules for Code Systems? (note that as of September 2018, there are no HL7 created Code Systems in Version 2)
- It seems that we must have somewhat different rules for Code Systems than for Value Sets
- It also seems that the rules for Code Systems will be simpler than those for Value Sets
- Do we need different rules for V2 Tables?
- Note that the unified vocabulary model we are moving towards for UTG (V2, V3, CDA, and FHIR) has only three states:
- Draft (content in development, not ready for use)
- Active (released and may be used in production)
- May be qualified (flagged) as Deprecated. This means that an Active code has a message to the user community that it is scheduled to be Retired in the near or at least foreseeable future. Note that it is strongly desired that an Active code be flagged as Deprecated for some period of time before it is moved to Retired.
- Note that in the current HL7 vocabulary model, the Deprecated flag includes the Date of deprecation, and an optional reason for deprecation and eventual retirement.
- There seems to be emerging consensus that there should be a ballot process around deprecation and retirement of a Code System.
- The recommendation is that you can make changes to a deprecated Code System, but the deprecation flag serves as a warning to those requesting changes that it is on a schedule track to be retired.
- A possible policy is that the Vocabulary WG review the deprecated Code Systems periodically (annually?) and if there has been no activity in the past (two periods?) then it is scheduled for a mandatory review, the result of which may be that it is submitted for retirement.
- We need to communicate to all workgroups that if a Code System is put into a deprecated state it has the consequence that a clock for a mandatory review for retirement has started.
- Folks are questioning whether or not to allow changes to deprecated Code Systems. It was suggested that changes are strongly discouraged and require a compelling reason to make the changes. We absolutely must have an effective way to tell the community when things are deprecated, and to move a Code System to a deprecated state might require the use of the ballot mechanism as it is the way that we reach out to the entire community with some HL7 change.
- Note that HL7 continues to strongly discourage the creation of an HL7 Code System where a freely available code system covering the domain is already available from an external (non-HL7) publisher.
- Marked immutable, no further changes or support for the content (but still published for reference)
Original email triggering this new effort from June 6, 2018:
Dear HL7 Terminology Authority,
When looking at some of the HL7 code systems and value sets, we know from some conversations at HL7, that HL7 is no longer maintaining some of these value sets and is no longer adding new concepts and in some cases encouraging implementers to use other code systems that are likely more appropriate.
Pharmacy is one such area. (orderableDrugForm as an example)
We could not find an official statement about this from HL7 to help us advise implementers accordingly in Canada or on your HTA page (http://wiki.hl7.org/index.php?title=Terminology_Authority)
Would you please point me to where I can find this statement from HL7.