sam.heard at oceaninformatics.com
Thu Feb 15 22:49:38 EST 2018
My approach is that a description of an iris uses the same observation at all times. If the state of pregnancy alters the interpretation of this observation then a state variable needs to be added that refers to pregnancy. If it does not then pregnancy should be determined from other observations.
-------- Original message --------
From: Bert Verhees <bert.verhees at rosa.nl>
Date: 16/2/18 5:17 am (GMT+10:00)
To: openehr-clinical at lists.openehr.org
Subject: Re: Archetype pattern
On 15-02-18 17:51, Thomas Beale wrote:
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.
Hi Thomas, I wrote, that the RM is too coarse to cause pattern to be predictable. As you say, this can be solved in archetypes and templates, so the coarseness of the RM does not need to be a problem.
But on the other hand, the RM defines the paths. So it could be that there is a problem to be solved on that level. We could need additional pattern-rules to be set, because the RM is too coarse, I also read that too in the WIKI I referred to
When I look to SNOMED, I see about 20 top-level hierarchies, but they are, at first sight, not all useful in a EHR.
There would be a function for a top-level hierarchy: "Body Structure" in OpenEhr, because an EHR is problem related and does not want to describe body-parts, although....
....... on second thought, I worked a few months for EuroTransplant (I believe that Wouter has given a presentation in Norway short ago?).
I think they maybe could have been pleased with a top-level hierarchy for Body-Structure, because they describe body-parts, and they use OpenEhr.
In my opinion, it could have been logical for them to start with a (f.e.) liver, and then in hierarchy, describe that liver.
But they found other also very good solutions to record the work they do.
So when talking about predictable paths, the more detailed the RM is, the more predictable it becomes.
So, before writing further I must admit, I think we need a rich worldwide agreed reference model, which will be maintained in a professional way by an external standardization organization.
Like SNOMED, with all its features.
I see your example of pregnancy, as long as data fit in the scheme, there is no problem, but what if there are unforeseen circumstances which want to be recorded?
Maybe for that purpose in an archetype there is a wild-card archetype-slot where you can put anything which is not defined in another entry?
Then there are data which have unpredictable paths, and therefore they are not easy to be queried on. That is where the proliferation of paths start.
Heather describes in her WIKI that there can be archetypes which are only used locally and then it does not matter. That is right
But you can read between the lines from that sentence and the following, that this is not very often the case.
Because archetypes are almost never on their own.
Data are mapped to messages, and in that mapping process the archetypes are used to formal describe the mapping, or data are handed out together with archetypes, or a vendor creates an application/device and creates his own archetypes to handout with that or even an OpenEhr messaging system is in use.
It was a shock to me that academical hospital I mentioned, I never realized before how much data-requirement changes in 20 years, and the impact of that on information-storage/retrieval/processing.
I think we must anticipate that this will go on like that.
Is it the RM which needs to change?
Everything which is not hard-coded in the RM will arrive in an archetype in a way we cannot foresee when there are no predictable paths.
So I think there is a very rich meta-model needed.
Suppose, using your example, a vendor wants to describe the iris of a pregnant woman, suppose that becomes of medical importance, you need on forehand a way to structure that information or else it will become on an unpredictable path,
We want to be interoperable, and that does not only mean, interoperable on reading of information by humans, but interoperable on level of querying and processing.
Intelligent systems, prepared for the future do not want to be worked on all the time, but need to be able to adapt changes in an intelligent and predictable way.
So the semantic way from pregnancy to description of the iris is defined in SNOMED, although there is no use for it now. The path will be predictable and is waiting there to be used when useful.
I know it is a long way to go, these are my two cents to think about
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:
* from pregnancy summary archetype: 'assisted reproduction', 'planned place of birth', ...
* clinical - temporal aspect, mostly in OBSERVATIONs
* historical - i.e. non-tracked variables
* previous pregnancy information
* tracked variables
* e.g. BP (for eclampsia), blood glucose (for diabetes) etc
* birth process variables, e.g. vital signs, contractions, fetal HR, fetal movement
* clinical - process aspect
* OBS => EVAL => INSTRUCTION => ACTION cycle
* 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....
On 15/02/2018 12:40, Bert Verhees wrote:
An interesting wiki from Heather Leslie
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.
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.
openEHR-technical mailing list
openEHR-technical at lists.openehr.org<mailto:openEHR-technical at lists.openehr.org>
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-clinical mailing list
openEHR-clinical at lists.openehr.org<mailto:openEHR-clinical at lists.openehr.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-clinical