CIMI archetype examples using latest openEHR AOM & ADL

Technical (archive)
1

For those of you following CIMI, there is now a dedicated CIMI space on the openEHR wiki. This page summarises some recent developments on the question of ‘panels in panels’ and ‘Entries in Entries’. Essentially we are trying to merge aspects of the modelling styles of Intermountain Healthcare, openEHR and others, to cover more modelling use cases.

The example is provided of BMI as a ‘panel’ that uses Height and Weight, which are themselves also usable as self-standing Entries, on this page in a series of screen shots and explanation.

  • thomas
2

Hi Thomas,

Overviewing the content on the wiki, IMO panels are an specification of sections.

Is very weird from the modeling point of view to have a composite pattern (ENTRY, COMPOUND_ENTRY, …) inside a composite pattern (CONTENT_ITEM, SECTION, ENTRY), is like defining a tree inside a tree in the model, but the initial model can also model the second, is just redundant. And IMO it doesn’t add semantics to the model.

It is also stated that “a panel is not a Section; it has specified and fixed [potential] content”, so it could be a templated section maybe (?). Without that statement, is clear that a collection of observations is just a SECTION with slots to OBSERVATIONS (archetyped or templated).

Also, the name “panel” makes me think of an user interface element, not a data structure. It would be nice to know why they need this new composite structure there, and if the requirement comes from structural needs or from information display needs.

As I see it, CIMI is mixing SECTIONS and ITEM_STRUCTURES.

OT, I tried to get closer to CIMI, but it seems difficult to participate from outside the EURO zone :frowning:

3

Hi Pablo,

I don't personally particularly agree with this approach either. There are two other approaches that could be used: the COMPOSITION / SECTION / multiple ENTRYs approach, and the CLUSTER-per-analyte approach (an earlier suggestion of Ian's and mine). I am going to build these models as CIMI archetypes as well, and document the results on the wiki as well. Then we can see the outcomes and judge objectively.

- thomas

4

I have read the PPT from Thomas which is linked in
http://www.openehr.org/wiki/display/CIMI/CIMI+Entry-in-Entry+Modelling+Pattern

I have some remarks on that. My two cents:

The proposal is written from the point of view of OpenEHR.

Although, I cannot comment on medical content, only from the point of view of information/developer.

Unknown future use-cases must be implementable. The OpenEHR RM is too semantic to be flexible on the long term.
So, all arguments, coming back a few times, about no need to change the RM can safely be dismissed.
Why would one not want to change the RM, when the use of the RM changes.
It is better to have an optimal RM for its purpose, than misusing an RM which was designed with other goals in mind.
It is better to learn a lesson than to get stuck on a suboptimal legacy RM.

Thomas agrees in Option 6, which I think is his preferred Option.

So the lesson is: No semantics in the Reference Model.
Also, because of the unknown use-cases, no other constraints on the reference-model itself, but still we need predictable query-paths.

This means, the RM cannot provide in this, so predictable query-paths should be in the archetype modeling instead of the reference model. The enforcement of consistent/predictable paths has to be done by the information-analyst when writing or choosing archetypes. The RM only need to give as much room as possible to do so.

To the Options:

Option 1:
Because of the no changing of the RM, but no use of semantic RM-classes we stick to GENERIC_ENTRIES for this?
The point that the PANEL-information needs to be distinguished from TEST-entries is not a real disadvantage. Because we are, in this option, not talking about another RM, it must be that we are talking about an consistent Archetype-Model. An archetyped schema.
SO it is all in the SECTIONs. For developing a kernel there can be consequences when an Archetyped Schema is used, there can be kernel-layer which is optimized for using that schema. For example, it can be optimized to know where to find the PANEL information.
Maybe that is a good approach, having a kernel-layer optimized in this way.
Software is then aware of the (by archetypes) enforced structure.
This layer be a semantic rich API on a generic working kernel.

