Issue: The term of smallest semantic enitities is ambiguous.

Proposed Resolution: The term is replaced with the term business concept which is defined.

The principle that the mapping between the MDMI Semantic Element and the MDMI Business Element is not as clear as it should be.

The use of AdmitDateTime is not valid as it is ambiguous. It is not a business concept because the context is missing.

smallest semantic entities is undefined and in the same paragraph the condition of losing semantic meaning results in having only generic data-type values which is incorrect.

Issue: The example of Admit Date/Time is ambiguous. It does not provide the context; Admin DateTime to what?

Proposed Solution; Provide the content in the example which is Encounter. There the example is EncounterDateTime

Issue: extra space between "Element" and "to".

Proposed Resolution: removed extra space

Issue: The term "ToMDMISemanticElement Semantic class" is not correct.

Proposed Resolution: Removed the word semantic in front of class.

Issue: the term semantic elements is ambiguous and could be interpreted by different individuals based on their perspective.

Issue: The term Semantic Element is ambiguous as it could be interpreted as a formal term.

Proposed Resolution: The term Semantic Element has been change to MDMI Semantic Element which has a specific meaning in the context of the standard and it refers to the name of the class in the MDMI meta-model.

Issue: There is a missing closing parenthesis after LOCAL

Proposed resolution: Paren added

There is an extra space after "NORMAL"

changed two to three and shouldn't have

see issue 21.

There is an extraneous "are" in front of synonyms.

Language missing that the development he MDMI Healthcare Concept Model was an iterative process.

Issue have been entered in Issue 21

Scope described was not appropriate for the FTF.

Issue: ANF was not used as a reference Model. It was inappropriate as a reference model for the SEER content.

Proposed Resolution: Remove all references to ANF. Section 0.6.1

Issue: The concept of a datum having a temporal concept (start time and end time) was missing.

Proposed Resolution: Added the term temporal

The concept of "near-synonym" mappings can lead to ambiguities and, in healthcare, possible patient safety issue.

The reference to SNOMED CT was missing in Annex A

Issue: the term semantic element is not defined and could be interpreted incorrectly.

Proposed Resolution: This reference is to the MDMISemanticElement and the word MDMI has been added.

The FTF did not use Step 2 in developing the MDMI Healthcare Concept Model.

Present language is misleading as it is not accurate.

As this term in used in Annex B which is informative about a healthcare example, the term MDCM should be move specific.

The term semantic element can be interpreted by differently by different readers of the standard. In the MDMI standard the term semantic elements is the MDMISemanticElement in the MDMI meta-model.

Issue: extra space between Element and to

In MDMI 2.0, we added two properties in the MDMI Business Element Reference Class; the StatementContext property and the DataElementConcept property. The name StatementContext is too limiting as there are concepts in the SEER the not only as defined in a "speech act" but can also be used to define a semantic of a more broader concept of Situation.

Because of prior changes, change all references to Step 4 to Step 3. This includes sub-steps.

Needed to occur because of deleting Step 2

In Annex B which is informative.

Present Step 2 has been deleted

O

The acronym SEER is not defined in the document and the term repository was used instead of registry.

The resolution of this issue is correlated to issue # 41 because the issue and the resolution of both issues have dependencies.

Issue: The name of the Business Element in the example beginning on the bottom of page 52 was VitalSignObservationActionFocus. Based on the work of the FTF, this name is not appropriate and should not be used. The name is inappropriate because Vital Sign Observation term as the ContentConcept property (formerly the StatementConcept Property) should be ObservationActivity. The name is also not appropriate because the term for the DataElementConcept Property, formerly ActionFocus, should be ContextFocus based on advice of the SMEs in the FTF.

he resolution of this issue is correlated to issue # 42 because the issue and the resolution of both issues have dependencies.

Issue: The name of the Business Element in the example beginning on the bottom of page 52 was VitalSignObservationActionFocus. Based on the work of the FTF, this name is not appropriate and should not be used.

Proposed Resolution: The name is inappropriate because Vital Sign Observation term as the ContextConcept property (formerly the StatementConcept Property) should be ObservationActivity. The name is also not appropriate because the term for the DataElementConcept Property, formerly ActionFocus, should be ContextFocus based on advice of the SMEs in the FTF.

Presently the wording of "MDMI Business Elements are synonyms" is not correct.

having the word "are" in first sentence leading off this section could be misleading and is not proper English.

Related to Issues 41 and 42

Issue: Graph description is incorrect as the ContextConcept is not VitalSignObservation.

Proposed Resolution: Removed words vital sign.

The term "a semantic unit" is ambiguous and does not convey the concept appropriately.

The word "The" is missing before "KBS Team"

Issue: The term smallest semantic unit is undefined in the document and it is ambiguous.

Proposed Resolution: Replace the phase with the phase "business concept" which is used in the description of the term MDMI Business Element and is appropriate in this context.

the term SEER was not defined in Annex A.

The term MHDM is not defined and inaccurate.

