Welcome and introductions

2

@Peter Williams

@Rob Hausam

Recording, notes & attendance.

Check questions in Zulip and SNOMED International #snomed-hl7-fhir

Next Time: Common Terminology Model (eg reconciling SNOMED / ICD / LOINC )?   

Also FHIR / OpenEHR collaboration (see Zulip discussion, particularly FHIR Questionnaires). Main work in reconciling lower level data types.   See https://chat.fhir.org/#narrow/channel/179174-openehr/topic/Transforming.20archetypes.20to.20Questionnaire.20and.20Logical.20models

Previous Meetings

2

@Peter Williams

@Rob Hausam

• 2025-09-30 - SNOMED on FHIR Meeting

• 2025-09-24 - SNOMED on FHIR Meeting

• 2025-09-16 - SNOMED on FHIR Meeting

New Spaces

2

All

Post link to new SNOMED on FHIR Space in chat:  SNOMED on FHIR

Other Meetings

10

@Peter Williams

@Rob Hausam

Recent Events:

Future Events:

Hospitals on FHIR 9 - 10 October see LinkedIn

SI SNOMED Business Meetings & Expo October 19 - 24 Antwerp Schedule (Update 2025-06-10 Discussion on LLM Abstract submission.  KK: https://github.com/IHTSDO/llm-chain-entity-extraction ). https://www.snomed.org/snomedct-expo

RACSEL - PH4H 28th to 30th October El Salvador see link

FHIR North October 28 - 29

Other Regular Meetings:

HL7 Group TSMG (meeting Wed PM ET every other week) - Terminology Service Management Group (HTA Thursday AM is now a subgroup of the TSMG).   2022-05-17 RH Joint session with Vocab at last business meeting.  2022-06-14 Group has approved minimum capabilities for terminology servers.  Now looking at bigger/better HL7 Terminology Server 

HL7 Cross group projects, CDA & FHIR Translation Meetings (weekly): @Jay Lyle Going well, there is an implementation guide and the group is doing connectathons. May in Dallas and Minneapolis.  See https://confluence.hl7.org/display/CGP/C-CDA+to+FHIR+and+from+US+Core+Mapping

Using SNOMED CT with HL7 Standards

20

@Suzy Roy

Request received from HL7 that this working group take a more proactive role in keeping https://terminology.hl7.org/SNOMEDCT.html up to date.

From Reuben:   This page and similar ones for other external (to HL7) terminologies are managed as part of HL7 Terminology (THO).  Additionally, changes to these pages are handled as so Pro Forma changes rather than UTG's Consensus Review / Voting process which applies to internal HL7 terminology artifacts. With Pro Forma changes, a responsible committee approves the change. For this page (and the other Using X with HL7 Standards), the responsible committee is the HL7 Terminology Services Management Group (TSMG) which Carol, Jess, and I co-chair. TSMG has effectively replaced the former HL7 Terminology Authority (HTA). Lastly, TSMG will always consider input from the SNOMED-on-FHIR committee and the HL7 Terminology Infrastructure Work Group when deciding on which changes to this page to approve.

PJ note that "Using SNOMED CT with FHIR" page is actually already part of the R4 page and so cannot be changed.   Moving it out of the specification for R5 going forward allows for it to be changed independently of the main spec.

Explicit syntax for properties

10

Russ Ott

2025-08-27 See email thread

KKE See bottom of Ontoserver CodeSystem response for SNOMED-CT https://r4.ontoserver.csiro.au/fhir/CodeSystem/32506021000036107-20210204?_format=json

Progress on FHIR Tx Ecosystem work in Snowstorm

10

TBC

Update on work to bring Snowstorm into line with FHIR Spec to allow participation in FHIR Tx Ecosystem.

Code in feature branch: https://github.com/IHTSDO/snowstorm/tree/feature/MAINT-2889

Available for review here (read-only instance): https://connectathon.snomedtools.org/fhir/CodeSystem?title=International%20Edition&_format=json  

Feedback here (request access): Google Sheet

Publishing expansion parameters on FHIR Implementation Guides

@Rob Hausam @michael lawley 

@Peter Jordan 

Based on a question in Jira: https://jira.hl7.org/browse/FHIR-44629. Discussed in this group to understand if we have requirements for this change, and add them to the discussion.

• The valueset definition can include parameters that affect conformance and do not need to be expressed on the expansion level

  • If you use precomputed expansions, the parameters are already baked in

  • If you have access to a terminology server you can compute the expansion and may need the parameters

• Other parameters like "only active concepts" or language may be represented only in the expansion, and may be added to the IG

• RH may be better to leave parameters to the valueset definition

• Plan: see what we can feed back to the FHIR discussion ticket

  • ML offered to add to the ticket to explain that it was discussed, and we may need more information

Laboratory representation in EU groups

@Rob Hausam 

Balance between the information model and the terminology model (postcoordination). LOINC SNOMED to Lab resources (orders and results), Service request, Diagnostic report, and Observation (specimen and method are the main attributes). Advanced cases like microbial susceptibility testing with references to antimicrobial substances, organisms, etc. Discussed possibilities for representing transformations in standard language. Experiences with transformations of the Situation with explicit context SNOMED concepts.

Question on use of multiple codings in a CodeableConcept

@Jon Zammit 

Question on the use of multiple codes in a CodeableConcept, especially when multiple codes belong to the same CodeSystem

eg from spec https://hl7.org/fhir/datatypes.html#CodeableConcept specifically "The concept may be coded multiple times in different code systems (or even multiple times in the same code systems, where multiple forms are possible, such as with SNOMED CT)"

PWI gave example of potentially transmitting most specific concept and also (for non-SNOMED members) the closest ancestor to that concept that is also in the IPS free set.    But the specification pre-dates the IPS, so whoever wrote the above was thinking about something else.

KH suggested reviewing: https://chat.fhir.org/#narrow/channel/179202-terminology/topic/Multiple.20codes.20in.20CodeableConcept also "Another dimension of CodeableConcept question is IG conformance and profiles using 'magic codes' to identify structural parts. Usually this comes up pretty quickly in this area."

Sept 16th:

JZ: Why would we use multiple SNOMED concepts?

PJ, DK, ALO: It can include the National Edition code, an International Edition code, and the IPS terminology code; the codes should have the same meaning but different granularity, providing the best representation for each version

JZ: The question code element in https://build.fhir.org/questionnaire.html supports multiple codings, the group discusses possible use cases and reasons for this

No further discussions are needed for now.

Surfacing alternate identifiers as a property in $lookup

@michael lawley 

@Peter Jordan 

@Peter Williams 

See Surfacing Alternate Identifier Values in FHIR ( See LOINC and NUVA Extensions)

2025-04-29 Group liked 'equivalentConcept' as it correctly identifies the relationship to the alternate code, and the fact that this is specifically a concept that is being pointed to.

2025-05-13 How to refer to the map/alternate identifier scheme (ML,KK,ALO)

Options:

• 1. Use the SCTID of the identifierSchemeId like in maps:

  • http://snomed.info/sct?fhir_cm=30051010000102

• 2. Use a different representation for alternate identifiers to reflect the difference in importance of an alternate identifier vs a map:

  • http://snomed.info/sct?fhir_cm=equivalentConcept

• In any case, translate operations can work OK with source and target URIs only

FHIR Questionnaire

Encoding issues

@Alejandro Lopez Osornio 

NLM issue with double encoding of URI parameter

Worried that URI contains invalid characters for a URL, so needs to be encoded, eg ValueSet URI that contains an ampersand.

ML shouldn't need to encode a 2nd time, as the encoding on the URI ensures that it is valid.   Notes that technically speaking, ECLs in URIs should have the terms removed.

PJ Could use POST to avoid the need for URL encoding (ML you can't cache a POST)

A new thread discusses this in Zulip, and during the call ML identified the issue, an erroneously encoding of the / in the URI. See: https://chat.fhir.org/#narrow/channel/179166-implementers/topic/Percent-encode.20parameter.20value.20for.20.24expand.3F/with/515590039

Working out what version of SNOMED CT has been loaded on your terminology server.

@Marie-Alexandra Lambot @Rob Hausam 

When I request a SNOMED code from a terminology server, how do I know which Edition has been loaded?

Ontoserver makes

this available in the terminology capabilities statement (force the output to be json to avoid truncation)

https://r4.ontoserver.csiro.au/fhir/metadata?mode=terminology&_format=json

Find the object that contains 

• uri: "http://snomed.info/sct"

and then look for the version that is marked as the default:

Open

A bad way to find out from the International Edition is to look at the descriptions on the root concept 138875005 |SNOMED CT Concept|, one or more of which feature the effective time of the release.  

Common Terminology Model

(eg reconciling SNOMED / ICD / LOINC )

@Peter Jordan 

RH Is this considering content or structure?  We express SNOMED CT (and therefore LOINC) in many different formats. Given that there are many formats, could there be a common one?    We already express all 3 in FHIR, with some loss of detail.

Reconciliation of datatypes probably too low level for a common model (necessary for implementation however).

Reconciliation of content would start with top level hierarchies, eg lab results appearing under < 363787002 |Observable entity (observable entity)|. ICD might approach this area with procedure codes.  

XiA -

Work package 4

@Marie-Alexandra Lambot 

XiA project - what should be taught?  Goal: what competencies/skills should be attained for the various groups of users to work with SNOMED and FHIR in Europe. (Fhirly are already members).

Who are the stakeholders being targeted and what do they need to know to work with EHDS?  

PJ recommended reaching out to HL7-Belgium.  HL7 International - what courses are available?  https://darrendevitt.com/

Snowstorm for IG Tooling

Planned work to bring Snowstorm up to spec for use with IG Tooling.   PWI to check if project plan has been confirmed.

Broker should route requests to the appropriate server, once certified / verified / registered.   Each HL7 affiliate should host their own national extension.   See https://confluence.hl7.org/display/FHIR/Publishing+terminology+to+the+FHIR+Ecosystem

Links to question of LOINC Extension and how that would work with FHIR, given that LOINC is already available in it's own CodeSystem.  Suggestion that a LOINC Identifier used eg in ECL would be immediately expanded to be the LOINC SCTID (see bottom of this page: 6.1 Simple Expression Constraints )

Case significance

@michael lawley 

Surfacing case significance.  Came about in the work done in AMT V4 where capitalisation was done to bring terms into line with the International Edition.   Validation was then failing as pre-existing terms were being supplied using the wrong case and this caused a matching failure.

Would this be best done via an Extension - eg on Concept.Designation which could appear as both on the CodeSystem and $expand

ML Case significance is part of the rules of the CodeSystem.   Note that the FHIR Spec allows for the case sensitivity to be determined by the CodeSystem itself.   PWI Notes that Snowstorm in general does case insensitive matching (Ontoserver is case sensitive - specifically in $validate-code) This has two parts:  1) correct behaviour in validate-code (ie check case where case has been specified to be significant) and 2) to tell the user what the case significance is so that they know when it is possible to modify the case of the term (and also for lexical operations like building narrative structures).