Option 2 is ignoring that the COMPOSITION-class is a good class as it is, and making a kind of ENTRY-class of it. Plus, that the level of possible depth-levels is reduced. Instead of the step in between of SECTION, we jump right away to ENTRY-CLUSTER. Also the query-path will not be stable because of the archetype-node-ids and the CLUSTER will need to be overloaded with semantic information. I think this is a poor option.

Option 3, the Uber Model, looks attractive, but there are some disadvantages, as I understand well.
Lets assume I understand well:
The "Uber" archetype will contain lots of unused entries, maybe only 10% or less is used in a specific case. Although this delivers a predictable path-structure.
But then the kernel-software needs to check that many times, for example during data-entry, and also at query-time.
This checking could be avoided if there was an index-entry at the top of the Uber-Archetype which would contain information about which entries are used.
So to say, a meta-information-entry in the Uber-Archetype.

Option 4 with LINKS does not attract me much because it will need subqueries, which will make datamining difficult. The advantage of TESTS which can stand independently also can exist in the Uber-model.

For Option 5, I cannot imagine a use-case. It seems hypothetical to me.

So we arrive at Option 6, which seems, considered against the previous 5, having best of all worlds. And it does not try to keep the RM unchanged, although it can be done in an older RM.
But it seems a bit similar to Option 2, which also has no SECTIONs.

In my opinion Option 3 and Option 1 are the best options, but both could need an extended specific kernel-layer which is able to use the archetype-modeling-structures optimized.
Option 2 and Option 4 are more or less just flattening the structure, which will be a disadvantage when there is a parallel need to handle other Archetyped Schemas as well. I don't recognize a need to do that.

Best regards
Bert

Thomas Beale schreef op 15-2-2014 13:12:

5

just to clarify, this PPT was created by the CIMI - it’s based on the CIMI model, not the openEHR reference model. I have only made comments about it, not authored it. well it depends on what we mean by ‘changing’ the RM. The archetype method relies on not changing (i.e. incompatibly with the past) the existing RM. But there is no reason not to add to the RM. E.g. if we want to model structures that would occur in CDISC and also Query return structures, we should add these to the RM. I am in favour of that. No argument there. The CIMI group however I think is trying to obtain an optimal RM for authoring shareable archetypes in a clean way that supports conversion and reuse in concrete existing formats. this is a common but misleading idea! There are semantics everywhere. Even the type ‘Integer’ has some semantics. The question is what semantics should be in the RM versus what should not be. My view is that ‘domain-invariant semantics’ should be included (for whatever you say your domain is, e.g. EHR, health data etc), and that variable semantics should go into archetypes. The trick is to work out where that boundary actually is. - thomas

6

Thomas,

That is fully correct.
Even a ‘one’ and ‘zero’ have a well defined meaning, as do their associated voltage levels in the CPU.

In our domain of eHealth it must be clear that when we speak about ‘Semantic’ we mean health related semantics, the clinical aspects.
I am a firm believer in a separation of concerns between the various layers in the semantic stack.
The RM must address the legal and ethical aspects of document structure of any thing.
Archetypes/Templates deal with the eHealth/Clinical semantics inside these structures.

There is nothing misleading.
It is wrong to mix general legal ethical aspects, document structure aspects, with specific health specific semantic aspects.
It is a wrong idea to mix these aspects.
The domain specific but invariant aspects must be dealt with in standardised patterns we use to construct (clinical, administrative, management, re-use) archetypes and templates.
And some parts of the semantics, as you advocate, in the RM and others in archetype patterns is wrong.
That is my opinion.

Gerard Freriks
+31 620347088
gfrer@luna.nl

7

Thomas Beale schreef op 16-2-2014 14:18:

just to clarify, this PPT was created by the CIMI - it's based on the CIMI model, not the openEHR reference model. I have only made comments about it, not authored it.

Hi Thomas,

I am sorry for that, I was apparently too hasty reading it. I really was seeing an openEHR-like RM mixed with 13606-like RM in it.
I don't know where I started misunderstanding, but the further contents did not force me to correct my assumption.

