Archetype pattern

Technical (archive)
1

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

2

Hello Bert

I think that this is an interesting topic from a number of aspects.

Can I please ask what do you mean by "clinicians create archetypes with unpredictable paths"? Can you provide one or two examples?

Also about the "something, that is: PATTERN", David Hay has written an excellent book "Data Model Patterns: Conventions of Thought", which
although old (by now), is very well structured. A partial listing of its table of contents so that you get what I am trying to say here:
The enterprise and its world
Things of the enterprise
Procedures and Activities
Contracts
Accounting
The Laboratory
Material Requirements and Planning
Process Manufacturing
Documents

The "The enterprise and its world" section outlines basically every "system user" database, I dare say, ever.

Are you thinking about taking a look at the healthcare environment and then coming up with openEHR patterns that can commonly address each?

I think that this could be done even automatically, given the existence of enough archetypes / templates and the fact that they are machine readable with enough semantics to infer commonalities and structure.

All the best
Athanasios Anastasiou

3

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.

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

  • 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- real-time

  • 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…

  • thomas
4

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

5

Hi Bert,

Unfortunately pattern by itself won't result in good archetypes. Mind you, I think the RM classes are brilliant and they have been the cornerstone for our modelling experience. In fact I suspect that the lack of these classes is a large part of the reason why other modelling paradigms such as CIMI have not been able to progress as far and as fast they had wished.

Clinical medicine is messy, by definition. Our experience is that we often identify patterns and then we routinely come across as many examples that break those patterns. The slow progress that results is the result of refining those patterns to work as universally as possible in the clinical scenarios and how to deal with apparently outlying data points.

Then you need to consider clinical diversity that takes into account the range of clinicians; differing professional requirements; differing professional levels of details; needs of specialists vs generalists; clinical context; institution and location; cultural differences; language differences; personal health records; requirements for public health and research.... I could go on. We need to identify what a concept is and the appropriate scope; ensure minimising overlap as well as minimising gaps between concetps. Good archetype design is just not as simple as what you yearn for, despite how logical it seems to you. Our job would be much easier if it were so.

The only practical way forward is to start with good representations of clinical data and then get broad review from ALL experts - to ensure that the clinical data is fit for use as well as to ensure that they are implementable.

As CKM Editors we try to get developers involved in reviews but they are often in the minority - not because they are not invited but mostly because they don't respond. We have a large list of technicians who were part of the companies who funded the original openEHR sprint. Some responded immediately with 'Accept' just to try to accelerate the archetype to get a published state. Most ignore the invitations to participate. DIPS engineers have been the most consistent participants and many modifications in archetypes arose from their participation in reviews - this has reflected their requirements for clinical content as well as their suggestions regarding the technical implications of the archetype design.

The adverse reaction archetype is a case in point - eventually we had 221 reviews from 92 individuals in 16 countries PLUS an unknown number of participants from HL7 Patient care and FHIR communities. Health informaticians and IT experts comprised at least a third of reviewers - engineer engagement to this level is not our usual experience and if my memory is correct, most of the technical input came from the HL7 community, not openEHR.

Patterns have been identified and more are being refined... but don't expect them for all concepts, there will always be lots of unique models. Representing data that real clinicians can use will not be solved by patterns alone. Engaging clinicians is critical. Ontologies are useful but don't necessarily cater for the entire reality that is clinical practice. Engineer review and input would be much appreciated if it were available.

Why don't you agitate to get more engineers participating in the reviews? I would gladly invite anyone who is willing to engage. Get them to adopt an archetype today and join in the collective effort - the resulting archetypes can only be better for everyone.

Regards Heather

6

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

7

Hi all,

In my opinion there are several types of ‘patterns’:

  • Specific Local Templates/patterns used in a defined community for specific purposes
  • Specific Clinical Models/patterns for things like: the documentation of lab-test forms/panels, collections of meta-data for documentation of specific observations/test for abdominal complaints, etc.
  • Generic Clinical Patterns for things like: any lab panel, address, any device meta-dataetc.
  • Basic Patterns for things like: any observation, any evaluation, any order, any action, and any process, and their full epistemology, etc.
  • Atomic Patterns for those standardised constructs making use of Data Types and that are used to construct the patterns above such as: types of Result, types of temporal meta-data, etc.

Is this classification of Patterns useful?

My SIAMM is about the last three patterns and NOT about specific local templates and specific clinical models.
Each consists of a limited and manageable set of patterns.

