2019-07-02 - SNOMED on FHIR Meeting (TS)
Date
20:00 UTC on Tuesday 2 July 2019 - 90 minutes.
Objectives
FHIR Terminology Services and Resources
Meeting Details
Online: https://snomed.zoom.us/my/snomedhl7
Phone: See https://zoom.us/zoomconference for available phone numbers (meeting id 242-348-6949)
Chat: public-snomedintl.slack.com # snomed-hl7-fhir (ask for invite!)
Attendees
@michael lawley,@Peter Jordan,@Rob Hausam, @Peter Williams, @Jane Millar, @Jon Zammit, @Reuben Daniels, @Former user (Deleted)
Apologies
Meeting Recording
https://snomed.zoom.us/recording/share/Or9eqyWl58nt1hUIJZEkrnyjuzNsMaaBUllZjft7QtKwIumekTziMw
Discussion items
Description | Mins | Owner | Notes & Actions | |
---|---|---|---|---|
1 | Welcome and introductions | 2 | @Peter Williams @Rob Hausam | Recording, notes & attendance.
|
2 | Summary of previous week and previous fortnight | 10 | @Peter Williams @Rob Hausam | Note Daniel away for 3 weeks after the 11th so keen to have meeting despite overlap with FHIR Dev Days (FYI @Jeremy Rogers) Discuss option for summer break. @Peter Williams away 30 July, back for 27 August. SNOMED International retreat 23 July |
3 | Other Meetings | 10 | @Peter Williams | SNOMED Expo Oct 31 - Nov 1 Kuala Lumpur Thursday half hour session. Title of session: "SNOMED on FHIR" Content: Profiles (eg Allergy Intolerance), Free Set, Implementation Guide, discussing and sharing. Sunday morning for HL7 Vocab "alignment" session. @Peter Williams Look for space for additional face to face meeting with HL7 Vocab members. |
4 | Publication of FHIR Free Set |
| @Jane Millar | Green - Grahame to provide feedback for next week. Update 2 July feedback was received, Grahame has asked us to look again at 3 ValueSets of interest to patient safety. Amber - documents going to Patient Care Group. @Peter Williams Capture Jim's feedback on Red items from meeting recording. Update 23 April: Terminology Binding group moving on to remaining Valuesets. Update 18 June: JC Parts of finding hierarchy contain context that can put us at odds with a hierarchy that FHIR might want, and this context (ML) may not be visible in the FSN. @Peter Williams @Jane Millar discuss arranging wider call with other members of Vocab for some TB week when Daniel is back (August?) - after framing of issue and specific goals for this. Update 2 July JM: Will be maintained in the Refset tool and made available to HL7. As with all derivatives, will be released once per year unless required otherwise. @Peter Williams restrict free set discussion to TB calls. |
5 | New Topic Expand operations parameters | 15 | @Peter Williams | Has anyone implemented "Context" ? Yes, ML. http://hl7.org/implement/standards/fhir/valueset-operation-expand.html |
6 | New Topic | 5 | @Reuben Daniels | Proposed changes to ConceptMap resource: Issue when there is equivalence between source and target. See tracker item: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=22632 7 Changes proposed to ConceptMap. Group.element.target.equivalence is going to change to "relationship" and the type of the relationship stated - new Valueset conceptMapRelationship (previous VS retired). Relationships enumeration will be: relatedTo, Equiv, Broader, Narrower, Not Related ML - this has implications for $closure (which returns a concept map which uses other values eg subsumes). RD: "Unmapped" is to be used by default when there is no target. Tracker to give advice on how to work in this resource with FHIR extensions. Update 2 July - RH Changes not applied yet. ML Impact on $closure will need to be removed (those values are removed in this proposal). |
7 | New Topic | 10 | @Rob Hausam | Clarification needed of the reverse flag in ConceptMap $translate Returning concepts from the "source" valueset where the code supplied is a member of the "target" valueset. Ontoserver (for example) will treat the "source" valueset as the target when no target is supplied. @Rob Hausam Vocab meeting this Thursday, will mention that further clarity is required here on what is expected in the source and target parameters when the reverse flag is present. Update 2 July: Vocab group have a proposal for improvement changes for 'code' input parameter: If 'reverse'= 'false': The code that is to be translated. If 'reverse'= 'true': The code that is translated to. If a code is provided, a system must be provided changes for 'reverse' input parameter: If 'reverse' = 'false': The operation returns all of the codes that have mappings from the code that is specified in the 'code' input parameter If 'reverse' = 'true': The operation returns all of the codes that have mappings to the code that is specified in the 'code' input parameter. changes for 'source' input parameter: Change the first sentence to "Identifies the value set that contains the concept(s) to be translated. @Reuben Daniels to provide some examples for next time. @Peter Williams also. Forward translate source = SCT, code = 1234500, Target = ICD-10 we're returning ICD-10 codes eg (ABC-1) Reverse source = SCT, code = ACB-1 ,Target = ICD-10 but we're returning SCT codes |
8 | New Topic | 10 | N/A | Follow up discussion on finding all refsets that a particular concept is a member of (relates to both $expand $lookup and ECL) eg ^( << simple refsets). Simple refsets and simple map would check the referencedComponentId, but there may also be a case to find references to other fields. PWI spoke to Linda who is interested to know the use cases. ML says it's a proxy for the importance of the concept ie is it in wide use. Can also give a sense of where it is used, and by whom. PJ has suggested (as an alternative to enhancing ECL for this) that a standard property (ie a well known) for a SNOMED code could include a list of all reference sets which include this concept. Note that language reference sets are not a good example because they reference description ids (double indirection). |
9 | Non-defining relationships (ie additional characteristic type eg Part Of, now inactive) | 5 | @Peter Williams | Should non-defining relationship show up as properties in a lookup. The question of whether or not ECL will consider these is delegated to the choice of substrate, but the default substrate does not (?) specify if they are or not. @Peter Williams Take this forward. Update: Snowstorm now includes as per https://github.com/IHTSDO/snowstorm/issues/8 |
10 | SNOMED FHIR Implementation Guide | 60 | @Peter Williams | **************** ALL Pitch in to Implementation Guide for using SNOMED CT with FHIR ******************* Progressing the SNOMED Implementation Guide and specific guidance of "Best Practice" of using SNOMED with FHIR. Can we include tests for 'correctness' - using existing FHIR Testing platforms? https://github.com/IHTSDO/snomed-ig with the built view hosted by GitHub at https://ihtsdo.github.io/snomed-ig/ Tooling: Current tooling appears to be solely command line based. See also Snapper for value set editing (currently STU3). @Peter Williams reference hosted build in Readme. What is the scope of content for the guide? Targeting "Best Practice" for FHIR Implementers using SNOMED CT. Possible layered approach and potentially strict (for internal record keeping and communication) vs permissive profiles when . General guidance for bindings or specific details on each resource. Audiences - Developer vs User of implemented services. ML Suggests single entry point document with multiple paths through the documentation. 8 January 2019 Update: Tooling: Forge (doesn't support R4) @Peter Williams install Simplifier @Rob Hausam suggest road map for where our focus should be. Pull in CodeSystem Resource page? What do we want to say about how SNOMED should be used in FHIR? Eg On the Terminology Services side, start with a narrative and head towards a test script where a particular query is expected (formally) to return a given set of results. Then on the resource side, talking about what particular value sets should be used for specific resources - condition code being a high value. Will we insist that these are SNOMED code or could they be proxy codes eg where a medication is given on a problem list and - in it's presence - indicates the underlying condition but without specifying that explicitly. Start with a Confluence page for collaborative work and once that's reached some stage of maturity it can be moved into the GitHub repository in a more structured form. Are we looking at one implementation guide or two? Terminology Server vs Terminology Binding and Profiles. @Peter Williams @Rob Hausam to bring SI's IG into line with current tooling expectations. |
11 | Mechanism for working with Languages. | 15 | @Reuben Daniels | Mechanisms for working with Languages @michael lawley has raised ticket about the "use" field being limited to FSN/Synonym. Elsewhere in FHIR there is a "display" code that can be used to indicate other languages See 22490. Also 19960 - additional term for "Consumer Terms" ready for implementation R5 (Q4 2020 at the earliest). 18 June PWI gave some notes from pop-up session at FHIR Dev Days - more about locale than language. ML: "Translation" extension doesn't allow for a particular piece of text being in a different language from that of the resource. |
12 | Ongoing items | 10 | @Peter Jordan @michael lawley |
On Hold / Maintenance |
13 | Any other business |
|
| Next meeting 16 July |
Meeting Files
Copyright © 2025, SNOMED International