Anyway, the Option 6 in the PPT is stating that this is not able to address the information-structure needs of CIMI.

8

Bert Verhees schreef op 16-2-2014 16:57:

Or is it possible that a new way of structuring health-data can come to life with no clear use for the semantic rich ENTRY-classes.

For Example, the OpenEHR/13606 EHR is build around the COMPOSITION Paradigm. This is a concept, which means: according to the EN13606-definition: "The COMPOSITION represents the set of RECORD_COMPONENTS composed (authored) during one user’s
clinical session or record documentation session, for committal within one EHR."

I believe in OpenEHR this is similar, but I am too lazy to check.

This is fine as long as one wants to stay inside this paradigm and one is willing to classify data to the semantic headers like EVALUATION or OBSERVATION, etc.
But at the same time, this is also a kind of straitjacket.

It prevents innovative thinking about data.
Sometimes, for example it is not that clear if something is an EVALUATION or OBSERVATION and forcing someone to classify can lead to an unclear base of classification, and in severe cases even to unfindable data.

9

Bert,

I think we can achieve more flexibility than the current RM without too much change, and keeping the useful components that exist today.

Bert Verhees schreef op 16-2-2014 16:57:

Or is it possible that a new way of structuring health-data can come to life with no clear use for the semantic rich ENTRY-classes.

For Example, the OpenEHR/13606 EHR is build around the COMPOSITION Paradigm. This is a concept, which means: according to the EN13606-definition: "The COMPOSITION represents the set of RECORD_COMPONENTS composed (authored) during one user’s
clinical session or record documentation session, for committal within one EHR."

I believe in OpenEHR this is similar, but I am too lazy to check.

This is fine as long as one wants to stay inside this paradigm and one is willing to classify data to the semantic headers like EVALUATION or OBSERVATION, etc.
But at the same time, this is also a kind of straitjacket.

It prevents innovative thinking about data.
Sometimes, for example it is not that clear if something is an EVALUATION or OBSERVATION and forcing someone to classify can lead to an unclear base of classification, and in severe cases even to unfindable data.

Can you say how this could happen? If there is doubt, just choose the one that seems to fit, and use it. I think the only question is: for a given clinical content model, is there no RM option that fits at all? Are there cases like this?

---
Not that I am capable of inventing a new health-data-schema, but I can see that semantic constraining in the RM is harmful.

An alternative way would be to build a new Schema of Health-Data.
Maybe there are some clever people out there, which are smarter then the predefined semantics.
Maybe the general opinion about the predefined semantics changes it, and the RM become subject of obsolescence.
But this would only be possible if the RM offers liberty to do so.

In the next release is there is a concrete Entry structure that is a free tree, that should help.

Note that if that gets used a lot, and different modelling groups need to model timing, various context, and they have to do it themselves, they will end up modelling things in a non-interoperable way, so that software can't be build that knows how to read the data. This is the danger.

To be innovative, we need freedom of thinking.

With complete freedom comes complete chaos. E.g. the current world of wiki & blog syntaxes - all a backward step compared to even HLTML 3, all non-interoperable... now we can't even do online software documentation that is shareable across tools.

I gave an example on this list a few weeks ago.
I explain it short, it could be an example of possible liberty of another way of approaching health-care data in a semantic poorly defined RM.

For example, just an example, not a serious solution!!!

An archetyped health-data schema could have a structure which makes paths predictable and consistent, and easy to query, and even fast indexes on data would be possible.
For this we would need a generic ENTRY. It exist in OpenEHR, but it has a low status: "If you don 't know where to put something, put it there, and else use the semantic ENTRIES."

I would prefer more status, or better, giving more status to the ENTRY-class by not making it abstract. And then making the ENTRY preferable above the semantic entry-classes.
Then this would become possible, or even obvious or logical.

yep, this is what will appear in the next release of the openEHR RM - ideally a 13606/openEHR merged RM.

- thomas

10

Thomas Beale schreef op 17-2-2014 14:59:

