Dan,
You've lost me. What is an ObservationCollectorClass? Googling the term
gives only one hit, namely your message.
The conceptualization of a class as denoting a set of instances is
quite common. It's in UML, frame representation, and OWL. I don't
understand why Observation, as a RIM class, should be an exception.
Maybe what you mean is that, within a (model of) health record system,
one doesn't deal with Observation as a whole, but always subsets (e.g.,
problems in Problem List), but that's a question separate from the
semantics of a class.
Matt, some of the terms (HL7 RIM, LOINC, OKBC) have specific meanings
that you can look up by googling. I am confused about the layering of
models that have been mentioned in this thread too.
Samson
Dan Russler wrote:
Ouch...
A class of Observation does not denote a set of instances of type
Observation...One uses "collector" classes to describe sets. In other
words, an instance of an ObservationCollectorClass contains instances
of an ObservationClass. The ObservationCollectorClass (and instances
thereof) certainly has different properties than an ObservationClass
(and instances thereof respectively).
Dan
Samson Tu wrote:
Yes, if we understand the semantics of a class as denoting a set of
instances. Specifying WBC_Count_Observation is equivalent to defining a
subset of all Observations, which is natural to think about. If we see
Observation as a metaclass, then it's the set of sets of
observations.The properties of observations and the properties of a set
of observations are quite different.
It is possible to talk about layers, but one should be careful about
the precise meaning of their relationships. I'd say that the
relationship between Vipul's layer 1 and 2 is one of specialization,
not instantiation.
Samson
Dan Russler wrote:
Hi Samson,
I agree...It is wrong to confuse the process of creating an instance in
the narrow sense (where the structural attributes and other attributes
are constrained to specific values) and creating an incremental
constraint on the structural attributes and code that allow one to
define "more concrete information models." By constraining classCode,
moodCode, and code to smaller value sets, one is creating more concrete
models, not creating instances in the narrow sense. In creating an
instance, one is constraining classCode to one value, moodCode to one
value, and constraining the CD datatype for code to a single semantic
meaning as well as setting values for other attributes (that might be
updated later).
Dan
Samson Tu wrote:
My understanding of the HL7 RIM is that, when you clone a RIM class,
such as Observation, into a specific domain model class (e.g.,
WBC_Count_Observation), you are placing restrictions on the RIM class,
i.e., constraining the cloned class's properties to have specific
values or to take values from a restricted vocabulary domain. The
process, I think, is characterized as creating a subclass of the RIM
class, not an instance. If you understand metaclass/class/instance in
the sense of OKBC, WhiteBloodCount as an instance of Observation where
code is specified to be the LOINC code for WBC means that code is not a
property of Bob's WBC. To query for the code, you need to go up the
class level.
I see no advantage in modeling the domain classes (detailed clinical
models) as instances of HL7 RIM classes. What's wrong with seeing them
as specializations?
Samson
Kashyap, Vipul wrote:
Dan,
Looks like there is increasing
convergence in our view points and some minor divergences.
<dan> I'm confused...can you illustrate in UML,
perhaps
with the blood pressure example? />
[VK] The UML Diagram illustrating WBC is
attached with this
e-mail (GIF format). Look forward to your thoughts on this issue.
<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.
/>
[VK] Well, that could be part of the
confusion. Another
viewpoint is that an ontology is a knowledge artifact that has a broad
consensus on what it means.
<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. />
[VK] Yes, the requirement to make a model
compact shouldn't
negatively impact the understandability of the model. Mood and type
codes can be very tricky to understand. Also these are some sort of
attributes at layer 1 as opposed to Layer 2. In some cases, the model
may be more understandable in one explicitly represents subclasses
based on these codes.
[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.
<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
In
Summary, we could propose the following Task Force which looks at the
following aspects as a part of HCLSIG:
(A) Determine
the feasibility of OWL as a common representational formalism for
healthcare delivery information models and terminologies
(B) Define
and implement the notion of "Semantic Conformance" of an information
model to HL7/RIM + Terminologies (may require a restructuring of the
RIM to some extent)
Let me
know what your thoughts are on this and we can figure out the next
steps.
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.
--
---------
Samson Tu email: [EMAIL PROTECTED]
Senior Research Scientist web: www.stanford.edu/~swt/
Center for Biomedical Informatics Research phone: 1-650-725-3391
Stanford University fax: 1-650-725-7944
--
---------
Samson Tu email: [EMAIL PROTECTED]
Senior Research Scientist web: www.stanford.edu/~swt/
Center for Biomedical Informatics Research phone: 1-650-725-3391
Stanford University fax: 1-650-725-7944
--
---------
Samson Tu email: [EMAIL PROTECTED]
Senior Research Scientist web: www.stanford.edu/~swt/
Center for Biomedical Informatics Research phone: 1-650-725-3391
Stanford University fax: 1-650-725-7944
|