Re: Archetype pattern

[A Verhees]

Thomas, that joke, let me elaborate on that. Sorry for the the lot of
context

I know most EHR systems for GP's in the Netherlands. Lately I checked the
most used EHR system, the latest version. It is designed by GP's

They register according SOEP: Subjective (complaint), Objective
(observations), Evaluation (mostly an ICPC) and Plan (medication, send to
hospital, etc)

The S is mostly free text.
The O can be coded in SNOMED
The E is ICPC but could as well be SNOMED
The P is mostly also codable in SNOMED.

An EHR for GP's in the Netherlands could have every contact registered
having some lines of free text and some codes.

It is almost SNOMED out of the box and some free text. And that is Dutch
EHR software in 2018.

So, it was a joke but very close to daily reality. Because of some
circumstances I often see medical software, also see the internals,
datamodels, etc.

I wrote software for cardiologists for a few European programs, you'll find
details on my LinkedIn site, I wrote a few own OpenEhr kernels because that
are the working horses, in no time it is possible to adapt new
data-requirements.

I wrote it first on relational DB, the second one on XML DB, the third one
on an own design of path-values in Postgress, the fourth one which was
never finished on Oracle XML.

I also wrote dozens of archetypes, they never asked me anything else then
to register simple data, ECG's, heartrates, bloodpressures, skin humidity,
temperature, everything could be coded. One project consisted of a
heart-belt which did some extra observations, and my software was the data
storage.

So they could as well have taken another system instead of OpenEhr, but I
was hired, and OpenEhr was what I did.

I know that OpenEhr has metadata, context, and data in context of each
other, that is what Ian called yesterday "The clinical question". The data
can mostly be coded but the context cannot. This is where OpenEhr differs
from the other EHR's.

As I wrote before, OpenEhr and SNOMED are a strong team!!!

But for many other products, my joke is very close to reality.

My question to you Thomas, am I right or am I wrong?

Best regards
Bert

Op 17 feb. 2018 20:22 schreef "A Verhees" :

> It was my own idea, I wrote they will not say that out loud.
>
> (It was a joke)
> Bert
>
> Op za 17 feb. 2018 20:18 schreef Thomas Beale :
>
>>
>>
>> On 16/02/2018 18:30, A Verhees wrote:
>> >
>> > 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...
>>
>> >
>> > 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
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> technical_lists.openehr.org
>>
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype pattern

[A Verhees]

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

(It was a joke)
Bert

Op za 17 feb. 2018 20:18 schreef Thomas Beale :

>
>
> On 16/02/2018 18:30, A Verhees wrote:
> >
> > 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...
>
> >
> > 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
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype pattern

[Thomas Beale]

On 16/02/2018 18:30, A Verhees wrote:


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...




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



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype pattern

[GF]

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
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 16 Feb 2018, at 12:41, Thomas Beale  wrote:
> 
> 
> in openEHR terms...
> 
> On 16/02/2018 05:38, GF wrote:
>> 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.

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


> 
> - thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype pattern

[A Verhees]

>
> 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
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype pattern

[A Verhees]

Op vr 16 feb. 2018 14:26 schreef Thomas Beale :

>
>
> On 16/02/2018 09:23, Bert Verhees wrote:
> >
> > 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..
>

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
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype pattern

[A Verhees]

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

Op 16 feb. 2018 14:55 schreef "Ian McNicoll" :

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


Dr Ian McNicoll
mobile +44 (0)775 209 7859 <+44%207752%20097859>
office +44 (0)1536 414994 <+44%201536%20414994>
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 16 February 2018 at 13:22, Thomas Beale  wrote:

>
>
> On 16/02/2018 09:48, Bert Verhees wrote:
>
> On 16-02-18 12:41, Thomas Beale wrote:
>
>
>
> - 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.
>
>
> 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.
>
>
>
> - 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.
>
>
> 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
>
> --
> Thomas Beale
> Prin

Re: Archetype pattern

[Ian McNicoll]

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


Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 16 February 2018 at 13:22, Thomas Beale  wrote:

>
>
> On 16/02/2018 09:48, Bert Verhees wrote:
>
> On 16-02-18 12:41, Thomas Beale wrote:
>
>
>
> - 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.
>
>
> 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.
>
>
>
> - 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.
>
>
> 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
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Team, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
> 
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype pattern

[Thomas Beale]

On 16/02/2018 09:23, Bert Verhees wrote:


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


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype pattern