Bert,

I think we can achieve more flexibility than the current RM without too much change, and keeping the useful components that exist today.

Bert Verhees schreef op 16-2-2014 16:57:

Or is it possible that a new way of structuring health-data can come to life with no clear use for the semantic rich ENTRY-classes.

For Example, the OpenEHR/13606 EHR is build around the COMPOSITION Paradigm. This is a concept, which means: according to the EN13606-definition: "The COMPOSITION represents the set of RECORD_COMPONENTS composed (authored) during one user’s
clinical session or record documentation session, for committal within one EHR."

I believe in OpenEHR this is similar, but I am too lazy to check.

This is fine as long as one wants to stay inside this paradigm and one is willing to classify data to the semantic headers like EVALUATION or OBSERVATION, etc.
But at the same time, this is also a kind of straitjacket.

It prevents innovative thinking about data.
Sometimes, for example it is not that clear if something is an EVALUATION or OBSERVATION and forcing someone to classify can lead to an unclear base of classification, and in severe cases even to unfindable data.

Can you say how this could happen? If there is doubt, just choose the one that seems to fit, and use it. I think the only question is: for a given clinical content model, is there no RM option that fits at all? Are there cases like this?

It is more the approach which is unnecessary limited by the semantic design, it can block a new approach, and it makes paths too much depending on the semantic pre-classification enforced by the RM.
It could be possible to define afterwards if something is an Evaluation or an Observation. There are gray area's between the two, in cases of interpreted Observations, and that is no problem. The problem is only that now one has to decide at storage-time what it is, while it could also be afterwards on reading time. One could also change opinion.

And now, there are four nouns to choose from, maybe a new approach wants three or five. It is not possible in this RM. This can block innovation.

---
Not that I am capable of inventing a new health-data-schema, but I can see that semantic constraining in the RM is harmful.

An alternative way would be to build a new Schema of Health-Data.
Maybe there are some clever people out there, which are smarter then the predefined semantics.
Maybe the general opinion about the predefined semantics changes it, and the RM become subject of obsolescence.
But this would only be possible if the RM offers liberty to do so.

In the next release is there is a concrete Entry structure that is a free tree, that should help.

Exactly, that is what I wanted to say. Not some Generic_Entry in a dark edge of the RM for hesitating people, but a full grown, ENTRY with the status of every other Entry, to be there as a choice for alternative data-modeling.

Note that if that gets used a lot, and different modelling groups need to model timing, various context, and they have to do it themselves, they will end up modelling things in a non-interoperable way, so that software can't be build that knows how to read the data. This is the danger.

To be innovative, we need freedom of thinking.

With complete freedom comes complete chaos. E.g. the current world of wiki & blog syntaxes - all a backward step compared to even HLTML 3, all non-interoperable... now we can't even do online software documentation that is shareable across tools.

Of course, but there will never be freedom, there will always be data-modeling and constraints in thinking. The matter is now that the constraints are on RM-level (first level modeling), and they should be in data-modeling level. In the second level of data-modeling (as the concept two level modeling promises)

yep, this is what will appear in the next release of the openEHR RM - ideally a 13606/openEHR merged RM.

Thanks for letting me explain

Bert

11

Bert,

I don't really understand this. The clinical modellers will decide on Observation or Evaluation, and build their archetypes and templates. The paths will come from the archetypes, whatever their choices were. There might be occasionally some ambiguity for clinical modellers, but once they decide on their model, there's no ambiguity.

What innovation are you seeking that is being blocked?

I'm not saying the openEHR RM couldn't be more flexible - but I don't understand the problem you refer to here.

- thomas

12

Bert,

I don't really understand this. The clinical modellers will decide on Observation or Evaluation, and build their archetypes and templates. The paths will come from the archetypes, whatever their choices were. There might be occasionally some ambiguity for clinical modellers, but once they decide on their model, there's no ambiguity.

What innovation are you seeking that is being blocked?

I was looking at the CIMI model, other models are possible too.

