Page tree


20:00 UTC on Tuesday 15 May 2018 - 90 minutes.


  • FHIR Terminology Services and Resources

Discussion items



OwnerNotes & Actions
1Welcome and introductions5

Recording + Notes.

Note that this meeting will clash with the HL7 meeting in Cologne and the timings will not line up to allow a joint call. We agreed to proceed as planned, with expected reduced numbers.

2Summary of previous week5
3Update from HL7 Discussions - Cologne20

JM: HL7 suggestion that some ValueSets be required as an aid to interoperability (in Normative Ballot). However, these ValueSets would need to be "Free and freely accessible" and therefore unable to use SNOMED as part of that particular specification. LOINC most obvious alternative. SNOMED could still be used in this situation, but this would require mapping since the LOINC codes would still be required.

RH: This would relate to "code" elements which always have required bindings ie FHIR ValueSets already exist for those. FHIR not intending to specify any SNOMED Codes with binding strength further than "example" since SNOMED is not freely available.

  • Peter G. Williams link to fair use policy when receiving data in a non-member country.

Vocab Group: Terminfo as distinct from SNOMED on FHIR. RH: 2015 Draft standard for trial use has now expired. Use of SNOMED in CDA, question whether specification can be "kept alive". HL7 would need to set up a new project in order to formally collaborate with SNOMED on FHIR (answers in next two weeks (Thursday)).

4Main item for discussion60SNOMED CT canonical CodeSystem resource
  • Review and attempt to resolve detail questions
  • Issue around extensions and what this CodeSystem resource actually represents
5Current items10
  • SNOMED CT "Universal" Edition
    • Definitely useful to have a catalogue of all concepts ever issued if not a proper edition which may be much harder?
    • Is this work for this group, or should this be handed on to a more appropriate SI group?
  • Check and fix ECL in the FHIR spec
    • Is there a way to systematically identify all ECL expressions in the FHIR spec?
    • If we run these through validation is there appetite/volunteers to review and fix them as feedback to the spec?
    • Is there a way to integrate ECL validation into the FHIR spec tooling to prevent recurrence?
  • Rob Hausam to progress Michael's tracker item on this issue.
  • Normal form and normal form terse definition
  • Rob Hausam to progress returning NormalFormTerse to the page.
  • Linda Bird to progress defining Terse Normal Form with the Family of Languages group (Rob Hausam confirms needed for July)
    • SLPG agreed that the Languages group is not the appropriate forum for this definition. Instead, we believe this should be defined in the DL subgroup of the Modelling Advisory Group.
    • Also agreed that the terms that need defining are "Canonical Normal Form" (which is terse by definition) and "Necessary Long Normal Form"

Review of "Using SNOMED with FHIR" page


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

  • Section suggestion that we terse Normal Form properties (Peter J disagreed). 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
  • Supplements are a possible way to allow language reference set type functionality.
7Review of TS Collaborative Work5Collaborative Work
8Any other business0
9Next Meeting

Tuesday 29 May

Peter G. Williams will be away.


Meeting Files

No files shared here yet.

1 Comment

  1. Item 3: Note that FHIR representative in this discussion seemed amenable to relaxing "code" datatype to "codeableConcept" to support use of additional terminologies, beyond FHIR-defined terms. Representative disagreed with stakeholders who expressed a desire to relax binding strength for these FHIR terms (beyond required or even extensible, to preferred), to support use of such additional terminologies without a requirement to also map to FHIR terminology.