Next Steps:  CSIRO to propose an extension for review.

Checking position of the group: 

Open Question: Should / how should the CodeSystem-default be asserted / indicated in a ValueSet expansion (bearing in mind that it might contain codes from multiple different CodeSystems)

2024-11-12 ML Notes: Case Significance

1. No way for a CodeSystem to indicate whether display/designations are case-significant or not (to affect $validate-code behaviour)

2. For SNOMED, this varies on a designation by designation basis

3. For SNOMED, there are three possibilities:

       1. Case sensitive

       2. Case insensitive

       3. Initial character case insensitive

Proposal:

1. an additional (optional) element on CodeSystem to indicate the default / global behaviour. If no value, then defaults to case sensitive (safest option).

2. an extension on CodeSystem.concept.display, CodeSystem.concept.designation.value, ValueSet.expansion.contains.display, and ValueSet.expansion.designation.value to indicate the specific behaviour. If no extension, then defaults to CodeSystem’s default.

3. Also need a CodeSystem for the above three cases OR re-use the three SNOMED codes

4. SNOMED CT SHOULD assert Case insensitive as the default?

Group felt that case should not be considered during searching / filtering.   Should be checked for $validate-code and specifically fail.  Data needed in $lookup and $expand for use cases where text is compiled into narrative or post coordinated term.    Related question around how to validate diacritic marks (café).   PJ notes that in UCUM the codes themselves are case sensitive, but this discussion only relates to designations.  ML Question of case sensitive $validate-code should go to a bigger audience.

