W3C home > Mailing lists > Public > public-hcls-coi@w3.org > April to June 2008

RE: Multi-layered Knowledge Representations for Healthcare (was RE: An argument for bridging information models and ontologies at the syntactic level)

From: Kashyap, Vipul <VKASHYAP1@PARTNERS.ORG>
Date: Wed, 11 Jun 2008 00:28:29 -0400
Message-ID: <DBA3C02EAD0DC14BBB667C345EE2D1240294894D@PHSXMB20.partners.org>
To: <dan.russler@oracle.com>
Cc: "Samson Tu" <swt@stanford.edu>, "Elkin, Peter L., M.D." <Elkin.Peter@mayo.edu>, <public-semweb-lifesci@w3.org>, <public-hcls-coi@w3.org>
 

			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. />
	[VK] Agreed. However UML supports the metaclass stereotype which can be
used to represent Layer 1 classes. The issue is whether a blood pressure
observation class is an instance of the observtion metaclass; or whether blood
pressure observation  class is
	a subclass of the Observation class in HL7.

			 
			 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. />
	[VK] Appears to me then that the reason for introducing the mood codes
and class codes is just a way to make the representation more compact and
doesn't add new semantic information. This is one of the reasons why the RIM is
difficult to understand.
	Would prefer a modeling approach similar to the BRIDG model where all
the mood and class codes are explicitly represented as subclasses. 
	

			 
			 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.
/>
	[VK] I don't think this is a small vs large domain issue, it is more of
a modeling approach. The combinatorial explosion is due to the underlying
complexity of the domain, that will not go away. For e.g., there are a huge
number of classes in Galen
	and Snomed. In the semantic web approach, instances are classified into
one or more classes. In programming languages, one declares a variable to be of
a particular type. But in both these cases the types and classes are defined
ahead of time. So, I am not clear 
	in what sense you mean the above statemetn   
	

			 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? />
	[VK] Would like to propose a task force where the OWL can be offered as
a candidate formalism to support the requirements identified by TermInfo. Would
this be of interest to you, Samson, Peter, Stan Huff and the rest of the
HL7/TermInfo gang?
	(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. />
	[VK] Great! 
	

			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. />
	[VK] Probably not, what I am trying to do is reinterpret and make
explicit the semantics in the context of a multi-layered representation. 
	
	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. />
	[VK] OK, then what you are suggesting is that a template is logically
equivalent to a set of constraints on the information model. Would be interested
in representing these conformance statements as a set of OWL axioms 
	
	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. 
	[VK]  This is basically syntax checking which checks for the format in
which data is represented and is not an information modeling or semantics issue.
	 
	 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. 
	[VK] XMl structure testing can be tricky because the healthcare IT
community has used XML Schema to represent information models. XML Schema is a
language designed to describe the format and structure of XML documents in
contrast with languages
	such as RDF, OWL and UML which seek to describe the semantics underlying
these documents. So "checking for conformance of XML Structure" could either (A)
check for the validitiy of the structure of the XML Document or for (B) validity
of the information
	model (R-MIM) underlying the XML document. What would be relevant is (B)
and we could try to use OWL axioms to describe the type of conformance
statements represented by (B)
	Finally matching terminologies is a semantics issues and OWL/Description
Logics have been used to represent Snomed and terminology matchin can be
expressed in terms of OWL subsumptions.
	 
	 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. />
	[VK] What can easily be implemted using OWL is information
model/vocabulary validation
	 
	Cheers,
	 
	---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.
Received on Wednesday, 11 June 2008 04:29:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 11 June 2008 04:29:16 GMT