Date 10:00 UTC on Wednesday 13 April 2022 - 90mins.
- FHIR Terminology Services and Resources discussion
- FHIR Terminology Binding discussion
Chat: public-snomedintl.slack.com # snomed-hl7-fhir (ask for invite!)
|Owner||Notes & Actions|
|1||Welcome and introductions||2|
Recording, notes & attendance.
Recent: Registration for April Business meetings open, as is call for abstracts for the SNOMED Expo fall 2022.
HL7 May 2 - 4 (running in Eastern Time) 2022
Dev Days US Edition in 6 - 9 June 2022 (Cleveland / Hybrid)
New HL7 Group TSMG (meeting Wed PM ET every other week) - Terminology Service Management Group (HTA Thursday AM is now a subgroup of the TSMG)
HL7 17 - 23 September Baltimore
IHE-Europe and IHE USA first Joint IHE Connectathon®, 12-16 September 2022. European Connectathon taking place in Montreux Switzerland, https://connectathon.ihe-europe.net/connectathon-2022
|4||Round Table Introductions||20||ALL|
India NRC - Manisha MantriSayali Pophalkar Gaurav Vaishnav Using SNOMED with LOINC and ICD-10. FHIR recommended nationally as a standard. Looking to build FHIR compliant TS at National Level, especially for lookup and validate & expand.
Australia - N/A
2022-04-13 CSIRO released next version of Ontoserver that implements some R5 features as pre-adoption, mixed with R4 eg typed values in concept maps. Also code properties without expansion.
Belgium - Marie-Alexandra Lambot Anne Nerenhausen multi-discipline data exchange programme for care-sets, FHIR objects codified in SNOMED CT (firstly allergy intollerance)
France - François Macary Phast
Netherlands - Pim Volkert Chantal Schitmeijer Feikje Hielkema-Raadsveld Ronald Cornet - using FHIR based terminology server which they supply to various vendors free to use except for usual licence fees - is an instance of Ontoserver, but not intended for use in "Live" system, instead used as offline supplier of terminology. Attempting to lower barriers to adoption. (Sander Mertens now working for a startup creating EHR system for GPs)
Norway - Oskar Hurtig using several Snowstorm servers in combination with SNOMED International's Managed Service. Oskar's team in start-up phase looking at the introduction of SNOMED on FHIR for Norwegian customers. Existing environment involves many classification systems (eg HealthTerm) which they're trying to consolidate with FHIR. Developing own FHIR Resources.
2022-03-16: This past month is that we’ve done some internal training on FHIR to prepare our team and (softly) requested our leaders to help us create a national recommendation on the use of SNOMED on FHIR in Norway. The use of FHIR and SNOMEDCT are separate recommendations already. We’ve also identified a use case where we would like to create some VitalSign profiles with terminology bindings to SNOMEDCT and be able to locate test patient data using a SNOMEDCT code search. This is primarily a way to learn terminology bindings and ask better questions to this forum, as well as to some extent understand our terminology server needs.
New Zealand - Peter Jordan (HL7) National Terminology Server for NZ currently under development. Peter's own implementation "Terminz". FHIR Release 5 underway eg changes to Concept Map.
Sweden - Daniel Karlsson, Anna Rossander No clear decision made yet on using FHIR with SNOMED but there are a number of projects underway eg with HL7 Sweden. Some competition in this space for Terminologies but
Swiss Annatina Foppa
United Kingdom - Andrew Perry(NHS) Various FHIR profiles in use for moving data between primary and secondary care incorporating SNOMED. National Terminology Server procured (not publicly available - constrained by copyright eg non UK access). Programme of implementations which use the National Server underway. See https://digital.nhs.uk/services/terminology-servers
2022-04-13 JR working with MS Excel add in to call FHIR $lookups from cells. Issues with oauth in that environment.
United States Jeff PiersonIMO
|5||HL7 FHIR Update||Peter Jordan|
FHIR Release Schedule : R5 will be trial use Q1 2023. New normative content will be added Q1 2026.
Minimum capabilities https://jira.hl7.org/browse/FHIR-24698 (aimed at R5)
|6||ICD 10 Maps in FHIR|
Feikje Hielkema-Raadsveld suggested that the"group" element could be used to transmit additional information.
PJ: StructureMap, although not technically a 'terminology' resource and generally used for model mapping, is a possible solution for complex maps.
|7||Recording suspected & negated diagnoses|
JR: Current UK use case is: primary care physicians do not want to record the available code for "Long COVID" because (a) they may not have any proof that the patient ever had COVID, because they had it before testing was available and (b) even in those patients who tested positive for COVID there is no test to prove that their current chronic symptoms are caused by that. So the proposal is to give them a "Suspected Long COVID" code.
MAL: Belgium use the confirmation code on the resource rather than a possible SNOMED CT code.
But that raises interesting questions about what happens when somebody sends a FHIR resource with code="suspected Long COVID" and verificationStatus= confirmed. Or refuted.
Historically, before the information models got around to adding their own support for contingent diagnoses, there have been codes for a small range of "suspected condition" only within the terminology. There are about 400 in SNOMED today. Of these, almost all are NEVER used in UK Primary Care. The significant exception is "Suspected urinary tract infection" plus a handful of others. Which also raises the question of whether clinicians really want, or should be allowed, to enter contingent diagnoses at all. In the case of the "Suspected Long COVID" code, for example, would it not be better to send what you know to be true e.g. "Post viral fatigue syndrome"?
Peter G. Williamsverification status is an example of an HL7 valueset (with a required binding) where some authorities may wish to use SNOMED CT codes instead. Belgium have created an extension to allow them to do this. Is there a way forward with the specification that would leave to a more interoperable outcome FYI Rob HausamPJ suggested that the binding strength be loosened eg to extensible or preferred (would go through the Patient Care Workgroup). Suggestion that any ticket raised is shared with this group and also that country HL7 Affiliate Chairs are involved (interest from at least 4 countries here). FMc states issue that existing valueset is unsatisfactory for clinicians because"suspected" is missing.
MAL provided: 410605003 | Confirmed present (qualifier value) | 410592001 | Probably present (qualifier value) | 415684004 | Suspected (qualifier value) | 410593006 | Probably NOT present (qualifier value) | 410594000 | Definitely NOT present (qualifier value) | 261665006 | Unknown (qualifier value) | 723510000 | Entered in error (qualifier value) |
PW: Given that this is a required binding to a codeable concept, could we add in the SNOMED CT code as a coding to the existing HL7 Code. This would force an equivalence that may not be generally agreed with.
JR: Brings up use case of differential diagnosis although this is supported in the HL7 ValueSet.
MAL: There are SCT ways to qualify a diagnosis, see << 106229004 |Qualifier for type of diagnosis (qualifier value)| could be added as an additional field.
SS: Differential Diagnosis is often used in Germany as a secondary option from the most likely diagnosis. MAL suggested DD was used more often when there was a set of more equally likely diagnoses. JR: UK doctors use the order of the DD list ie most likely first. RC: This was the point of SNOMED CT was that the logical definition of concepts allowed for the detection of equivalence.
SS: Also to note that some languages like German would express suspected asthma as a single word, which needs to be computable.
PW: Preference here, in general, would be to use the fields in the information model (avoids excessive pre-coordination in FHIR or forcing others to use PostCoordination) and then constrain profiles to remove the SNOMED codes where things like verification are included in the concept to avoid ambiguity or worse, contradiction.
JR: The AdverseEventActuality valueset looks to be a broadly similar idea for the AdverseEvent resource, but is also different.
2022-04-13 Suggestions for a way forward here? PW Something to raise with Rob Hausamfor the HL7 Vocab working group (also mention the transversal nature of this VS - MAL). JR List of options eg profile out the codes that leave us open to contradiction. Guidance on how to interpret various combinations eg a confirmed diagnosis of a SNOMED code that indicates "suspected". DK Refers to the previous work done that resulted in orange mappings Free SNOMED CT set for FHIR MAL: Also discussed on the EAG call at the Business Meeting. Also inconsistency of these "certainty" fields in various FHIR Resources. Also query around level of certainty when several potential diagnoses are presented. ML: Suggestion that several condition objects would be linked in this case. PW Can I say: "This group recommends that profiles should be used to remove these "contextual" SCT codes from ValueSets which could contradict other fields (AP 'Semantic Clashes') in the FHIR Resource." ? DK We may already have implementations that are using something like 722545003 |Suspected rabies (situation)| and has decision support systems that would look for this. ML "The verification status pertains to the condition, itself, not to any specific condition attribute" (ALL this part of the spec was thought to be ambiguous. Does this mean just the condition code or the whole Condition resource ie are we verifying all aspects of the resource? ML Adding in a SNOMED code as an additional coding in a CodeableConcept has a little wiggle room due to "differences in granularity". TB Provisional (or "Working Diagnosis") is often used when a disorder perhaps takes a long time to fully confirm eg Motor Neuron Disease and in fact a treatment plan may already by underway. So it's further down the line than "suspected". JR Suspected may also be used when a condition has cleared up and it is no longer to test/prove that that is what it was. MAL notes that the Refuted status is valuable in terms of saving time and money. General agreement to avoid the situation hierarchy (No known allergy) and instead pass the allergy condition with the refuted flag. (Note: psychological feature for humans to fail to hear negation!). MAL Suggestion to tag the EAG on this Jim Case also with a view to being clearer about the definitions of these concepts (eg suspected diagnosis) in SCT to either align or clearly differentiate with the FHIR VS. Discussion about "Family History Of" and complications around roles vs sex see HL7 Gender Harmony Project. (see "In the Land of Invented Languages" - ML)
Interest here was specifically on FHIR Education for Clinicians.
Peter Jordan to discuss with Sadhana, still pending.
MAL would like to compile background information for Clinicians to approach FHIR (with SNOMED CT) and the rules around what you can and can't do with FHIR Resources such as the cost / pros / cons of creating FHIR Extensions.
See also Hospitals on FHIR: https://www.linkedin.com/pulse/hospitals-fhir-launch-event-catherine-e-chronaki/
MAL: More complex examples fully expressed with medical specifics ie real life problems including business rules.
Belgium looking at specifics of substance use / misuse / abuse. Alcohol has some representation in FHIR but not other substances. SNOMED CT coverage considered inconsistent (ie a line gets drawn where an observation becomes a disorder), would be keen to work in tandem so that any changes in the SCT hierarchy have an intended destination in a FHIR resource. PJ suggested solution use FHIR Resource as building blocks. MAL would like to see guidance so that whatever is put together can be commonly shared.
Peter G. Williamsto bring up internally that the Content Team is under represented in the working group.
DK Linking observations to diagnoses then CarePlans is a common problem and links between them may be spotty and open to interpretation. A generic discussion about linking resources would be useful. Secondly lifestyle factors (Social Determinants of Care). Both a content and terminology binding issue. Some modeling needed in SCT but may not be scaleable. If not, information model support would be needed.
MAL Non-substance addictions (also habits) not well represented in SNOMED CT
Copied from 2022-03-22 Agenda: https://jira.hl7.org/browse/FHIR-29821 "Updated cardinality of designation.use" Expected to be part of R5.
2022-02-22 Add HL7 Jira ticket about designation use context and designation.additionalUse. For discussion on HL7 Vocab call March 3.
2022-03-08 See also https://jira.hl7.org/browse/FHIR-36231 "Add designation context to designation.additionalUse"
Feedback from this group: relying on the order of elements in the additionalUse array could be tightened up. If a new element is being proposed, perhaps we could add some structure/hierarchy so that the relationship between refset and acceptability could be more explicit.
DK Compromise using BCP-47 standard seems hopeful. designation.additionalUse being added with 1..* but DK/ML/RH thought that this would be confusing (more than one way to do things)
DK Suggests implementing BCP-47 in Snowstorm.
PW Has documenting examples of these on TODO List.
FHR: NL have patient friendly text definitions - how is that going to work?
|11||Allergy Resource Issues||Marie-Alexandra Lambot|
Rob Hausamhas reviewed and document now in final draft (see previous agenda attachment)
Bruce presenting at Clinicians session Wednesday 12:30UTC
Annatina Foppahad issues with the 2 profiles in Switzerland (findings vs substances focus)
SS Notes that one could determine the substance from the finding. MAL in fact you could go both ways and having access to the entire range of substances. Further confusion caused by negation fields vs SNOMED CT concepts
FMc If using the Finding concept, the substance could be separately included. Would be keen to see preferred choice stated, or at least for each country to declare their implementation
DK Notes that IPS does not attempt to constrict the list.
|12||Metadata in FHIR|
RC: Particular interest in the provenance of information. Interested in relationship between FHIR and FAIR and metadata around patient eg why was patient included in study, potentially metadata for the dataset, rather than just an individual. FAIR See https://confluence.hl7.org/pages/viewpage.action?pageId=91991234 Findable, Accessible (conditions and ways rather than "open"), Interoperable & Reusable.
PJ Suggested looking at the bulk capabilities in FHIR (Zulip stream - https://chat.fhir.org/#narrow/stream/179250-bulk-data )
Ronald Cornetwill give updates at further meetings. What metadata are we interested in (question could be put to the MAG)
PWI Has interest in metadata from SNOMED as being progressed with annotations in the MAG. Also notes that the HAPI library has (had?) issues with aggressive caching of the Capabilities
TODO Ask Ronald about categories of Metadata
PJ HL7 Vocab collaborating with OMOP on this (meeting weekly). RC OMOP well aligned with FAIR.
See also CDISC - Clinical Data Interchange Standards Consortium (focus on clinical trials cf OMOP using real world data)
|13||NLP / Text Annotation|
Most real world data is held in narrative. To train data, annotators are needed who should follow annotation guides to ensure consistency. New guidelines are needed which are informed by FHIR.
Something that could be discussed at future meetings.
Question from FMc about limitations of using German (eg availability of tooling), SS says they have a set of interface terms which are comparable to English.
DK Compound languages need to be able to "decompounded" for translation & analysis. Germany provides the majority of this work. Snowstorm does not do matching on compound words well (doesn't recognise same root)
|14||Terminology Binding - Diagnostic Report|
Review by group, see DiagnosticReport
TODO Work through the V2 VS http://build.fhir.org/valueset-diagnostic-service-sections.html for mapping and suggest additions to SNOMED CT where a mapping does not exist.
|15||Known FHIR Implementations / National Terminology Servers||10|
National Terminology Servers: United Kingdom, Netherlands, Norway
HL7 Jan 2022 Virtual meeting: Aim for testing ConceptMap on the Connectathon (Jan 10-12). 590 attendees. Discussion on improving test suite (driven by need to create a group of trusted terminology servers for federation. Also interest in IPS (International Patient Summary)). Interest in LOINC, less so for ICD-11. Another Australasia event hopefully planned for this year due to travel restrictions.
SI Business Meeting April
Late April NZ / AU connectathon - still being planned.
HL7 May 2022
HL7 September Baltimore, meeting and connectathon.
FIRELY Dev DaysNext will be US Edition in June 2022 (Cleveland, hybrid event) (Dev days planned for once per year)
|17||India specific situation and direction||20|
FHIR Implementation Guide developed by India NRC. Development Team also available - all options on the table.
PJ suggests high level architect to represent client and ask questions eg "how often does EHR have to validate a Terminology Server" Some support in FHIR for server side caching (see $closure) on a per-client basis. HL7 TX server needed extensive work around performance due to being used in IG Tooling.
16 Feb Particular interest in contributing to the development of ValueSets.
|18||SNOMED CT guidance around Allergy and Hypersensitivity|
Asked group for review of FHIR specific elements in "
Implementation Guide for Use of SNOMED CT in Documentation of Allergy, Non-allergic Hypersensitivity and Intolerance"
DK - suggests a dedicated meeting on this work. Are there specific questions on this? MAL - Too long to spend time in a meeting reading, would like feedback.
16 Feb DK Added examples to the FHIR IG, see https://github.com/IHTSDO/snomed-ig Rob H doing review prior to publication.
|19||Definition of GPS||Rob Hausam|
Request that SI make the GPS ValueSet available as an extensional definition.
SI are (I think - PWI) in agreement to do this.
16 Nov Update: "Search After" functionality will be available in Prod 1 Dec.
|20||Language Reference Sets in FHIR||All|
24 August 2021 DK Added pull request to Snowstorm here
Implementation by ML using existing fields and specifying LangRefset in displayLanguage parameter with "preferredForLanguage" code and wildcard Eg https://r4.ontoserver.csiro.au/fhir/ValueSet/$expand?displayLanguage=*-x-sctlang-20581000-087109&_format=json&url=http://snomed.info/sct/20611000087101?fhir_vs=ecl/160303001&includeDesignations=true
Oct 5 Release of Ontoserver 6.5.0 which includes support for language reference sets as above.
16 Feb Some discussion about the proposal for making designation.use 0..* (previously 0..1) and also the introduction of additional use - looking for clarification. R5 Ballot cut-off 22 Feb?
16 Mar See Tuesday meeting cardinality discussion 2022-03-08 - SNOMED on FHIR Meeting (TS & TB) and Tracker https://jira.hl7.org/browse/FHIR-36231 "Add designation context to designation.additionalUse"
|21||SNOMED FHIR Implementation Guide|
IG Documentation: http://build.fhir.org/ig/FHIR/ig-guidance/index.html
|22||Any Other Business|
MAL suggests discussing FHIR Resources for clinicians (clinical terminologists).
16 Feb MAL More of a question around teaching resources to bring clinical terminologists on board. Existing information is vast, split between different websites and finding a step by step path through it is very difficult. Something that could be taken forward by HL7 although there is an intersection with SNOMED CT when it comes to developing ValueSets. PJ suggests contacting Director of Education Sadhana Alangar sadhana@HL7.org (US based) in HL7 re "FHIR for Clinicians" . Crossover from OpenEHR may be useful.
Potential Items for Discussion
|Description||Owner||Notes & Actions|
|Description||Owner||Notes & Actions|