Skip to end of metadata
Go to start of metadata


Attendance can be found here

Co-Chair and Key Participant information can be found on the Agenda found here

Discussion items - Model-bound vocabulary maintenance


V3 RIM CS vocabulary

FHIR model bound vocabulary

Ted and Lloyd

V3 resources include structural components such as ActMood, EntityDeterminer and many others - if they refer to structures in the RIM.

Current thinking for terminology governance is to identify items which are structural.

Ted explained the structural components in V2 and their table numbers are identified in the unified terminology governance project Unified Terminology Governance Project (UTG) Page

We could treat the structural artefacts as if they are external and include documentation of the external source of truth which identifies the artefact to which they are bound.

FHIR value sets which behave as 'structural' all have

  • DataType - Code
  • Required status

The choice of data type (code) and binding determines whether the data element is fixed In the value set space - if a fixed binding exists the value set should be immutable.

All immutable value sets should be considered structural and not open to maintenance.

What will the screens and processes be that are needed to manage this more effectively. FHIR tooling would not support a process through HTA. FHIR has a process for requesting change it might be possible to figure out a mechanism. If anyone needs to make a change in terminology they go to UTG to make that change - irrespective of the origin of the request (ie. product family). FHIR needs to be able to push new artifacts into the UTG process.

For objects which are considered to be structural - the source of truth lives with the object to which they are tightly bound. These UTG objects will be treated as external vocabulary objects even though they are 'owned' by gruops within the HL7 organisation. This makes them external from the centralized UTG governance process but are still managed by HL7.

It is OK for all terminology maintenance to come through JIRA but there is a need to consider how the tooling will work. (there is an assumption that we can make this work).

Objects in the UTG being identified by what kind of thing they are the tooling will prohibit peole entering changes into structural codes and an alternative process will be needed.

Technical unknowns

  • how to coordinate change requests
  • how each product family manages these change requests in JIRA.

An extension to the persistance objects in UTG will identify whether a data element is structural or not and clearly define the requirements to be considered structural.

In code system resources do we need a persistance image in UTG where some data elements can be automatically identified as structural. The instance should have the metadata necessary and the content curration organisation needs to be defined. Ted and Lloyd will discuss potential solutions.

Ted requested a list of FHIR structural data elements of Lloyd.

It was agreed that no HL7 balloted IGs will ever use extentions where DataType = Code and this will be supported in the tooling.

 V2 structural vocabulary 

The structural codes include:

  • Acknowledgement code
  • Check digit scheme
  • Processing ID
  • Processing Mode
  • Query Response Status
  • Alternate Character Sets

It was agreed that these codes would also be considered as structural and they will be treated as if they are an external code system.

 General DiscussionTed

It is ackknowledged that the use of the term structural in this case is not the intended meaning of structural codes and that this term might not be the best one but we are effectively treating codes which are not structural as structural.

UTG functions are to:

  • consistently enforce rules that our terminology is quality controled
  • single place of publishing all of our terminology
  • improving consistancy of our terminology content

Action items