Gerard Freriks
+31 620347088
gfrer@luna.nl

Kattensingel 20
2801 CA Gouda
the Netherlands

8

in openEHR terms…

specialisations of any archetype for local usage. COMPOSITION archetypes, probably some SECTION archetypes all the ENTRY archetypes ENTRY part of RM Data types and Data structures part of RM. - thomas

9

Heather, no doubt clinicians are necessary to design archetypes, the have the domain knowledge.

But you mentioned in your WIKI also the word "implementable", and this in connection to technicians, of course this is not a black and white word, some concepts are better implementable then others.

What does "implementable" as a technical term mean?

I think it means, predictable paths, so data can be found by queries without even knowing exact what one is looking for. For example, the eye-colour example for a pregnant woman as Thomas gave. I changed it to iris, because iris is not often registered, but there are clinicians which think it is important. A vendor could create an iris-analyzing device, and hand over an archetype with it to read out the data. That is what we wish for for OpenEhr, isn't it?
It ain't going to happen tomorrow, but it could happen in the future.

So when querying the particularities of a pregnancy an eventually irisscopy must be part of the result-set, even when no-one asked for it. So the vendor I just mentioned should have has archetype modeled in a way that it fits in the querying structure. This is a technical issue, deciding if an iris is interesting is a clinical issue, but storing an irisscopy in a way that it can/will be found, even when it is not expected is a technical issue.
There must be a pattern imposed on the archetype structures which causes that data can be found, and never become invisible.

It is not that I want make technicians to important, it is not my call anyway. I am glad that clinicians can do most of the jobs, but to optimize the implementable aspect of archetypes, we need technicians, I hope that this example makes this clear. And it is not the only example, there are other examples which to find ask for other structures.

Bert

10

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

11

in openEHR terms...

Hi all,

In my opinion there are several types of ‘patterns’:

- Specific Local Templates/patterns used in a defined community for specific purposes

specialisations of any archetype for local usage.

I don think you should ever create an archetype in the idea that it is a local archetype. I think you can never guarantee that. Archetypes are a model of thinking, a semantic model, instead of a technical model, like Codd-normalization.
So in an other situation there will also be the need to express the same way of thinking in an archetype, but they will probably structure it different.
That is something were we should find a way to avoid that.

- Specific Clinical Models/patterns for things like: the documentation of lab-test forms/panels, collections of meta-data for documentation of specific observations/test for abdominal complaints, etc.

COMPOSITION archetypes, probably some SECTION archetypes

Sections are, I think, a problem, they are part of the path, so they change query-paths and can make data invisible, because maybe no one thought of a section when searching in a database.
I don't know if AQL has a wild-card to pass sections without paying attention to them. I think that is necessary.

Bert

12

the key word is ‘specialisation’. In ADL, a specialised archetype is a computable technical artefact, and creates data reliably queryable just using the parent archetype. (Note that only ADL2 specifies this properly). The question of ‘good’ structuring is a separate one. AQL does have a ‘wildcard’ - it is the CONTAINS operator - it’s the equivalent of the ‘//’ operator in Xquery and Xpath. That’s why you can query for an Observation path (say, to systolic BP) regardless of how many layers of SECTIONs it might be under. - thomas

13

I think it means, predictable paths, so data can be found by queries without even knowing exact what one is looking for. For example, the eye-colour example for a pregnant woman as Thomas gave. I changed it to iris, because iris is not often registered, but there are clinicians which think it is important. A vendor could create an iris-analyzing device, and hand over an archetype with it to read out the data. That is what we wish for for OpenEhr, isn't it?
It ain't going to happen tomorrow, but it could happen in the future.

no reason it cannot happen now..

So when querying the particularities of a pregnancy an eventually irisscopy must be part of the result-set, even when no-one asked for it. So the vendor I just mentioned should have has archetype modeled in a way that it fits in the querying structure. This is a technical issue, deciding if an iris is interesting is a clinical issue, but storing an irisscopy in a way that it can/will be found, even when it is not expected is a technical issue.
There must be a pattern imposed on the archetype structures which causes that data can be found, and never become invisible.

you will just use a generic eye/iris archetype for the iris data points; it will be mixed in to a template with pregnancy specific data if it is needed. And it will be reliably queryable via the paths in the generic eye/iris archetype.

It is not that I want make technicians to important, it is not my call anyway. I am glad that clinicians can do most of the jobs, but to optimize the implementable aspect of archetypes, we need technicians, I hope that this example makes this clear. And it is not the only example, there are other examples which to find ask for other structures.

