Welcome and introductions

5

@Rob Hausam

@Peter Williams

Recording + Notes.

Summary of previous week (TS) and previous TB

5

@Rob Hausam

@Peter Williams

• 2020-02-25 - SNOMED on FHIR Meeting (TS)

• 2020-02-18 - SNOMED on FHIR Meeting (TB)

Future meetings

5

@Rob Hausam

@Peter Williams

Upcoming events: 

SNOMED International Business Meeting April 5 - 8 SNOMED on FHIR meeting Sunday 5 April

San Antonio HL7 Meetings + Connectathon May 16 -17

FHIR DevDays - June 16-18, 2020 Cleveland, OH

SI Business + Expo October

Follow up on Blood Pressure.

10

@Daniel Karlsson

@Andrew Perry

Is the "vital signs" scope too limited?

Distinction being made between "Vital Signs" blood pressure and general blood pressures.

No conclusion reached on "panel codes". Compromise to use whatever is recorded on the system and where none available use a high level concept.

Specimen

30

@Riki Merrick

Specimen binding. Update from HL7 Specimen Project Group by @Riki Merrick (and offer to review this group's work!)

information for the HL7 specimen project calls: Mondays 2 -3 PM ET join web: Description:Online Meeting Link: https://join.freeconferencecall.com/ord Online Meeting ID: ord If not on FCC or not wanting to use VOIP, use the following dial-in: Dial-in Number (United States): (515) 6065332 Access Code: 294586 International Dial-in Numbers: https://www.freeconferencecall.com/wall/ord#international

DK Both FHIR and SNOMED have reasonably elaborate models for dealing with these which creates "interesting" opportunities for binding discussions.

Why use SNOMED with FHIR?

5

@Peter Williams

• Best in class Terminology combined with best in class information model. (KR: is most popular but the looser semantics in the information model calls for stronger semantics in the Terminology)

• Achieve the highest level of detail in clinically recorded data (KR - actually the ability to use specific levels of detail where required ie summarising without needing to change format for data exchange)

• Use the power of SNOMED’s polyhierarchy and attributes in realtime decision support and to identify cohorts from FHIR resources (-1 ICD-11 can do this also)

• Generate filtered ValueSets based on ECL in multiple Languages

• Leverage Terminology Services directly in Mobile Apps (this makes processing feasible)

• Machine assisted reasoning

• Leverage re-use of existing data and ValueSets and existing maps to other code systems.

JR: Since the case for using SNOMED in EHRs is overwhelming, FHIR must also

DK: FHIR used for communicating data that has already been captured. Would be impossible to use SNOMED as a transmission terminology if the data were not already at that level of granularity.

URI Standard update

2

@Peter Williams

Update 3 March 2020, the next draft of the SPLG URI Spec will suggest:

The SPLG workgroup discussed sticking to the naming conventions of the particular technology being referenced, which will avoid current issues with IG tooling, so for example: http://snomed.info/fhir/ValueSet/gps

SNOMED concepts appearing in large clinical valuesets

@Peter Williams

@Rob Hausam

Secondly could the links use the SNOMED URIs for those concept instead of linking directly into our browser application (which might change) eg http://snomed.info/id/23406007

Query from Daniel and Jeremy if the substrate could be restricted to the GPS without changing the definition of the ValueSet.

Implementation Guide

31

@Peter Williams

The Implementation Guide is now building fine. Please everyone have a look and share comments. http://build.fhir.org/ig/IHTSDO/snomed-ig/index.html

Cancer Disease Status

Carmela Couderc

http://hl7.org/fhir/us/mcode/2019Sep/StructureDefinition-onco-core-CancerDiseaseStatus.html

http://hl7.org/fhir/us/mcode/2019Sep/ValueSet-obf-datatype-ConditionStatusTrendVS.html

Query about qualifier values used. Would it be better to use < 418138009 |Patient condition finding (finding)| ? (JR suggested immediate children ie "<!" rather than descendants)

See also 373117000 |Pathology examination findings indeterminate (finding)| (child of 250537006 |Histopathology finding (finding)|)

Exemplar Profile

@Daniel Karlsson

@Jeremy Rogers

Publishing Profiles

• Wrapped by implementation guide - in this case https://github.com/IHTSDO/snomed-ig

• Value set publish to a live SI hosted Snowstorm instance. Alternatively @michael lawley has offered to host.

• Additional hosting on Simplifier (STU3, not yet R4 - January?)

• Suggestion to review work already done to ensure R4 compatibility

• Would value sets also be published as reference sets? Maintain via Refset tool and published in MLDS. Note: UK experienced substantial 'getting off the ground' effort in this area. Sweden have worked through ~10 (will request promotion of content to International Edition where appropriate).

• HL7 FHIR Registry?

• Option to have multiple profiles available at the same time using slicing.

• Chance to do some technical work at HL7 San Antonio

Options for Profile discussion:

Notes 26 Feb: UK working on pathology reporting - diagnostic / observation.

Suggestion that we try out two types of profile, both of which avoid issues of conflict between fields within the information model:

1. Where we only use the code field for clinical content (plus the administrative fields)

2. Where we restrict the code field to atomic values and all other resource fields should also be populated. Note that this does not solve the role group problem.

28 May: Plan to publish profile for the October conference (8 sessions + working between meetings. Completion for review Tues 14 October (or earlier since we'll need time to complete the IG?)

• Build implementation guide

• Setup FHIR server with relevant valusets

Tooling for profiles: Forge (.NET) is now R4

14 Jan 2020: Update from Rob on his progress with a new FHIR Template infrastructure. Required migrating/juggling what we had already built on older infrastructure. Sits under our implementation guide materials at build.fhir.org/ig/IHTSDO/snomed-ig/branches/new-template/ as Option 6: SNOMED Specific Profiles

Differential Table view shows the difference between the parent resource and our SNOMED-specific further profiling of it.

Discussion around practicalities of handling bindings where the ECL isn't very pretty, but the enumerated membership list could change very frequently e.g. a list of codes for vaccine preparations (or procedures) that are specifically relevant to some national childhood immunisation programme, and which can therefore change monthly as new vaccine preparations become available. Preferred implementation solution would be for suppliers to be able to consume ECL, however complex.

Discussion about what kind of separation should exist between the Implementation Guide (which should list things we think everybody should be doing in some certain way) and any more discursive musings that have have not reached that level of consensus or experience.

Thoughts on whether the IG should be balloted, and how to assess the maturity of any of it? Should each SNOMEDonFHIR published profile have its own (1-5) maturity metric stated?

RH: Suggestion that "published" valuesets would be read-only.

Next meeting

5

17 March 2020

Discussion of Specimin