Rob Hausam

Recording + Notes.

Rob Hausam

• 2020-01-07 - SNOMED on FHIR Meeting (TS)
• 2019-12-17 - SNOMED on FHIR Meeting (TB)

Jane Millar

HL7 Sydney, February. Business Meeting Agenda: https://hl7.sydney/programs.php

Christmas Break: Skip 24 + 31 Dec.

• Peter G. Williams document SLPG counter proposal - basically agreed that ValueSets are not FHIR specific and they'd like to use the more general http://snomed.info/<resource type>/<resource name>
  

The SPLG workgroup discussed this

http://snomed.info/valueSet/GPS

Update this causes a problem in the tooling as it demands a capital V in ValueSet.

• Peter G. Williams discuss with Lloyd MacKenzie. Also specifying a different terminology server for expansions. Also output/qa.html should we start again from a template project.
  

http://snomed.info/fhirStructureDefinition/example

Update 3 Dec: Publisher tooling has specific requirements around URI construction that isn't compatible with the proposed URI standard.

• Daniel Karlsson to supply code line(s) that's causing the problem to Rob Hausam
  

Jane Millar

• Peter G. Williams progress 4 step actions from 27 October meeting

Update 3 Dec: Draft of notes arising from KL and subsequent SNOMED on FHIR meeting being reviewed. Intention to reach out to Grahame and Keith to discuss further. Amber mappings outstanding, but value of partial implementation questionable so need to discuss before further work is done. RH has given KeithC an update.

Peter G. Williams

Did we conclude on the best approach(es) for semantic overlap between fields as discussed in Terminology Binding

Update: Option 4 seems the most elegant - "BodySite must always be a specialization or self of finding site" although BodySite is an easy example since the mapping to the SNOMED concept model (finding site) is well understood. It would not work for Condition.Status where resolved/remission is not represented in attribute values.

Update 17 Sept: If we were to express ValueSets for profiles using Refsets (which this group would have to curate and publish) then National Centres could add to those refsets using their own module.

Update 15 Oct >2 issues:

1. We're still seeing only the differential in the profiles, no option to view the snapshot
2. The link from profile to a ValueSet uses a slash (eg http://build.fhir.org/ig/IHTSDO/snomed-ig/ValueSet/bodyheight.html - does not exist) and navigating from the ValueSet itself uses a dash (eg http://build.fhir.org/ig/IHTSDO/snomed-ig/ValueSet-bodyheight.html )
3. Only the first element in the differential is being displayed. The page appears to cut off early. See http://build.fhir.org/ig/IHTSDO/snomed-ig/StructureDefinition-AllergyIntolerance-SubstanceFocused.html

Rob Hausam Check with Lloyd McKenzie and Eric Haas if their two frameworks have been fully

Procedure Expert assistance for CarePlan:

• Jane Millar please mention our discussion to Zac Whitewood Moores (NHS) and provided with dial in details to attend a Terminology Binding group call
• Rob Hausam please mention our discussion to Michelle Millar (HL7), Stephen Chu (AU), Emma Jones.
• Read Workflow https://www.hl7.org/fhir/workflow.html

Procedure (not completed 3 Dec) followed by Care Plan

KG: procedure code concern about overlap with reasonCode.

Jeremy Rogers

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

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

• Peter G. Williams Fill in current values and parents

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

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

• Peter G. Williams discuss Rory Davidson
• Peter G. Williams re-run tooling to include existing profiles in appropriate hierarchy.

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?

• Daniel Karlsson to try loading existing Allergy Intolerance profiles into Forge R4. The STU3 profiles loaded fine in Forge R4 as just STU3 profiles. There are almost no changes between STU3 and R4 for AllergyIntolerance, so by manually changing the XML files from "3.0.1" to "4.0.0" the files showed as R4 profiles with no errors displayed. Files uploaded to profile page.
  
• Rob Hausam to take Observation questions to OO group.
  

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

Daniel Karlsson

Revisit any outstanding questions on Allergies.

External publication of v0.1 of the AllergyIntolerance resource

Vital Signs Profile of Observation Resource

Jeremy's work to compare Vital signs profile and SNOMED Subhierarchy - issues with eg blood pressure. Complex expression constraints available which cover the use of observables by the NHS(UK). Mapping to LOINC codes.

See Spreadsheet attached to: SNOMED on FHIR Meeting (TB) - Tuesday 21 August 2018

Issues / Discussion :

• Normative vs. descriptive purpose - 1, 2, or 3 profiles?
• Unresolved modeling issues

2019-08-20:

Update of the Vital Signs panel binding page.

Discussion about the Vital Signs FHIR profiles and how to profile those to SNOMED profiles. We are going to create SNOMED profiles on the specific FHIR Vital Signs profile (e.g. Heart rate) and declare conformance with a generic SNOMED Vital Signs profile.

Daniel Karlsson

These two separate resources existed in the FHIR 3.0.1 Spec. Rob Hausambut have been removed in 4.0 and replaced with ServiceRequest

http://build.fhir.org/servicerequest.html → ServiceRequest

Questions:

• What determines which FHIR resource to use: the location of the data item in the sending system’s information model, or the semantics of the particular code regardless of where it was found? Some hybrid of both?

• If the resource to be used is determined at least partly by the location in the sending information model, how does a requesting system cope with the fact that different implementations (or different users of the same implementation) both can and do secrete essentially the same clinical info in very different parts of the host information model?

Need to revisit the original questions raised in this group wrt the two separate resources of yore, and consider whether the same issues persists wrt the new single ServiceRequest resource.

28January 2020