Archetype pattern

Bert Verhees bert.verhees at rosa.nl
Fri Feb 16 07:40:28 EST 2018


On 16-02-18 04:49, Sam Heard wrote:
> Hi Bert
> 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.
> Cheers Sam

Hi Sam, it is not that I want to be an "enfant terrible", of course your 
way of working is good. I think the best way, possible inside this 
eco-system.
It is just that flexibility offers many possibilities, but also offers 
chaos. How can you find data if you don't know how they are stored? And 
to know how they are stored, you need to study the archetypes.
In anyway, this is much better then a relational model, which often is 
accompanied by documentation which is hard to understand, written long 
ago, is it still valid? If it exists at all?

So OpenEhr is much better then that. But still chaos can occur, because 
of its flexibility. For example, inside a Composition there can be 
sections.  They will be part of the path. How many sections are there, 
how many layers?
Inside observations item-structures can appear, how many layers do they 
have, is it a matter of taste, there are not really rules.

I am not having a solution for these problems, except going to a very 
rich RM like SNOMED.

I was just being glad that Heather was recognizing pattern-related 
issues also, and she was, besides, referring to  clinical also referring 
to the word "implementable".

This brought me to this idea which is on my mind for several years now. 
I just can't believe that CKM will ever cover the whole clinical 
data-requirements, so there will always be a need for archetypes which 
have to be created in the wild.

There must be a better solution for this.

Bert

>
>
> -------- 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
>
> 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
>
>
>
>
> _______________________________________________
> 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/20180216/1208e7be/attachment-0002.html>


More information about the openEHR-clinical mailing list