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

sorry for the long delay...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. />
>     [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.
>
<dan> I'm confused...can you illustrate in UML, perhaps with the blood 
pressure example? />

>>          
>>          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.
>
<dan> Everyone has preferences on modeling conventions (and I don't 
necessarily disagree with your preferences)...The important thing is to 
understand what the models mean...If the concepts are the same, the 
concepts are the same...the pictures are just techniques for 
communicating the concepts. />

>
>>          
>>          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> depends what one means when one says they "create" an ontology. An 
ontology is just another name for a belief system. When one writes down 
one's beliefs, one is not really creating an ontology. />

>     <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  
>
<dan> looks like the antecedent to my statement "In small domains..." is 
lost somewhere above. In any case, in small domains, one can easily get 
a picture of all the classes on a small diagram that is easy for people 
to look at together. In large domains, the multitude of classes makes 
the diagram huge and makes it difficult to express the essentials on one 
computer screen or piece of paper (too many trees to see the forest). 
The HL7 UML model of the RIM that makes mood and class code attributes 
is simply a pictorial approach that assists discussion in many venues, 
i.e. one doesn't need a huge piece of paper on the wall! Again, not to 
get hung up in pictures of concepts. Focus on the concepts. />

>
>>          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> These models that are specific to problems and care plans already 
exist under the Care Structure Domain in Care Provision. />

>>
>     <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
>
<dan> I agree...Adding an OWL version of these conformance statements 
would be a great next step. />

>
>
>     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.
>
<dan> Again...agreed...OWL is a natural tool for this task />

>      
>      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, 25 June 2008 18:02:44 UTC