• Party or parties changing the artifact
• THO curator verifies and may instruct those assigning version to amend version
• In rare circumstances, the THO curator can assign the version (e.g., to avoid potential conflicts)

See https://confluence.hl7.org/pages/viewpage.action?pageId=91995515#SpecifyingtheDetailsInsidetheProposal-CodeSystemMetadata for how CodeSystem.id and CodeSystem.url relate.

CodeSystem.id is strongly related to CodeSystem.url.

Changing id (caused by change to url) would result in a new CodeSystem.

Blanket statement: Cannot change or remove a CodeSystem.identifier. You can add them, but once you add them they are immutable. You must create a new CodeSystem for identifier changes or to remove an identifier. Extreme care must be taken with identifiers.

Note that best practice is to maintain identifiers and so we do not anticipate them being removed. 

These identifiers are considered authoritative for the CodeSystem and deprecating them (method is not currently set/clear) is considered a change and thus the CodeSystem as a whole needs to be deprecated. 

Note that the current plan for adding IRI stems involves adding them as identifiers. 

Discussed treating this element as a secondary identifier (to urls). CDA/V3 uses OID as a primary identifier, however.

Does changing url force you to change identifier, and vis versa?

Identifiers in the Code Systems are authoritative you must use, and NamingSystem identifiers track additional identifiers.

Recommended that extension be defined in THO or core spec to document which artifact supersedes the artifact. Since New OID = New CS, it is up to code system owner to deprecate, but it is recommended. 

Major unless only change is improved clarity or perform editorial corrections. 

CodeSystem.useContext

Not Currently In Use for UTG.

Recommendation: Should decide what the intent of this element is within THO, could consider exclusion

CodeSystem.copyright

x (changing base, removing)

x (adding)

Pro-forma in UTG, Cannot Change Value.

Recommend that TSMG come up with rule for using this data considering canonical vs. uri and if version should be asserted. Should either go versioned or versionless and not switch between the two.

Handle with canonical vs. uri only cases in this policy.

Might want to consider tooling that programatically creates all codes Value Sets.

Versionless = only add and remove

Versioned will change with change of version of Code System

TSMG should suggest policy or guidance that going from F to T may be a new code system . Unsure what it means if absent. This should really be a mandatory element.

When going from unvalued to valued, it should be a major change. Flip flopping is new code system.

We have some code systems that are marked as complete, but are actually not, such as http://build.fhir.org/ig/HL7/UTG/CodeSystem-v2-0140.html. Table 0005 is a fragment as well.

TSMG should consider whether example content should be in THO, but for now we assume they will be supported. Value should either be complete or example and should be fixed for the life of the code system. Changing is new code system.

TSMG needs policy on supplementing HL7 code systems. Need justification of changing supplement over changing. Changes could be made directly to the code system themselves. Affiliate could make supplement for an external code system

Major for Concept Status and defining property changes (like isSelectable), status changes to/from Active to Retired, Active→Backwards Compatible, addition of language translations of the text bits (print names, descriptions, etc.).  

Use cases:

• From IG to THO
• From FHIR core to THO

Recommend that TSMG consider the following option for approach if version of artifact to be moved is not in format x.y.z

• Set initial version in THO to 1.0.0.
• New artifact (need different id in uri)

Changes would be driven by required element changes and then follow versioning policy above.

Recommend that TSMG consider adding an extension to declare the version of FHIR in all HL7 code systems now. That way this can be incremented when THO moves to a new version to make it clear which version of FHIR the resource is based on.

Addition, modification, or removal of extension value. Approach should be based on THO authorized extensions and a policy must be established for each of those that is controlled by TSMG. 

Could also consider making it a major change across the board to handle more significant cases. 

Also need to consider that most extensions are not rendered in THO at all.

Change is based on the data elements that have changed.

Should ensure that THO supported extensions are accounted for when text is auto-generated.