Page tree


20:00 UTC on Tuesday 26 November 2019 - 90 minutes.   


  • FHIR Terminology Services and Resources

Meeting Details


Phone: See for available phone numbers (meeting id 242-348-6949) # snomed-hl7-fhir (ask for invite!)

Discussion items



OwnerNotes & Actions
1Welcome and introductions2

Recording, notes & attendance.

2Summary of previous week and previous fortnight10
3Other Meetings10

FHIR Dev Days Nov 20 - 22 2019 Amsterdam

Digital Health Week New Zealand (including HINZS and Snomed & FHIR workshop)

Upcoming events: 2 - 3 Feb 2020 HL7 Sydney

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

FHIR DevDays - June 16-18, 2020 Cleveland, OH

SNOMED on FHIR Christmas Break: Skip 24 + 31 Dec

4Versioning of ValueSets10

Use of ValueSet versioning in relation to SNOMED CT modules / versions

When authoring ValueSets, do not tie them to a particular version of the terminology (or risk a maintenance nightmare)$expand?system-version=|

SNOMED allows the membership of a set to be made inactive (the concept is considered to be no longer part of the set at this point), independently of the active state of the concept itself. In FHIR elements are deleted entirely when they are no longer part of the ValueSet - a previous version would need to be consulted.

5Filtering VS expansion based on ECL10

No, you can't mix ECL and named ValueSets at expansion time.

But if a ValueSet was based on a ReferenceSet then an implicit ValueSet could be constructed which was the intersection between the members of the reference set and some other ECL.

6Concept Map - Mapping Relationship5

See ConceptMap

Update 26 Nov: HL7 close to concluding change. Codes that have a meaning change will have value changed to make the direction clearer. PJ: Will any changes be included in the reference libraries in time for the Sydney meeting?

7Licence conditions of GPS
Daniel Karlsson

Are translations of GPS available? SR: No, see

Point made that SI have rights to use extension content as they see fit.

8Behaviour on expansion regarding which description type to return.20Peter Jordan

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. See 22856.
  • Jane Millar to note that additions to this ValueSet would require adding << 900000000000511003 |Acceptability (foundation metadata concept)| to the FHIR Free Set
  • 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 move this item to IG pages.

9SNOMED FHIR Implementation Guide60



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? with the built view hosted by GitHub at

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.

  • 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.

10Mechanism for working with Languages.15Reuben 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.

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:$expand?identifier=|281000210109

This is based on the definition of the designation parameter: "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:

{name: "designation",
part: [ {name: "language", valueCode: "en"},
{name: "use", valueCoding: {
  system: "",
  code: "900000000000013009",
  display: "Synonym"}},
{name: "value", valueString: "Obstetric umbilical artery Doppler" }] }

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:

valueCoding: {

system: "", //No need to specify because a PCE is still a SNOMED code.

code: "900000000000013009+900000000000508004+900000000000548007",

display: "Synonym+GB Language+Preferred"}

Update 26 November: The semantics of this post coordinated expression are problematic. Is a SNOMED specific extension the way to go here? Firstly by working out the most useful value for "use" and then add further detail into the extension. Is 'Patient Friendly' part of the R5 specification yet?

Use case - querying for terms in a particular language reference set. When not all of the terms are part of that language reference set (eg no patient friendly term exists) we want to indicate which ones are patient friendly and which ones are not. OR should we return nothing when no acceptable/preferred description is available and allow the client to make a follow-up call requesting the "fall back position" language reference set - like US English. This behaviour would reduce the need for an extension. Would we return the concept without a designation in that case - so the client could detect that there is more information to be obtained.

We still have no way to differentiate between preferred terms and merely "acceptable".

Some indicator of "Not Acceptable" would allow us to indicate non-membership of the specified language reference-set.

$lookup is more problematic as a number of designations are returned and no indication is given for their context of use. Perhaps a stronger use case for the need for an extension.


Any other business

Next meeting 10 December.

Potential Items for Discussion

DescriptionOwnerNotes & Actions
API for FHIR Resource ↔ Post coordinated expression mapping

API for FHIR Resource to SNOMED Expression

  • 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?
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.

eg /CodeSystem?system=htp://

See Discussion on Global Patient Set (GPS)

Meeting Files

No files shared here yet.