Welcome and introductions

2

@Peter Williams

Recording, notes & attendance.

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

Previous Meetings

2

@Peter Williams

• 2023-06-13 - SNOMED on FHIR Meeting (TS & TB)

• 2023-05-30 - SNOMED on FHIR Meeting (TS & TB)

• 2023-05-16 - SNOMED on FHIR Meeting (TS & TB)

• 2023-05-10 - SNOMED on FHIR Meeting (TS & TB)

Other Meetings

5

Recent events:

FHIR Dev Days June 6 -9 Amsterdam https://www.devdays.com/.  CSIRO giving 5 talks.   https://www.devdays.com/schedule/    Updates:   Update from GG about multi-language support for IGs.  RH: Google potential involvement with IPS & an Android SDK.  DMc reminded about selecting patients using Patient.hasCondition.below=123456001  which makes cohort identification extremely easy (potential to add ECL or member of subset (if we used a ValueSet expansion, that would give us functionality for as much complexity as is required).  PJ voiced need for more content in the IPS.   Also support for presenting multiple releases of FHIR in a single server (ways to do that in both HAPI & Microsoft - "Shared Project" both use MIME types).    PGW:  Going forward, DevDays will alternate year about in the US and Amsterdam.   June 2024 will be Minneapolis.  Appreciated having all introductory talks on the first day.

NHS Scotland Connectathon June 12 - 13 (Clayton Hotel, Glasgow  Registration)

Upcoming events:

MedInfo 8 - 12 July Sydney Australia see here session on a wide number of standards.  See https://medinfo2023.org/program-schedule/   RH & PJ presenting session on IPS (Sunday).  HL7 & SNOMED International being represented.   Panel involving JIC

HL7 September (Atlanta Phoenix) 9 - 10 Connectathon, followed by 5 days working groups.

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 

Round Table Updates

20

All

Australia - 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.  2022-08-31 ML CSIRO taking over responsibility for production (including authoring) of SNOMEDCT-AU.  Further announcements in the pipeline.

2022-09-25 ML Australia specific FHIR training package in development (not focussed on clinicians, rather focussed on domains, developers and Information Modellers) Ontoserver approaching R5 however level of demand current unclear.

2023-04-02 - FHIR Community Process, FHIR Training Courses (mix tech and business)

Belgium - @Marie-Alexandra Lambot Anne Nerenhausen  multi-discipline data exchange programme for care-sets, FHIR objects codified in SNOMED CT (firstly allergy intollerance).

2023-04-02 - Working though list of FHIR ValueSets

Canada - 

Estonia - @Rutt Lindström @Kerli Linna switching to FHIR Nationally, preferring international terminologies.  No National TS yet, currently capturing requirements.   2022-09-25 KL Developing National Terminology Server, piloting 

2023-04-02 - Now using Ontoserver Nationally, moving to message (eg ambulances) using FHIR structures.

Europe - 2023-04-02 (MAL) Hospitals on FHIR

France - François Macary Phast 2022-09-25 FM Profiling FHIR based on R4 Nationally.  Intending to join Snomed International as a member.  FM coordinating translation with LP (Canada).

Hong Kong - @Former user (Deleted) @Maggie Lau (Unlicensed)Have own terminology table, mapped to other terminologies including SNOMED CT.  Looking to learn more about using 

India NRC - @Manisha Mantri@Former user (Deleted) 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.  2022-05-11 MM focused on insurance domain profile - just starting (requirement gathering, looking at HL7 profiles).  ValuesSets for Patient, Practitioner, Organisation.

2022-07-06 Successffuly imported of multiple code system using HAPI FHIR Server (also pending the beta release of the Snowstorm modifications in this area - next few weeks).

2022-09-25 SP FHIR is being adapted as a standard for exchange in National Digital Health Mission of India called Ayushyaman Bharat Digital Health Mission (ABDM). We have FHIR implementation Guide for ABDM where we have created profiles for FHIR resources as per Indian needs. We are using multiple terminology standards like SNOMED CT, LOINC, and ICD depending on the context. We are also working towards having a nation specific term server who can support multiple terminology standards mentioned above. And we are having hands-on on Snowstorm for that.