FHIR Observation Observation VS for Vital Signs

@Rob Hausam 

HL7 Orders and Observations Workgroup looking at Observation profiles for Vital Signs and Value Sets for what is considered to be a vital sign and need to consider SNOMED CT (possibly also NPU) for analogous value sets.  DK NPU have looked at this - suggests using the superset of this material and allowing users to work with a cut down set.  Concerns that this might need to be context specific.

Tx Compatibility

@Peter Jordan 

@Kai Kewley 

Discussion on work being done to make Snowstorm compatible with Tx

https://chat.fhir.org/#narrow/stream/179202-terminology/topic/Terminology.20server.20requirements.20for.20IG.20builds.2E.2E.2E

1 month of effort "pencilled in" for Q2 2025.   Also interest from St Bart's Hospital.

Obtaining additional Description details.

@Daniel Karlsson 

Ways to obtain Description SCTIDs.  There is an extension to allow this: https://build.fhir.org/ig/HL7/fhir-extensions//StructureDefinition-coding-sctdescid.html but is there a way to switch it on/off at runtime eg additional parameter on a $expand operation?

ML Ontoserver does not support FHIR extraction of description ids and aren't keen to (although some requests have been received in this direction).  SNOMED maintenance will be done via RF2, so IDs accessible that way.

@Jon Zammit 

