Professional Associations, such as HL7, which bring together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of the Governance and Operations Manual (GOM).
Minutes Approved as Presented
This is to approve minutes via general consent. "You have received the minutes. Are there any corrections to the minutes? (pause) Hearing none, if there are no objections, the minutes are approved as printed."
Meeting was recorded
Rollcall & Proxies
Note that meetings are recorded
Approval of meeting minutes
THO v3.1.0 release available as of 2/25
Sprint 2 of UTG Jira development items is in progress, focusing on release tracking
Scheduling meeting for mid March to define release tracking requirements
Scheduled kickoff call with Lawrence to get started with Jira automation development
Priorities are automating creation of branch and cloning, as well as automating commit and push after editing changes
Subcommittee Work in Progress
THO release schedule
Need input from TSC/HQ and they have requested some information from TSMG on documentation and level of effort
Consideration for later: Need a policy for old proposals because branches will become very outdated and cause issues for both submitters and the Terminology Curator due to large number of merge conflicts over time
This would break Published Example links in the UTG proposals
LN: Concerns that this is a manual process
MD: Release process requires downloading entire repo and so size can be a factor
Ask Grahame if possible to make publisher not publish those branches, but reverse them if we need them published
MD will look more into the pros and cons of both sides
RV: Might be better to keep them then breaking the links
Vocab suggests that TSMG require all code systems to have a Steward
UTG submitters would need to get WG approval from the Steward to propose changes to the code system
Discussed on last week's main TSMG call but no one wanted to make a motion to make this a policy
Reuben suggested there may need to be a better description of what a Steward is / what that entails before crafting a policy statement. When there is a proposal for the definition, this issue would be brought back to this group.
From codesystem.steward: Usually an organization but may be an individual. The publisher (or steward) of the code system is the organization or individual primarily responsible for the maintenance and upkeep of the code system. This is not necessarily the same individual or organization that developed and initially authored the content. The publisher is the primary point of contact for questions or issues with the code system. This item SHOULD be populated unless the information is available from context.
LN: Publisher is more of a practical role, such as maintaining convenience copies and may or may not be the steward.
MF: Points out that this also applies to external code systems
LN: Steward implies domain expertise/knowledge and publisher is putting the information out there for use, not necessarily understanding it
JH: Vocab could be Steward initially and as we get requests we can update the Steward, then update Steward as part of the changes to be done
MD: If we use a default value, make it clear that the WG defined is actually responsible or just a default value
Add missing Value Sets for cda-core-2.0
LN: These are value sets with no underlying code system. Where can we get them from? They might be in the base spec
Lisa is going to look into this further and bring to SD
Probably need to make a corresponding code system
May be able to clarify that they are active value sets used by CDA and previously used as a V3 concept domain but are now considered retired in V3 via the <definition>
Probably want them only on CDA tabs
Workflow process for use of internal code system identifiers in FHIR and beyond
Need to determine what kind of content should/should not be added to THO (i.e. if used in a balloted IG)