1

Welcome & apologies

@Daniel Karlsson

2

Conflicts of interest

• None stated

3

Minutes from previous meeting

@Daniel Karlsson

4

Scale Observables

@Jim Campbell

@Jim Case 

@Former user (Deleted)

@Steven Dain

• Scale/score Observables for anesthesia and clinical medicine

• The Anesthesia CRG has submitted a paper to the EAG describing some of the problems of SNOMED in relation to modeling of assessment scales (see )

• See attached presentation for discussion this date: "Clinical Scale Scores20210301"

• Deliverables: 

  1) Anesthesia CRG will proceed with proposing FSN/PT for ASA scale scores as qualifier, including definitions of each value, and proceed with obtaining permission from ASA for publication

• 2) Anesthesia CRG will proceed with proposing FSN/PT for Mallampati scale scores as qualifiers, including definitions of each value, and proceed with obtaining permission from authoritative source for publication

• More complicated use case of Glasgow Coma Scale was discussed briefly to prepare for detailed discussion next meeting.

• Deliverable:  3) Meeting attendees to consider special use case of supporting calculations for Glasgow Coma Scale Total Score from three Ordinal component scores for discussion next meeting

2021-04-19:

Assessment scale hierarchy requirements https://docs.google.com/presentation/d/1b_vmIY7IFjfYuaXd6H-c5GxijEyaFj75wbvreZ4_fkA/edit?usp=sharing

@Former user (Deleted) provided background to the use cases provided by the Anesthesia CRG.

A requirement to represent the scale points of the assessment scales when they correspond to findings, but question is who is responsible for the association between clinical findings in general and scale points. 

There are two use cases which are slightly different: (1) the requirement to be able to use SNOMED CT to encode contents of the EHR and then use that to "populate" assessment scale components, and (2) the requirement to be able to store and communicate results of application of the assessment scales per se using SNOMED CT concepts. Moving from (1) (i.e. a SNOMED CT encoded EHR) to (2) (SNOMED CT encoded assessment scale representation) is non-trivial. There is a discrepancy between the recording of clinical findings (more granular) and the recording of values for assessment instruments (discrete buckets). The challenge is matching the clinical findings to the appropriate value in the assessment. This is not (necessarily) something that is handled within SNOMED. However, assessment scales are also sometimes used as the primary documentation.

2021-05-17:

Some example existing scale observables were discussed in relation to the subsumption expected from any work done to define scale observables. E.g. the Apgar component observables are not subsumed by any observables related to heart rate, respiration, skin color etc. To contrast, pain score observables are subsumed by other pain observables. The group agreed that being able to group scale observables by what the scales assess is a desireable feature of any solution.

2021-06-21:

@Jim Campbell made a presentation at the Anesthesia CRG call about representing assessment scale observables. A key missing piece is the representation of scale points (ordinals) beyond their scale value (e.g. 1, 2, 3, ... for GCS) to include the actual clinical meaning. For GCS, neurologists' input will be sought. Experimentation with the CRG include more complex scales will help produce a decision paper for the EAG.

2021-08-02:

Slides

Scale observables could, when they correspond to e.g. physiological or otherwise established observations, be represented as <base observable> : | Technique | = <the assessment scale>, | Scale type | = | Ordinal|. See example in slides.

IP issues might prohibit the representation of some assessment scale components: Proprietary Names and Works

5

Parameters (previously "Settables")

X

The issue of representation of target observables has been raised again in a Jira ticket.

The question the group needs to answer is whether targets and observables need to be seperated or to be kept apart. In practice, is there a requirement to query for both observables and "settings" alternatively is there a risk in having targets and observations mixed up?

One solution would be to (minimally) add a primitive parent "setting observable" (or just "setting") to all targets, settings, parameters, etc. in the current observables hierarchy.

2020-09-21:

@Suzanne Santamaria shared with the nutrition group, will share with @Jim Case

2020-11-16:

Release of content postponed to July 2021.

2020-12-14:

If time permits, go through comments from Jim Case.

See this page

2021-02-08:

"Parameter" is a better name for the super concept of all observables determined by decision.

Proposed definition "A parameter is an entity whose value is determined by decision of an agent as opposed being observed in reality. Examples of settings are goals or targets, equipment settings, and treatment parameters"

Subtypes of | Parameter | will be added including Goal/Target, Device setting etc.

Reusing 252116004 | Observation parameter (observable entity) | might be risky as it might already be in use plus we could at the meeting not determine its meaning.

2021-04-19:

Agreement on separating "observed" observables from target observables (possibly calling those observables might be a misnomer). 

Implementation of the separation needs to be discussed. As proposed, the separation depends on there being primitive stated parents for non-parameter observables, but the more concepts are fully defined, the greater the chance of a fully defined observables subsuming a parameter. 

2021-05-17:

"Parameters" now in International daily build: https://dailybuild.ihtsdotools.org/?perspective=full&conceptId1=1156597009&edition=MAIN&release=&languages=en

1156597009 | Parameter (observable entity) | now has 129 concepts subsumed. The definition of Parameter was reviewed,

There is still an issue where fully defined Observable entities might subsume parameter observables. 

6

Editorial Guide

@Daniel Karlsson

A review of existing Editorial Guide for Observables is due. Some pages seem dated. Comments to pages are done in a Google Doc here. https://docs.google.com/document/d/1dfDd-K4hP425O_7poTA8roZ_fkAKQj0l458LGob1FBM/edit?usp=sharing

• @Former user (Deleted) terming guidelines needs updating

• Many pages seem dated, e.g. Relationship between Observable Entities and NPU codes, Representing LOINC Terms with the SNOMED CT Observable Entity Model, Test Observable Entity Naming Conventions

• Wording of guidelines could be lighter on the jargon

• Examples from existing Observables as well as from the LOINC tech preview could be added

• Process for approval of changes discussed

2020-12-14:

Templates for quality and process observables.

Particularly, the boundary between quality and process observables might need discussion (presentation). There is (at least) a potential for inconsistencies unless there are clear guidance on when to use quality and process patterns respectively as there 

@Former user (Deleted) what about e.g. clotting time?

Open

2021-01-18:

Comments from SNOMED staff to the EG Google Doc was discussed. Comments were added to the document. "PG agreement" as a comment in the document indicates that the project group agreed to the comment above.

2021-06-21:

Changes made in the document

2021-08-02:

Changes made and accepted by the project group. Some examples to be added concerning Inheres in and Direct site.

7

E2O

@Jim Campbell @Daniel Karlsson

Report

8

Next meeting

@Daniel Karlsson

Next meeting is 2021-08-16 20.00 UTC

• Scale observables

• E2O discussion