Vocabulary Working GroupMeeting Minutes

January 20141 Attendees

Given Name Family Name Affiliation eMailLester Arthur Miss Dept of Health barthurutch@yahoo.comJos Baptist NICTIZ Baptist@nictiz.nlRhoel BareldsJim Case NLM/ NIH james.case@mail.nih.govKathleen Connor VA Kathleen.connor@comcast.netCarmela Couderc Seimens carmela.couderc@siemensPatty Craig The Joint Commission pcraig@jointcommision.orgRory Davidson IHTSDO rda@ihtsdo.orgJean Duteau DDI jean@duteaudesign.comFloyd Eisenberg Iparsimony feisenberg@iparsimony.comAna Estelrich Anna.estelrich@phast.frChris Fillmore Systems made simple Chris.fillmore@systemsmadesimple.comSarah Gaunt Lantana Sarah.gaunt@lantanagroup.comHeather Grain eHealth Education h.grain@ehe.edu.auPatricia Greim HHS/ONC Patricia.greim@hhs.orgMarc Hadley Mitre mhadley@mitre.orgRuss Hamm Lantana Russ.hamm@lantanagroup.comKendra Hanley AMA-PCPI Kendra.hanley@ama-assn.orgRob Hausam Hausam Consulting rrhausam@gmail.comPeter Hendler Kaiser Permanente Peter.hendler@kp.orgCatherine Hoang VA Caterhine.hoang2@va.govWendy Huang CHI whuang@infoway-inforoute.caStan Huff Intermountain Healthcare Stan.huff@imhc.orgJulie James Blue Wave Informatics Juliejames@bluewaveinformatics.co.ukCrystal Kallem Lantana Consulting Crystal.kallem@lantanagroup.comDaniel Karlsson phoneRosemary Kennedy Ecareinformatics Rosemary.kennedy@ecareinformatics.comTed Klein KCI ted@tklein.comCarol Macumber Apelon cmacuuber@apelon.comRob McClure MD Partners rmcclure@mdpartners.comFrank McKinney Fm.@frankmckinney.comDavid Markwell IHTSDO dma@ihtsdo.orgRiki Merrick Contractor for APHL rikimerrik@gmail.comJane Miller IHTSDO jmi@ihtsdo.orgSenthil Nachimmuthu 3M snachimuthu@mmm.com

document.docx

Lisa Nelson LOTS Lisarnelson@cox.netFrank Oemig HL7 Germany HL7@oemig.deCraig Parker Intermountain Healthcare craigparkermd@gmail.comVaspaan Patel NCQA vpatel@ncqu.orgDivya Raghavachari Accenture Divya.raghavachari@accenturefederal.comGuillermo Reynoso Termmed IT greynoso@termmed.comMark Roche ONC mrochemd@gmail.comAtanu Sen Accenture Atanu.sen@accenture.comMark Shafarman Shaferman Consulting m.shafarman@gmail.comAbdulmalik Shakir HI3 Solutions Abdulmalik.shakir@HI3solutions.com

Anne SmithNational Committee for Quality Assurance On phone

Kimberly SmukAmerican Medical Association Kimberly.smuk@ama-assn.org

Robert Snelick NIST rsnelick@nist.govHarry Solomon GE Harry.solomon@ge.comSandra Stuart Kaiser sandra.stuart@kp.org Sheryl TaylorSylvia Thun HL7 Germany Sylvia.thun@hsnr.deRobert Turnbull IHTSDO rtu@ihtsdo.orgLee Unanyst AND Dietpro1123@gmail.comMead Walker

2 Sunday Q3 Chair: Ted KleinScribe: Heather Grain

Number of attendees: 9

2.1 Co Chair AssignmentsChairs and scribes for each session were established

2.2 Facilitator Training There is an agreed need for consistent terminology use between SDOs to assist HL7 connection and interconnection for standards. Julie James offered to Assist Ted with resolution of comments related to Terminology Binding ISO work item. Binding Intensity is a term related to implementation which is not clear outside the immediate vocabulary community. Provision of material to support processes and implementation is needed. It is not clear how to structure much of this information for those who enter it new.

Educational material and tutorials need to be designed for a given audience -

document.docx

For example: Vendors might include FAQs such as What is an Hl7 vocabulary facilitator Why and how does V2 differ from V3? Is CDA different to V2 and V3? Who needs terminology implementation knowledge? How is HL7 coded content maintained?  

Butch Arthur as a new attendee who offered to provide comment upon documents offering a new person perspective. Ted Klein offered to mentor Butch to assist with questions and access.

Action: Vocabulary WG to consider how to publish and develop FAQs. Heather to share the suggested questions with the list

Tutorial planning:Action: Ted – review content of Vocab 1 to ensure data types are introduced. Heather updated the tutorial specification for this Tutorial and sent to Ted for confirmation.

