Peter G. Williams

Rob Hausam

Recording, notes & attendance.

Peter G. Williams

Rob Hausam

• 2019-10-01 - SNOMED on FHIR Meeting (TB)
• 2019-09-24 - SNOMED on FHIR Meeting (TS)

Peter G. 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.

Closed TB Small working group arranged for the Sunday AM to address proposed solution for FHIR Free Set mapping issues.

Michael Lawley, Daniel Karlsson and Rob Hausam have been entered for a "SNOMED on FHIR" presentation for the Thursday. Topics included to be: Free Set, Implementation Guide and Profiles.

• Jane Millar Deadline of 14 October to upload FHIR presentation for Expo
  
• Peter G. Williams Setup Presentation template (Google Slides) and email out.
  

Update 8 Oct: DK suggested 10 minutes per participant.

NHS FHIR Connectathon Cardiff - Wed 2 & 3 October. 140 participants.

Expecting to skip call on 29 October due to KL Business Meeting. Calls as normal until then. Schedule will skip one week so TS/TB will need to swap. Also watching out for Day Light Savings changes. Time of meeting UTC will remain unchanged.

Upcoming events: Nov 20 - 22 2019 Amsterdam

2 - 3 Feb 2020 Sydney

Priorities for Events: Working with languages, hosting the GPS legally, ConceptMap$translate (new relationship types)

Peter G. Williams

Binding patterns

Problem with information fields that indicate negation, severity, etc.

Group requested an example use case - input and output expectations. DK: CIMI have looked at this previously, resource needs to be constrained in a detailed way to allow such a mapping to be safely performed ie restrict resource only to those things that can be expressed in the SNOMED concept model.

ML thought the API would be fairly dumb and populate template (passed in) slots from values appearing in a resource ie no interpretation of semantics.

Bindings (using some path specific to the implementation model) were suggested in the languages group, distinct from the slot names. Use case query - would it instead be possible to work directly with the information model.

• Daniel Karlsson Thought there might be some documentation from CIMI on this. Also notes from DMarkwell about constructor bindings.
• Peter G. Williams Pull these notes into confluence - can we mention it in the IG?

Peter G. Williams

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.

eg /CodeSystem?system=htp://snomed.info/sct&code=12345678&_elements=version

• Peter G. Williams Ticket implementing this lookup. Note that this could be implemented more generally for lookups of http://snomed.info/id/<SCTID> where the SCTID exists in an extension. Done - see STORM-262.

See Discussion on Global Patient Set (GPS)

Terms that are returned when requesting implicit valuesets. Snowstorm returns FSN, Ontoserver returns Preferred Terms.

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)

• Rob Hausam add to agenda for discussion (Designation Use ValueSet) in Atlanta (Sept)
• Peter G. Williams rework Snowstorm to return PT by default and FSN as additional designation when designation parameter is present

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 -

• Reuben Daniels to raise tracker to note that FSN and Preferred Term concepts are now part of the GPS therefore licence restrictions no longer apply.
• Jane Millar to note that additions to this ValueSet would require adding << 900000000000511003 |Acceptability (foundation metadata concept)|
  
• Peter G. Williams add to agenda for KL. Is this really needed? Do we just need to specify a table in the IG of what parameter to specify and what to expect back in each case.
  

Peter G. Williams

****************

• ALL Pitch in to Implementation Guide for using SNOMED CT with FHIR

*******************

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?

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 G. 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 G. 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 G. Williams Rob Hausam to bring SI's IG into line with current tooling expectations.
• Rob Hausam please help with telling IG tooling to render the entire StructureDefinition from the base resource not just the delta fields as we see here. DL says the resource made more changes than this.
  
  
  

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.

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?

Next meeting 22 Oct.