Semantic Web Health Care and Life Sciences Interest Group Teleconference -- 16 May 2017

Introductions

Claude: Cognitive Medical, work on HL7 on CIMI

Eric: W3C, RDF geek, focus on life science and helathcare

Joseph: Optum, real world interfaces and integration, HL7

Thomas: Original architect of OpenEHR, lead on spec. Created archetype formalism used in OpenEHR, based on longitudinal health record.

rob: Physician, informaticist, vocab, Hl7 co-chair, FHIR core, interest in RDF

<inserted> dbooth: Hokukahu, working on DoD healthcare data project using RDF

Collaboration across open source efforts

thomas: Maybe talk about concrete methods of collab. Another interesting point of collab would be semantically.
... From Harold Solbrig, should be looking at bridging archetype and constraint languages to formalisms. Potential transforms of each other. Currently working on hight quality constraint lang based on SNOMED, may be interesting to RDF folks.
... Get a map of tools, projects and programs.

Claude: In terms of tooling, there's a broad initiative under HSPC, libraries and modules to support std APIs in healthcare. Might be an interesting area on tooling front. Within that umbrella there's a smaller group supporting CIMI, which has adopted the OpenEHR spec for this work. Working on a Java implementation for CIMI.
... Strong CIMI community interest, but medium to longer term, and tooling in RDF space to represent CIMI logical models, using OWL, but also translation of archetype. Wondering if you have looked at this -- how to represent the archetypes in ref model as RDF.

thomas: there have been efforts over the past 15 years. One tech problem to solve: with multiple levels of models, you need to solve namespacing problem, and that stopped us before.

joseph: If the goal is to encourage open source to collab, if we could get OS projects to get involved in connectathons, that would help. Though logistics costs are a barrier. if we can lower that barrier that would encourage collab.

rob: In support of ideas mentioned. Very int in potential of RDF/OWL for use across models, including OpenEHR, CIMI, FHIR, and terminology models, and terminfo project. We're looking at using RDF/OWL to bridge FHIR and SNOMED CT. Grahame and I are now asking NLM to advance the collab work.

dbooth: Both connectathons (incl virtual) and openehr-RDF mapping are great ideas.

Mapping OpenEHR ADL to RDF

eric: What a doctor knows, constellations of observations, eg apgar score. If we had a simple CIMI apgar score, we could ask what it corresponds to in FHIR -- a set of codes, taken at a particular time.
... CIMI provides more of an ont for how to clinically represent info, wheras a single property in a CIMI model will be a whole FHIR resource, because of all of the speech-act info needed in FHIR.
... So you end up mapping one FHIR observation to a single object in CIMI.
... If I look for a body mass, there isn't a connection between two masses in CIMI. If that were connected, that would encompass a fraction of medical practice.

dbooth: What about OpenEHR?

eric: Take CIMI models in OpenEHR, and unify their properties, then map them to FHIR observations.

dbooth: Map CIMI models in OpenEHR to FHIR, and that gives them in RDF, because FHIR already has an RDF serialization?

eric: Standardize the properties first.

claude: As part of FHIR connectathon in madrid, we translated the CIMI model (which is still young). that was the first stage of CIMI. second is to develop core patterns of CIMI. In connectathon we aligned OpenEHR metamodel and constraint model to the FHIR structure def.
... Not sure the translation is perfect, but mostly able to do this.
... Because we now have structure defs for CIMI models, this already gives you a route to CIMI RDF.
... our goal is not to write CDS on FHIR. There are three ways to define attributes in FHIR (element, slicing, ____), but in CIMI there is only one way.
... And every attribute in CIMI is a first class thing in the model.
... Plan to take logical profiles, generate a bunch of them and if an instance conforms, we'll use FHIR as service interface to CDS app, but behind the service, we transform the messages to CIMI object model and our rules are written against CIMI as CIMI objects.
... This allows us to now have to write rules that deal with FHIR extensions, slicing, etc., which are ugly.
... Another advantage: you can write your rules against CIMI regardless of the transfer representation.

eric: We're both trying to use CIMI for CDS, then provide a translation into FHIR. I was dreaming about doing that by OWLifying CIMI files, but you've already done that in effect by taking the CIMI archetypes and mapping them to structure defs.
... Then use structure map to map to FHIR resources?

claude: Yes. That library is in development.
... Doing it on Grahame's colorectal example, but goal is much larger.

eric: If you have M different ways to write body mass in FHIR, and you have a bunch of places for body mass in CIMI models, you'd probably come up with a FHIR resource with a valueset. You end up doing a unification of the CIMI model by mapping it to FHIR resources, which has the same effect.

claude: would be nice to go through some examples, to show how they map to FHIR.
... If I take CIMI in its OpenEHR rep, and map to FHIR logical rep, that's one view of the model that is surfaced through underlying rep.
... But there's also a rep of the CIMI model that is independent of the phys rep.
... Want to be able to represent the logical model regardless of the physical manifestation.
... Then say that this higher level model maps to this FHIR RDF this way, and to this OpenEHR this way, but I have OWL that is independent.