Suppose you don't care at design time what kind of Clinical Noun you are classifying, but you describe your data you want to store using a code, maybe SNOMED, maybe a section of SNOMED which does not exist right now. Innovation is a future thing. Let the people afterwards decide how to use the data.

For example, say an Observation becomes a Evaluation, because there were reasons to observe something, or a gray area Observation, like an interpreted combination of ECG, radiology. A mixture between complex measurement-data and evaluation. Maybe some data-analyst find the strict separation of observation and evaluation artificial.

Whatever, there is not always a clear reason to classify it in one of the four nouns, it could be possible that you afterwards just search for that SNOMED code which is not yet invented. Because you designed a rigid structure, you always know the path to that code, and you always know the path to the datetime. Maybe you don't know what you are looking for, a mysterious decease, and you are just scanning data, or you are datamining, searching for non-obvious relations between deceases.

Suppose your rigid structure looks like this, always this model, except the Value, which can be more complex, depending on what it is.

ENTRY[at0001]
   Single_Item[at0001.1]
     CLUSTER[at0001.1.1]
       DateTime[at0001.1.1.1]
       Code[at0001.1.1.2]
       Value[at0001.1.1.3]

You see, this is not possible in the current RM, first because there is not yet a generic ENTRY (except the hesitater-generic-entry, which no-one wants), second, because there is no complex structure possible under a CLUSTER, so the rigid structure here needs some adjustment. :wink:

But it illustrates what I want to say, there is always a Code at the same path and archetype_node_id, and there is always a datetime under same condition. This should give special opportunities, only because from point of view of indexing, but in more aspects, and of course, it needs more thinking, this is just an illustration.

But the point is:
It is a semantic structure, completely defined in archetypes. It is an archetyped schema. This is no chaos, this is order.
And it is making true the promise of two level modeling. All modeling is in second level.

This should create a complete new playground for medical data-analysts. Innovation can go its way, there are no semantic boundaries.

The only thing needed for this is a generic non-semantic RM, like the EHR section in 13606 is more or less, and the next version of OpenEHR will be, as you say.

Maybe you cannot imagine anything at what I am saying here, my wife can't (she is a GP), but still you have decided to make of ENTRY a concrete class, although there already was a GENERIC_ENTRY. Why is that, if it is not for the reasons I mention?

Thanks,
Bert

13

Hi Bert,

I think the problem here is that many people get hung up on the idea
of the ENTRY classes being a formal classification upon which some
sort of abstract computing will take place e.g. query for all
OBSERVATIONS but not EVALUATIONS. i.e. we get caught up on the
philosophy and do not focus on the utility. In other words if I
weirdly decide to make problem/diagnosis an ADMIN_ENTRY nothing will
be lost computationally.

I think there is value in having a true generic ENTRY since it avoids
getting into these kind of marginal ontological discussions but I
still think there is place for the more complex constructs where these
make sense i.e when data requires a consistent date/event pattern as
in OBSERVATION or to support consistent state machine behaviour as in
ACTION.

I'm not sure that you gain a whole lot from moving these more complex
constructs into the archetype layer. either you force modellers to
recreate the structures de-novo, or you end up inheriting from a set
of reference top-level archetypes which have to be just as tightly
constrained and controlled as if they were in the RM.

Although CIMI has decided to move 'domain semantics' to the archetype
layer, there is also an intention to model against top-level
archetypes and to enforce quite struct adherence to 'patterns'. I'm
not convinced that this will actually end up being much different from
where we are now, in terms of flexibility.

I don't find the examples of 'Interpreted Observations' convincing. To
me, an EVALUATION is an interpretation that applies to the person as a
whole, not just to a specific test or set of findings. A radiological
diagnosis of 'Lung cancer' is always for me an Interpretative
statement about the chest x-ray - not the patient. The only place that
the person reporting a lab test is the same as the person making the
formal diagnosis might be in haematology. It is interesting that the
haematologists use the term 'synthesis' to describe the final
diagnostic assessment which relies on much more than their
interpretation of the blood film and count.