[Thomas Beale]

On 16/02/2018 09:48, Bert Verhees wrote:

On 16-02-18 12:41, Thomas Beale wrote:




- 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.


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.





- 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.


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

--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Archetype pattern

[Anastasiou A .]

Just to note, we do not disagree here. My main point is that for someone to 
make use of all this "machinery" we are referring to here, they first have to 
be aware of it.

I am keeping an eye on this discussion with great interest.

All the best
Athanasios Anastasiou




From: Bert Verhees [mailto:bert.verh...@rosa.nl] 
Sent: 16 February 2018 13:04
To: Anastasiou A.
Cc: openehr-technical@lists.openehr.org
Subject: Re: Archetype pattern

Dear Athanasios,

A pattern must be imposed so strongly to an archetype, that even a clinician 
cannot escape them. That is the idea. Conforming to SNOMED may not be the best 
idea, but it is not a bad idea. It is a restriction which impose connections 
and hierarchy and still allows a user needed level of granularity

Bert


On 16-02-18 10:24, Anastasiou A. wrote:
Hello Bert and all
 
Thank you for your reply, please see below:
 
> every path unpredictable if there is no pattern used, so you can find many 
> examples of your own
 
Alright, sounds like a pattern by itself :) I cannot say this brings an obvious 
example to mind.
This unpredictability though might be due to another reason (please see below).
 
> So clinicians and technicians create different archetypes, how about the 
> medical informatics specialists, how about other cultures, how about people 
> in between?
> I am sure that every person creates different archetypes, especially when you 
> look at the small details which are so important when querying.
> ...
> A similar kind of semantic pattern is also in SNOMED but then tailored to the 
> clinical world.
 
I think that this goes right to "the heart of the problem" and the keyword here 
is "Culture", or maybe even isolated cultures.
Even people from the same discipline cannot get to communicate sometimes. 
 
SNOMED and openEHR were not developed together. When you develop a model you 
have an objective in mind. The model is built to be able to answer a specific 
question (or range of questions). SNOMED is built with a different set of 
specifications and its granularity does not have to conform to anything other 
than its specifications.
 
So, you either try to make best use of both "tools" in isolation or, you stand 
back and think about integrating them (but again with a specific objective in 
mind).
 
In either case, I think that anyone who wants to start working in this domain 
needs to have a basic understanding of a few things (e.g. What is this thing 
called a "Data Model", what does the process look like, what is object 
orientation, what is abstraction, what constitutes an entity, what constitutes 
an attribute, what constitutes a relationship, what types of relationships are 
there and what do they mean in context and many other "basics".) as well as 
other models they are going to have to work with.
 
Otherwise, you get those "unpredictable results".
 
My experience has been that before you get people "excited" and engaged with 
this type of work, they first have to understand what it is and what is the 
value it brings to THEIR work. 
 
Most of the times, if you mention "Data Modelling" to someone from a health 
related environment (whether research or clinical), they immediately think 
numerical models. 
 
Finite modelling, is not even on the map. Someone is more likely to have 
(simply) heard of the logistic equation as a model of growth rather than 
generalisation as a way of specialising an entity. And we are talking "simple 
marketing" here. Just to have heard the term, they don't have to know exactly 
what it is.
 
So, for this environment, Patterns are Science Fiction. If someone doesn't get 
abstraction, they will not "arrive" at patterns.
 
This creates a mismatch between the technical and clinical communities which 
can probably be lowered by educating each other. I am probably equally 
frustrated about all the different types of Blood Pressure as a clinician is 
with all the different types of data structures but both are necessary, we are 
not trying to waste each other's time. I too need to know what the domain looks 
like to understand the objectives that the models are trying to satisfy. I am 
not saying that the clinicians are "lacking", I am "lacking" too :D
 
All the best
Athanasios Anastasiou
 
 
 
 
From: Bert Verhees [mailto:bert.verh...@rosa.nl] 
Sent: 15 February 2018 16:29
To: Anastasiou A.
Subject: Re: Archetype pattern
 
On 15-02-18 16:52, Anastasiou A. wrote:
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?
Hi Athanasios, in fact is every path unpredictable if there is no pattern used, 
so you can find many examples of your own.
I think the EHR-classes in the RM is too coar

Re: Archetype pattern

[Bert Verhees]

Dear Athanasios,