Priority tutorials for Phoenix meeting - Vocab 1 (Introduction) and a new tutorial, using largely existing material Best Practice in terminology content development. Reconsidered on Thursday Q3.

2.3 Sunday Q4: Facilitator Discussion on facilitationChair: -Scribe: -Lack of quorum

3 Monday Q1 Agenda Planning and Project ReviewChair: Jim CaseScribe: Heather Grain

Number of attendees - 14

3.1 Project ReviewExisting projects and their status were reviewed.

Title Status ActionCharacteristics of a formal value set definition.

Actively working on this with calls twice a week. The outline has been provided and the plan is to move this further forward at this meeting. This is now aiming for ballot in the next cycle.

Ensure intent to ballot documentation is submitted

document.docx

Version 2.x examples verification and management

– stalled. The process is reasonably clear but the bandwidth of workers is not yet available. The objective is to have this ready for V2.9 ballot. Requests for V2 expertise to complete this were made.

Due date now 2015 - to be updated

Provide guidance on the use/role of interface terminology and reference terminology

3 year plan item No action

Document methods for establishing how to do conformance with post-coordination for HL7

3 year plan item No action

Define a process to assign a single HL7 preferred value set and/or code system for specific coded attributes in HL7 standards

The notion of this comes from core principles. For many coded attributes the modelers have in mind a particular value set for an action, but the descriptive property for terminology guidance in the RIM in order to carry the guidance from the modelers to the implementers.

This provides a communication pathway. Review the requirements and possibly reactivate the project, and add that once the process is established training updates are also required.

Update this to specifically consider the scope and to consider the existence of the Terminology Authority where relevant – V2, FHIR, and need for tutorial support. Add to conference call agenda – Ted.

Determine a formal process for vocabulary maintenance

3 year plan item No action

LOINC Clinical document ontology

Preparing for ballot.

Review ISO Principles and Guidelines of Terminology Maintenance

3 year plan itemAwaiting document from ISO process

No action

Vocabulary Conceptual Model

Develop a document to support V3 terminology implementers3 Year plan

No action

OWL representation of HL7 V3 artifacts

Completed Request MnM close this project

HL7 work group facilitator training

Heather has provided the scope of vocabulary tutorials and the relationship of this to facilitators. This meeting determined priorities for development and new material will be prepared for delivery in May

Inform Education and request date update to 2015

Vocabulary maintenance in the IHTSDO workbench

a wiki has been established to identify what we need form a tool. The objective is to be able to create reference sets from SNOMED CT and potentially LOINC and other systems. A WIKI has

Russ to review and update if necessary

document.docx

been created to support requirement collection.IHTSDO are working on a new terminology management infrastructure. Take the harmonization proposal forms and checklist and use that as a requirements specification. There is a need to talk to IHTSDO but we agreed that this project should be to gather the requirements generically not just as they relate to this tool, Review this after clarification on the direction of IHTSDO tooling. Then modify this project statement and resubmit to TSC if necessary

CTS2 incorporation of SVS

– no report and lack of clarity. There is a need to update the dates on the project.

Confirm project facilitator and update if necessary. Also confirm the timeline expected.

Evaluate NLM Vocabulary Submission Tool (SCRS) at HL7

Ted reported that we are waiting to hear from NLM about availability. We would need an external host and prepare a proposal but we need the date of code availability.

Ted to contact Vivian to confirm availability and potential date of availability so that project dates can be updated.

Refinement, Constraint, Localization Release 3

To be covered in discussion with CGIT later this week

No action

V2 Tables Project First pass complete but documentation of rules and review of decisions still underway. Suggestions for new formats will be discussed with publishing on Wednesday. V2 code table versioning and alignment to V3 vocabulary model (Tables Project)Project end dates and milestone dates. The project scope must also be reviewed to indicate V2.9 rather than V2.8.

Ted to update.

Ballot release 2 of core principles of V3 models

Ballot release 2 of V3 limited scope update.Vocab content is resolved

Request an update from MnM on WednesdayTed to establish and publish location of a wiki page to hold all the actions needed for update of core principles.

Term Info Ballot completed this round. Ballot reconciliation is to be undertaken this meeting and over the next few weeks. There is also further work required on the document. There will also be a need to address LOINC input shortly.

Rob H to update the project milestones after discussions this week.

document.docx

Common Terminology Services - Release 2 - Implementation Guide

No report and lack of clarity. Dates on the project need to be updated

Confirm project facilitator and update if necessary. Confirm the timeline expected

Implementation model metadata documentation

Awaiting approval No action

Binding Syntax for implementation guides

Target ballot was May 2011 Update milestones and project end date as a result of binding syntax discussion at this meeting - Ted

