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
[email protected]
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/>
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