In any case, if I did create an EVALUATION.blood_count archetype and
later think that this might 'ontologically' be an OBSERVATION, I would
see no reason to change it. We are not trying to do reasoning on the
Entry class category.

Ian

14

Ian,

Can you answer the question:
When ‘formal classifications’ are unimportant, what is the use of such classifications?

we get caught up on the
philosophy and do not focus on the utility

Caring for the correct meaning is at the same time caring for utility.
It is not a philosophical issue.
Although some philosophical notions,
and linguistic ones
are helpful.

Practicalities, translated as ‘corners quickly cut’, ‘quick fixes’,
look nice in the short run.
But how about the long(er) run?

Gerard Freriks
+31 620347088
gfrer@luna.nl

15

Hi Ian,

Maybe it is hard to find an classified evaluated observation. You are right. Maybe this is a bad example.

Maybe it is only a matter of art or style, I am talking about.

What I see is that there is no congruent style in archetypes.
They are (excuse me, no offense meant) a collection of archetypes written by several people in several styles.

(Sorry I have to bring in some styling in this message, it is to keep it readable.)

16

Hi Gerard,

Good question. The value is not in the classification but in the
attributes provided by the class. These save me some work as a
modeller, should help the developer optimise some system aspects
optimally (e.g by knowing that every ACTION archetype inherits a time
and status that can be optimised for querying).

The first thing to say is that I do not see a particularly clear
distinction between 'classes' modelled in a Reference model and
'top-level' i.e rigid patterns modelled in archetypes. In both cases
you are providing modellers with some fixed attributes which are
inherited by child archetypes.

I am going to use Contsys as an example since this is alternative
example of where the modellers have introduced specific
classes/top-level patterns to reduce variability and enhance
computability.

IMO it does not really practically matter whether the Contsys
'Assessed Condition' is modelled in UML as part of the RM or provided
as a 'reference archetype' sitting on top of a leaner RM. In both
cases, if I want to adhere to the ContSys model, I have to inherit
from 'Assessed Condition'. That puts severe constraints on the way
that 'Assessed Condition' develops over time. It must remain very
stable and carefully managed whether an RM construct or a top-level
archetype.

So whilst the full-blown generic ENTRY has value, both openEHR and
Contsys do offer semi-rigid top-level patterns either via RM or
'reference archetypes'. In fact 'onotologically' there is a pretty
close match between the ContSys 'Entry' models and openEHR Entry
sub-classes

AssessedCondition = EVALUATION
Observed/PerceivedCondition = OBSERVATION
Activity = ACTION

which is unsurprising since both work from the same 'clinical process model'.

If we accept that there is some utility in establishing these
'top-level patterns', we are inevitably going to run into use-cases
where it is unclear if an ENTRY is an Observation or Evaluation but
equally where it is unclear if a Condition is Assessed or Observed
(smoking or housing summary being a prime example), or a least where
there is variable interpretation.

In most case this mixed or muddled classification is not at all
important for querying purposes. I am not aware of any situations
where I want to query for Observations. I want to query for 'Smoking
Summary'., If I happened to model it as an Observation I would get the
'observation time' as part of the RM (or top-levle archetype). If I
modelled it as an Evaluation, I would have to create a date
recorded/verified' node explicitly in the archetype.

So t value of the Classes/top-level archetypes are in the attributes
that child archetypes can inherit, saving modelling effort and
applying some consistency which can be exploited by developers, but
there is little value in the classification per-se, other than as a
guide. We do not query on archetype ENTRY sub-classes.

Ian

17

Hi Bert,

The reason that I have pushed to introduce an ENTRY class is to avoid
having these kind of arguments!! Fundamentally I think your post
beautifully highlights the problem.

At first you rightly complain about the ad-hoc styling and variability
of archetypes i.e we need more consistency, more frameworks. more
top-level patterns. In theory, I agree, in practice, I could point to
the very many inconsistent java coding frameworks available, the very,
very many competing code libraries in the open source space and simply
assert that trying to enforce consistent style will be impossible. The
experience of clinical modellers and the clinical requirements they
are trying to model are just too varied to have any realistic prospect
of imposing control.