CTS2 Normative Comment disposition largely done, some model updates are needed but the final work completion date is the end of January.

Russ to update project end date to be updated to May 2014.

Some of these projects were described prior to work on definitions. The value set definition project may assist this project once it is complete.

Vocabulary TutorialsHeather provided an updated

Facilitator training pathway was discussed as was the scope of Vocabulary tutorial content. The model below identifies the scope and the logical pathway for facilitator development. Pink learning topics are pre-requisites for vocabulary facilitator training. The green section is specific for Vocabulary Facilitators and is essential for them. They focus on requirements for vocabulary facilitation within HL7. The pale green is useful for Vocabulary facilitators and for others. The Blue represents a block related to implementation of vocabulary content and yellow to glossary development.

document.docx

Rob McClure suggested that an additional tick on the Harmonisation Proposal Document be included for all HL7 products a question on whether vocabulary best practice has been followed.

Julie James suggested that vocabulary comments on ballots could be a means of educating and motivating. Heather suggested that this could be used in conjunction with having available appropriate training. The loop must be closed. It was agreed that the Vocabulary WG will take responsibility for getting the ball rolling and selection of a ballot or two to be reviewed with this in mind could be undertaken on a call.

There are significant issues wtih CDA vocabularies partly because it doesn’t go through harmonisation processes. This exception was granted in order to speed up the process. CDA ballots have far more vocabulary comment as a result of this.

4 Monday Q2 Value Set Definition ProjectChair: Ted KleinScribe: Heather Grain

document.docx

Number of attendees: 20

Rob McClure provided details of the wiki: wiki.hl7.org/index.php?title=Value_Set_Definition_Standard_Project

This project identifies and describes metadata used in value set mechanisms.

This project also maintains documents on drop box. These documents are linked from the wiki to provide a permanent publically available document access mechanism. It was agreed that there would always be a publically available version on dropbox available through the link.

Meetings will be held on Wednesdays starting the 29th . The intention is to develop written materials for ballot consideration. The intention of the ballot is to describe names parts and to define whether they are required for a particular value set attribute. It is a normative specification. It has named components and their cardinality. In an annex the MIF will be included and an attempt to get a FHIR representation to indicate how the implementation might have different names but the components are used consistently.

DICOM is being published in XML this year and Harold indicated that there may be further examples which would be useful. Informative materials such as these could be published in many ways.

ACTION: Ted to submit intent to ballot ACTION: Ted to arrange calls – Timetable Tuesdays at 4pm for 1 hour. Starting on the 28th of January. ACTION: Rob to send updated meeting details

The value set element spreadsheet was reviewed. This document includes definitions, explanations, notes and metadata about each element, such as Source, Identifier, Name. Heather suggested that specific headings are needed to describe what each component is, why we have it, how it is used, how it is constructed/represented or implemented to meet specific use cases.

This document is intended to represent a complete enough metadata statement to support governance of value sets. User stories are to be collected and included to make the content clearer.

Objective – persistent information authoring, maintaining, distributing, expressing, processing, to get a list of codes for use.

document.docx

Value Set Identifier can be for example an OID what does that mean for me. What can change and what cannot change. Is directly associated with the semantic space for which the concepts in the value set are used. This is permanent the idea does not change.

The concept domain is the description of the purpose and semantic domain associated with the information model. The value set includes the business purpose and the means by which the implementation is achieved. The binding is where the two join. The value set will e more specific as it aligns with code system to be used.

IHTSDO have signed a contract on how to use SNOMED CT and LOINC together. The contractors would be interested in existing work on this topic. David requested members to contact him if they would like to contribute. Contact: dmr@ihtsdo.org

5 Monday Q3 Value Set Definition Project (Continued)Chair: Ted KleinScribe: Heather Grain

Number of attendees: 30

There may be inconsistencies in this document which require clean up. For example: The intention of capturing definitional attributes – actually captures whether a change of this element means that it is a new value set. Comments are used to retain comments and issues identified that are not yet represented elsewhere. There are also references to other standards documents indicating the relationship between this item or work and that document.

Identifier:Very like a concept identifier. Modified to Value Set Identifier – a unique machine-oriented representation of the value set.

Definitions in the document should be able to replace the term in a sentence, for this reason the definition should not be a sentence.

Metadata Revision Time: date/time of a change to any element of value set metadata

Need to add definition column, and to indicate the purpose and how the element is used.

Discussion on Name: human readable identifiers should be used in addition to the primary identifier. The intention that this is both an identifier within the use

document.docx

case and a tag for broader use (e.g. multiple languages). It was agreed that there is value to unique names, but that these will not be a requirement .