ECL Binding to Data Entry forms - picking up unwanted terms due to also searching text definitions.   Suggest skipping them as part of the FHIR VS expansion filter.

ECL (if it were possible to use it in this way) would let you move your term search earlier in the process and restrict to SYN and FSNs:  <  56265001 |Heart disease|  {{ term = "heart", type = (syn fsn) }}

MAINT-2665 raised so that default FHIR $expand filter behaviour will be to only search SYN + FSN, but we should clarify the ECL spec on this as well.  See https://build.fhir.org/valueset-operation-expand.html ML : Ontoserver puts text definitions into the definition field, does not treat as a description - see CodeSystem $lookup out parameter:  https://build.fhir.org/codesystem-operation-lookup.html (DL asks if we could have it out in a VS$expand.   ML suggested we could specify definition in the property input parameter (see also VS.expansion.property)).

Archive.

Translation in Code System Supplements

@Daniel Karlsson 

@michael lawley 

2024-08-06

Translation in Code System Supplements.   See Zulip discussion 

https://chat.fhir.org/#narrow/stream/179202-terminology/topic/CodeSystem.20supplement.20use.20cases

See also https://build.fhir.org/ig/FHIR/ig-guidance/languages.html#creating-a-language-pack

Observation and Device Data

@Marie-Alexandra Lambot 

@michael lawley 

2024-08-06

MAL Belgium wants to exchange Continuous Glucose Monitoring data using FHIR, specifically, Percentage of time in set ranges was a difficulty.

ML Argonaut CGM project ongoing

https://chat.fhir.org/#narrow/stream/179175-argonaut/topic/CGM.20Project 

https://build.fhir.org/ig/HL7/cgm/

https://build.fhir.org/ig/HL7/cgm/StructureDefinition-cgm-summary-times-in-ranges.html

Document the use of an issue type to return incomplete validation

40

@Peter Jordan 

@michael lawley 

@Daniel Karlsson 

HL7 Jira ticket: https://jira.hl7.org/browse/FHIR-44810

The group discussed the topic and documented the discussion in the HL7 Jira ticket: https://jira.hl7.org/browse/FHIR-44810?focusedCommentId=231490

UPDATE June 25 2024: Notes from HL7 WGM in May:  Attendees agreed that we'd like more feedback from the SNOMED on FHIR committee on how this would work in practice in all the cases where it would apply to SNOMED CT.  Input on whether or not machine processable responses should be supported would be appreciated as well.