2023-05-10 SP Testing recommending on Snowstorm 8.1.0

Netherlands - @Former user (Deleted) Chantal Schitmeijer @Feikje Hielkema (Unlicensed) @Ronald Cornet (Unlicensed) - 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).  2022-07-06 Hitting technical issues with termserver (suspected scrambled mounting points).

2023-04-02 - Also hosting Ontoserver

New Zealand - @Peter Jordan (Unlicensed) (HL7)  National Terminology Server for NZ currently under development.  Peter's own implementation "Terminz".   FHIR Release 5 underway eg changes to Concept Map.   PJ Medicines Data Repository.  National Terminology Service Mon 5 Dec Connectathon including "Escape from burning platforms"

2023-04-02 - Also using Ontoserver.  Data Repo - 

Norway - @Former user (Deleted) 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-05-11 Currently running assessment of various FHIR servers including HAPI, Microsoft.  Focused on VitalSigns.

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.

Sweden - @Daniel Karlsson (Unlicensed), @Anna Rossander (Unlicensed) 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.

2023-04-02 - National based profile work stalled.  Ontoserver procured.  Update on Europe wide FHIR initiatives.

Swiss @Foppa, Annatina

Austria / Germany. @stefan.schulz (Unlicensed) Use SNOMED CT together with FHIR for Natural Language Processing in a research context (projects AIDAVA and GeMTeX). Elaboration of an annotation guideline for clinical narratives using SNOMED CT and FHIR.  [https://docs.google.com/document/d/1BQPL8sNIMorRb9qdvsZL0ckpmx2DILsZF6bewRduvWI/edit]

United Kingdom - @Andrew Perry (Unlicensed)(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-09-25 AP  GP to GP transfer happening in V3.   NHS Digital being brought into the main body of the NHS.  Medicine Connectathon happening in a couple of weeks. NHSx for interoperability also re-absorbed.

2022-04-13 JR working with MS Excel add in to call FHIR $lookups from cells.  Issues with oauth in that environment.

2023-04-02 - Ontoserver.  Working on UK Core "sprint 6" updating profiles.

United States @Jeff Pierson (Unlicensed)IMO 2022-09-25 RH Strong set of Core profiles (came out of Argonaut). Data exchange still based on CDA. Accelerator Projects.  See https://www.hl7.org/about/fhir-accelerator/

SNOMED International -@Alejandro Lopez Osornio @Kai Kewley @Peter Williams

HL7 Europe IG

@Daniel Karlsson (Unlicensed) 

@Feikje Hielkema (Unlicensed)

2023-05-10 HL7 Europe IG - ongoing work.  DK focussed on SNOMED ValueSets.  Missing content being requested, also potential changes to concept model.

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

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

Visualisation of FHIR resources

10

@Marie-Alexandra Lambot

MAL working on visualisation of FHIR resources - entity relationship diagram.

European Terminology Services Collaboration

10

@Rutt Lindström 

There is a European Commison working group under MyHealth@EU that is considering requirements for future terminology services for EU cross border eHealth services (ePrescription, eDispensation, Patient Summary, etc).
A temporary side activity of this group is to discuss national terminology server and terminology management systems implementations. Most people involved in the group are also involved in the national terminology services projects, and sharing those plans and experiences are helpful for finding the middle ground and needs for common EU services. 

@Rutt Lindström is the co-lead of that group. If you're interested in learning more, or you're just bored with your life and feel like chatting with someone about these topics, please get in touch.

2023-04-02 Discussion on managing ValueSets - taking refset and publishing as a ValueSet with additional information.   Imposing a hierarchy within a ValueSet   See Item Weight Extension (discussed in Zulip)

@Marie-Alexandra Lambot 

ValueSet Question - http://hl7.org/fhir/R4/codesystem-tooth.html

Suggested connecting with @Sarah Lukha 

SNOMED CT to ICD-10 map

@Jeremy Rogers (Unlicensed) 

JR: How should the SNOMED CT to ICD-10 complex map be used with FHIR?

ML: There are changes to ConceptMap introduced in R5 to support this use case. In R5 the property element carries additional information about a "map row" including map rule, map priority, map advice, etc.

JR: For fully automated mappings from SNOMED CT to ICD-10 there is a notion of a default mapping, in the UK this has been identified as the map alternative, given that map rules have been applied, with the highest map priority.

ML: There is in R5 no way to specify a "default behavior" with the ConceptMap resource. Either this would be up the client to decide, or alternatively there might be two maps provided; one which provides only one default mapping for each SNOMED CT code, one which provides additional properties to allow the client to decide.

SNOMED complex maps cannot be not represented in R4.

The R5 changes have just recently been published and implementation in terminology servers is to be done.

Post Coordination

@Alejandro Lopez Osornio @Kai Kewley 

Walk through of the new Guide to Post Coordination.

Practical Guide to Postcoordination

https://ihtsdo.github.io/iid-postcoordination/

ML: Ontoserver supports level 0 Post Coordination.

Allergy Guide work 

5

@Daniel Karlsson (Unlicensed) 

@Marie-Alexandra Lambot 

Allergy Guide binding question on representing symptoms - discuss on next Tuesday call.

MAL - has finished current version of guide.  Some layout work to do and small additions possible prior to publishing. 

Snowstorm multi-codesystems support

20

@Kai Kewley 

Discussion on Snowstorm multi-codesystems support.   Should get pulling into develop branch.

Sayali and Gurav (India NRC) gave feedback on the current Snowstorm X code.  India focussed on ConceptMap functionality.

2023-03-15 PWI SI has merged the SnowstormX work into the main branch and this will reach production on 22 March.   India had paused testing on Multi codesystems, will return to it.

Update on changes for LOINC

@Peter Williams 

2023-01-18 DK Asked about provision for ConceptMap

ML Extension for alternate codes is available

ML Question about ValueSets and Bindings - would we accept a LOINC code if it is an alternate identifier?

Group agreed that it would be simpler to do the conversion from LOINC to SCTID up front, and then validation, ValueSets and ECL should all work only using SCTIDs.  ConceptMap would be implicit using the two CodeSystem URIs and no need to specify an SCTID for a map referenceset.   Although DK reminds us that mixed CodeSystem ValueSets exist.

4.2.4 Identifier File Specification  ML suggests changing the SchemeId to a CodeSystem URI or add another column for it.

ValueSet of all of SNOMED CT

15

@Rob Hausam 

What is the proper valueset URI from which to reference a SNOMED CT concept?

http://snomed.info/sct  (ie across all editions and all versions, but this is the CodeSystem URI, not a ValueSet one)

vs

http://snomed.info/sct?fhir_vs  as per see https://www.hl7.org/fhir/snomedct.html#implicit

Whatever we use, it should be populated in CodeSystem.valueset see https://www.hl7.org/fhir/codesystem.html

However, certainly in the Snowstorm implementation that ValueSet would only expand to the default edition & version loaded.   That said, $validate-code does check across all concepts known to the server (in any extension).

Snowstorm support for other CodeSystems

@Kai Kewley 

Support based on HAPI library support for generic CodeSystem imports (doesn't allow for loading maps or valuesets)

• What happens to force-system-version in VS $expand where there is a mix of CodeSystems.   Presumably it only applies to the matching codeSystem.    If there were a mix of two editions, would both editions attempt to expand against the same forced version?

• VS $validate-code with Post-Coordinated concepts as a way of validating correctness of PCE.    How is PCE represented in a GET request?   ML It's one long URL encoded string.   Terms are not required (does the spec suggest they should be stripped out).   KK No PCE support in Snowstorm until later in the year.

ML Question on motivation for adding support for other code systems to Snowstorm KK Was at the request of members.  Also for a SI use case, we'll have access to the terms associated with published core mappings so we can be more expressive than just returning "Q.74" or whatever the code is.

2022-07-06 Question about specific vs general support.   Specific code written for LOINC and ICD-10 / ICD-10CM to allow import in native format  Existing HAPI support for generic code system format is also available.   CodeSystems which declare "IS A" semantics allow parent child ie $subsumption testing to be done.  DK asked if non-international ICD-10 maps have been loaded - they have not.

2022-08-31 KK Snowstorm-X  fork of the SI master Snowstorm project (beta) allows for loading packages from Simplifhir (pre-downloaded).

R5 changes suggested around specifying language using BCP-47 

@Peter Williams 

@Daniel Karlsson (Unlicensed) 

See Tuesday meeting item #6

Changes for R5  and check on use of dialect in x form in ECL Specification Appendix C:  Appendix C - Dialect Aliases

Note that where a language reference set pulls from more than one language, the BCP-47  tag could potentially missing out the <lang> element and start directly with "x-".  Options for referring to multiple languages: could be done either with a * (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language#syntax ) or with a comma separated list to indicate a priority order (although this isn't supported by the FHIR parameter (unless the server went out of it's way to allow for this), or use the accept-language header).  Use case is in the displayLanguage input parameter to a ValueSet $expand operation

2022-08-31 ML CSIRO attempting to get R5 compliant Ontoserver ready in time for HL7 Connectathon.

Post Coordinated Expressions in FHIR

@Kai Kewley 

@Former user (Deleted) 

Review of SNOMED CT Postcoordination Workflow (Discussion)

ML would like the expression supplement to use a system uri of http://snomed.info/xsct rather than http://snomed.info/sct.

See http://snomed.org/scg

2022-09-25 ML Main focus of languages working group is around risk, particularly in the transformation from close to user form.

See also https://snomed.atlassian.net/wiki/display/HRCM20200131/Concept+Model+Domains

Clinicians on FHIR

@Peter Jordan (Unlicensed) 

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.  

Cardinality on Designation.use

@Daniel Karlsson (Unlicensed)

2022-05-11 DK FHIR-36231 has been marked as resolved.

See Use of BCP-47 + designation.use 

This group recommends using the FHIR "consumer" use where appropriate as this aids interoperability (as opposed to using some custom extension like DesignationUse).  It might be helpful for all "consumer" type refsets to have a common parent so that we can detect them and map appropriately to use = consumer in FHIR (@Former user (Deleted)?)

2022-08-03 Final recommendation

2022-09-25 RH New location for terminology specific information (Terminology Services Management Group), this is advantageous because the content is no longer subject to FHIR Ballot cycle.  See https://terminology.hl7.org/ updates via UTG (Unified Terminology Guidance, but TSMG will take Jira tickets directly)

HL7 FHIR Update

@Peter Jordan (Unlicensed)

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)

2022-05-11 RH Date for R5 ballot still open

OH question about ConceptMap - maturity level?  RH Current updates first need to make it officially into R5 (which is expected to happen at ballot).  ML the changes are being driven by increasing maturity, but of course are then 'new'  RH option for 'parts' of a resource to be called 'trial use'.   Dependent mainly on reports of production level implementations.

ICD 10 Maps in FHIR

@Jeremy Rogers (Unlicensed)

Issues:  

• Additional fields in complex / extended maps are not represented eg different code when rule "is pregnant" applies.  @michael lawleyapparently looked at this a year ago with a view to progressing but no firm. 

• Also specifically need an order / priority field.

• Are there any known Extensions to allow additional information to be either returned OR if we could pass additional parameters into the request in order to obtain a more specific match based on match. 

@Feikje Hielkema (Unlicensed) 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.

Recording suspected & negated diagnoses

@Jeremy Rogers (Unlicensed)

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 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) |

https://build.fhir.org/valueset-condition-ver-status.html

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.

MAL: note that valuesets for verificationStatus are not the same for the FHIR Condition and FHIR AllergyIntolerance resources.

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)

• SNOMED+FHIR education

@Marie-Alexandra Lambot

Interest here was specifically on FHIR Education for Clinicians.

@Peter Jordan (Unlicensed) 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/ 

https://www.hospitalsonfhir.eu/

• What should be in the Implementation Guide? (missing/to be added)

@Marie-Alexandra Lambot

@Peter Williams

See https://github.com/IHTSDO/snomed-ig   build: http://build.fhir.org/ig/IHTSDO/snomed-ig/

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

• SNOMED+FHIR in multi-language settings

@Rob Hausam 

@Daniel Karlsson (Unlicensed)

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"