eric: OWL rep will map to an RDF graph. Is it important that it not be a phys rep?

claude: Eg if I have an attribute in CIMI, in FHIR that would be an extension on a resource. In FHIR RDF you would rep that attribute as an extension. But in CIMI RDF, I'd like to represent it as a property on a class, and not have to worry about the fact that it is an extension in FHIR.

Thomas BealeMaking FHIR work for everybody - https://wolandscat.net/2015/12/20/making-fhir-work-for-everybody/

11: 37 AMThomas Beale'openEHR' in this conversation refers to the openEHR archetype formalism
... 38 AMThomas Bealehttp://www.openehr.org/releases/AM/latest/docs/index
... 38 AMThomas BealeBMM = basic meta-model (= readable replacement for XMI for data aspect of object models) - http://www.openehr.org/releases/BASE/latest/docs/bmm/bmm.html
... 39 AMThomas BealeThe BMM format is used to represent object models (openEHR, CIMI, CDISC, ...) for use with archetype tools.

thomas: When you say OpenEHR, I think you mean the ADL.
... There's a level of mapping that must take into account the object model, and a level that must take into account things like apgar or discharge summary, etc.
... We already do a whole method of portable CDS queries in OpenEHR, using AQL -- a SQL structure where inner structure is paths on containment structure.

Thomas BealeThe BMM format is used to represent object models (openEHR, CIMI, CDISC, ...) for use with archetype tools.

thomas: You might want to look at how we did that.

Example: [[

let $systolic_bp="data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude" let $diastolic_bp="data[at0001]/events[at0006]/data[at0003]/items[at0005]/value/magnitude" SELECT obs/$systolic_bp, obs/$diastolic_bp FROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1] CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1] WHERE obs/$systolic_bp>= 140 OR obs/$diastolic_bp>=90

]]

http://www.openehr.org/releases/QUERY/latest/docs/AQL/AQL.html#_further_discussions

dbooth: Merits of the mapping route from CIMI as ADL to FHIR, versus a more direct mapping route?

thomas: Clinical model has something like BP, with children systolic, diastolic. And another tree will have something like body position. As a mind map or tree, you'll have those things -- a typical tree. The instances in the ref model will be things like element/classes, etc. If we forget about the fact that a BP node is an element, and concentrate on it being a systolic BP node, that gets you out of trying to map the underlying types like cluster/element

/quantity to what FHIR uses. IN OpenEHR we have types for different things. But if we stick to one level of modeling, it will make mapping into RDF a whole lot easier.

scribe: The killer we had was trying to map both levels, with the connection between them. But probably not so useful in RDF.

eric: Only really care about the data type. But how deep do the trees get?

thomas: ECG is 4-5 levels. Microbiology resource ...
... You can get easily 6 levels deep. There are major categories of clinical data. Most of lab lives in a particular complexity category. Micro tends to be big trees. Orders tend to be messy structures. Everything is its own structure -- no universal characterization. Long tail.

eric: These things have a class hierachy that constrains their structure. But the things that constrain microbio result, if you wrote just the info into a structure, rather than a derivation of the data types, would that be bushy?
... If I've got two attributes in CIMI, it likely will be two differnet observations in FHIR. But if I have a CIMI attribute that is composed of two different things, the speaks of act-relationship things that don't exist in FHIR.

thomas: In OpenEHR ref model, we have a sophisticated model with history of events. If you have 100 BPs, you'll have a history node, 100 events, each tree with a BP. Normal ways of querying it, and putting it into Java. hard to map into FHIR observation We gave up.
... i'm working 1/3 at Intermountain. They're trying to map their internal structures to FHIR, and it's turning out hard. Mapping isn't easy for lots of data.
... "Making FHIR work for everybody - https://wolandscat.net/2015/12/20/making-fhir-work-for-everybody/" caused a flame thower reaction from FHIR folks. :)
... If you have a modeling env, it has its own semantics, and you interpose FHIR, you've instantly got a problem because yo have two things trying to impose their own models.
... you wouldn't use FHIR if you were using CIMI and you knew your own semantics and structures.
... Mapping to FHIR ain't gonna be easy.

<scribe> ACTION: Eric and Claude to bring example for next week [recorded in http://www.w3.org/2017/05/16-hcls-minutes.html#action01]

<trackbot> Created ACTION-86 - And claude to bring example for next week [on Eric Prud'hommeaux - due 2017-05-23].

<scribe> ACTION: David to move next week's call 1 hour earlier [recorded in http://www.w3.org/2017/05/16-hcls-minutes.html#action02]

<trackbot> 'David' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., dderour, dhansen2, dnewman, dshotton).

- DRAFT -

Semantic Web Health Care and Life Sciences Interest Group Teleconference

16 May 2017

Attendees

Contents

Introductions

Collaboration across open source efforts

Mapping OpenEHR ADL to RDF

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output