Q3 Sunday - Agenda Planning - Health Level Seven …
HL7 Vocabulary Minutes – San AntonioJanuary 2017Q3 Sunday - Agenda PlanningHL7 Vocabulary Meeting MinutesLocation: San Antonio, TexasUSA(CP co-chair present), P Present, T present on telecon.Date:2017-January 16 – 20FacilitatorTed KleinNote taker(s)Heather GrainAttendee NameAffiliationPCJim CaseNLM.PCTed KleinKlein Consulting.PHugh GloverBlue WavePGreg GustafsonPenRadPCRob HausamHausam ConsultingPCRob McClureMD PartnersPCHeather GrainGlobal eHealth CollaborativeQuorum Requirements Met:?YesAll changes to the agenda were logged on the wiki: Q4 Project review and Training ReviewHL7 Vocabulary Meeting MinutesLocation: Baltimore, USADate:2017-January 16 – 20FacilitatorTed KleinNote taker(s)Heather GrainAttendeeNameAffiliationPCJim CaseNLM.PCTed KleinKlein Consulting.PSusan BarberTN Dept of HealthPGreg GustafsonPenRadPOyvind AasseNorway Directorate of e-HealthPCRob McClureMD PartnersPCRuss HammPCHeather GrainGlobal eHealth CollaborativeQuorum Requirements Met:?YesProject ReviewAll Vocabulary projects on Project Insight were reviewed: ()Only projects that are active (not awaiting approval) were discussed at this meeting.Project 1197 Terminology Quality Development and Management Processes (TQA) Project was reviewed. The scope of items within this project is being progressed through overview and focus on resolution of specific issues. There is a need for TQA review of the Governance process documentation. First project call for this project should review the scope items and the priorities for each action to ensure the coverage and progress management for this project.Project 1247 HL7 FHIR vocabulary specification updatesLeader Rob Hausam, and Ruben Daniels - This project gives ownership of the Vocabulary specifications in FHIR to Vocabulary. The vocabulary pieces and resources should be governed by Vocabulary. This process is to define the management process for curation of the relevant resources.ACTION – Jim will follow up with Ruben and Rob to find out the status of this project.Project 1306 Unified HL7 Terminology Governance ProcessApproved by Vocabulary, awaiting approval from MnM and HTA. Discussed formally tomorrow.Action: Ted following up with other work groups. HG to put on HTA agenda (done).Project 849 Terminfo Focus between now and Madrid will be to establish guidance for the use of SNOMED CT in FHIR resources.Project 1047 Characteristics of a formal ‘value set definition’.This is DSTU seeking comments. No action now. Review issues identified in September meeting to plan actions beginning January 2018. ACTION - done: Agenda requires a quarter for this activity in the September meeting Jim Case has put it in Monday Q3.Project 630 Develop and publish principles and guideline for syntax for vocabulary bindingTo be discussed in Q2 Thursday. Move this project to Vocabulary rather than conformance.Project on Tooling The group were unable to find the project details for Vocabulary Tooling. There is a known PSS which was approved but it is not showing in project insite. ACTION: Russ will investigate and report.Action Item ReviewThe action item list was reviewed and updated. See the updated file at: Tutorial ReviewHeather Suggested the following webinars for developmentIntro to TermInfo – needs a more descriptive title for those who don’t know what TermInfo is. – how use snomed CT in HL7, including FHIR.Prepare a harmonization proposalHeather prepared the first draft and the meeting reviewed the tutorial specification see V4 of this document.Monday Q1 Terminology Governance Project and ToolingCo-chairs in bold.FacilitatorJim CaseNote taker(s) Heather GrainAttendeeNameAffiliationPJim CaseNLM.PHeather GrainGlobal eHealth CollaborativePTed KleinKlein ConsultingPCarol MacumberApelonPRuss HammIMOPA. MacleanInfowayPCarmela CoudercIMOPBrian PechKPPDaniel KarlssonHL7 GermanyPRaychelle FernandezVP DHITPRob McClureMD PartnersPGreg GustafsonPenRadPSusan BarberTN Dept. HealthQuorum Requirements Met:?Yes 12 present plus chair.Objective to provide a single source of truth for all terminology artefacts which an also support FHIR requirements. Ted Klein shared documentation about this project and sought input from the WG.This is to develop a process recommendation to replace harmonisation process and fold in the governance requirements for all terminologies across all HL7 product lines. The process must also be open, asynchronous and maintainable. This is intended to be available to non-members of HL7. It must be easy to use and available internationally to encourage those who are not familiar with the detailed processes of HL7. The process must be reconciled with the ballot process, ANSI rules.Drafts will be available on the project page but this has not yet been set up.The process includes:Openness – anyone may submit a proposal. An artefact is saved which represents their requirements/changes etc. Submission notifies relevant stakeholders, different kinds of proposals for different kinds of objects may have different balloting rules to meet practical requirements. At the end of timeframe, or all requirements are metIt may pass, fail, or have controversial elements. If failed it is archived. If it passes it goes into a queue to have the approved changes applied to the central terminology store. The terminology store is being defined by Vocab, HTA in collaboration with Tooling. Specific issues includeStructural terminology – bound to standards rather than records or clinical practice. Table of data types in V2 standards. In V3 these are the mood codes. Domain Content Terminology – codes chosen to represent concepts in HL7 standardsExternal Terminology – the code systems used in HL7 standards but maintained by others. Ted presented diagrammatic explanations of the draft processes. One of the issues is where comments are handled. There were two options. That comments are dealt with either by terminology curatorDocumented disposition which recycles into the ‘ballot’. Input and assistance is needed to define a pass and consensus management Link to document discussed: curation must be adequately resourced. It is currently estimated that the terminology curation would require approximately 4 hours per week, based upon an estimate of the workload estimating the current number of requests. It is more difficult to estimate the load for harmonisation across the product family. The proposal includes the need to fund the hours required for terminology curation.Alterntive methods of resolution of issues which arise were discussed. It is hoped that most content modifications will occur through work groups and simple, flexible resolution processes – documented and formal but able to be managed through calls etc. Where there is a highly contentious issue which cannot be resolved through the simpler process there may be a need for an HL7 Harmonisation Face to Face Meeting (occurring at HL7 WG meeting). The diagrams in the diagram seek to provide a simplified view of the process. Monday Q2 Terminology Governance Project and ToolingCo-chairs in boldFacilitatorJim CaseNote taker(s)Heather GrainAttendeeNameAffiliationPJim CaseNLMPHeather GrainGlobal eHealth CollaborativePTed KleinKlein ConsultingPCarol MacumberApelonPRuss HammIMOPA. MacleanInfowayPCarmela CoudercIMOPDaniel KarlssonHL7 GermanyPRob McClureMD PartnersPGreg GustafsonPenRadPSusan BarberTN Dept. HealthQuorum Requirements Met:?Yes 10 present plus chair.Continuation of the previous discussion in Q1.Confirmation that the process is not limited to the HL7 ballot process it operates outside that cycle. The publication of ballot content would be an extract from the current or specified version of content from the terminology store.It was acknowledged that there is still considerable evolution required, including the definition of extensions to the HL7 vocabulary model to support our requirements. It is expected that none of the existing models will be sufficient for what is required. There is a need to make the relationship to ballots and engagement clearer.Action: Ted will send out a revised draft to the vocab. List.Consensus managementThis process replaces the harmonisation process currently in place.Step 1: is to determine the requirements for the consensus pool. What is pass / fail etc.Step 2: how to make the community aware that there is a pool available for comment and that it is open.Step 3: Submitter begins the process for changing/adding to the terminology store. This may be a person, a group or organisation. There is a need to differentiate between the point of contact (called the submitter) and the group responsible for the request (proposer).Action: Ted – update Endorsement acquisition process document - should indicate community engagement more clearly. Update community on the diagram to consensus rmation is needed on changes made to the request and the tooling must support these requirements. There was significant discussion on the levels of status information. Canada’s experience shows that keeping it simple has many advantages. There may be advantages to keeping it simple in early tooling to learn what is really required. Reduce errors and efficiency of editing, proposing and applying changes needs to be considered. Tooling is there to make quality processes easier to achieve.left53340Reference from Rob McClure regarding STAMP status informationHere is some info on (Status, Time, Author, Module, Path) STAMP. We use a standard for managing fine-grained change to data artifacts, where we add new STAMPed versions of artifacts, resulting in a STAMP Chronology.?The?chronology provides a means to generically represent the revisions to a?component over time, and to?index those revisions by status (active, inactive),?effective time of change, author of change, module within which?the change?occurred (international edition, US extension, AMA extension, etc.), and the?development path of the?change (development, release candidate, etc.). Taken?together, these fields can be referred to as a versions STAMP?(status, time,?author, module, and path).STAMP is an amalgamation of widely used concepts that provides simplification and standardization. I’ve used it extensively, and the IHTSDO has as well in its tooling efforts.?See for example, ?Table 88: Module Dependency Reference Set - Data Structure in the SNOMED technical implementation guide.? particular reference is important for a couple of reasons:?Notice that objects are identified by UUIDs as the “identified object”. This is the same as I proposed: Identified objects using UUIDs as the primary identifierNotice the fields:?active,?effective time, module id. These correspond to the ST*M* of STAMP. They use the entire STAMP internally, but on release, they strip the author and path…?Notice that this particular refset—the module dependency reference set—is the way SNOMED provides for representing dependencies between modules, taking account of module versioning. This is how we should initially approach “OSGi like” dependency declaration between modules.?Path has the meaning defined here for branch:?(version_control)The problem with branch, is that it is technically incorrect for our use (and does not fit the STAMP acronym). A branch can have only one origin, where a path can have multiple origins. We frequently use multiple origins to represent a development path that incorporates more than one module (for example a version of SNOMED, and a version of the US extension, and a version of LOINC… 3 origins to a development path).?For more background, see for example Feiler’s paper on “Configuration management in Commercial Environments” from Rob McClure regarding STAMP status informationHere is some info on (Status, Time, Author, Module, Path) STAMP. We use a standard for managing fine-grained change to data artifacts, where we add new STAMPed versions of artifacts, resulting in a STAMP Chronology.?The?chronology provides a means to generically represent the revisions to a?component over time, and to?index those revisions by status (active, inactive),?effective time of change, author of change, module within which?the change?occurred (international edition, US extension, AMA extension, etc.), and the?development path of the?change (development, release candidate, etc.). Taken?together, these fields can be referred to as a versions STAMP?(status, time,?author, module, and path).STAMP is an amalgamation of widely used concepts that provides simplification and standardization. I’ve used it extensively, and the IHTSDO has as well in its tooling efforts.?See for example, ?Table 88: Module Dependency Reference Set - Data Structure in the SNOMED technical implementation guide.? particular reference is important for a couple of reasons:?Notice that objects are identified by UUIDs as the “identified object”. This is the same as I proposed: Identified objects using UUIDs as the primary identifierNotice the fields:?active,?effective time, module id. These correspond to the ST*M* of STAMP. They use the entire STAMP internally, but on release, they strip the author and path…?Notice that this particular refset—the module dependency reference set—is the way SNOMED provides for representing dependencies between modules, taking account of module versioning. This is how we should initially approach “OSGi like” dependency declaration between modules.?Path has the meaning defined here for branch:?(version_control)The problem with branch, is that it is technically incorrect for our use (and does not fit the STAMP acronym). A branch can have only one origin, where a path can have multiple origins. We frequently use multiple origins to represent a development path that incorporates more than one module (for example a version of SNOMED, and a version of the US extension, and a version of LOINC… 3 origins to a development path).?For more background, see for example Feiler’s paper on “Configuration management in Commercial Environments” Q3 TutorialsCo-chairs in boldFacilitatorRob McClureNote taker(s)Heather GrainAttendeeNameAffiliationPRuss HammPHeather GrainGlobal eHealth CollaborativePCarmela CoudercIMOPGreg GustafsonPenRadPSusan BarberTN Dept. HealthQuorum Requirements Met:?YesFree tutorials – the PowerPoint should be available for these presentations. Heather confirmed that the PowerPoints for all tutorials are available when you enrol in a tutorial. If it is a free tutorial, therefore the PowerPoint is free.Facilitator Roles and Responsibilities webinar is done and available.Action: Ted to complete Harmonisation Preparation webinarRequest that Vocabulary do an audit on the FHIR vocabulary tutorial. This was welcomed by the Education WG. When tutorials are given collect questions, which can be included in webinars. Webinars should all include what are the things we assume you know and where do you go next. Learning pathways should be clear and contact details for more questions and information should be provided.Create webinar for code systems and terminology selection – short web session also has a specific page in resources with all the relevant linkages.Divide the authoring value set into sub webinars. Examples of good and bad practice need to be collected. Select a collection which cover the bases, some intentionally defined and extensionally defined, some with includes and excluded. These examples should be able to be understood without being a clinician.We need to create a repository of examples of good and bad or reasons why one approach is better than another. The intention is to gather resources which can be used in tutorials but also be referenced to help people understand the pitfalls and opportunities relevant to terminology specification. Action: All send examples of good and bad terminology artefacts to Heather. Action: Russ will come up with a few examples of value sets and represent them in FHIR specification formatAction: Heather Grain to collect and consider how a repository of these examples could be published.Concerns over our ability to inform co-chairs and others regarding vocabulary activities – This page is specifically for facilitators and others interested in vocabulary processes. This could include if you have new content requests, new tutorials available. Ability to have a watch facility. If they subscribe to the page they will get a notice of what’s new. Could use the vocabulary standards portalQ4 Monday TermInfoFacilitatorRob HausamNote taker(s)Rob McClureAttendeeNameAffiliationPOyvind AasseNorway Directorate of e-HealthPSusan BarberTN Dept of HealthPJim CaseNLM.PCarmela CoudercIMOPGreg GustafsonPenRadPRuss HammIMOPRob HausamHausam ConsultingPMark KramerMITREPRob McClureMDPPRicki MerrickAPHLPDaniel KarlssonHL7 GermanyPPeter JordanHL7 New ZealandQuorum Requirements Met:?Yes 11 plus chairSCT and working directly in two places in HL7:FHIRCIMIAnd liaison for content through HTAHL7 Vocabulary portal allows download of SNOMED CT for use in HL7 artifacts – see link: TermInfo Implementation GuideDiscussed current ballot on V3 is now out 2 years. No discussion needed on this activity at the moment.TermInfo and FHIRShould Terminfo for FHIR be the next TermInfo task? working on some guidance on use. Coordinate with SNOMED International (formally IHTSDO) work on that (Linda and David are on the implementation side, Jim is working on making the content work, if new content is needed)Review the collaborative work proposal.How is this different from working with HL7 overall work with other standards? Just the fact that they are picking the standard to work with – all product families have value sets may be a scope issue. We want to support rapid development of FHIR standard. FHIR has expressed interest in work with SNOMED International under the overall agreement with HL7.CIMI is another group that is doing similar things, but they are not a product family, but CIMI models are being used in FHIR resources - CIMI representatives were involved in planning of this document.Based on the agreement for free use of SCT codes in HL7 artifacts internationally HL7 Vocabulary portal allows download of SNOMED CT for use in HL7 artifacts – see link: Note: clarification post meeting: the agreement for free use of SCT codes – is that we may apply for specified codes and descriptions to be available free for use by all using HL7 standard/s. There is no agreement for free use of all of SNOMED CT codes by HL7 users.The portal is for standards development purposes – not for implementation use which requires specific licensing.FHR terminology server for SNOMED CT provide by SNOMED International is being discussed – that would be for the standard at the namespace level – that will not cover the domain specific ref sets etc.And FHIR is working with SNOMED International on model-meaning binding of the FHIR resource elements. Those also apply to CIMI models – working on trying to actively align more with the underlying SNMED CT concept model, but there is a problem between the scope and CIMI FHIR resources.Purpose of SNOMED concept model is to create the ontology, but we have a lot of atomic SNOMED concepts that can create richer representation in the context of a specific model, that we don’t necessarily want to add as pre-coordinated content, so a lot of the model-meaning bindings might be created as expressions rather than pre-coordinated concepts.In FHIR profiling if you set an attribute to a fixed value – in a profile can you slice the term into sub-terms (more granular)? This should allow only creating more constrained subsets (can I use the descendants of the term used in the value set? Rob M says no, unless it is part of the value set definition. The value set defines an expansion set to be used in IG instance and you can answer ONLY once you have created the expansion set based on the definitionIn value set definitions can create a CEA = send an exception = CWE in v2 – it is marked as an exceptionTermInfo will fit into the implementation guidance section of the collaboration proposalHopefully this can be as much computable as possible with additional prose for human understanding based on the FHIR tooling availableThe TermInfo guidance will be for R4 of FHIR at the earliest. This could include guidance on transformation between local codes and SCT. There is also a need to consider value set bindings – do we restrict to only core, also create guidance on how to localize – also focus on making the value set definitions intensional as often as possible and allow different editions to consider = this kind of guidance should come from HL7, while details on how to create some of the localization in SNOMED CT side.Need to decide who will be the core resources – will need to create a PSS and that will help with thatTermInfo project in HL7 Vocab will work with SNOMED International in developing guidance for use of SCT in FHIR, which will involve a FHR implementation guide and profiles – limit to core clinical resources and diagnostics and review the other resources on the level 4 row, potentially starting with the most mature resourcesAction: Rob H will draft PSS and distribute – bring up in later Vocab quarterDiscussion on time for Terminfo proj To meet - Sweden, London, NZ, USA. Current 9am ET Wednesday Tuesday Q1 Realisation Requirements for Value Set ExpansionFacilitatorJim CaseNote taker(s)Heather GrainAttendeeNameAffiliationPSusan BarberTN Dept HealthPJim CaseNLM.PCarmela CoudercIMOPHeather GrainGlobal eHealth CollaborativePGreg GustafsonPenRadPRuss HammIMOPRob HausamHausam ConsultingPPeter JordanHL7 New ZealandPDaniel KarlssonHL7 GermanyPTed KleinKlein ConsultingPCarol MacumberApelonPAndrea MacleanInfowayPRob McClureMD PartnersPJean NarcissiAmerican Dental AssociationPAnnette VernonQuorum Requirements Met:?Yes 15 present plus chair.Value set definition project did not cover all requirements associated with value set expansions. There is a need for expansions as these are what implementers use as the artefact in implementations. We need to determine if HL7 should define a standard for value set expansion. Some families already do this. FHIR has an expansion profile. This can be an input to services which create expansions but others say given an expansion the documentation describes what is in the expansion and details included. Expansions are a list of coded concepts, what the codes are and whether display names are included etc. is not consistent or clear. Where you are using code systems with multiple descriptions this can be a problem. It was agreed that a PSS is needed to cover this new work item.Motion: Ted moved that a PSS be established to address the need defined below.Seconded: Rob McClureVote: For 15, Abstain 0 , Against 0Action: Ted Klein to develop PSSThere is a need to define a cross-HL7 product family specification that describes how to clearly specify the concept representations (codes) and associated concept metadata to be included in an instance of a value set expansionThis project will combine the binding statement information necessary to obtain a value set expansion, any desired allowed modification to the binding information in the context of a specific use, plus the set of minimum and allowed additional information to be included in an instance of a value set expansion. This project will begin with FSD, FHIR value set and expansion profile resources to define this specification and may result in modifications to the VSD and FHIR resources. DiscussionThe FHIR profiles are used to direct creation of the expansion, but other products do not and the FHIR process in not necessarily consistent. An expansion should contain a component which describes what is in it. The expansion profile in FHIR is how to get an expansion rather than the requirements of the content and structure of the expansion, There is informative information about Value Set Expansion Files in section 8 of Characteristics of a Formal Value Set Definition, but this is insufficient.There is the value set definition which tells you about the value set and the content logical definition – here is how to get the member so the value set expansion. The requirement of the code list/value set expansion content is a set of concept representations and other things needed to make the set of codes useful in your use case. The objective is to identify the minimum requirement for quality expansion content as well as additional information which could be included for different use cases.The value set definition underspecified all of the components implementers have identified as needed in expansions. FHIR went ahead and established an artefact to meet this need – the expansion profile. If an expansion profile does not exist or if it is underspecified. Example: If an expansion profile creates a set of LOINC codes and definitions (long common name) but it is not specified which language you want – you will assume it is English but the service has provided French instead – how will the system know that these are French translations of the long common name.The FHIR expansion profile serves as a starting point but this work will be across all HL7 products. It is envisaged that this will leverage, update and improve FHIR expansion profiles and offer mechanisms applicable across other HL7 products in a consistent manner.This work is about the member set which may include the definition of a minimum set of components (as specified in an expansion profile). This project should use standard FHIR processes if it identifies any requirements for FHIR it is about getting the functionality needed to support other products but in a manner which is consistent with FHIR. The deliverable explains the requirements for expansion profiles across all HL7 products, including areas of known problems such as V2 and CDA.There is a need to clearly define the problem/s which this work will solve. There are problems when data aggregation is attempted from what are supposed to be standardised expansion content.An instance of an expansion we are calling an expansion file. Scope: This will be normative track product.This product is intended to cover all HL7, including V2, CDA, FHIR, and though not a product it also impacts CIMI. Calls and times will be determined on Thursday.Tuesday Q2 Vocabulary Hosting Structured DocumentsFacilitatorTed KleinNote taker(s)Heather GrainAttendeeNameAffiliationPSusan BarberTN Dept HealthPJeff BrownASCOPJim CaseNLM.PGeorge ColeAllscriptsPCarmela CoudercIMOPGay DolinIMOPBenjamin FlessnerEpicPRick GeimerLantanaPHeather GrainGlobal eHealth CollaborativePGreg GustafsonPenRadPSteve FineCernerPRuss HammIMOPRob HausamHausam ConsultingPLindsey HoggleANDPDaniel KarlssonHL7 GermanyPTed KleinKlein ConsultingPAustin KreislerLeidosPTony LaurieNoridianPFrancois MacaryPHAST/HL7 FrancePRob McClureMD PartnersPAndrea MacleanInfowayPCarol MacumberApelonPSean MuirVHAPIvan NiezgockAccenturePRussell OttDeloitte consultingPSteve PosnackHHS/ONCPMark ShafarmanShafarman consultingPDaniel VreemanRegenstrief InstitutePGenny LuesmanCDC/NIOSHQuorum Requirements Met:?YesTopic: Value Set MaintenanceThough we are careful to follow good terminology practices we are under contractual arrangements with organisations such as SNOMED International – to keep our content current. This means that code system values have to be updated from time to time. We need to discuss how we do this and maintain it. You are required to use the current version of the international release and standards should be up to date within 18 months of the current standard. If you content is from a national release of SNOMED CT and the standard is international a request to promote that material to the international release should be made to the HTA. Ted encouraged the process of review of terminology early and explained how harmonisation is being decoupled from the balloting process. Publication will be a snapshot at the time of publishing or ballot. We would like to retire the current process as soon as possible. Rob McClure presented information on VSAC downloadable resources including value set downloads and definitions at Vsac.nlm.There is a health services location code system that we have used and we created an OID and one created by VSAC who also have an OID. Resolution to this is being discussed. Topic: Binding SyntaxRob McClure showed how to get to the binding syntax wiki and explained the approach to binding. Considerable effort has been made to make the requirements much clearer and implementable.The information required for an expansion set must always indicate the value set definition, version of the value set, which specific code system and which version of the code system. If you don’t specify each of these components your expansion may not be consistently implemented or comparable.All future specifications are expected to follow the binding approach documented, this includes CDA future standards. This is semantic specification requirements to support interoperability. It also supports derivative specification. It is necessary to make sure that this binding approach is sufficient to meet the need, and SD has experience in implementation, Vocab seek input on whether the binding specification is sufficient.The question then is how will CDA implement these requirements. Topic: Combination concepts / codesThis is a case with a main code and a relationship observation / value cardinality. Detailed presentation available at (BDF)(GD)%20V2.pptxSome vendors/implementers want a simple way to Reliably send in more granular coded information in CDAThat correlates with the way clinicians document problemsCDA R2 does not allow for the notion of ‘equivalence’ in translationCode (FHIR has this notion)There is a need to consider informal loosening of translationCode ‘same-as’.Best available snomed ct code is in observation/valueOriginal Text may capture the text the clinician captured in the EHRs User interfaceIn translationCode trading partners could use custom (interface) terminology code OR their local system code/identifier that represents the code for the originalText the clinician capturedThis code could be more specific than the best available standardised code but it reflects clinical intent of the clinicianThis allows machine computability of more specific terms.This functional use case is intended only to be used to make content more specific in the example, but rules were not considered around it so it could be less specific. Same As is used to mean best batch it does not mean same as. The data type guidance should make this clear and explicit. This could be included in the Vocab Policy document. Vocab will bring this up in the joint session with MnM.Problems include:Multiple codes for a single conceptMany EHRs have the capability to map multiple codes to a single concept.Some EHRs have the capability to map related codes (not ‘same-as’)How to easily send? What should be the recommendations when people don’t use post-coordination but implement the principles of post-coordination in their information model. Qualifiers in data types R1 were built for handling post coordination. This doesn’t work well for ICD and other areas where post coordination is used.Observation/value cardinality.In base CDA observation/value is 1…*In CCDA observation/value is restricted to 1…1Could this be considered an errata/enhancement?Could be a solution for previous issue of combination multiple related not same-as codes. Are there rules for what the relationship/type of codes allowed in observation/value in an observation?Is there a conformance concern? What does it mean to have more than one way of representing this information? There is the notion in observation value that the results of tests and observations may be multi-part. The parts have to be interpreted by the clinician as a group. You can have a single laboratory test where there are multiple pieces with different results. This solution seems to be partial and potentially problematic. With post-coordination, you want to know the relationship between the tuple. The suggested approach does not resolve that requirement. It would be useful to have explicit examples of what can’t be done well today. Action: Gay Dolin and SD to provide examples of specific problems and request more information which Vocab will consider and advise on action most ic: CDA Value Sets and HarmonisationVocabulary issues which arose at harmonisation were considered.X_ServiceEventPerformer used in ServiceEventPerformer has only PRF and SPRF. It does not include PPRF!. CDA R2.0 has all three values identified. This looks like a technical correction to the value set may be needed to support backwards compatibility. This is a problem when you migrate to CDA R2.0. OptionsAdd back to the value set would need a version management declaration. You could say that the scope of the value set should include PPRF so the new version puts it back in. When removed from the value set (which was enumerated) we made a new version effectively. We could add a new version of the value set and add it back in that way. If put back in it doesn’t solve the problem of using it in the new version of the RIM. The recommendation is to create a new value set as the RIM only includes the most recent version of the value set it will be included in the next version of the RIM.ParticipationSignature value set contains:S: signedI: inendedX requiredIn CDA R2.0 table 9 and Table 35 only shows S and X is listed as deprecated for use in CDA. This means that there is a code system of 1 value. This means that in CDA (though not in the RIM) there is only 1 permissible value.encounterParticipant.typeCode one of the code values CON was listed as CONS in the CDA R2.0 specification . this is a typographical error it should be CON. There should be no CONS – it is a typo in the spec. and the schema only lists CON. Recommendation is to publish the errata to change the specification.Action: Jim Case to add to Agenda and room requests. Another joint meeting is requested between Vocab and SD with Vocab Hosting. Tuesday Q2.Tuesday Q3 Vocabulary Hosting FHIR infrastructureFacilitatorRuss HammNote taker(s)Heather GrainAttendeeNameAffiliationPOyvind AasseNorway Directorate of e-HealthPGerman AcunaPSusan BarberTN Dept HealthPMichael CaldereroPJim CaseNLMPCarmela CoudercIMOPHeather GrainGlobal eHealth CollaborativePGrahame GrievePGreg GustafsonPenRadPRuss HammIMOPRob HausamHausam ConsultingPAlexander HenketPPeter JordonPDaniel KarlssonHL7 GermanyPRichard KavanaghPTed KleinKlein ConsultingPAndrew LiuPFrancois MacaryPHAST/HL7 FrancePRob McClureMD PartnersPAndrea MacleanInfowayPCarol MacumberApelonPIvan NiezgockAccenturePH. SoienePHarold SolbridgePDaniel VreemanRegenstrief InstitutePAnnette VernonQuorum Requirements Met:?Yes 20 plus ChairTopic: Ballot ReconciliatioDetails are in the online ballot reconciliation tooling in Gforge.Question: If there are 3 different expansions for a value set the value set definition URL should give you all you need to create an expansion. When you do an expansion you return the expansion value set and the URL and expansion identifier. You are not really using the expansion it is the same canonical URL but if you want to share the expansion there are problems with the same canonical URL with Information provided needs to be sufficient to recreate the expansion exactly. There are different services and we aren’t in control of the version being used etc. and this means that you can’t be assured without that being locked down. Additional guidance on expansion has been requested. Do we need to provide this now? GG indicated that this could be resolved. Firstly, document canonical URL expectations more clearly. Confirm understanding that each expansion should return canonical URL and a unique expansion identifier unless the resultant expansion is exactly the same. Sharing after expansion has potential issues and this can be documented. There is a need to understand how expansion identifiers work.The server may retain the identifier which may allow retrieval of the expansion content later from this same server, but there is no guarantee that this will be so. We should be able to identify the generation of an expansion and whether it is identical to another generated expansion. This would be deterministic and bindings support this capacity.Outparameters 0 definition updated to reflect error in cardinality. ApprovedConcept Map functionality – when mapping between different versions for the same code system. Default behaviours were identified – map to the root of the code group or say there is no match. This task will add a new section to the concept map to say what to do if you get through the list of the formal map and you haven’t found a map. A specific default will be defined – match to target specific code (defined) or say no match or unmapped. This would support identification of the need for more than one map.Option 1: fixed code used for any entries not mappedOption 2: use the ‘unmapped code’ – the source (input) and target (output) codes are identical.Option 3: nominate a different map.ic: FHIR Project Expansion ProfileGrahame Grieve discussed Release 3 of FHIR which will be settled in the next months. Release 4 first draft will be released for Dec – Jan 2017/18 and it is anticipated that this will be normative and ballot will be undertaken and discussed in May and Sept meetings with the intent to publish by the end of 2018. Administration will be patient information and conformance section will include vocabulary. If ballot reconciliation is achieved without substantive changes sections of the work will be marked as normative. The whole work may not be normative – but sections can be. R4 is hoped to be normative for vocabulary code system concept map and some operations. The focus in this committee needs to undertake the activities to ensure that we have the feedback and engagement needed to warrant normative status. The intent is not to add new features. Grahame asked if there were any features currently known to be missing? Terminology maintenance was an issue identified. Issues:BindingTerminology capability statementTerminology maintenance be part of the FHIR specification requirements. Ted raised the issue of whether all the V3 content is all available in FHIR. Without checking this it is difficult to be sure that all is present and consistent. A call should discuss the quality criteria requirements. New components will be STU status rather than normative. Resources have to be coherent.Value set content which is enumerated – is this to be included as an enumerated content Action: Ted include on a shared call FHIR quality issues, and maintenance and governance and discuss with PA how to handle enumerated content in schemas. Tuesday Q4 – Vocab/Patient Care (Hosting)Topic: Negation requirementsSee Patient Care minutes for details of this session.Presentation available at: Q1 – Joint with MnM/FHIR (Vocab Hosting)FacilitatorTed KleinNote taker(s)Heather GrainAttendeeNameAffiliationPOyvind AasseNorway Directorate of e-HealthPSheila AbnerPSusan BarberTN Dept HealthPCarmela CoudercIMOPHeather GrainGlobal eHealth CollaborativePGrahame GrievePGreg GustafsonPenRadPRuss HammIMOPRob HausamHausam ConsultingPAlexander HenketPPeter JordonPDaniel KarlssonHL7 GermanyPTed KleinKlein ConsultingPFrancois MacaryPHAST/HL7 FrancePRob McClureMD PartnersPAndrea MacleanInfowayPCarol MacumberApelonPRon ShapiroP Harold SolbrigPAnnette VernonQuorum Requirements Met:? Yes 18 plus ChairTopic: Use of "Code" data type for non-structural contentThe list of ballot content below was discussed and voted on in block.pose.filter should be a modifierLloyd McKenziePersuasive with Mod8766ValueSet/$validate-code definition should allow code and ValueSet.url as two input parametersJason WalonoskiPersuasive with Mod8884Need extension for min valueSet for DataElement.element.mapping.languageLloyd McKenzieNot Persuasive with Mod8911Expansion paging questionsGrahame GrievePersuasive8912Expansion Conformance questionGrahame GrieveConsidered for Future Use9033add OID for ICD-10cm to systems pageEric HaasPersuasive with Mod9095Add for examplesKeith BoonePersuasive with Mod9121Add designation[0..*] to ValueSetScott DeerwesterPersuasive9132Additional SNOMED CT Implicit ValueSetMichael LawleyNone9385ConceptMap example using code system URI, not value set URLScott DeerwesterPersuasive9425When asserting a mapping, need to be able to assert a concept map for the resulting codeLloyd McKenzieNot Persuasive with Mod9431How is ConceptMap used to map to DataElements and CDALloyd McKenzieNot Persuasive with Mod9540Change element names to 'system' and 'version' for consistency with ValueSet and CodeSystemRob HausamPersuasive with Mod9555NDC documentation should explain product vs package IDScott DeerwesterPersuasive10127Clarify use of word 'closure'Erich SchulzPersuasive with Mod10129Clarify filterErich SchulzConsidered for Future Use10244Error in Terminology Service $expand exampleSimone HeckmannPersuasive10277Revisit the proposed ExpansionProfile resourceRob Hausam (Michael Lawley)Persuasive with Mod10283Concept Map Translation: Incorrect Parameter Name In ExamplePeter JordanPersuasive10303Value set Content Logical Definition rendering for intensionally defined value sets should include descriptionsRob HausamPersuasive with Mod10357Make CodeSystem.version a CodeableConcept so it can be chosen from a ValueSetRussell McDonellNot Persuasive with Mod10437Add additional member "related to" to ConceptMapEquivalence Value SetMary DobbinsPersuasive with Mod10470Add 'exists' to filter operator code systemMichael LawleyPersuasive10490Text associated with ValueSet.lockedDate is not quite correctRob McClurePersuasive10542Definition of CodeSystem.concept.concept is incorrect.Reuben DanielsPersuasive10543ISO country code preferenceSimone HeckmannPersuasive with Mod10658Value set validate should have language as a parameter and code lookupGrahame GrievePersuasive10660Definition of excludeNested is wrongGrahame GrievePersuasive10661subsumes example is back to frontGrahame GrievePersuasive10751Support expansion.contains.designationAlexander HenketPersuasive with Mod10768ValueSet $validate-code operation should support "displayLanguage" parameterAndrew LiuPersuasive with Mod10964Example for ConceptMap $translate has incorrect parameter (valueSet instead of source)Corey SpearsPersuasive11030Clarification: Can a derived value ever be promoted to "selected," e.g., by user review? - 2016-09 core #49?Jay LyleConsidered - Question Answered11445Improve diagram - 2016-09 core #606?Lloyd McKenziePersuasive11446Summary diagram doesn't cover everything - 2016-09 core #607?Lloyd McKenziePersuasive with Mod11448Use-cases overly focused on operations - 2016-09 core #609?Lloyd McKenziePersuasive11449Use flyovers consistently - 2016-09 core #610?Lloyd McKenziePersuasive12065Update Defintion for ValueSet/filter-operator is-a?Caroline MacumberPersuasive12069Clarify he use of?Rob McClurePersuasive12217Representation of Description IdDunmail HodkinsonPersuasive with Mod12223Fix definition of requiredGrahame GrievePersuasive12278Document use of the ISO 21090 ICD combination syntax as a base part of the ICD-10 code system in FHIRRob HausamNone12302Define an extension for SNOMED Description IDGrahame GrievePersuasiveRob Hausam explained that all comments have been reviewed and addressed. There was some discussion on how the map work will function. The functionality is supported by the concept and structural mapping requirements. The majority are already addressed and others will be addressed as a result of the comments and actions required.12217 – include definition for inclusion of description ID (a SNOMED CT use case). This is not efficient but a UK requested requirement. 10543 – ISO country code preference – this is a string field which could be a two-character code or a 3-character code. Addressed.Moved Rob Hausam that the block be approved, except for 12278. Seconded by Grahame Grieve.For, 16 Against, 0 Abstain 212278 – Use of ICD combination codes in FHIR. The current specification requires that each code be separated by a space. E.g. staph aureus bronchiolitis (Dagger / Asterisk). Where postcondition is required Grahame will work with Heather G to describe them properly. Where relevant this will be a post-coordinated string in the code slot, but it will not include post-coordinated approaches to content that cover different information concepts (such as injury, cause of injury) will not be post-coordinated as these should be handled in the information model. ICD does not define display requirements for descriptions for multiple codes. Moved Rob Hausam that the disposition of 12278 be accepted. Seconded Grahame Grieve.For, 17 Against, 0 Abstain 1Code Data Type (Code Simple) is model bound – StructuralThere are recommended eternal code systems used in this area. The data types must be bound to a value set and defined in each case. Value sets for structural components are fixed. There were no further questions associated with the ballot.There are 12 deferred items which were then discussed.12617 Add display to ConceptMapRequest to add descriptions to the map to support human review. Adding a display introduces the possible lack of clarity of the intended use. There was concern about misuse. The use case where vendors review the definitions in a map to determine if the map is suited to use. This is inappropriate and insufficient – see ISO work on Map Quality Assessment (current work item – draft available for comment on Vocab Web Site).This type of data is often used and misused but at least looking is better than not considering quality at all. Document that the purpose is for user convenience end is not to be used in any translate operation and may be insufficient to assess the quality of the map.Moved Russ Hamm seconded Rob Hausam that this be acceptedVote: For 17, Against 0, Abstain 1Mode Parameter – describes whether the operation is being used by a human or a machine. The connectathon has shown that it was better to say whether this. Was mode human or machine. If renamed to exact it only indicates whether the server returns only exact matches or not. It tells what to return. Moved: Rob Hausam that we Change parameter from ‘mode’ to ‘exact’ as described. Update documentation. Seconded by Grahame GrieveVote: For 17, Against 0, Abstain 1Required – to be conformant. This means that to be conformant at least one code in this element SHALL be form the specified value set. We need to talk about what we are trying to achieve rather than the proscriptive description. Moved: Grahame Grieve, seconded Rob Hausam that - In the table for 4.1.4, change the text for required to: to be conformant, the concept in this element SHALL be from the specified value set. Also, update the text for the other binding strengths to be consistent. Add text to indicate that precise conformance criteria for these binding strengths varies by data type as described in the paragraph below.Vote: For 17, Against 0, Abstain 1Wednesday Q2 – Joint with MnM (Vocab Hosting)FacilitatorTed KleinNote taker(s)Heather GrainAttendeeNameAffiliationPOyvind AasseNorway Directorate of e-HealthPSheila AbnerPSusan BarberTN Dept HealthPWilfred BonneyPCarmela CoudercIMOPHeather GrainGlobal eHealth CollaborativePGreg GustafsonPenRadPRuss HammIMOPRob HausamHausam ConsultingPPeter JordonPDaniel KarlssonHL7 GermanyPTed KleinKlein ConsultingPRob McClureMD PartnersPCarol MacumberApelonPLloyd McKenziePBirtil ReppenPRon ShapiroPHarold SolbrigPAnnette VernonQuorum Requirements Met:? Yes 18 plus ChairTopic: Tooling IssuesCan the same as issue be interpreted in the RIM. Is it a tooling issue or a notional issue? There is an expectation around what must be produced in the future. What is the minimum level of specification required? This is currently early discussion and strategic considerations of the reality. HQ can’t manage publication of the V3 artefacts. The requirement elements in VSD and FHIR aren’t in MIF2.2 there has not been an update of the MIF and there is no appetite to add them to core MIF. They can be manually added but this won’t necessarily validate against the schema.A single common source of all content is needed and how can MIF content and V3 content be amalgamated. The terminology piece has not been discussed significantly in the strategic discussion as terminology is not as ‘bad’ as the modelling problems. There are two different stakeholders in V3 – national programs such as Canada and a few projects (primarily FDA). We have no current way of finding out who uses specific components of the standards and who would be impacted by change.In preparation to move to a single source of terminology truth we have been folding all the guidelines and processes into a single harmonisation process. V2 is covered and a process is in place for a single source of truth. For V3 and CDA (in part) is published in the core MIF – this has an established process but is not extensible nor is it maintained. We don’t know if it is robust enough to handle changes to the MIF schema. We suspect that it is not robust enough for this need. The next evolution is likely to be extensions to binding to persist that information will require changes in the binding model. We must decide what we need to do about the binding model for V3. We must deal with the syntax for persisted bindings. Current tooling will support updating and publishing the core MIF files but beyond March 2018 it is hard to know what and how we will proceed. There will be activity to define the minimum expectations and make sure that terminology and terminology maintenance and publishing is part of that. The need is to support tools that can publish in different formats.What would be involved in getting back to the proof of concept of taking code system and value set content from MIF content. What outliers in the V3 terminology model must be carried forward and maintained to support publication in a central terminology service? What would be the timeframe to specify these requirements? Lloyd will develop this progressively including the transform and extensions. It would be helpful to have this work done before the binding process discussion must occur. Within a year from now we need at least a prototype for a central terminology store which must be able to generate V3 content for publishing. Discussion with Publishing WG will occur in the next ic: Structured Documents – Code CoordinationDiscussions on translation and post-coordination have been occurring with Structured Documents for CDA R2.0. They are seeking how to do coordination for ICD10 but also for other terminology requirements. CDA have issues where there are multiple codes with a component of the statement you are making. Can they do translations which are ‘’closest match’’ rather than same as though same as is the attribute used. CCDA does not allow post coordination, but want to allow more than one code. FHIR can do this but how do we support CDA’s requirement. This functional use case is intended only to be used to make content more specific in the example, but rules were not considered around it so it could be less specific. Same As is used to mean best batch it does not mean same as. The data type guidance should make this clear and explicit. 1: SD want to change the meaning of translation to – these are multiple pieces of a component. Vocab said no to that option.2: This quarter had a new discussion of describing in CDA 2.1 or whatever comes next to define and potentially align to FHIR data types to meet the use ic: Binding SyntaxSee project work is not static. This discussion focused on semantics. The words used are consistent with the original meaning of these terms. The terms have been more clearly defined now and this may not be reflected in the terms on the wiki. This is the way we would like to talk about these words not how they are used. We don’t differentiate between a single code and multiple codes and value set binding. The project does not talk about direct reference binding (see TQM). Phrasing in the binding part of FHIR indicate restrictions based upon data elements but also based upon the binding. Intent is that we can use the phrases described here to represent constraints in the data type as well as the binding. We should b able to translate between what is currently being describe using FHIR and what vocab is doing. Lloyd asked whether there are things which need to change in FHIR to support binding? We anticipate that there will be some changes but it is not yet clear what those changes will be. The intent is to provide consistent guidance across products. The permutations of required specifications include outliers, but the common ones FHIR has. A map from FHIR representation of binding to this work would help discovery. There has been little FHIR input on this project and we are keen to see if we have missed a requirement or if FHIR has missed a requirement Vocab see as important. Link to presentation by Rob McClure on Binding Syntax you are using a coded data type which permits text instead of a code, then the binding may put a conformance constraint on top of the capability of the data type. i.e. If there is no code, you must use a flavour of null. The FHIR process has not yet gone through the conformance test process to any great degree it is hard to be sure whether these are best practice or how they are implemented. Binding strength in Vocabulary is not the same as binding strength in FHIR.Wednesday Q3 – Joint with Publishing (Publishing Hosting)Refer to Publishing minutes for notes on this sessionThe issue of single source terminology was explained to publishing. Publishing need to consider how to manage and render the new movement. V2 is now in a database. There is a need to make the terminology available in a computable format. Publishing should be aware that there are already problems occurring which require manual review and modifications. Luckily this has not generated significant problems as yet.Action: Jim to request meeting in Madrid same quarter.Action: Ted to contact MnM and FHIR regarding requirements for join meetings in Madrid.Wednesday Q4 – Structured Data Capture (SDC) UpdateFacilitatorJim CaseNote taker(s)Heather GrainAttendeeNameAffiliationPJenny BrushPJim CaseNLM / SNOMED InternationalPCarmela CoudercIMOPHeather GrainGlobal eHealth CollaborativePGreg GustafsonPenRadPAlexander HenketPMichael HolckPDaniel KarlssonHL7 GermanyPTed KleinKlein ConsultingPRob McClureMD PartnersPKathy PickeringPMelissa MendivilQuorum Requirements Met:?Yes 11 plus ChairThis is a US Realm specific activity. Presentation from Jenny Brush available at (1).pptxIt was suggested that this work should also reference ISO 13606. This work sets attributes about values but often uses FHIR resources as the source of data content.The discussion highlighted terminology issues in – for example: expansion jurisdiction. See url : Rob Mc log a tracker item against DST cod NO6 combination of code and code system is what is unique in an expansion set not the code.CAP have committed to implement the IHE version of this standard. There is funding to support it. It was noted that the terminology content was not of good quality.The question for vocabulary is – is it a good idea to have no recommendations on whether the same concept can be represented an undetermined number of ways in a value set. There should be a police statement on this.This is a specification has a maturity level of 0.Action: Jim asked Jenny to submit questions, comments or review related to their structured data capture and we will dedicate some time to that at the next face to face meeting. It is expected that this will take less than a full quarter. This may require time on the agenda -Jim Case to manage.Question duplicate concept representations of a single concept in a single value set. Conant logical definition permits this but it is not good practice – it is necessary in some rare cases. Vocabulary have discussed in the past that different code representations from different code systems in a single value set for the same thing is not best practice and needs a good reason to support this. It does not represent best practice. IN country codes you might have the UN set and the ISO set which can be combined – the logical content definitions should be used – instead it combines the numeric codes from UN and 2 digit codes from ISO. Thursday Q1 – Vocab (host)/CGIT/InMFacilitatorRob McClureNote taker(s)Jim Case and Heather GrainAttendeeNameAffiliationPSusan BarberTN Dept HealthPNathan BunkerAIRAPJim CaseNLM.PHeather GrainGeHCOPGreg GustafsonPenRadPDaniel KarlssonHL7 GermanyPRuss HammIMOPTony JulienMayo ClinicPTed KleinKlein ConsultingPRob McClureMD PartnersPGenny LuensmannCDC/NIOSHPRaj MehraCernerPFrank OemigHL7 DEPDave ShaverCorepointPRob SnelickNISTQuorum Requirements Met:?Yes 14 plus chairHow to publish normative vocabulary version in the non table structure?The version of the tables used in V2 as published with the standard. Discussions around removing that linkage were initiated. i.e. which version of the vocabulary tables should be used in implementations. Some usage notes in implementations specify different versions of the tables than are published with the standards.How do we publish the normative vocabulary version that must be used with a specific version of the standard?Frank raised another question: for v2.9, the vocabulary has been cleaned up and aligned. Now have generated a table view of the vocabulary. Looking to have a single view of vocabulary for all product families. For version v2+ how do we eliminate the use of tables? Should 2.9 be the last time we publish something called tables? What impact is this likely to have? If you have an implementation which references Tables there will be problems, but if the implementation is referencing value set structures from a data base perspective it should not cause a problem.Guidance given in 2.5 to use the latest version of the value set irrespective of the standard version you are using. Those who have not attempted to manage versions won’t have any difficulty but those who have inserted versioning information may have a problem. Good practice is that receiving systems should validate received values in all cases. If you are creating a new implementation guide what would the process be?Motion: Ted Klein moved that 2.9 release of version 2 will be the last release which publishes the tables focused vocabulary model for version 2 coded concepts. Post 2.9 release the version 2 vocabulary model will be migrated to the generic HL7 terminology model (which incorporates code system / value sets).Seconded Frank Oemig.Discussion:If we move to code systems and value sets we should go back and say for all prior versions of version 2 – this is the code system identifier for this code system and this is the version identifier associated with each table. Effectively providing a map to support migration.Vote: Against 0, Abstain 0, In Favour 14Implementation Guide IssuesHow do we communicate which version of the vocabulary should be used within an implementation guide? The question is asked – should people use the latest version and others are not. Those who are not changing need guidance. Heather G indicated that there is a requirement from HTA to use the latest version of any code system / value set specification. This requirement originated from licensing requirements of terminologies such as SNOMED CT but the principle should be applied consistently across all terminologies. If there is a need to retain an older version this need must be documented and validated. There is no discussion of the concept of pre-adoption of vocabulary. Starting in 2.7 deprecated elements of 2.x were removed and this impacted backward compatibility. If everyone has to update we are essentially telling all vendors that they are not conformant any more. The value is in conformance to a profile rather than a standard version. All receivers must be able to receive new or old message content without error. It was suggested that we have a policy from Vocabulary, InM and Conformance that indicates best practice for the use of version 2 coded content in implementation guides relative to versions. Policy could include guidance such as – if you need additional content to the values available in the release you are using – before you create your own additions – see if the content required is in an existing specification in a more recent published version.Motion: The Vocabulary, InM and Conformance develop a policy statement that indicates best practice for use of version 2 coded content in implementation guides relative to versioning. Moved Rob Snelick, seconded Ted KleinVote: Against 0, Abstain 0, For 14Action: Prepare a draft for discussion in Madrid – Rob Snelick, Ted Klein and Frank Oemig. Dave Shaver offered to reviewChanges to V2 – Rob McClure asked the group working on this to consider the FHIR approach to identification of code systems and value sets. This is a convenient time to make any changes which will assist us moving forward. The use of URIs was agreed to be very useful.ISO 11179 metadata registry - HL7 requirementsTed outlined the issue for the attendees. There are deficiencies in the functionality and specification of metadata registry requirements. TC215 Health Informatics – Semantic Content Work Group are working on this update. Issues required to support HL7 needs. Binding is a problem which is not currently addressed in 11179 and this has been added to the list of known issues.Vocabulary are seeking examples of issues and suggestions. When draft document is prepared at ISO that document will be circulated to InM, CGIT and Vocabulary. Set up a Liaison Wiki Page .Action: Jim to arrange joint meeting in Madrid Q1 Thursday CGIT, InM and Vocabulary. This will include 11179 discussion.TQA projectThe TQA project has been active for around 12 months. It is a very big project so has been broken into smaller components. The objective of the project was to have a representative from each product family member to identify issues and opportunities and solutions. As the project progressed there were specific problems which people had an interest and energy to solve. These include:Vocabulary facilitators have been updated and more clearly defined and education has been defined and some materials provided, others being updatedGlossary – universal terminology glossary projectGovernance of terminology content, including creating, maintaining, delivering terminology across the HL7 specifications. This is being led by Ted Klein and Lloyd MacKenzie. This project will develop a process that the TSC, Board and Executive committee will review with the hope of being a roadmap including GOM changes, tooling etc. Ted invited others to assist and contribute to this project. This will be discussed in detail in Madrid as it is urgent work. This process is intended to replace harmonization.Publication of terminology – improve the process of publishing a single unified terminology content. There is a TQA sub-activity about collecting how we do publish terminologies across product families.Project 630 – Binding Syntax conformance projectIt was agreed verbally from CGIT lead to Vocab Lead. This project is also overdue. This is about providing principles and guidelines to specify the syntax for vocabulary binding in implementation guides.Motion: Frank Oemig moved that project 630 be changed to Vocabulary Lead. Seconded Nathan Bunker. Vote: Against 0, Abstain 0, In Favour 14.Action: Frank Oemig to contact Dave to modify these details.Thursday Q2 Vocabulary (host)/ ConformanceFacilitatorTed KleinNote taker(s)Heather GrainAttendeeNameAffiliationPSusan BarberTN Dept HealthPJim CaseNLM.PCarmela CoudercPHugh GloverBllue WavePHeather GrainGeHCOPGreg GustafsonPenRadPDaniel KarlssonHL7 GermanyPRuss HammIMOPTed KleinKlein ConsultingPRob McClureMD PartnersPRaj MehraCernerPFrank OemigHL7 DEPJoel SchneiderNMDPPRob SnelickNISTPMead WalkerMWK.Quorum Requirements Met:?Yes 14 plus ChairBinding syntaxRob M. went through a background of the project and went through the wiki page ().Mentioned that there is a flavour regarding binding from all product families and aligns with core principles. This project attempts to make clear the concrete components to define the binding and you can change it but it is specified separately. Presentation provided can be found at: are two kinds of terminology binding. One that produces codes and is implemented (a value set binding), the other does not produce an implementable code set.Discussion:If we say that a code must be from this list. The sender believes it is right, but the receiver thinks it is wrong. The receiver lets the sender know that they think the data is wrong. There is a need to be able to differentiate whether this is an extension to the expected code set, a code unexpected by the receiver, or an actual error. If the code that is sent is a valid code it must be a code in the expansion set. There is also an issue that a code sent might be subsumed by a valid code in the list. Is it valid to send that code as an extension or should you send the code which subsumed it? The rationale behind this seems to be that some applications take a terminology and insist on code to leaf level, others you may pick any code and use the value set to do conformance checking. Are we trying to over specify things that are really application specific implementation issues? If you know that rules exist they can be provided and shared, but adding this to the machinery seems excessive. It was suggested that we should not peruse marking the CEA codes not in the expansion set as exceptions. If you designate the binding as CEA and you mark the code as an expansion – the meeting agreed that such functionality is not required. A guidance note in the conformance profile is sufficient.Action: Rob McClure remove exceptions methodology from CEAGuidance SectionIf you have a binding with a set of codes that are CEA the value set definition has an identifier and a version, that information along with the binding information specify an expansion set. When sending a code you say it is from this expansion, but the code is not in the value set as it is a CEA binding. People will receive concepts associated with a value set version that they may not be able to process or represent properly and this will still be conformant. Is that OK? Guidance must be provided on how this is to be processed and handled.Hugh Glover identified a case where the need to store semantic details beyond just the code – i.e. Case 1: just logging a code which only ever applies to that trial and only ever want to know what was stated at that time. Case 2: If however there is a need to aggregate data across time, or different clinical trials there is a need to be able to process semantically. If you have case 1 there is no need to worry about the detailed binding, in case 2 you must be able to process and retrieve binding and value set details. This issue may identify the case for min and max binding. How much information should be included in the guide to cover various use cases. Vocab are trying to create a mechanism that the computer always knows how to process and make clear what humans must do to support this. Conformance – there is an issue to make clear what is and is not allowed. The use of max makes it less clear about the use of subsets. The intent is that conformance has to test that the code received is within the max set which means it can be beyond the specified value set. Use case example: a reference laboratory receiving specimens for analysis from many different states. The value set for state codes is used. Can they use the value set for the patient addresses as people only send specimens from US laboratories? The answer is that people travel from other countries and may have other states. We don’t want to reject the message if the state is not a US state, a free text state from another country for example. It is suggested that:NEA Min = the states they deal withNEA Max = all US statesCEA is the other states that aren’t US states. – can you send text or a null value?Alternative only say CEA MAX – which is the US states but can be more. The idea is that if you have a max set and if it isn’t in that set it is an error – that is NEA Max. Do we need min and max? When people agree on a set of codes but there is also a tail of potential additional components the additional codes (max set) is a problem to handle. This is a practical problem. There is a practical use value set and a max value set – i.e. snomed subset for emergency attendance might be limited to 500 things but you can use any part of clinical findings. Which of the possible solutions has the lowest cost and greatest utility and flexibility? Suggestion of CEA max – where the top level extension is controlled and CEA Where the max – where there is a conformance requirement to all codes sent. can be anything at all – the receiver is not required to be conformant on expansion content.Where the system takes the MAX and says that’s my Min this would only be done to support conformance. The purpose of conformance testing is to catch errors. If you don’t care then send/receive anything without restriction. The communities being targeted include vendors and standards and conformance specification writers. Thursday Q3 – Vocab (host)/CIMIFacilitatorJim CaseNote taker(s)Heather GrainAttendeeNameAffiliationPSusan BarberTN Dept HealthPNathan BunkerPJim CaseNLM.PCarmela CoudercIMOPRachel EsmondPerRadPHeather GrainGeHCOPGreg GustafsonPenRadPSteve HufnagelPTed KleinKlein ConsultingPDaniel KarlssonHL7 GermanyPGert KoelewijnNICTI2PPatrick LangfordIntermountain HealthcarePJay LylePRob McClureMD PartnersPGalen MulrooneyVATeleconStan HuffTeleconSusan MatneyQuorum Requirements Met:?Yes 18 plus chairUse of SNOMED CT extension. Understand how artefacts published for ballot and free standards use would be done. How to integrate this activity into the overall publishing process. Creating models and related information would first be published as implementation guide information on the web site. IAny of those things that can be globally agreed would be balloted through FHIR and would end up ultimately on the HL7 FHIR website. The information models being produced should be able to map to FHIR profiles. The logical implementation models could be used in other implementation technologies. Where the terminology which is a part of this could be available through the FHIR resources to any implementation.CIMI will develop new content / modifications to content. Unless this content is US specific the request for content inclusion / modification should go directly to HTA and IHTSDO.CIMI work in alignment with HSBC (Healthcare Services Platform Consortium - a US specific initiative) – got a namespace and plan to send content requests directly to SNOMED CT. It is not clear whether the single contact point to SNOMED International is still a requirement or whether this need not go through HTA.Is there a dependence between the CIMI namespace and the HSBC namespace? Stan indicated that there is no interdependence. CIMI namespace is owned by HL7 and CIMI don’t want to use it Vocab or HTA could use it. All concepts required by HSBC for CIMI models will be made in the HSBC namespace. There is a relationship between HSBC and CIMI as HSBC will use CIMI for all its initiatives. If all CIMI content is in HSBC – how will tooling for publishing be supported. For publishing – we need to not only prepare documents for a ballot but publishing – availability of computable coded terminology content of the HL7 standards. There are very different requirements if the content I s not intended for the international release, just as when there are international requirements which d not meet the requirements for US use.In some cases, we just need to start and try to solve identified problems to see what works. In addition to the Solar instance CIMI would need a terminology server which can be used by publishing and model authoring (such as 3M HDT or Apelon DTS or something else). We need a terminology server where those concepts will be. They wish to support FHIR terminology services against that server. Regularly export from the Solar instance into the Terminology Server to make content available to FHIR. If there is a better place to put them they are happy to export to another publicly available resource.Stan also identified that publication will also occur through VSAC to make visible to people. Is the HSBC relying on US edition content? There is a significant need from the international community that content be in the international release of SNOMED CT if the actual resources are to be robust. There are already instances where FHIR has used national release content and international implementations have picked up those resources but not been able to access them in their national SNOMED CT releases.Where the name in FHIR and the name in CIMI and SNOMED CT are different – effectively synonyms dialect is being used to clarify this. We generally a difficulty getting vendors and implementers to engage with terminology effectively. Vocab know that this eventually causes problems which are too large and difficult to handle. We need to start to incorporate the easy parts of terminology as soon as possible. Consideration should be given to gated stops which ensure that e.g. before they get to the next maturity level all concepts from the US release must be in the international release.Ted asked – as models are being created some may be realm specific, some appropriate to the international release. Early on the model or terminology objects will need to identify the governance problems identified today – such as what release the content comes from, whether the intended use is realm specific. There is an active project on terminology governance across HL7, which will probably move to a federated terminology store initially at least. Eventually someone from the CIMI group to become part of that project to ensure that whatever they come up with is relevant to their processes and be as seamless as possible to users. Stan and others supported this approach. We need to keep communicating. We will meet again in Q3 Thursday in Madrid.Thursday Q4 – Planning and GlossaryFacilitatorTed KleinNote taker(s)Heather GrainAttendeeNameAffiliationPSusan BarberTN Dept HealthPJim CaseNLM.PHeather GrainGeHCOPRob HausamPTed KleinKlein ConsultingPRob McClureMD PartnersQuorum Requirements Met:?Yes 4 with chairJoint Meeting requests Jim reported: Note: There is no Q1 on MondayStructured docs Q2 TuesdayFHIR Q3 TuesFhir Q1 WedMnM Q2 WedInM and Conformance Q1 ThursdayConformance Q2 ThursdayConformance and CIMI Q3 ThursdayAccepted joint with Publishing Q3 WednesdayAll rooms reserved and done.Responsibilities – see Ted’s colourful document. A regular review of which co chairs will be able to attend Conference CallsCallDay scheduleTimeVocab GeneralThursday fortnightly starting Feb 2nd3:30 USA Eastern Time for 90 minutes.TQA callsAd hoc calls when requiredDue May 2019Binding SemanticsTuesday fortnightly beginning 31st January2pm – 3pmValue set expansionTuesday fortnightly beginning 24th Jan2pm – 3pmUnified terminology governance project Thursday fortnightly starting Jan 26th3:30 USA Eastern Time for 90 minutes.ToolingTuesday fortnightly starting on 31st of January1pm – 2pmTermInfoSchedule to be established after initial call.Initial call 9am USA Eastern on Wednesday 25th January Action: Projects to be updated in project insite as completed 1056 and 1146 – TedAction: 948 follow up with Melva to have the facilitator training project completed – Heather – done.Action 1169 – check with leading WG and update status – Heather.Action 1170 vocabular registry – covered by other projects now in play - HeatherGlossaryHeather explained the process being undertaken to review the glossary. The meeting reviewed the process and definitions for attribute and cardinality. The spreadsheet has been updated and will be loaded to the wiki. The future process will be the provision of a single term for discussion and resolution on each call. When / if resolution achieved that term / definition will be updated in the SKMT and added to the HL7 Vocabulary Glossary.Note: see to use the tools.Meeting Adjourned 5pm. ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- business review agenda sample
- powerpoint agenda template
- entry level public health jobs
- purpose of strategic planning in health care
- health care strategic planning process
- strategic planning models for health care
- management review agenda examples
- introduction meeting agenda sample
- printable weekly agenda 2020
- agenda for introductory business meeting
- free agenda templates in word
- free meeting agenda templates printable