Jun 13, 2019 - Use Case Working Group
- Stephen White (Unlicensed)
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)
- 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
- 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.
Action items
Add action items to close the loop on open questions or discussion topics:
- enter action item