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
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.
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:
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.
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:
- Lloyd McKenzie provide list of FHIR 'structural' data elements.