W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > April 2008

RE: An argument for bridging information models and ontologies at the syntactic level

From: Oniki, Tom (GE Healthcare, consultant) <Tom.Oniki@ge.com>
Date: Thu, 10 Apr 2008 11:28:08 -0400
Message-ID: <BD1803FE7117EF418A824FC52A43B0700617B17A@ALPMLVEM06.e2k.ad.ge.com>
To: "Samson Tu" <swt@stanford.edu>, "Kashyap, Vipul" <VKASHYAP1@PARTNERS.ORG>, <rector@cs.man.ac.uk>
Cc: <public-semweb-lifesci@w3.org>, <public-hcls-coi@w3.org>
It seems like we're having difficulty getting to a point where we can
see if we agree or not.

Let me attempt to further a convergence by drilling down on what Alan
said earlier about the 3 levels of medicine, giving my


* Pathophysiology - what we know about the patient

*	A patient may have hypertension

	*	The patient actually has to have some certain "kind" or
"subtype" of hypertension, e.g., "labile diastolic hypertension" - no
patient simply has "hypertension"
	*	The patient's hypertension has a severity, e.g., "mild"

		*	In this realm, the severity is mandatory -
*every* instance of hypertension has a severity

*	A patient has a heart rate, and the heart rate has a value,
e.g., "60 bpm"

	*	In this realm, every patient has a heart rate and every
heart rate has a value, even if it's "0"

* Clinical care - what we do to the patient based on our assessments of
the pathophysology of the patient

*	I'm not sure if Alan is deliberately saying that this "clinical
care" level addresses actions taken *based on* assessments/observations,
but that assessements/observations themselves *do not* fall into this
category, but belong elsewhere (in the "record" category below?)
*	Regardless, I'm sure he's saying that assessments/observations
must be regarded separately from the pathophysiology realm above.
*	For the sake of this drill-down, I'll assume
observations/measurements/assessments fall into this "clinical care"
*	Here we have a "hypertension" observation/finding/diagnosis.

	*	A hypertension observation may be a subclass of a more
generic "observation"

		*	It *makes reference to* the "hypertension" of
the pathophysiologic realm above, but is not equivalent to that
		*	One may observe that a patient has
"hypertension", even though, as noted above, no patient actually has
"hypertension", but must have some particular subtype of hypertension.
(Or maybe at this level we would say the observation still has to be of
a certain type of hypertension, and it's only at the next level - the
record of care - that we're permitted to say the patient has generic

	*	We may also observe the severity of the hypertension,
i.e., a severity observation is an observation about the hypertension's
severity described above in the pathophysiology realm.

		*	One can make a hypertension observation without
making a severity observation although, as stated earlier, in the
pathophysiologic realm, every hypertension has a severity.

*	Here we have a "heart rate measurement"

	*	We measure the heart rate at a location, e.g., the left

		*	Every heart rate measurement has a location -
you can't measure the heart rate without measuring it at a location

	*	The value of the heart rate measurement might not be the
"true" value of the (pathophysiologic) heart rate, but we accept it as
an approximation

* The record of that care and those assessments

*	At this level, the hypertension record and the heart rate record
speak of RIM- or Archetype- or Clinical Element Model-specific data

	*	It models from data capture/data exchange/data retrieval
use cases, which differs from the above levels

		*	e.g., it allows a heart rate measurement without
a measurement location, even though in reality every heart rate
measurement is taken from some location.

*	Significantly, it is here that codes and code systems are
introduced -- the records reference these codes and code systems, which
as Alan says are "meta" to the pathophysiology realm above, i.e.,
they're data structures that attempt to represent that realm.


Look forward to your comments.





From: public-hcls-coi-request@w3.org
[mailto:public-hcls-coi-request@w3.org] On Behalf Of Samson Tu
Sent: Wednesday, April 09, 2008 11:41 PM
To: Kashyap, Vipul
Cc: public-semweb-lifesci@w3.org; public-hcls-coi@w3.org
Subject: Re: An argument for bridging information models and ontologies
at the syntactic level


On Apr 8, 2008, at 6:50 PM, Kashyap, Vipul wrote:

Fundamentally, the only interpretation that works is to regard codes as
being "meta" to the ontology.  I.e. the individuals in the ontology are
things in the conceptualisation of the world - cases of diabetes,
people, livers, etc. - individual codes represent classes in the
[VK] Agree. Codes represent classes in some ontology or information


IMHO, codes don't represent classes in some information model. An
information model has classes like Observation, whose instances are
clinical statements made by some entity (person or machine). I think
information model is "meta" in the sense that its instances are
statements  (The observation that "John has diabetes") about something
that happens in the real world (the person named John has an instance of
Diabetes).  In BFO term, the observation is an instance of
information-content-entity, as opposed to an assertion about the John
instance of Person and an instance of Diabetes.


 The entire information structure - HL7 or Archetypes  - in fact, is at
a meta-level. 
[VK] Agree with this. In particular, the HL7/RIM has a very confusing
construction. It could be viewed as a meta-model but then it also has
fields to store patient data,

For e.g., one may view a class of lab values, say HbA1c as an instance
of the RIM Observation class (making it a meta-class), however, the RIM
Observation class also

has the value field for the value of those labs and is in some sense a
multi-layered representation, which is probably why it is so confusing.


I don't understand how a class of HbA1c can be an instance of the RIM
Observation class.  I don't see how the Observation class having the
value field is the issue.


Received on Thursday, 10 April 2008 17:40:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:20:33 UTC