Usage notes will indicate guidance on, for example, that name is not definitional, however if the name changes the actual meaning of what is included e.g.: Anti-haemorrhagic to Antibacterial – that should be a new value set, while changing from flavour to flavour would not be as there is no change of meaning.

Source now source reference- if the value set is a derivative of something that pre-exists the source should be indicated. This is optional. This is free text and would often be a citation.

Overview URL – this references the value set members URL that points to a description of the value set definitional metadata.

License Requirements – this is free text to indicate information about licensing. Machine operable may be developed later. The fixed string could include ‘ no IP requirements”.

There are 47 rows and the meeting progressed through 7 of these. This document is shared through Google docs .

The idea of content logical definition is that if someone adds a new body part do I need to add that to a value set including that body part? This use case should be considered in this project.

This work centres not just on establishing value sets but governance and maintenance

Value Sets require stewards. Structured Docs had concern that we are getting ahead of the game, should we be consistent, should it be driven by meaningful use needs, or are these US Realm activities.

6 Monday Q4 Vocabulary Model / Information Model BindingChair: Russell HammScribe: Heather Grain

Number of attendees: 18

Ted and Wendy reported difficulties with connecting the terminology model and the vocabulary model.

There is significant lack of understanding related to binding constraints, conformance testing requirements etc related to terminology content, particularly

document.docx

in structured documents. The work described in this session identifies the attributes.

Today there are many systems which are testable, but the actual conformance requirements are not well specified nor do we know that, particularly with CWE the robustness of testing and requirements for conformance . With CNE a good set of tests can be developed. Based upon the approach and understanding at the moment conformance can only be tested at the time of testing. We are not able to assess compliance with data requirements. Sent will always be in the accepted term set.

Analysis seeks to determine the size of the problem. It is also acknowledged that testing is done for different purposes, testing conformance, testing performance, and testing capability. There may be a set of components relevant to documents required to be constrainable, while those being implemented in less regulated environments need to be able to be more flexible.

Most often in vocabulary is ‘structural vocabulary’ where the terminology is bound to the model specifically.

We could be more precise is the conformance verb and the model binding verbs were pre-coordinated: This has highlighted the need to ensure representation to reflect the ability to test the binding. Undefined means that this form of representation is not clearly able to do the task specified. The table below is an example of the initial review of descriptive elements.

Complete determined, testable non extensible (SHALL, CNE)

Plausible determined, untestable with current tooling, extensible (SHALL, CWE)

Complete, recommended, untestable with known tooling, non-extensible (SHOULD, CNE)

Plausible, recommended, untestable with known tooling extensible (SHOULD, CWE)

Complete, illustrative untestable with any tooling, non-extensible (MAY, CNE)

Plausible, Illustrative, untestable with any tool, extensible (MAY, CWE)

Single code model biding

Valid (use) Undefined Undefined Undefined Undefined Undefined

Group of codes context binding

Valid Valid Valid Valid Valid Valid

Group of codes model binding

Valid Valid Valid Valid Valid Valid