A pattern must be imposed so strongly to an archetype, that even a 
clinician cannot escape them. That is the idea. Conforming to SNOMED may 
not be the best idea, but it is not a bad idea. It is a restriction 
which impose connections and hierarchy and still allows a user needed 
level of granularity


Bert


On 16-02-18 10:24, Anastasiou A. wrote:


Hello Bert and all

Thank you for your reply, please see below:

> every path unpredictable if there is no pattern used, so you can 
find many examples of your own


Alright, sounds like a pattern by itself :) I cannot say this brings 
an obvious example to mind.


This unpredictability though might be due to another reason (please 
see below).


> So clinicians and technicians create different archetypes, how about 
the medical informatics specialists, how about other cultures, how 
about people in between?


> I am sure that every person creates different archetypes, especially 
when you look at the small details which are so important when querying.


> ...

> A similar kind of semantic pattern is also in SNOMED but then 
tailored to the clinical world.


I think that this goes right to "the heart of the problem" and the 
keyword here is "Culture", or maybe even isolated cultures.


Even people from the same discipline cannot get to communicate sometimes.

SNOMED and openEHR were not developed together. When you develop a 
model you have an objective in mind. The model is built to be able to 
answer a specific question (or range of questions). SNOMED is built 
with a different set of specifications and its granularity does not 
have to conform to anything other than its specifications.


So, you either try to make best use of both "tools" in isolation or, 
you stand back and think about integrating them (but again with a 
specific objective in mind).


In either case, I think that anyone who wants to start working in this 
domain needs to have a basic understanding of a few things (e.g. What 
is this thing called a "Data Model", what does the process look like, 
what is object orientation, what is abstraction, what constitutes an 
entity, what constitutes an attribute, what constitutes a 
relationship, what types of relationships are there and what do they 
mean in context and many other "basics".) as well as other models they 
are going to have to work with.


Otherwise, you get those "unpredictable results".

My experience has been that before you get people "excited" and 
engaged with this type of work, they first have to understand what it 
is and what is the value it brings to THEIR work.


Most of the times, if you mention "Data Modelling" to someone from a 
health related environment (whether research or clinical), they 
immediately think numerical models.


Finite modelling, is not even on the map. Someone is more likely to 
have (simply) heard of the logistic equation as a model of growth 
rather than generalisation as a way of specialising an entity. And we 
are talking "simple marketing" here. Just to have heard the term, they 
don't have to know exactly what it is.


So, for this environment, Patterns are Science Fiction. If someone 
doesn't get abstraction, they will not "arrive" at patterns.


This creates a mismatch between the technical and clinical communities 
which can probably be lowered by educating each other. I am probably 
equally frustrated about all the different types of Blood Pressure as 
a clinician is with all the different types of data structures but 
both are necessary, we are not trying to waste each other's time. I 
too need to know what the domain looks like to understand the 
objectives that the models are trying to satisfy. I am not saying that 
the clinicians are "lacking", I am "lacking" too :D


All the best

Athanasios Anastasiou

From: Bert Verhees [mailto:bert.verh...@rosa.nl]

Sent: 15 February 2018 16:29

To: Anastasiou A.

Subject: Re: Archetype pattern

On 15-02-18 16:52, Anastasiou A. wrote:

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?


Hi Athanasios, in fact is every path unpredictable if there is no 
pattern used, so you can find many examples of your own.


I think the EHR-classes in the RM is too coarse grained to guarantee 
predictable pattern. We can also see that in the WIKI from Heather Leslie.


I quote: "It has been observed on many occasions that even with 
identical clinical requirements, a clinical modeller and a technical 
modeller will build quite different archetypes. Which archetype best 
represents the data recording requirements? In most cases it will be 
the clinical modeller's attempt which is more useful, although 
technical input wi

Re: Archetype pattern

[Bert Verhees]

On 16-02-18 12:41, Thomas Beale wrote:



in openEHR terms...

On 16/02/2018 05:38, GF wrote:

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

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype pattern

[Bert Verhees]

aging 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

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bert Verhees
Sent: Friday, 16 February 2018 2:41 AM
To: For openEHR technical discussions 
Subject: Archetype pattern

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@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype pattern

[Thomas Beale]

in openEHR terms...

On 16/02/2018 05:38, GF wrote:

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.

- 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

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


all the ENTRY archetypes

- 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

- 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 Data structures part of RM.

- thomas

--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Archetype pattern

[Anastasiou A .]

Hello Bert and all



Thank you for your reply, please see below:



