20:00 UTC on Tuesday 10 September 2019 - 90 minutes.
- FHIR Terminology Services and Resources
|Notes & Actions
|Welcome and introductions
Recording, notes & attendance.
|Summary of previous week and previous fortnight
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.
HL7 Atlanta Connectathon 14 + 15 September goals: shakedown of specification, client and server software. Specific focus on SNOMED CT.
Question on identifying just GPS concepts for use in FHIR Terminology Servers
Problem is with implementations in an international setting using eg IPS "safely" ie without infringing license issues, so a new code system is required. What version string should be used in this case? ML asks if these concepts could sit in a different module?
GPS (a grouping of other free sets) is being published next week (Monday). It doesn't exist as a reference set. Format is going to be non-RF2, a zipped tsv file. This most obviously lends itself to being implemented as one or more ValueSets in a FHIR Terminology Service.
ML: "This would need a code system sitting behind that valueset, but if you don't have a licence, that's not acceptable. So a new version is required to form a 'GPS CodeSystem'". RH suggested working with a CodeSystem fragment but we'd need to be able to identify it.
Possible option to issue a notional module id which only existed to identify this CodeSystem. Since the TSV file is not RF2, this would not appear anywhere else.
Or, could use the URL at which the GPS is published in order to reference it.
The "ValueSet only" approach can be used immediately. Do we need to go further with this? Could wait to receive feedback once GPS has been published. Group agreed this would be our approach.
ML: This will be an issue for Snowstorm. PWI: We'd assumed it would be used by SNOMED licence holders.
ML: Also do we need to specify the URI for the subsets within the GPS. Rory Davidson indicated that the various constituent parts are (or will) be available as refsets, so the valuesets can be expanded based on the refsetId.
Update 10 September 2019
Discussion that describing the GPS as an intensional refset would be attractive, but not all the constituent refsets have their concepts visible in the core module. Under the hood there is (sort of) a notional refset and a concept does apparently exist for that: 787778008 |Global Patient Set (foundation metadata concept)|
Does an update to the IPS have an immediate licensing effect such that non-licensee holders could use them?
Question on how often (and when exactly) the GPS would be updated. Can we confirm that concepts will never be removed, only inactivated? Is the GPS concept included in the GPS set? Andrew Atkinson ?
ML: The inability to version the code system when talking about code system fragments is a limiting factor here.
|Behaviour on expansion regarding which description type to return.
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)
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 -
|SNOMED FHIR Implementation Guide
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.
|Mechanism 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.
Any other business
Next meeting 24 Sept