Page tree


20:00 UTC on Tuesday 8 January 2019 - 90 minutes.   


  • FHIR Terminology Services and Resources

Discussion items



OwnerNotes & Actions
1Welcome and introductions5

Recording, notes & attendance.

Note skipping of 15 January throws subsequent meetings out by a week.

2Summary of previous week and previous fortnight5
3Other Meetings10ALL
  • San Antonio HL7 Connectathon (Sat Sun) & Working Group January 13 2019
    • R4 Compliance? Dialects eg Patient Friendly Terms
  • Option for a SNOMED on FHIR session on Sunday April 7 at the Business Meeting in London
    • Attend via conference call / attend in person / will be there anyway
    • Best use of our time for getting work done, face to face:
      • UK + US present so could be used as information sharing rather than working.
4Publication of FHIR Free Set20

Free SNOMED CT set for FHIR

  • Rob Hausam reach out to Jay and Keith at the VA to elicit use cases / requirements - any update?

Considering question of 'who publishes what', RH thought SI should publish a refset as the authoritative source which HL7 could then use to derive FHIR friendly forms eg Concept Map.

Question for GG: What is the use case for the mapping? This gives context to the question of how (and by whom) the map is maintained.

Agreement being drafted this week for both FHIR and IPS Free Sets (but can be de-coupled if required).

5Completed Tasks5
6SNOMED FHIR Implementation Guide10

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.

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

7DL Enhancements on PCEs10

How can we represent the definition of a concept as a Post Coordinated Expression given that NNF may not fully express the stated form.

MAG work item: DL Enhancements impact on Post Coordinated Expressions

Zulip enquiry has not yet suggested anyone using the returned expressions for anything more involved than straight forward display - although there's no way to be sure.

FHIR property lookup does allow for role grouping by using nested properties (candidate topic for implementation guide! PJ)

Languages group next meeting could be into the new year. MAG meeting 3rd week in January 2019.


Revisit Using SNOMED CT with FHIR

All participants are invited to review this local copy of that page.

  • Section Clarity needed on which Normal Form is being represented (eg breaking sufficiently defined concepts down to their primitive components, unlike what is supplied in the browser). Further discussion needed on what these properties are being used for. Perhaps only 1 is necessary since terms can be added/removed as required. Update 28 Aug: A link to the definition of NNF is desirable (MAG - define what this should be for PCEs?)
  • Supplements are a possible way to allow language reference set type functionality.

Update October 9

  • Peter G. Williams move into Maintenance section. Further discussion could be cross pollinated with the implementation guide. Outstanding question about the guidance on NNF? SnoChillies server does return this value, for example.
  • Michael Lawley raise tracker item for the removal of this section (link here).
  • Rob Hausam to progress.
9Ongoing items10
  • SNOMED CT Canonical CodeSystem resource
    • Outstanding question of whether this is the Canonical CodeSystem for the International Edition, or some base set of properties for all Editions.
    • How is this distinct from the Terminology Capabilities Resource?
    • Review and attempt to resolve detail questions
    • Update 28 Aug: Official endpoint should be hosted somewhere (SI?)
    • Update 13 Nov: (ML) We should publish as part of the IG - possibly two - a) International and b) a template as guidance for implementers. In the event of a choice of versions, suggest the default is to return the most recent available.
10Mechanism for working with Languages.15Reuben Daniels

HL7 Vocab Item:

ML: Supplement would hopefully only add additional descriptions that are not described in the base content.

Precedence (fallback) for multiple language reference sets only really discussed in Languages Group for ECL - other use cases not yet brought to light.

Update 28 Aug: Keen to see an implementation using Supplements to see how it would actually work. Option to explore this at Baltimore Connectathon?

Update 11 September: Do we need a parameter for the expand operation for this - Reuben looking into this currently.

Update 11 Dec: HTTP Headers RFC 5646 (Tags for identifying languages). Suggestion that where dialects are to be referenced which do no have a standard code, one could be constructed, either using new letters or the language reference set id directly eg en-nz-x-12345601 Note also that requested language/dialect could be an ordered list for gradual fallback where descriptions may or may not be available.

Can also be passed in the language parameter passed to an expansion operation.

Language reference set could be an implicit code system supplement.

Update 8 Jan: Note that SNOMED CT Language Reference sets do not indicate if they relate to a dialect, language or context of use. GG suggested FHIR could address that more directly than using a reference set SCTID to supply that desired context. Include someone in a non-English speaking country!


Any other business

Next Meeting: Tuesday 29 January 2019

  • Update from HL7 Connectathon

Meeting Files

No files shared here yet.