See below...Dan
Kashyap, Vipul wrote:
You are correct that classes in HL7 may have sub-classes.
[VK] I think the interesting question is whether these classes are
metaclasses, i.e., whether they belong to layer 1 or whether they
are in layer 2.
<dan> Classes and subclasses in a UML model cannot represent "different
layers" in your layered hierarchy...a subclass in a UML "isa" hierarchy
"is" the same class as it's parent, it is just constrained by an
additional set of attributes. />
To be more specific, by definition, once a class in HL7 is
instantiated, the classCode and the moodCode can never be changed
throughout the lifecycle of the instance.
[VK] Was wondering if instead of having multiple class codes and
mood codes, if it were possible to actually represent them as
individual classes?
I beliebve the BRIDG model follows this approach.
<dan> Correct. There is no semantic difference when representing the
classCodes and moodCodes as separate classes in UML than with
"superloading" the current classes with classCode and moodCode
attributes. The classCode and moodCode attributes in the RIM are simply
a method for extending the model through vocabulary manipulations. The
BRIDG model elected to not use classCode and moodCode in the UML for two
reasons (one most important reason is that the BRIDG is a "pre-RIM
mapping analysis model" for the domain experts. A later mapping of the
BRIDG to the RIM for purposes of use in documents, services, and
messages would collapse the various classes into the appropriate
moodCodes and classCode representations. />
Therefore, operationally, the HL7 RIM ontology is definitively
declared when the instance is created.
[VK] This is interesting, because typically one first creates
ontologies and then instantiates them.
<dan> In small domains, that is true. However, in large domains, where
information models and terminology model techniques are integrated, the
"small domain" techniques provide huge amounts of ontologic
combinatorial explosions. />
Further granularity in the semantic meaning of the instance is
declared in the "code" attribute, which contains a series of
fields: Original Text;
mapping of orginal text to an expression from a published
vocabulary (e.g. SNOMED);
[VK] If we view SNOMED as an ontology, this effectively declares
that instance to be an instance of the class described by the
SNOMED expression.
<dan> Correct...The instance must be simultaneously an expression of any
hierarchies and other associations in SNOMED and of any hierarchies and
assocations in the HL7 RIM. />
The essential rule of Term Info in HL7 is that none of these
parts of an "expression" may contradict the other, although each
part may contribute to the total semantic meaning of the
"expression." It is also important that the semantic meaning of
the "class" within its hierarchy in the RIM and the meaning of the
published code within its hierarchy in the published coding system
not contradict each other. However, much work remains in order to
remove contradictions in the hierarchies of all these ontologies
when used together.
[VK] This is exactly where having a common representational
formalism and framework to represent information models and
terminologies would be very useful!
<dan> Ergo...The Term Info project. Should this group join efforts with
HL7 TermInfo, since both groups are trying to achieve the same ends? />
(As noted earlier, the RIM is a compromise between the very
abstract, raw, models like ASN.1 or EAV and the more concrete
models often found in database schemas for a narrow domain.)
[VK] This sort of validates my opinion that it is more of a
meta-model, i.e., it belongs to Layer 1.
<dan> Correct. The RIM in your model belongs in Layer 1 and the domain
specific, derived models from the RIM, e.g. Clinical Statement Pattern,
implementable RMIM, CDA,, service models, belong in your Layer 2. />
What are called Archetypes in OpenEHR correspond to HL7 structures
called Care Structures in HL7 Patient Care. These "Care
Structures" represent aggregations of classes used to represent a
medical record construct such as a problem list or care plan. Care
Structures typical provide the "context" to very granular
concepts. For example, by itself, the term "diabetes Type 2" is
merely a concept. Once diabetes is placed within a problem list
care structure for a specific patient, the "sense" of what is
meant by "diabetes Type 2" in a particular assertion of the term
is more clear.
[VK] Would be interested in undertanding the semantics underlying
the "Care Structure"? Maybe one could model specific classes for a
Problem and a Care Plan and may be Diabetes Type 2 can be a
subclass or an instance of the Problem MetaClass or Class. Just
throwing out some alternate modeling approaches ... Would like to
know the fallacies if any.
<dan> When the SNOMED code for diabetes is used in the Observation class
in the RIM, one is creating an instance of the combined relationships
found in the RIM and in SNOMED. You aren't really adding any new
modeling approaches here. />
In HL7 templated CDA documents (like CCD), templates are used to
bind to a schematron conformance test that validates that a
certain XML Care Structures (again, aggreations of classes,
attributes, and vocabulary) do not extend beyond a specific set of
allowable constraints. Therefore, templates don't really add to
semantic meaning. However, the do enforce semantic meaning, and
therefore support improved interoperability.
[VK] Agree CDA documents do not add to the semantics. We are more
interested in the information model or R-MIM underlying the CDA.
<dan> you missed the point that templateID is part of the RMIM of the
CDA. The templates are used to enforce the combined information model
and terminology models conformance statements. />
I hope this long-winded description helps in this "multi-layered
Knowledge Representation" discussion. How one classifies the
concept of "context" for a given concept, or the concept of
"conformance testing the constraints on an aggregation of
structure and vocabulary" in a multi-layer Knowledge
Representation is not clear to me.
[VK] Some thoghts on this are as follows:
- A context can be typically represented as a MetaClass or a Class.
<dan> Context for an instance of a class is represented by all the many
class associations that exist for an individual class instance.
Computationally, in an EHR, the context extends to anything previously
recorded in the EHR as well as all the associations to references
outside of the EHR, e.g. knowledge links to country information,
terminology information, basic science information, facility
information, etc. Don't think too small on context! />
- A given concept can be a class which can be represented as an
instance or a sublcass of the context or associated with a context
through well defined
semantic relationships
- Can you present a concrete definition of conformance? I am
assuming for the purposes of this discussion Conformance =
Semantic Subsumption.
Assuming that we have represented concepts and aggregation
structures in a common formalism, conformance would correspond to
checking
for subsumption.
<dan> There are many kinds of "conformance." One basic example is
testing the contents of a data entry field before committing the
contents to the database to make sure the contents have the right kinds
of characters, e.g. numeric, alphabetic, etc. Schematron testing in CDA
tests the conformance of the XML structure and the codes and other
values within the XML structure (think terminology) to make sure the
wrong codes aren't used in a specific XML structure. I'm sure that a
broader definition of conformance can be created that includes things as
basic as character validation and as complex as information
model/vocabulary model validation. />
Obviously this needs to be further fleshed out and the best thing
would be to take a concrete example and work through the various
issues you have raised.
Look forward to feedback.
Thanks,
---Vipul
The information transmitted in this electronic communication is intended only
for the person or entity to whom it is addressed and may contain confidential
and/or privileged material. Any review, retransmission, dissemination or other
use of or taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received this
information in error, please contact the Compliance HelpLine at 800-856-1983 and
properly dispose of this information.
