BMI archetype

GF gfrer at luna.nl
Wed Apr 12 03:07:16 EDT 2017


see below

Gerard   Freriks
+31 620347088
  gfrer at luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 11 Apr 2017, at 16:30, Thomas Beale <thomas.beale at openehr.org> wrote:
> 
> For those who are interested in the background....
> 
> the underlying design of the Entry types <http://www.openehr.org/releases/BASE/latest/docs/architecture_overview/architecture_overview.html#_entries_and_clinical_statements> were the result of an epistemological analysis of kinds of information that could be generated in clinical work. That required an analysis of the 'clinical cognitive loop' as I now think of it, which is similar to a scientific investigation (theory building), but goes further and then intervenes in reality, based on the theory of what is going on.
> 
> So briefly, the types are:
> 
> Observation - data gathered, including what is called 'subjective' data, e.g. patient-reported pain. It is assumed that both manual and machine means are used to gather data, and that the data may be of unlimited complexity. However, the data are 'about' the one individual, i.e. the patient (patient's kidney, skin, CV system, etc)

This analogous to my definition of Observation.
It has the next set of characteristics:
- data obtained
- using human senses
- about phenomena as the result of processes in the patient system
- in addition observations, evaluations, plans, orders and actions can pertain to other processes also, including administrative processes

This implies that sources (third parties other that the author) produce data  about the patient system that potentially can be observed by the author.
Until observed this existing data exists in the EHR as observable.
When the author really observes it the status is transformed from ‘observable' into ‘observed’. Meaning that there was a conscious action by a person to admit it to the patient record.

> Evaluation - inferences made by human mind or machine, by comparing the individual data to the current knowledge base - i.e. standard medical knowledge, diagnostic guidelines, etc - any knowledge that is 'about' categories, e.g. 'patient with high BP', 'patient with raised blood glucose 2h after challenge', etc. These can be understood as some kind of 'opinion', since there can always be errors in matching the observation to the knowledge, or even knowing which observations matter and so on (think: episodes of House). Typical clinical words for Evaluation are 'assessment', 'diagnosis', but even just identifying a 'problem' is a kind of evaluation. An evaluation that has been made can be considered some kind of clinical decision on which actions can be based.
I agree, but extend it to the execution of rules, algorithms, using observed data. I consider it an assessment of existing data.
Many times just the result of an Evaluation is used and therefor will be observed as Observation.
The Evaluation will document the calculation documenting the method used.
The Observation will document the noticing of he result only. References might point at the calculation


> Instruction - request to various actors to perform specific actions, based on the Evaluation(s), typically medications, other therapies, education, further observation.

I have as additional Entry the Planning of Instructions and Actions

> Action - record of actions actually performed.
> Admin_entry - record of administrative statements recording passage of patient around the care system
I see no need to have this kind of Entry since all kinds of Entry pertain to processes and/or phenomena of processes, among which the processes in the Patient System.

> .
> The actual data structures we defined for these types are in some cases quite structured, e.g. Observation, Instruction, Action <http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_entry_and_its_subtypes>. This was based on the idea that these kinds of Entry have data of a certain shape. For example, Observations are by definition time-linked samples in past time, so the data structure is a time-series. Additionally, the data/state/protocol triple format mimics the reality of measurement.
> 
> As we gained experience with these Entry types over the years, it became apparent that there are some grey areas, e.g. path labs and radiology can send back results containing 'interpretations' and so on. If we were to redo the analysis today, we might potentially have somewhat more flexible structures, and rely a bit more on archetyping to specifiy the epistemic category of each Entry. However, I would say that the current system has held up pretty well, and the grey zone is pretty small. 
> 
> It should be additionally understood that concretely defined data structures are what make it possible for software engineers to build clinical software that can work with the data.
> 
> Compare this with software based on most of the extant message formats or other more freeform models - there is no support for even the most basic things like time-series of data, or state machine transitions of orders. While there are sometimes debates about whether some data item should be an Observation or Evaluation, once the choice has been made (at least for international or national archetypes), everyone has the same representation of that data, and software is guaranteed to be able to process its basic structures (time points, data/state/protocol etc).
> 
> So, of course what is there is not perfect, but it seems to have held up reasonably well, and new additions like Task Planning <http://www.openehr.org/releases/RM/latest/task_planning.html> will make it better.
> 
> Here are some FAQs about the Entry types <https://openehr.atlassian.net/wiki/display/resources/openEHR+ENTRY+Types+FAQs> that talk about the grey zone etc.
> 
> - thomas
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20170412/ddda6da6/attachment-0002.html>


More information about the openEHR-clinical mailing list