Archetype pattern

Bert Verhees bert.verhees at rosa.nl
Thu Feb 15 13:16:34 EST 2018


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

Bert


> 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/>
>
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org


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


More information about the openEHR-clinical mailing list