Archetype pattern

Thomas Beale thomas.beale at openehr.org
Thu Feb 15 11:51:13 EST 2018


Indeed, patterns are conceptually what is needed - many of us have 
thought so for a long time. The real question is what lies behind a 
pattern? Consider the OBS/EVAL/INSTR/ACTION set of classes in the RM - 
they are a formal representation of a pattern (each containing some 
micro-patterns), that I would call the 'cognitive loop of care'. It's 
very useful but only solves one problem among many.

There are many patterns and some are more basic than others. Patterns 
that are universal in health care an appear in the RM (you may debate as 
to whether what is actually in the openEHR RM today is correct, but this 
is the principle); others will be realised in archetype or template levels.

An older attempt of mine to categorise some patterns is here on the wiki 
<https://openehr.atlassian.net/wiki/spaces/CIMI/pages/1802243/Typology+of+content+types>.

The paradigmatic approach for finding patterns is to use ontological and 
epistemological conceptual approaches. In the ontological aspect, 
'reality' needs to be explored and understood. Reality is very complex, 
and we don't capture anything like all its aspects.

Here's an example: in pregnancy and birth, there are the following kinds 
of data items:

  * administrative
      o from pregnancy summary archetype: 'assisted reproduction',
        'planned place of birth', ...
  * clinical - temporal aspect, mostly in OBSERVATIONs
      o historical - i.e. non-tracked variables
          + previous pregnancy information
      o tracked variables
          + e.g. BP (for eclampsia), blood glucose (for diabetes) etc
      o real-time
          + birth process variables, e.g. vital signs, contractions,
            fetal HR, fetal movement
  * clinical - process aspect
      o OBS => EVAL => INSTRUCTION => ACTION cycle
      o schedule of visits, tests etc

and so on. We don't currently distinguish different kinds of variables 
in time that well, nor do we separate adequately various kinds of 
administrative and clinical data items in the current archetypes.

On top of this, things are complicated by what is 'epistemic' and what 
is 'ontological'. For example, the patient tells you she had 10 
miscarriages; do you consider this a 'fact' or not? It depends. 
Statements about events that are not directly observed or performed are 
of the form 'X said that Y'. Do you trust X, or X's method of obtaining 
the information? If X says they are diabetic, probably yes; if they say 
that demons are speaking to them, well...

In the end, reality is fractal and there are finer and coarser levels of 
it. We can think of this as being similar to the levels of molecular 
complexity in biomedicine: proteins are macro-molecules with emergent 
behaviour such as key/lock etc, due to their physical form, also 
chemical binding behaviour, and are constructed of simple molecules 
(amino acids), which have their own chemical characteristics, and so on 
down to atoms.

Models of clinical process (e.g. over a pregnancy, or managing an acute 
stroke) are something like a macro-molecule level, while inside this 
there are many fine-grained elements.

I believe there are patterns we can identify based on various aspects 
and levels of reality, but currently we have poor theories of this. 
Clinicians don't tend to have any formal training in ontology or 
epistemology (but they have some good practical concepts like SOAP, and 
tend to understand the subjective / objective divide quite well), and 
90% of IT people don't either (and accordingly most software is terrible 
because the developers have no idea how to model properly), so everyone 
is weak in this area. But at least clinicians know what they are talking 
about at a medical level.

To do better than we are currently doing would require a better 
engagement with ontology methods (how to investigate reality) and 
concepts from epistemology (how to model gathering and recording of 
information).

Just to finish with a simple example, why is any clinical data item 
included in a data set or model? E.g. why do docs measure BP and blood 
glucose for (some) pregnant women? Because they relate to common risks. 
If the woman has pre-existing risk of pre-eclampsia / eclampsia (such as 
hypertension, family history) then BP needs to be measured. Why don't 
the docs measure her weight (generally speaking) or eye colour? Because 
they don't relate to any particular risks. Tracking variables is work, 
and there is no point in doing useless work. So healthcare professionals 
try to track variables that are indicators of patient state, and can 
quickly indicate deviation into various abnormal states. So properly 
modelling the data for pregnancy for example would require a model of a 
normal pregnancy, and models of abnormal states (various kinds of 
infections, diabetes, eclampsia, and so on), and linkages of the 
relevant variables to the pathological patient states for which they act 
as warnings. Currently we don't model any of this properly - we just 
lump together a lot of data items for which there is tacit medical 
evidence behind the scenes, but it is not made explicit, and therefore 
computable in the models. Docs know what they are looking at, most of 
the time, but not that much is computable, because not much is explicit.

We have a long way to go (by 'we' I mean everybody; SNOMED for example 
hardly touches any of these questions). But at least in openEHR we got 
past the situation of adding a new DB table every few days....

- thomas


On 15/02/2018 12:40, Bert Verhees wrote:
> An interesting wiki from Heather Leslie
>
> https://openehr.atlassian.net/wiki/spaces/healthmod/pages/90507705/Archetype+Design+Patterns 
>
>
> She concludes that pattern are necessary, I agree with that, and she 
> also concludes that clinicians are better modelers then technicians.
>
> Well, that depends, of course it is very important to have 
> domain-knowledge when modeling data, and clinicians have the best 
> domain-knowledge. So from that point of view, she is right.
>
> But what we have seen until now is that clinicians create archetypes 
> with unpredictable paths. And that is bad, because it makes it very 
> difficult to find data and it makes it easy to miss important data, 
> because some data were on a path where one did not expect them.
>
> OpenEhr works fine to find data which are on a known or predictable 
> path, but what if data are on an unknown path?
>
> Let me explain by comparing this to a classical relational 
> health-application. There are similarities.
>
> I have seen classical relational systems which experienced a wild-grow 
> in number of tables, I have seen once in a prestigious 
> university-hospital where they had a grown of 7000 tables in 20 years, 
> more then one per day!! No one understood the meaning of all the 
> tables and data, no one dared to use data he did not understand, many 
> data were and still are redundant. Every new development in the ICT 
> starts with designing new tables.
>
> How can in such a situation a clinician research a persons medical 
> record, even with the help of the current technical staff, this is 
> often impossible. So, important information can get lost. Adding to 
> this are software-updates which often cause a clean-up, and that 
> clean-up is also done by people who do not always know what they clean 
> up. People live long, and a medical problem they had 30 years ago can 
> be important to find to solve a current problem. So old data, and 
> understand them, and be able to find them, can be important.
>
> This can also happen with archetypes. Every new development in a 
> application can start with a new archetype, and at a moment there can 
> be thousands. It is impossible for a clinician to search all possible 
> paths for medical information, even with the help of the current 
> technical staff this can be impossible.
>
> The old data-hell situation will not be solved by OpenEhr if there is 
> not something behind it. And that something, that is: PATTERN
>
> It is not only a clinical thing to understand how pattern in paths are 
> best modeled, it is in fact also a technical thing. Clinical knowledge 
> is not stable, the thinking about clinical facts change all the time, 
> what now is important is tomorrow maybe not. So the pattern need a 
> technical, mathematical base, that, something like Codd-normalization, 
> but of course then applicable to archetypes.
>
> The Wiki from Heather Leslie is a good starting point for the design 
> of pattern and stop the proliferation of paths.
>
> I described an approach to solve this problem in a blog, one and a 
> half year ago.
>
> http://www.bertverhees.nl/openehr/medical-data-context/
>
> I had some discussion about that, but many had problems against the 
> use of SNOMED in this context. So, maybe read it and forget SNOMED ad 
> find something else to structure the medical data.
>
> Bert
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
>
>

-- 
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Team, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20180215/a85af9c9/attachment-0002.html>


More information about the openEHR-clinical mailing list