- thomas

14

Hi Bert,

A couple of quick observations…

  1. You are correct that the flexibility of openEHR can lead to chaos. Or more accurately it simply reflects the existing chaos. The idea of having the CKM archetypes is to allow us to hold up a set of well-designed patterns for folks to use, accepting that this is a huge and varied problem space in which reduction of chaos will take a long time. Reducing the chaos is a cultural and organisational problem, not just about technology and semantics.

  2. openEHR is not just about having interoperable, shared models. It is just as much about being able to quickly develop and adapt datasets, even if these use significant local content.

  3. Deciding when to use ‘standard’ archetypes or when to roll your own is not easy. It requires decent knowledge of openEHR but much more importantly, detailed health informatics knowledge and expertise. This is still like climbing Mt. Evert - you are better off hiring some local Sherpa Guides, at least for the first few ascents. Ordinary clinicians do not have this knowledge - their knowledge of their domain is critical but often siloed.

  4. The reason that SNOMED CT did not provide your solution is that it was never designed to do so. It provides an excellent means of sematically labelling the values of clinical questions “What was the name of a diagnosis, procedure or medication?” but cannot handle the complexity of how and where that question was asked - this is the role of the structural information model repesenting documentaion of clinical care, not biological entities.

Ian

15

Thanks, Ian, for your reply. I regret to say that I don’t understand all that you write, but on the other hand, I am busy with this kind of questions a few years, so I do not expect them to be solved this weekend, and they also do not keep me from sleeping. It is not very important to me.

But I have one remark about your point 4, about SNOMED. Just some thinking.

I think I understand the original purpose why it is designed. Encoding every clinical term and arranging them in graphs, and also offer translations.

But they did not stop there, they defined a query language and a data storage language, both capable of not only handling terms, but also handling graph-based hierarchies and handling quantities.

The purpose still can be to offer an international usable storage, but why then the query language? I think they want to offer a base for an EHR, but they don’t say that loud, so they do not scare away vendors.

But again, it does not keep me from my sleep, it is better for me to concentrate on what is feasible now and have fun with that.

Best regards
Bert

16

Of course, it is a good way for a device vendor to publish data. The archetyped data together with the archetypes are self explanatory and support many languages. Software developers not using OpenEhr can still process these data easily.

Bert

17

AQL does have a ‘wildcard’ - it is the CONTAINS operator - it’s the equivalent of the ‘//’ operator in Xquery and Xpath. That’s why you can query for an Observation path (say, to systolic BP) regardless of how many layers of SECTIONs it might be under.

Sorry I did not think about that. The CONTAINS operator is very strong and solves this problem

Bert

18

I agree that the different kinds of ‘templates’ show up in different parts of the RM.
But we need to think more.

All are ‘patterns’ of different kinds.

Gerard Freriks
+31 620347088
gfrer@luna.nl

Kattensingel 20
2801 CA Gouda
the Netherlands

in openEHR terms…

Templates used to define an active interface in a specific context

  • Specific Clinical Models/patterns for things like: the documentation of lab-test forms/panels, collections of meta-data for documentation of specific observations/test for abdominal complaints, etc.

COMPOSITION archetypes, probably some SECTION archetypes

I think these will be sometimes SECTIONS, ENTRIES or perhaps CLUSTERS

  • Generic Clinical Patterns for things like: any lab panel, address, any device meta-dataetc.

all the ENTRY archetypes

Generic CLUSTERS

  • Basic Patterns for things like: any observation, any evaluation, any order, any action, and any process, and their full epistemology, etc.

ENTRY part of RM

ENTRIES

  • Atomic Patterns for those standardised constructs making use of Data Types and that are used to construct the patterns above such as: types of Result, types of temporal meta-data, etc.

Data types and atomic generic Data structures part of RM.

DataTypes. Anything other than DataTypes are CLUSTERS

19

But I have one remark about your point 4, about SNOMED. Just some thinking.

I think I understand the original purpose why it is designed. Encoding every clinical term and arranging them in graphs, and also offer translations.

But they did not stop there, they defined a query language and a data storage language, both capable of not only handling terms, but also handling graph-based hierarchies and handling quantities.

Bert, can you point to the specifications for this - I was unaware that SNOMED had re-invented the EHR...

20

It was my own idea, I wrote they will not say that out loud.

(It was a joke)

Bert