20:00 UTC on Tuesday 12 November 2019 - 90 minutes.
- FHIR Terminology Services and Resources
|Owner||Notes & Actions|
|1||Welcome and introductions||2|
Recording, notes & attendance.
|2||Summary of previous week and previous fortnight||10|
Upcoming events: FHIR Dev Days Nov 20 - 22 2019 Amsterdam
2 - 3 Feb 2020 HL7 Sydney
Priorities for Events: Working with languages, hosting the GPS legally, ConceptMap$translate (new relationship types)
|4||ECL with compose element||10|
Question of use of ECL within compose.include see http://hl7.org/fhir/snomedct.html#126.96.36.199.8.3
See tracker on the intersection or union when working with multiple valueset elements inside the compose.include element (suggestion is that it should be intersection because union could be achieved using multiple include elements).
|5||Concept Map - Mapping Relationship||5|
Concept Map - mapping is made from source to target but the relationship is interpreted from target to source eg "broader" is to say that target is less specific than the source. Is this reversal causing confusing
Feeling of the group was that the existing implementation (ie "mapping relationship is about the target") is the more intuitive and we just need to highlighted that sooner rather than later (the specification is already considered to be clear on this topic). Note that the mapping relationship is a sub property of the match element itself ie the target.
SNOMED CT has similar functionality in Complex Maps with the correlationId field which takes << 447247004 |SNOMED CT source code to target map code correlation value (foundation metadata concept)|
DK Thought that the terms used here come from the linguistics domain which may explain some of the trouble here.
RH Adds from SKOS: Note on skos:broader direction: for historic reasons, the name of the skos:broader property (the word "broader") does not provide an explicit indication of its direction. The word "broader" should read here as "has broader concept"; the subject of a skos:broader statement is the more specific concept involved in the assertion and its object is the more generic one.
Tracker on this: #16364
Update 12 Nov: RH "The relationship itself should make the relationship direction explicit so 'broader-target' rather than just 'broader'". Group suggested going further eg 'has-broader-target' this could be done in the display text rather than the code itself. This more explicit set of values maintains the existing relationship direction (target → 'relationship type' → source)
|6||Behaviour on expansion regarding which description type to return.||20||Peter Jordan|
Terms that are returned when requesting implicit valuesets.
ML: Intention is that this list would be used to populate a resource and so the PT is appropriate "The best display is the preferred". DisplayLanguage parameter should be used for the client to specify what they want - how would we use that for FSN vs PT vs Other (eg Patient Friendly Terms)?
Designation parameter should be used to recover the FSN (pulls from Designation Use ValueSet)
Group's current interpretations is that includeDesignations=true (with no other designations specified) would return all designations whereas specifying the specific designations is a request to return those specific designations.
Note for Vocab group that although 900000000000548007 |Preferred (foundation metadata concept)| exists, we do not ( ?) have a concept to represent patient friendly terms.
Note issue with licence restrictions in ValueSet. Tracker needed to remove text -
|7||SNOMED FHIR Implementation Guide||60|
Rob Hausam Please add documentation on running updated tooling.
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?
Tooling: Current tooling appears to be solely command line based. See also Snapper for value set editing (currently STU3).
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)
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.
|8||Mechanism for working with Languages.||15||Reuben Daniels|
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.
Peter Jordan's implementation can take a refset Id (which is more flexible for dealing with same-language designations such as dialect and patient friendly terms ```includeDesignation = SYSTEM+<SCTID>```
Problem: We can't tell the difference between Preferred and Acceptable. Currently the best we can hope for is to use array ordering.
Update Nov 12 Recommended option for specifying a language refset:
This is based on the definition of the designation parameter: "A token that specifies a system+code that is either a use or a language. Designations that match by language or use are included in the expansion. If no designation is specified, it is at the server discretion which designations to return" A token is specified as <system> | <code>
In terms of the designations returned from, say, lookup, the group felt that it was reasonable to suggest that any given designation could have more than one use, and we would like to say something about its language reference set entry as part of some additional "use" element.
Example of current implementation:
Question outstanding: if an acceptable designation is not available in the specified language reference set, would we want to return the fall back (default) language refset instead? In that case we would absolutely need to be able to indicate in which language reference set the term is acceptable/preferred.
Also, can we specify in the request that we are only interested in preferred terms, rather than - current implementation - both acceptable and preferred.
Also, the filter currently works at the level of the concept and the specified language. Could we filter in a way that was specific to the designation use?
Thinking aloud, shoe-horning everything into one block and using a draft URI proposal:
display: "Synonym+GB Language+Preferred"}
Any other business
Next meeting 26 Nov (note skipping a week so TS / TB meetings will change week)
Potential Items for Discussion
|Description||Owner||Notes & Actions|
|API for FHIR Resource ↔ Post coordinated expression mapping|
|Looking up an SCTID in an unknown module|
Problems when dependencies do not align. Multiple code system resources represent multiple editions / versions.
ML: See code parameter to code system search. Should return code systems (ie versions) where that code is defined. International concepts would appear in every edition known to the server.
|GPS||See Discussion on Global Patient Set (GPS)|