> every path unpredictable if there is no pattern used, so you can find many 
> examples of your own



Alright, sounds like a pattern by itself :) I cannot say this brings an obvious 
example to mind.

This unpredictability though might be due to another reason (please see below).



> So clinicians and technicians create different archetypes, how about the 
> medical informatics specialists, how about other cultures, how about people 
> in between?

> I am sure that every person creates different archetypes, especially when you 
> look at the small details which are so important when querying.

> ...

> A similar kind of semantic pattern is also in SNOMED but then tailored to the 
> clinical world.



I think that this goes right to "the heart of the problem" and the keyword here 
is "Culture", or maybe even isolated cultures.

Even people from the same discipline cannot get to communicate sometimes.



SNOMED and openEHR were not developed together. When you develop a model you 
have an objective in mind. The model is built to be able to answer a specific 
question (or range of questions). SNOMED is built with a different set of 
specifications and its granularity does not have to conform to anything other 
than its specifications.



So, you either try to make best use of both "tools" in isolation or, you stand 
back and think about integrating them (but again with a specific objective in 
mind).



In either case, I think that anyone who wants to start working in this domain 
needs to have a basic understanding of a few things (e.g. What is this thing 
called a "Data Model", what does the process look like, what is object 
orientation, what is abstraction, what constitutes an entity, what constitutes 
an attribute, what constitutes a relationship, what types of relationships are 
there and what do they mean in context and many other "basics".) as well as 
other models they are going to have to work with.



Otherwise, you get those "unpredictable results".



My experience has been that before you get people "excited" and engaged with 
this type of work, they first have to understand what it is and what is the 
value it brings to THEIR work.



Most of the times, if you mention "Data Modelling" to someone from a health 
related environment (whether research or clinical), they immediately think 
numerical models.



Finite modelling, is not even on the map. Someone is more likely to have 
(simply) heard of the logistic equation as a model of growth rather than 
generalisation as a way of specialising an entity. And we are talking "simple 
marketing" here. Just to have heard the term, they don't have to know exactly 
what it is.



So, for this environment, Patterns are Science Fiction. If someone doesn't get 
abstraction, they will not "arrive" at patterns.



This creates a mismatch between the technical and clinical communities which 
can probably be lowered by educating each other. I am probably equally 
frustrated about all the different types of Blood Pressure as a clinician is 
with all the different types of data structures but both are necessary, we are 
not trying to waste each other's time. I too need to know what the domain looks 
like to understand the objectives that the models are trying to satisfy. I am 
not saying that the clinicians are "lacking", I am "lacking" too :D



All the best

Athanasios Anastasiou









From: Bert Verhees [mailto:bert.verh...@rosa.nl]

Sent: 15 February 2018 16:29

To: Anastasiou A.

Subject: Re: Archetype pattern



On 15-02-18 16:52, Anastasiou A. wrote:

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?

Hi Athanasios, in fact is every path unpredictable if there is no pattern used, 
so you can find many examples of your own.

I think the EHR-classes in the RM is too coarse grained to guarantee 
predictable pattern. We can also see that in the WIKI from Heather Leslie.



I quote: "It has been observed on many occasions that even with identical 
clinical requirements, a clinical modeller and a technical modeller will build 
quite different archetypes. Which archetype best represents the data recording 
requirements? In most cases it will be the clinical modeller's attempt which is 
more useful, although technical input will be required to ensure it will be 
implementable."



So clinicians and technicians create different archetypes, how about the 
medical informatics specialists, how about other cultures, how about people in 
between?

I am sure that every person creates different archetypes, especially when you 
look at the small 

Re: Archetype pattern

[GF]

an only be better for everyone. 
> 
> Regards Heather
> 
> -Original Message-
> From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
> On Behalf Of Bert Verhees
> Sent: Friday, 16 February 2018 2:41 AM
> To: For openEHR technical discussions 
> Subject: Archetype pattern
> 
> 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@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Archetype pattern

[Heather Leslie]

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

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bert Verhees
Sent: Friday, 16 February 2018 2:41 AM
To: For openEHR technical discussions 
Subject: Archetype pattern

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 o

Re: Archetype pattern

[Thomas Beale]

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

RE: Archetype pattern

[Anastasiou A .]

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



-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bert Verhees
Sent: 15 February 2018 15:41
To: For openEHR technical discussions
Subject: Archetype pattern

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@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@

Archetype pattern

[Bert Verhees]

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@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org