Relationship is missing in MagicDraw diagram. It appears to have been the result of an editing error as is has shown up in all versions of 8.2 I see in document.

Issue: the present name of the association is repository.

Proposed Resolution: The name of the association should be changed to registry based on other proposed resolutions

the SemanticElement is used in the UML model

Not an issue .... original language acceptable

In the Annex B, based on the work in the FTF the term VitalSignObservationActionFocus is not valid.

The term smallest semantic unit is undefined in the document and it is ambiguous.

Issue: the term Referent Index appeared in the document. It was deprecated in the 2.0 submission.

Proposed Resolution: Changed the term Referent Index to SEER.

During the FTF process, there was one change made to the name of a property in a class and there were one or two changes made to class names to remove possible ambiguities. In addition, as different modeling tools used to develop the diagrams throughout the 2.0 process, new diagrams were generated for Section 8. At some point during the review process, it was discovered that an important relationship was missing.

Currently there are (usually) subtle differences in the XMI files created by different design tools. If runtime engines are going to successfully read MDMI maps, then the standard has to specify a standard format for the XMI for a map
Discussion:
It is agreed that the XMI format of an MDMI map must be consistent. However there are ongoing activities both within OMG and ISO 20022 to more generally define a consistent XMI standard. The MDMI FTF would like to assess the potential of these other formats before defining an XMI format standard just for MDMI.

The MDMI specification identifies the semantic unit in a message to be a Message MessageElement and MessageElementSet. The term Message Element and associated class names may be confused with the term Message Element in The ISO 20022 specification for those using the specification for financial service mapping. Since the central hub dictionary used in these mappings will most likely be the ISO 20022 data dictionary.

For better documentation, there is no reason why there should not be a description attribute for each class but this must be integrated into any table or spreadsheet UI.

we beleive the MDMI 1.0 spec has only limited ability to support data translation in the presence of structure clashes bewtween source and target data structures. We suggest ways in which this could be tackled.

These are important for impact analysis and management purposes. The following should be drawn as associations and have opposite properties:

• SemanticElement::datatype

• DataRule::datatype

• MDMIBusinessElementReference::referenceDatatype

A key concept of MDMI is that it requires a domain dictionary as a hub in its "hub and spoke design". The current specification does not associate a Message Model with a domain dictionary. If the specification is to work, such a reference will be important. Otherwise, the specification will not be clear and maps may be ambiguous.

Current text
In particular, an implementation needs to support a design-time activity with all of the steps involved in generating the conversion maps, and the runtime application of the generated maps to a source physical message in order to create a target physical message.
New text
SEE QUESTIONS & COMMENTS IN NEXT COLUMN
Rationale
Must all implementations have a design-time activity? Don't we expect to have more implementations that use the conversion maps than implementations that can create the maps?

The property SemanticElement::datatype has no type itself in the metamodel or UML diagram. According to 8.3.4 (property 4) it should be MDMIDatatype so this is arguably an editorial change.

Likewise MDMIBusinessElementReference::referenceDatatype has the same problem (missing from the model but documented as Property 5 of 8.5.3.)

However it is a fundamental problem with use of the normative metamodel and should be fixed as an urgent issue.

Figures 8.1, 8.2, 8.4, 8.8 also need updating.

Oddly Figure 8.5 is OK (indicating that it is out of date with the metamodel so may be missing other changes. E.g. the property ToBusinessElement::description is missing its datatype of String).

Likewise 8.6 is OK in that respect but is out of date with respect to the metamodel: datatypes of int and bool are shown instead of Integer and Boolean correctly used in the metamodel

Since it is derived from fieldName presumably this means that on creation fieldName is always set to null! I don’t think this effect was intended, so /isSyntacticField should have isReadOnly=true and not have a default.

In the metamodel Choice::contraint is mis-spelled. It is correct in 8.2.6 but not Figures 8.1 and 8.8.

The description and use of MDMIBusinessElementRule is completely unclear. All we have, in 8.5.7 is “some business rules may have to be specified within a map to make sure that the mapping is correct”.

Section 8.5.3 states that a Dictionary is required to have a function that returns a unique id for any use of the ‘same’ business element. However it’s not clear what ‘same’ means here – and this is key to the whole MDMI process. It would help if the operation signature and semantics were to be specified in MOF as part of the metamodel.

Section 8.6.3 makes several references to ‘source’ and ‘target’ SemanticElements. However the metamodel does not use these terms – but ‘context’ (which I presume is ‘source’) and ‘relatedSemanticElement’ (which I presume is ‘target’). The descriptions of the properties sourceIsInstance and targetIsInstance are confusing, do not make sense, and in some cases are outright wrong (e.g. “the relatedSemanticElement owns the relationship by composition”). The scope when sourceInstance=’false’ is unclear – is it all instances of the semanticElement class in the message? The known universe?

It would make sense for the ‘defaultX’ properties of MessageGroup to be optional

Property SemanticElementSet::/mesageModelname should have isReadOnly= true