Terminology Service

Assumed terminology service API for openEHR - FHIR / IHTSDO / CTS2 (LexGrid etc)?

DK: no easy answer...

FHIR TS has some redundancy but can process SNOMED expressions

LOINC querying - no stds

Ian: some addition of 'groups' to coalesce same analyte+tissue combinations.

Consider FHIR as a starting point - multi-terminology support.

AQL use of Terminology

Embed SNOMED constraint language expressions in AQL queries?

Terminology Binding

Older notes from openehr-technical

Recently we discussed terminology bindings. We probably still have not got them right, but we don't have a model of what we think they should be. I posted a quick idea of a possible more structured version:

term_bindings = <
	["snomed_ct"] = <
		["/data[id3]/events[id4]/data[id2]/items[id26]"] = (SIMPLE_BINDING) < 
			target = <http://snomedct.info/id/169895004> -- Apgar score at 1 minute 
			notes = <"some notes">
			min_version = <"2017-02-01">
			etc = <"etc">
		>
		["id26"] = (CONSTRAINT_BINDING) < target = <"71388002 |Procedure| : 405815000 |Procedure device| = 122456005 |Laser device| , 260686004 |Method| = 129304002 |Excision - action| ,405813007 |Procedure site - direct| = 1549700l6 |Ovarian structure|"> min_version = <"2017-04-01">
			notes = <"some notes">
			etc = <"etc">
		>
	>
>

I noted that the right hand side of a binding can be a few different things, each of which would be accompanied by various meta-data, including:

a single concept code
a single code or other id referring to an external value set in an external terminology (in SNOMED it is a SNOMED code; for e.g. ICD10, there is no standard that I know of)
a composition expression that refers to a more refined concept
possible a constraint expression that locally determines a value set intensionally, to be resolved by application to the Terminology service.

I'd rather avoid the last, because of the brittleness of intensional ref-set query syntax expressions. In any case, we need a better idea of what meta-data are needed. E.g.:

something to do with (min) version of terminology required for the reference to be valid
something to do with purpose?
other notes - a tagged list of basic types?

I would like to get a better idea of the requirements.

DK comments: possibly better to avoid value set defs in archetypes, particularly for multi-terminology support. Have to deal with different versions of constraint def / binding.

important point - data instances (based on templates) should look the same, regardless of whether terminology binding is inline or not.

TB: should openEHR provide a service to maintain small value sets.

Ian - need 'package management' - archetypes + templates + value sets - how to define versioned bundles?

DK: currently only SNOMED release based; unit of distrib = module; e.g. national extension + intl release; doesn't help with archetypes / templates;

possibly extend SCT URI scheme to cover other artefacts and bundles.

check FHIR profiles for different terminologies for URIs.

Expression resolver strategies

For expressions embedded in AQL queries : only want to resolve to a flat list to test membership; may be on client or server or cache;

For terminology choosing in UI, we need to resolve to structured, not flat lists, i.e. with IS-A relationships intact.

Mappings

Browser not supported