There are a bunch of spacing errors (6.4.1 has just one of these) in the document. Word’s grammar checker will find them.

Remove extra spaces

as above

In the XMI file there is a bunch of weird DataType with blank names that are not used.

Fix datatype issues

as above

OWL seems essential, but there is nothing mentioned about OWL until 8.5.3 and no other references.

Add OWL to glossary

Add OWL to glossary

as stated

Add comments to red-line document

as above

as above

Clarify graphics as able

Unable to change some graphics that are too big to fit a standard page legibly.

as above

Make corrections for loading into Cameo

as above but there is no access to Cameo

List of contributors incomplete

Add missing contributor name

Gargi Gajjar contributed to the Finalization Task Force. Her name was added to the list of contributors

The term Admit Data Time used in the example is not correct because Admit Date Time has more syntax than it just in the ADT A01 file.

Add the term "message" to further specify data use

Change " in a HL7 V2.8.2 ADT-A01 there is a field representing Admit Date/Time." to "in a HL7 V2.8.2 ADT-A01 message there is a segment that has is a field representing Admit Date/Time". The change specifies the structure of where a data item of Admit Date/Time would be located for those familiar with HL7 V2.8.2 message model.

The term SNOMED CT is used in the Annex C and it is not included in Annex A

Add the missing definition for SNOMED CT

The definition of the term was added. "The SNOMED CT is a systematically organized computer-processable collection of medical terms providing codes, terms, synonyms and definitions used in clinical documentation and reporting"

The term "MDMI Semantic Element" is incorrect because it represents a proper name and its class name, MDMISemanticElement, should be used.

Change "MDMI Semantic Element" to "MDMISemanticElement" (no spaces)

The term "MDMI Semantic Element" is the proper name of the class MDMISemanticElement in the specification and therefore the term has been changed throughout the document to MDMISemanticElement.

See attached document for specific locations.

The examples provided for the term datum were missing a key concept of time.

Reword sentence to clarify definition

The concept of time as a datum was missing. Change "an atomic datum, such as a name or measurement value" to "an atomic datum, such as a name, measurement, or temporal value"

The file went missing but was recovered. It appears that the recovery munged some of the text.

Reviewer comments:
Lots of elements are strangely duplicated, like Bag, SemanticElementSet, Node, SimpleMessageComposite, ToBusinessElement, MessageSyntaxModel, etc. As I recall, this was one of the files that was lost. I think the recovery was an implosive mix.

Corrected file obtained

File without corruption replaces the one there

The description of the Step 2 process in Annex C for developing the MDMI Healthcare Ontology is incorrect.

Remove ANF reference

ANF was not used as a Reference Model. All sentences after the first sentence in Step 2 were removed.

In the first line:
The goal of the MDMI standard is to provide a declarative, model-driven mechanism to perform message data...

The word "message" is in subscript.

Changed font type of word

"Message" changed from subscript to normal text

No attestation in section 3, Normative References

OWL is mentioned in the document but has no further reference

Added missing reference

Provided link to W3C site for OWL.

Text for the section is missing. It only contains an irrelevant caption.

Added missing diagram

Added diagram for MDMIDatatypes, DataRules - Abstract Syntax

Should this be identified as an RDF/OWL file?
I did find documentation in the RDF file, thank you! However, it might not be aligned with your specification. For example, hasAuthorPersonLegalName is in the RDF, but not in the specification or XMI.
Looking at the RDF itself, I find the following at the beginning that I have questions about:
                <!ENTITY dct "http://purl.org/dc/terms/">
                <!ENTITY mdmi-gsm "https://www.omg.org/spec/MDMI/MDMIGenericStatementModel/">
                <!ENTITY owl "http://www.w3.org/2002/07/owl#">
                <!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#">
                <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#">
                <!ENTITY skos "http://www.w3.org/2004/02/skos/core#">
                <!ENTITY sm "http://www.omg.org/techprocess/ab/SpecificationMetadata/">
                <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">
 
Questions:
1. Should these be in normative references in the spec?
2. What is the reason for the choices in these standards (annex?)?
3. Except for the minor reference to OWL, there is no other mention of RDF and these related standards. I’m assuming this is important information that is missing from the specification, given that this is a normative machine-readable file.

No changes necessary

Use of RDF is informative not normative

You are burring the lead in the specification scope. I suggest starting with the Scope section with the remainder of the second paragraph: “The goal of the MDMI standard is to provide a declarative, model-driven mechanism…” The remainder text can then follow as background. A better scope will help with adoption as you will be leading with what the spec is to do.

Clarify scope

Change to:

The goal of the MDMI standard is to provide a declarative, model-driven mechanism…

6.4.2 “360  View of diverse IT eco-system” seems like an odd choice for a paragraph title. There is no mention of 360 in the body. Perhaps this is better discussed as enterprise-level definitions and reuse.

Change title of the paragraph

as above

as above

Add normative references

for OWL and RDF

6.2.1.1 Please define ‘conceptsentities’ or fix the typo (missing comma).

Put a space between the words

as above

No references are made to the normative machine-readable,  no RDF/OWL hook to hang your propeller cap. OWL is not defined or discussed.

No changes necessary

Files are informative not normative

as above

No changes necessary

File is required by OMG process

The name, VitalSignObservationActionFocus, in Annex C is inaccurate and the graph description of the correct term is inaccurate.

Remove "Action" from "VitalSignObservationActionFocus" and "ActionFocus"

In the example in Annex C, change the term VitalSignObservationActionFocus to VitalSignObservationFocus. In addition, change the graph description of the DataElementConcept to Focus.

The expression "are synonyms" is incorrect. There are other possible conditions that may cause the condition besides the MDMIBusienssElements being synonyms.

Change statement from definitive to possible

An example of a different condition is that one MDMIBusinessElement has an incorrect specification of its StatementContext or DataElementContext. Proposed change is to change "are synonyms" to "could be synonyms".

In the standard, each MDMISemanticElement must be unique. Having "near-synonyms" with the same MDMISemantic Element violates this principle.

Remove the sentence

Deleting the sentence "In effect, they define the domain of “near-synonyms” that are allowed in a mapping." addresses this issues

There has already been introduced a term in the document for "semantic unit" and it should be used.

Clarify use of "semantic unit"

The term data item has been used previously. Change "to expedite the insertion or extraction of as little as one semantic unit data item of a message" to "to expedite the insertion or extraction of as little as one data item of a message"

With the additional functionality of providing a StatementContext and DataElementConcept to the MDMI Business Element Reference Class, the term registry does not sufficiently express the nature of the SEER.

Change "Registry" to "Repository

same

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.

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

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