Yet another OBSERVATION vs. EVALUATION issue
gfrer at luna.nl
Wed Aug 15 05:05:04 EDT 2012
In EN13606 Association we think that all artefacts must be derived from (specialised) from one generic pattern.
The draft document SIAMS defines this, plus more.
All artefacts inherit this generic pattern.
It is just one change of one attribute in the pattern that changes it from constraints on the generic ENTRY class used as Observation to one that is an Action or Instruction or Evaluation.
And all use the same generic pattern, but depending on different requirements they use other combinations of possibilities in the pattern.
What they have in common, will not change.
An other attribute defines the usage of the artefact for either documentation, querying, presentation.
gfrer at luna.nl
On 15 Aug 2012, at 10:42, Koray Atalag wrote:
> Hi Heather, all others – many thanks for your responses.
> I agree that risk is an evaluation – no question with that. However I reckon I couldn’t explain the issue I had clearly:
> My question was when documenting a patient’s health information at a point in time base on past diagnoses, medications and smoking status not necessarily assessed by the same physician, should these be observations or evaluation? I’m not really asking about risk assessment – in that case the physician (or decision support tool) is considering past observations etc. against a knowledgebase and making a clinical judgement. That should clearly be an evaluation
> To give an example: a medical student is reading problem list, medication list and smoking status from patient’s EHR and putting on a form to present to a physician – is the stuff on that form Observation of Evaluation? Heather I take your point that in order to reuse data it is best to stay faithful to original models...
> So that makes me think whether we find a smarter way of dealing with Observation vs. Evaluation types. Kind of multiple inheritance where, depending on a particular usage, they can inherit contextual parts of either Observation or Evaluation. I can see this will save a lot of hassle and still enable us to reason using the ontological Clinical_Entry classes. Probably same is true for Instruction/Action types as well.... Anyway this is probably even a bigger discussion!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-clinical