20:00 UTC on Tuesday 28 January 2020 - 90 minutes.
- Bindings to FHIR Clinical Resources (e.g. value set bindings)
|Owner||Notes & Actions|
|1||Welcome and introductions||5|
Recording + Notes.
Summary of previous week (TS) and previous TB
Upcoming events: 2 - 3 Connectathon Feb 2020 HL7 Sydney (followed by Business meeting)
We will skip 4 February TS during HL7 Meeting and re-jig the meetings to bump TS to the 11th.
Terminology Services Track Proposal: https://confluence.hl7.org/display/FHIR/2020-02+Terminology+Services+Track
Business Meeting Agenda: https://confluence.hl7.org/display/VOC/Feb+2020+-+HL7+Sydney+WGM+Meeting+Agenda+for+Vocabulary
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
|4||URI Standard update||2|
The SPLG workgroup discussed this
Update this causes a problem in the tooling as it demands a capital V in ValueSet.
Update 3 Dec: Publisher tooling has specific requirements around URI construction that isn't compatible with the proposed URI standard.
|5||Free Set Response||1|
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.
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:
Rob Hausam Check with Lloyd McKenzie and Eric Haas if their two frameworks have been fully
Use ECL in compose in the ValueSets where possible. More consistent, more elegant, more expressive, more powerful, more readable (descriptions can be added). However, also fewer terminology servers might support profile, adds complexity. Complex value set definitions will give complex (and hard to read) ECL, but likely also complex and hard to read compose structures.
Procedure Expert assistance for CarePlan:
Procedure (not completed 3 Dec) followed by Care Plan
KG: procedure code concern about overlap with reasonCode.
The status element was discussed and compared to SNOMED CT context values for action, e.g. as in this UK reference set: http://diseasesdatabase.co.uk/snomed/refset_metadata.aspx?id=999000081000000105
In implementations, other kinds activity status values are relevant, and agreeing on a standard set of activity status values can be a challenge.
See updates here: Observation binding
|9||Cancer Disease Status|
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)|)
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:
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?)
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.
Revisit any outstanding questions on Allergies.
External publication of v0.1 of the AllergyIntolerance resource
|12||Vital Signs||15||Daniel Karlsson|
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 :
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.
For reference, the UK vital signs profiles are available here: https://fhir.hl7.org.uk/STU3/StructureDefinition/CareConnect-VitalSigns-Observation-1
The Vital Signs (misnomer...) profiles contain additonal slices on Observation.code adding SNOMED CT bindings on top of existing magic number/LOINC bindings. No other constraints have been added to the profiles. Descriptions or notes about any terminology binding overlap issues should be added, e.g. for the bodySite element of the core body temperature profile.
v3.4.0 (publication Aug 19?)
These two separate resources existed in the FHIR 3.0.1 Spec. Rob Hausambut have been removed in 4.0 and replaced with ServiceRequest
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.
18 February 2020