Conformance verbs (shall, should and may

document.docx

Coding strength CWE and CNE - these can be used to define the expected completeness (exhaustiveness) of the representation.

CNE CWESHALL Complete, determined, testable,

non-extensiblePlausible, determined, untestable with known tooling, extensible

SHOULD Complete, recommended, untestable with current tooling, non – extensible

Plausible, recommended, untestable with known tooling, extensible

May Complete, illustrative, untestable with any tool, non-extensible

Plausible, illustrative, untestable with any tooling, extensible.

The words used to describe this environment are defined below:

Completeness of the list of coded concepts: Complete – coded concepts expected to satisfy business requirements Plausible – coded concepts that may fully satisfy the business

requirements, but may be incompleteConsideration was given to implausible – but no use case was found to meet this definition.

Conformance expectation relevant to the use of coded concepts: Determined – the list of coded concepts that must be used to satisfy

business requirements Recommended – The list of coded concepts that is strongly

recommended to be used to satisfy business requirements Illustrative – the list of coded concepts is intended to be illustrative or

exemplary, and is expected to be incomplete to satisfy the business requirements.

Testability Testable - Tooling is currently available to certify conformance or non-

conformance May be testable with known tooling – May be testable. Tooling is not

currently available to certify conformance or non-conformance but can be developed. This applies to tools known to the relevant HL7 community.

Untestable with any tooling – Tooling is not available to certify conformance or non-conformance and cannot be developed. This may indicate insufficiently clear specification.

It was acknowledged that further work is done on how conformance, performance, compatibility etc testing will be defined.

Senders and receiver systems also have different requirements comvere din part by mandatory and required.

ExtensibilityExtensible – local codes or codes not part of the list can be used

document.docx

Non-extensible – local codes or codes not part of the list cannot be used.

Another set of characteristics in core principles and in models carry control parameters around whether they are required or mandatory. The relevant appropriate combinations are to be discussed with MnM to improve content in publications.

This analysis is required to clearly understand and specify and provide guidance. Assistance was requested.

There is a need to clarify the mandatory vs. Required components. When this is complete the templates community should review and identify identify how many templates fall into each category.

As an implementer you need to know what you have to do to meet the profile requirement. There is concern that the CNE and CWE are both used in V2 and V3 are data types in V2 and coding strength in V3

ACTION: Ted to manage the calls and this is to be determined on Thursday. Doodle poll between Ted and Wendy and others informed of the time to join as they can.

Section 5.2.3 Core Principles R2 Conformance with value set assertions. This paragraph may need review to reflect the learning of this analysis.

7 Tuesday Q1 TermInfoChair: Rob HausamScribe: Heather Grain

Number of attendees: 16 (including 2 on the phone) one additional person at end of session – Total 17.

Next steps – ballot reconciliation, then determine next extensions of scope of the document.

This version focuses on SNOMED CT and CDA models.

The question was asked whether to publish TermInfo following ballot disposition and then start a new project to progress the next updates. This was supported by the meeting.David Markwell reported that mapping of LOINC content is likely to progress quickly and a scoping study of what guidance is needed view of where we are. Draft guidance. Draft should be available in July.

document.docx

The scope of the agreement is laboratory, anthropomorphic measurements (height weight) and vital signs.

As a general and imperfect definition of the agreement it is LOINC is the question while SNOMED CT represents the answer. Question – eye colour, Answer Blue

Ballot reconciliation:

Total of 228 comments. The bulk are from within the TermInfo group. 89 negatives 39 major 50 minor,

Comments of those present were dealt with first. Details of discussion are recorded in the ballot reconciliation documentation.

8 Tuesday Q2 TermInfo (continued)Chair: Rob HausamScribe: Heather Grain

Number of attendees: 18 Call Schedules. Wednesday morning 8am East Coast USA. Starting January 29th.

Negation DiscussionIssues associated with where and how to provide improved specification and guidance on negation in core principles, but also in implementation guides is needed.

The examples collected by Lisa form a sound basis to support confirmative information, but the examples also need to be available on the ballot site as a user guide. Requirements:

Explain how negation works – this is in core principles but an implementation guide ‘for the general implementer’ is needed. This would need to cover CDA and V3 and explain the use requirements/or lack of them in other HL7 products such as V2.x and FHIR.

Implementation guide to include ‘help desk’, conformance statements, examples and how to for all HL7 products.

A link is also required to define conformance or policy which could be the list of examples.

document.docx

The question was asked whether such an implementation guide could have chapters on each HL7 product. The implementation guide should include conformance requirements and examples.

Core Principles currently includes the overarching principles of V3 and CDA but does not address V2 or FHIR.

A significant issue has arisen within CDA representation of negation. Negation should negate the content of the assertion. Whatever is in the

‘box’ is what is negated. This has the advantage of being able to be consistent and taught.

Where does it make sense to use the power of the terminology resource Where negation works inside the structural constraint that has been defined.

A negation construct to observable – the concept to be represented is negation of the assertion – I am not saying that X is the case. Rather than I am saying the X is not the case The value problem of putting the value into the observable.

Code assertion value allergy to substance The profile has to define how negation is applied. The problem is that

different profiles might represent this differently.

I am asserting that you are not (negation indicator) true – you are allergic to X.I am not asserting

Assertion can be positive or negativeValue can be positive or negative

I am asserting (without negation) – value no known allergiesI am asserting (negative) – value no known allergies – I am not saying that you have no known allergies.

You should represent negation in the terminology only when you can’t do it in the information model

There is general guidance in CDA documents now saying not to use the terminology content to represent negation. Though it is known that there are CDA profiles which break this requirement. Guidance is provided in the implementation of allergy information such as this – for example displayed as Patient Declares that they have no known allergies. How do you express a patient with rheumatoid arthritis – then you do tests and confirm that they do not have rheumatoid arthritis as a conclusion? More guidance is needed in this area.

Suggestion: reduce to a set of common patterns of clinical statement

document.docx

The negation must be the next thing after the negation. If this is the rule, how would we say it. Where would the negation indicator be put to represent this example. This is to be covered in the guidance document.

Actions:Review to core principles – to expand the discussion of negation and revise how profiles are affected. Update and enhance the negation indicator section (6.6). This can be included in core principles R3 and included when the update of R2 is complete. Completion is dependent upon MnM to complete this work.

Action: Prepare scope statement ready to go (to take section 6.6 and expand and update to provide the detail necessary to manage negation - Jean) and start work on that project. This would be a joint project between MnM and Vocabulary.

Action: Help desk article – Lisa Nelson no PSS necessary.

Action: Implementation guide on negation in HL7 product PSS – Jean will produce this – Vocab and MnM. – MnM Lead with Vocabulary co-sponsor. It would also be useful to have CGI and structured documents included.

Next Meeting Room and Joint Meeting Requirements:Continue as a listed item on Vocab for a quarter but also but should be on the list of items for the joint meeting with MnM as negation representation (listed as joint TermInfo/Vocabulary/MnM).

9 Tuesday Q3 Meeting with officers of IHTSDOChair: Jim CaseScribe: Heather Grain Number of attendees: 16

IHTSDO reported that internal tooling is being reviewed and the framework is now being considered more holistically. For example how is the workflow integrated. The architecture is being modularised and the functionality required in an interface based architecture which provides flexibility in how things are implemented. The workbench continues to be used by a number of national release centres and enhancements and fixes are being undertaken but the objective is to move to an internet based approach to better support the needs of all.

Tools are being built for members to be able to undertake: Mapping – the existing tool is a prototype and is being made a release

version 1.0 by the end of April

document.docx

Refset Management – for member countries to create and manage reference sets. This will be an online service hosted by IHTSDO through a browser. The first version of this is also due in April. It will be an initial cut, not necessarily all the requirements and will be extended and improved over time.

Workflow management User management Anyone using the workbench will have a pathway for migration.

Infrastructure development – the foundations are being established as phase 1, phase 2 focuses on authoring. Processes like cloning, retiring which support improved speed and workflow. Activities are divided into small units of functionality in order to produce outcomes quickly with ongoing iterative development.

The intention is to build the tooling suite. Also under consideration is how to improve collaboration for members, how the terminology is published, how tools to support members are defined and built and made available, how content is made available.

The modules of tooling are open source developed using apache. Once tested it is hoped that release cycles will shorten.

Question: Will it be possible for extension managers to view content as it is being added so that they can track against their own purposes? Answer: The current request system allows extension managers to see what is happening in more detail as this will be a more integrated system allowing you to see exactly where your request is in the system.

In future the whole process should be transparent.

As we develop our requirements we will share them with IHTSDO to inform them without expectation of their inclusion but they might inform development.Internally the intention is that within 3 years the members will be using the new tool. Those who are using the workbench will be provided with a mechanism for transition over time to the new tooling.

Tool sets for clinical terminology focus on a large domain which does not cover the structural components of the RIM. These coded concepts, and there are thousands of them. These might result in content n an HL7 extension.

HL7 sent a letter to IHTSDO last July concerning the use of value set definition distribution including SNOMED CT IDs and descriptions. Because our mechanisms are to define intentional value sets with SNOMED CT we have a number of sets such as this SNOMED CT and all of the children. This does not enumerate the content of the group. This does not appear to meet the

document.docx

requirements for public good release of information which is not intended to use more than the SCTID and description.

The question was asked whether these would be a violation of the public good specification. The whole idea of public good is a little complicated. Some think that if they have a public good agreement they don’t need to be an affiliate. You can use it in a non member country without fee – but you still need to be an affiliate. Fees are waved for public good such as research or for disasters or for other public good situations.

Agreements are being reviewed and the intention is to tidy this up and make clearer to all. Declaration that the content belongs to IHTSDO must be included, and the wording for this was requested and provided.

Action: Jane / David requested to provide the words and forward to Ted and Jim.Action: Rob H will do CDA, Heather has asked Don Lloyd, Ted will cover other publishing requirements.

Role changes: David Markwell is now the Implementation and Education Officer while Jane ;Millar is responsible for Collaboration, including agreements. HL7 agreement completes in April this year and needs to be revisited.

Portugal was added to the national members of IHTSDO today. There are now 26 members.

There will be a release of the workbench in April.

Action: IHTSDO Tuesday Q3 will be the timetabled for this discussion at the next meeting.

10 Tuesday Q4 CTS2Chair: Russ HammScribe: Heather Grain

Number of attendees: 12

There are a number of comments which may or may not be considered substantive. This will be considered further and reported back to Vocabulary and at the end of the month determine options either:

- Proceed with targeted editorial review- Request vocabulary to approve publishing of CTS2

CTS2 Implementation Guide Project and other outstanding project reports

document.docx

Action: Russ Hamm to contact project facilitators and obtain updated details

Scope of CTS2While reviewing CTS2 there were two things beyond the scope of CTS2. Representing languages and terminology which has retroactive changes.

Language TagsAt present the following format is recommended for language tags in HL7 CTS v1.2 and possibly in other HL7 standardsEn, en-US, en-GB, fr, fr- FR, fr-CA, etcRequired two letter language code lower case from iso 639-1Optional two letter country code upper case from ISO 3166-1 alpha – 2, preceded by a hyphen.

This is similar to RVC 1766 (1995) without the extensions. RFC 1766 is now marked obsolete.

There is a requirement to use the vocabulary of ISO external to HL7. There is a question on how to create a value set expansion for this content when using CTS2. The concept identifier has to be used to refer to the specific code system. CTS1 has one answer but the use of language requires a syntactic construct of more than one list of codes and all of these lists are external to HL7 – how is this to be done in a standardised, unified way. This is a design policy recommendation and the appropriate answer will take some consideration.

IETF BCP 47 primary language subtag provides a specification. This problem is more complex than this specification. BCP47 offers a post coordinated approach to different code systems. The HL7 terminology model considers each to be a different code system. We don’t have a way to make an entry in our systems which represents post-coordination of values from different code sets.

We have no standards on post-coordination from multiple terminologies – This was identified as a weakness in our current mechanisms and models. This is a particular variation of post-coordination work being undertaken by Charlie McKay.

Action: Ted to contact Charlie McKay to ask if he is able to include this use case in his work, and also to confirm the status of the current work item.This work is syntax for value set definitions where the value set is made up of post-coordinated expressions for SNOMED CT. It is currently misnamed Binding for SNOMED CT.

This will require a PSS statement. Action: Senthil to prepare PSS statement for Vocabulary review

Terminologies that do retroactive changes – for example:

document.docx

Ambulatory payment classification (APC) Healthcare procedure coding system (HCPCS)There are possibly others – these are largely reimbursement related terminologies

11 Wednesday Q1 Value Set Definition (hosted by MnM)Hosted by MnM – see their minutes.

Number present: 23

12 Wednesday Q1 Vocabulary in FHIR (hosted by MnM)Hosted by MnM – see their minutes.

13 Wednesday Q3 Publishing HostsSee publishing minutes

Number of attendees: 7

14 Wednesday Q4 InMInM Hosting see their notesIt was agreed that V2 and FHIR documents need to be published with the SNOMED CT license statement.

15 Thursday Q1 Joint meeting with CGIT Chair: Ted KleinScribe: Jim Case

Number of attendees: 7

NIST - V2 Value Set

Rob Snelick provided a presentation on the HL7 V2 vocabulary specification – Value set classification proposal. His presentation provided a clear description of the issues around testing constraints with examples.

He then presented a proposal:1. Specify the binding of a value set to a message element.2. Specify the conformance strength of the binding3. Specify the vale set definition

document.docx

4. Define value set usage codes and their use5. Handle code exception with the definition of the data type

His proposal is to include a new attribute of Conformance Binding with the values of Mandatory or Recommended. The conformance examples showed that elements with optional usage and mandatory conformance binding would apply only to further constrained profiles. Additional information about value set definitions and usage definitions were provided.

Usage types include: Required, Permitted and Excluded. With regards to the requirement for the use of a code, it is defined by the data type of element. The proposal includes a suggestion that the distinction between CWE and CNE be removed as the issue around the confusion of the relationship between the data type and the value set. There is considerable confusion about how these two data types are implemented.

Changes that are being done in the V2 tables project will have some impact on the way the tables will be used in profiles. The current structure makes it difficult to begin implementing the distinction between value set definitions and data types. The impact of the tables project on the value set definition project must be recognized and harmonized.Proposal elements 1-4 come as a set and element 5 is a new further constraint on the use of a data type.

Key observations1. Specify the binding of a value set to a message element. – nothing new in

this part of the proposal. Simply an indication of the binding of a value set to an element.

2. Specify the conformance strength of the binding – specifies the coding strength; mandatory is a SHALL whereas the Recommended is a SHOULD with no conformance requirement.

3. Specify the vale set definition – The value set definition has both metadata and the set of codes the value set resolves to.

4. Define value set usage codes and their use5. Handle code exception with the definition of the data type

Extensive discussion about the alignment of the conformance criteria and the value set definition project ensued. Rob (or his designate) was encouraged to participate in the value set definition project to make sure his requirements are included in the outcome of that project.Value set classification- Extensibility of a value set has two proposed characteristics; open (may

be extended) and closed (may not be extended).

document.docx

- The proposal to include two new columns in the table definition for an implementation guide; Usage and Code system that will define which values in a table are defined as to what may or may not be used.

An explanation of the value set usage was given from the detailed information provided on the slides. A discussion of the impact of these decisions on how VSAC might represent them did not result in a clear path forward and issues would need to be forwarded to ONC to determine how to distinguish mutually exclusive grouping value sets and overlapping grouping value sets.Frank raised the issue of whether the documentation of these proposals is seeking to make this easy or complete and correct? The proposed distinction between value set definitions and data types would require additional work on the part of constraint profile developers to make more explicit the binding and usage of values sets for a particular element. Another issue that has not been discussed in detail is how to manage the versioning of these constrained profiles as value sets evolve.

16 Thursday Q2 Hosting CGITChair: Jim CaseScribe: Ted Klein

Number of attendees: 7

Continued from previous discussion

Examined the Open/Closed parameter on Value Sets. The WG recommended that it is better if things are explicit rather than implicit. Rob pointed out that this has some serious issues related to the Required vs. Permitted flag as soon as you are not in the space of these tiny HL7 tables with only a handful of rows.

Everyone agrees that the three states of Required, Permitted, and Excluded for coded values are a required function. We need to determine if there are two processes that should be available to specify this: the row-by-row flag on a code in a table, or the MIN/MAX/IGNORE structures defined in Core Principles. We will examine which way is best for this.

There was significantly more discussion on VSAC and other efforts that need this work.

17 Thursday Q3 PlanningChair: Ted KleinScribe: Heather Grain

Number of attendees: 9

document.docx

TermInfo Comment DispositionReview of comment from Wendy H. related to TermInfo ballot disposition. Terminology artefact is what terminology may be bound to an artefact.Wording modified. See comment disposition document for voting and disposition details.

Tutorials:The following 4 tutorials are required:

Vocab introductionTermInfo AdvancedSNOMED CTAuthoring value set content (previously best practice in terminology development).

Action: Heather to notify HQ and circulate tutorial specification documentation for Vocab WG to consider

Vocabulary WG CallsTed (agenda, minutes and call) with Russ as backup. Heather to set up recurring go to meeting.Frequency: Thursday fortnightly (every two weeks)Time of day: 2pm New York, 6am Melbourne, 7pm UKDuration: 2 hours Date of First Call: Starting Thursday 24th (New York and UK), 25th Australia

Version 2X table callsFrequency: fortnightly (every two weeks)Time of day: 3pm New York, 7am Melbourne, 8pm UKDuration: 90 minutes (as we have a large amount of work)Date of First Call: Starting February 6th

Value Set Project calls: Ted to arrange and Rob McClure backupTime: 4pm New York, 8am, Melbourne, 9pm UKFrequency: WeeklyDuration: 1 hourStarting: Tuesday, January 28th.

TermInfo CallsRob Hausam to arrange (no backup currently).Time: 8am New York, Midnight Melbourne, 1pm UK.Frequency WeeklyDuration: 1 hourStarting: January 29th

document.docx

Minutes and backup Due February 3rd heather to produce and backup is Russ.Post working group meeting survey: Due 2 weeks Russ – Heather backupPhoenix meeting room requirements and bookings: Jim and Ted backupCTS 2 standard publication – Russ is primary and Carmella is secondary (January 31st for changes, and February for publication).Phoenix agenda – Jim is primary Ted secondary – available next conference call.Project status updates – Jim will verify that they are done3 year plan to be reviewed in 2016.

Joint meetings have been confirmed and included on the agenda plan.

18 Thursday Q4 Trifolia Workbench demonstrationChair: Jim CaseScribe: Heather GrainAttending: 9

A demonstration of this tool was provided by Sarah Gaunt from Lantana. The tool features:

Template versioning CDA implementation guide can be generated directly from the tool, Export vocabulary files

CDA R1 are included.

Browse implementation guides – allows you to view and edit documentsBrowse templates

19 Friday Q1 and Q2 V2 TablesChair: Wendy Huang (CGIT)Scribe: Ted Klein (Vocab)

Attending: 8

We looked at Wiki to see if we were finished with the July 7, 2011 minutes. #10 was done, but not the others. We need to have a discussion with INM about recommendations for the tables with ‘No Suggested Values’ and what should be populated in the codeSystem component of the CWE datatype. If local values are created for this (which must be done since there are no suggested values), should this value set of local values have its code system identified with an ‘L’, or the table number, or ‘99zzz’ or something else? Mead suggests that we be silent on this and leave it underspecified.

document.docx

We went through the rules in the July 7, 2011 minutes and updated the Wiki. We discovered new understanding about our rules around versioning and what triggers the creating of a new code system rather than a version. We introduced the topic of hierarchy in V2 vocabulary, but ran out of time before completing the discussion. We will resume this discussion on the first tables call on February 6, 2014 at 3:00PM EST. We finished the July 7, 2011 minutes rules extraction, but still refining the wording for #9 in that document (Wiki new code system rule 4). We added a number of new rules from this minutes document.

The Wiki page for the project can be found at http://wiki.hl7.org/index.php?title=V2_Code_Table_Project

The next call will be determined during our planning and discussions in our joint meetings on Thursday morning at the San Antonio WGM next week. Ted will distribute the minutes. Call adjourned at 12:36PM CST.

document.docx