Then at the end you say you want more freedom (via the ENTRY
archetype) and to let 'a thousand flowers bloom'. This of course will
result in even greater variation in the way that archetypes are
modelled with no consistency at all. You may be correct that some
useful frameworks emerge through competition, but you can be certain
that developers will end up using multiple 'frameworks' just as tends
to happen in other developments, simply because no clinical modelling
team will ever have the capacity to 'drink the ocean'.

As I understand it, the idea of the ENTRY sub-classes was to remove
some of this variability in the top-level patterns and strike some
sort of balance between your two contradictory wishes. That balance
may be wrong but I am struggling to understand how you would reconcile
the simultaneous need to reduce 'ad-hoc styling' and to increase
innovation - these two wishes are completely opposed.

The ENTRY sub-classes is an attempt to introduce some sort of
framework to clinical models at a very abstract level. Contsys is
attempting to do something very similar.

I think we probably agree that having a generic ENTRY class will help
reduce angst about 'which class is appropriate' and may help people
examine alternative approaches but ultimately this will create more
variability not less.

Ian

18

I don't think so.

It is the wish, I know, of all working on Health-ICT-projects/standards that their standard will serve the whole world, or at least an important part of it.

Because if that happens, all the interoperability problems are gone.

This strong wish motivates many decisions, which, after some time, need to be adjusted.

For example, in the OpenEHR, the idea was that CKM would serve the world with archetypes, and there would be no need of a strong archetypeId-system, because, all archetypes ever to be taken seriously were in CKM.
Now it is recognized that this is not the case, and the proposition regarding archetypeIds changed.

Now, I can read between your lines that variability should not occur. It should be avoided.
This reflects the same old wish for one standard for all.

But not to focus on you, not to focus on you or OpenEHR, just because this is close on this list. It happens in all other standard-communities. It happens everywhere where they define standards.

Maybe you know the joke, I told it a few times:

Andrea: Sigh, there are 51 HL7 standards, this is bad. I am going to solve that, I will create a new HL7 standard which will make all others obsolete.
Few months later....
Carlos: Sigh, there are 52 HL7 standards, this is bad. I am going to solve that, I will create a new HL7 standard which will make all others obsolete.
Few months later....
Francis: Sigh, there are 53 HL7 standards, this is bad. I am going to solve that, I will create a new HL7 standard which will make all others obsolete.

A world that speaks one language and sings Song of Joy before sleeping will not happen. There will be variability, there will be a free market, there will be free software development, there will be good and bad frameworks. This will always be.

The best we can do is provide means on which good things can come forward and the world has a chance here and there to do better.

By the way, do they in the UK still use British Standard Whitworth?

Have a nice day
Bert

19

Hi Bert,
I think you would find a sufficient number of presentations and papers from me and others about managing archetypes from around the time when we started to work on CKM (2007) that would convince you that even then we were far more realistic as to say that the openEHR CKM will serve the world with archetypes.
We were and still are just striving towards the (lofty) aim to get as much agreement/convergence as possible as well as unite the archetype development efforts where possible.

That a stronger/better/different archetype-id system is needed is true in my opinion - but a different story: for starters the archetype-id system predates CKM (or even any vision of it) by many years as far as I am aware.
Sebastian

20

In response of my own rather cynical looking post, I must say that I am not cynical at all. I have other expectations.

I think the health-ICT should focus on interoperability on base of independent systems. Thus, one or some system-independent message-formats. System developers should write routines to import/export them.

And besides that, health-ICT should make fabulous platforms, which serve their customers and their needs.
I think, archetypes, two level modeling are a great tools from this perspective.

So the world should be grateful for the work of the OpenEHR community, and that is my honest opinion.
I am proud to be involved even for just this little bit

Best regards,
Bert Verhees