Versions Compared

Old Version 2

changes.mady.by.user Stephen White (Unlicensed)

Saved on

compared with

New Version Current

changes.mady.by.user Stephen White (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

Date

13 June 2019

See Meeting Recording

Previous Meeting - Next Meeting

Agenda


Item / Topic

Presenter

Description

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

Participants

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)
TBD
:
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

Anchor
Meeting Recording
Meeting Recording
Meeting Recording

View file
nameOMG Field Guide Use Case Working Group-201906132005.mp4
height150

...