TBD: Discuss in future calls with @Kai Kewley and @michael lawley present

2024-08-06: No changes on HL7 Jira ticket. Assigned to Grahame G.

Observations vs Questionnaires

@Marie-Alexandra Lambot

Plans for patients in crisis (eg what can be done, who should be contacted, what does the patient accept).  Best way to capture in FHIR - CarePlan or Questionnaire?   Similarly for scales - each point on the scale is an observation.   

ML suggested using the questionnaire to capture the information and then transmit it via an Observation. Also see https://smartforms.csiro.au/dashboard/questionnaires - open source Questionnaire rendering with SDC support

ALO See https://build.fhir.org/ig/HL7/sdc/extraction.html.  Scores can also be computed.   See also 

https://lhcformbuilder.nlm.nih.gov/ and https://ihtsdo.github.io/sct-implementation-demonstrator/#/questionnaires

JZ Terminology Binding see Terminology Binding Principles

(MAL - Side discussion on documentation generation (click tracker with screenshot capture) - Datango.   What is @Anne Randorff Højen using for Simplex user guide?)

MedicationRequest Question

20

@Marie-Alexandra Lambot 

There are questions here currently regarding the Medication "line" (medication Statement I think in the international models) / Medication request / Medication dispense. One is, is there a way in FHIR to somehow link two medications to say that people have to take one drug X hours after the first one? 

How can we in MedicationRequest.dosage instruction express that a drug must be taken x hours after another drug which is in another medication line/Request? Can we somehow group two prescriptions to link them and give "global instructions" for both? Or would that pose other problems?

DK (update 31 July 2024): See also IG HL7 Europe FHIR IG for Medication Prescription and Dispense - https://confluence.hl7.org/display/HEU/Medication+Prescription+and+Dispense%2C+Edition+1 (FYI @Marie-Alexandra Lambot )

General discussion on work being done in EU

6

@Marie-Alexandra Lambot

@Daniel Karlsson 

See https://build.fhir.org/ig/hl7-eu/laboratory/branches/master/index.html

https://github.com/hl7-eu/laboratory

https://confluence.hl7.org/display/HEU/Laboratory+Report+Implementation+Guide%2C+Edition+1

https://build.fhir.org/ig/hl7-eu/xpandh-hdr/

ML: https://csct.be/projects.html

https://nuva.mesvaccins.net/

2023-09-19 ML CSCT now has official "Not for Profit" status as an entity.

2024-05-29 RH The HL7 Europe Laboratory Report FHIR IG will be balloted as a universal IG either in Sep 2024 or Jan 2025.

2024-07-31 DK See also IG HL7 Europe FHIR IG for Medication Prescription and Dispense - https://confluence.hl7.org/display/HEU/Medication+Prescription+and+Dispense%2C+Edition+1 

Identifying Modules - is most dependant the right thing to do?

@Jon Zammit 

Problem that changing the Canadian identifying module to the most dependant one (French Module) is not recognised by Snowstorm

The "most dependant module" idea doesn't continue to hold when we think about extensions that have multiple, equally dependant modules.   Also some external content (like LOINC) could be used by multiple countries and be the most dependant module, but could not be used as an identifier - it would no longer be unique.

2024-07-09 Review the guidance in the extensions practical guide to define how to select the identifying module, even when is not the most dependent module. The agreement of the group seems to be to separate the notion of package composition from module dependency. The terminology server will use the provided module as an identifier of packaged, which contents are defined elsewhere. The extension maintainer will choose which moduleId will identify his package, and needs to make this available to implementers. Maybe this is a use case for annotations. 

Alternative approach AP: NHS has created a composition module, that is created only for the purpose of referring to the other 5 NHS modules, and be used as the identifier of the package.

Model Binding

@Jay Lyle 

Model Binding, specifically model binding for elements within resources (rather than values).

Previous binding discussions:   Bindings to FHIR Clinical Resources. See also terminology binding

See demo which shows various elements in FHIR resources and how those would be populated from a SNOMED concept:  https://ihtsdo.github.io/sct-implementation-demonstrator/#/context. but working back from that, we could identify the SNOMED Attribute Types, which are relevant for the various elements in each resource.