Date

13 June 2019

Previous Meeting - Next Meeting

Agenda

Item / Topic	Presenter	Description
Continue review of proposed extensions to Item /wiki/spaces/BPMPLUS/pages/420970781	Stephen White (Unlicensed)	Walk through metamodel proposal
Discuss use of MDMI (if we have examples to look at)	@Ken Lord	How does MDMI help with links to ontologies and sources of truth

Participants

Stephen White (Unlicensed); @Ken Lord; Sharnita Riley; Sean Muir; @Marc Sainvil; Claude Nanjo; Ken Rubin; Robert Lario; Denis Gagne; Peter Haug

Goals

List goals for this meeting (e.g., Set design priorities for FY19):

Address any Situational Data Requirements from the Field Guide and OMG Meetings
Discussion all comments on the Item Definition update proposal
Update document as appropriate
Identify next steps

Notes (raw)

We discussed semantic references.

The current mechanism that has been included in the situational data metamodel has three attributes:

name - user defined description of the reference
codeSystem - a domain-specific enumerated list of possible targets for the reference (e.g., SnoMed, LOINC, RxNorm, etc.)
address - the link to the specific item within the codeSystem

Claude suggested a couple of changes to the names of the attributes.

from codeSystem to conceptNamespace - I changed it to conceptType to be consistent with other enumerations we have
from address to conceptURI - I made this change

Claude also pointed out that there are three places where semantic references could be applied:

on a class itself
on attributes of a class
on values (constraints) on the attributes

We have attached the SemanticReference class to the root class of the spec, thus, any concrete model objects could have a semantic reference. For an attribute of a class, that attribute would have to be an association to another class. Constraints are defined by Expressions, which can have a semantic reference. Simple type attributes probably can't have a semantic reference. If a modeler wants a reference for such an attribute, that attribute would have to be made into a separate class and have an association.

Ken Lord gave us an explanation of MDMI and how it might be used.

In general, MDMI has a capability for creating semantic references. It also could provide a target for a BPM+ element to bind to and the SEER component of MDMI can find other relevant sources of truth for that element.

In the end, we agreed that our current semantic reference mechanism, with the three properties was sufficient. Noting that the solution has to be domain-independent.

In the Field Guide (in some later version), we could provide guidance as to how to use existing healthcare-specific sources - such as using MDMI or SOLOR, etc.

Next week, if Claude is available, we can look at some of his examples.

Chat Log

1:30 PM

Claude Nanjo (to All):
A few comments on the diagram: (1) the address field should contain the formal snomed concept URI rather than the link to the browser view. (2) the address should be a URI that contains both the code and the version of the concept/value set or a separate field should be added to support version.

1:33 PM
Claude Nanjo (to All):

'Name' is tricky. Does it refer to the name of the class or the name of the concept. If the latter, at least for SNOMED, it could be either the Fully Specified Name (FSN) or a synonym of the concept within a language.

1:34 PM

Claude Nanjo (to All):

You might want to consider the following labels for the following attributes:

1:34 PM

To All:

Ok. I'll look at using the appropriate URI

1:34 PM

Claude Nanjo (to All):

name - display name

1:34 PM

Claude Nanjo (to All):

codeSystem - concept namespace

1:34 PM

To All:

The name is a user-defined name

1:34 PM

Claude Nanjo (to All):

Okay

1:34 PM

Claude Nanjo (to All):

address - concept URI

1:35 PM

Claude Nanjo (to All):

It would make it a little more general. Also the URI may not always be a navigable URL.

1:35 PM

To All:

ok

1:37 PM

Claude Nanjo (to All):

Steve, here is a reference for SNOMED. This format wil be different for different terminologies which may make a case for a separate version field in case it is not always part of the URI of the concept/value set for that terminology:

1:37 PM

Claude Nanjo (to All):

https://confluence.ihtsdotools.org/display/DOCURI/2.3+Version-Relative+Component+URIs

1:37 PM

To All:

ok. thanks

1:40 PM

Ken Rubin (to All):

I am supportive of SOLOR and note the value of that terminology binding. Want to make sure that the fundamental work we are doing around semantic binding is not prescriptive about any particular terminology.

1:43 PM

Claude Nanjo (to All):

We are really talking about (1) the binding of a structure to a concept in an ontology or (2) the binding to a set of concepts in an ontology. The former may be a special case of the latter.

1:44 PM

Claude Nanjo (to All):

The ontology/terminology could be any ontology really.

1:45 PM

Claude Nanjo (to All):

Version is tricky too. It could refer to the version of a specific set (e.g., Beta-blocker meds) within a specific ontology or to the version of the ontology itself that is being referenced.

2:04 PM

Claude Nanjo (to All):

Need to drop off but would like to talk more about the SemanticReference. I have some concrete examples we should discuss to better understand this.

Action items

Add action items to close the loop on open questions or discussion topics:

enter action item

Meeting Recording

Browser not supported