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

Chimezie -

The SOAP pattern is widely used for writing medical charts.  As
a well-known industry model, it can clarify related terminology.
Its parts describe the "Subjective", "Objective", "Assessment", and
"Plan" aspects of a typical medical care-giving encounter.

Each part uses its own *separate* professional terms and (often)
specialized syntax too - like codes, units of measurement, etc.
This is appropriate, for the four parts model *disjoint* things:

   http://hillside.net/plop/2005/proceedings/PLoP2005_tsorgente0_1.pdf

In this paper (and many like it), "Assessment" is equivalent to
"diagnosis" - a model of health conditions in the actual patient.
This chart aspect should (and usually does) give pathophysiology
views, hopefully accurate, in some local "Assessment" ontology.

Other SOAP parts model other things/statements that are "evidence"
to justify (and not preclude) the "Assessment"; or else are medical
interventions (if any) which that "Assessment" suggests may help.
Coding can occur or not in any part.  The parts differ because of
*what* they model, not because of *how* they attempt to do that.

It would foolish to ignore such a tested, widely-ingrained pattern,
or spend much time trying to rearrange its details.  We'll do far
better to just (1) pick SOAP as a de facto standard; (2) formalize
it by citing any well-written spec on "Objective" vrs "Assessment"
(like the ones found in the above paper); (3) build on top of that
foundation, *separately* for each of SOAP's four disjoint aspects.

regards,
Dan Corwin


Ogbuji, Chimezie wrote:
> Thanks for that drill down, Tom.  It gives a good backdrop to call out
> important distinctions
> 
> [[[
> 	* 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 assessments/observations themselves
> *do not* fall into this category, but belong elsewhere (in the "record"
> category below?) 
> ]]]
> 
> My understanding is that the distinction here is between the
> characteristics of the patient (pathophysiology) and the clinical
> actions that are part of the provision of care (diagnostic actions,
> therapeutic actions, etc..).  Following this distinction, I would
> consider an assessment to belong to this category, but I would not
> consider an observation or a finding to fall in this category.  The
> former is an action (or what BFO would call a Process), the latter are
> data points recorded as a result of a clinical action.
> 
> [[[
> 	*	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 hypertension. 
> ]]]
> 
> Yes, this separation is critical IMHO.  Findings, diagnoses, measurement
> data, and observations are sections of a medical record
> (representational artifacts) that are *disjoint* from what they refer to
> (in the pathophysiologic realm).
> 
> [[[
> 	* 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 structures. 
> 		*	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. 
> ]]]
> 
> I agree, however, with the caveat that I would group observations,
> measurement data, and findings here (as a record of care and in the
> realm of information models such as RIM, Archetypes, etc..).  The term
> measurements is a bit ambiguous, so I wonder if what you had in mind was
> the process (or action) of measurement or the resulting data.   
> 
> Chimezie (chee-meh) Ogbuji
> Lead Systems Analyst
> Thoracic and Cardiovascular Surgery
> Cleveland Clinic Foundation
> 9500 Euclid Avenue/ W26
> Cleveland, Ohio 44195
> Office: (216)444-8593
> ogbujic@ccf.org 
> 
>  
> 
> 
> ________________________________
> 
> 	From: public-semweb-lifesci-request@w3.org
> [mailto:public-semweb-lifesci-request@w3.org] On Behalf Of Oniki, Tom
> (GE Healthcare, consultant)
> 	Sent: Thursday, April 10, 2008 11:28 AM
> 	To: Samson Tu; Kashyap, Vipul; rector@cs.man.ac.uk
> 	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
> 	
> 	
> 
> 	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
> thoughts/interpretation:
> 
> 	 
> 
> 	* 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"
> category. 
> 	*	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 hypertension. 
> 			*	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
> "hypertension"?) 
> 
> 			*	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 wrist 
> 
> 			*	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 structures. 
> 
> 		*	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.
> 
> 	 
> 
> 	Tom
> 
> 	 
> 
> 	________________________________
> 
> 		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 ontology.  
> 	[VK] Agree. Codes represent classes in some ontology or
> information model.
> 
> 	 
> 
> 	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.
> 
> 	 
> 
> 	Samson
> 
> 
> ===================================
> 
> P Please consider the environment before printing this e-mail
> 
> Cleveland Clinic is ranked one of the top hospitals
> in America by U.S. News & World Report (2007).  
> Visit us online at http://www.clevelandclinic.org for
> a complete listing of our services, staff and
> locations.
> 
> 
> Confidentiality Note:  This message is intended for use
> only by the individual or entity to which it is addressed
> and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable
> law.  If the reader of this message is not the intended
> recipient or the employee or agent responsible for
> delivering the message to the intended recipient, you are
> hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited.  If
> you have received this communication in error,  please
> contact the sender immediately and destroy the material in
> its entirety, whether electronic or hard copy.  Thank you.
> 
> 
> 
>

Received on Friday, 11 April 2008 07:21:04 UTC