Archetype conceptual and technical operational are 2 different things

Technical (archive)
1

These are archetypes in which the clinicians materials are sorted out, coded etc.

They currently are made operational for use in a message. Sam has worked with the Barthel index, which based on this example for R-MIM, however based on the tables, could be written up in ADL language in less than 15 minutes, where the sorting out of Barthel for clinical and making the variable / coding tables etc took about 8 days of work due to many variants in practice.

How these can obey to the model is explained in the CEN 13606 R-MIM which is going to be discussed next weekend in San Antonio.

I am just waiting for a tool that helps me with the conversion to the different operational archetyping.

This does bring me to the conclusion that we are more or less focussing on different concepts which we both call archetype.

For me the archetype (and in HL7 world template and in CEN also GPIC) is a reusable and standardised format of a small or little larger piece of clinical information, expressed into a model that makes it implementable into technology.
So giving structure, determining data type, assigning a mandatory value set and meaning such as in clinimetric scales (Barthel, Apgar), unique coding (the tables in the current format under section's 8 - 10) is for me the essence of the archetype. So a technical specification of clinical content.

Then, I think comes your point, and perhaps I now better understand your position, this technical specification of the clinical stuff must be given a specific format to make it work in IT. In our projects I have to make it work in the HL7 v3 messages and in the EHR's that use the RIM and D-MIMs as their reference model for the database (similar to Oracle HTB)

In your case for OpenEHR it must adhere to the archetype definition language.

Well, not to go into the discussion again about which is best the egg or the hen, I have the experience that we do need a well structured clinical information set to work in both a message and in an EHR.

To me it does not matter how it is formalised to work in IT, but to you it apperently does because you want to implement it in the EHR based on OpenEHR principles.

For the clinical content expressed it does not matter, for what you need to do with it it does.

So given the parallel discussion on vocab:

steps to deal with it are beginning to become clear:

- formalize the clinical materials (literature, evidence, clinician input)
- make them technically specific operational (data type, coding, valueset binding, cardinalities etc)
- express them in ADL for use in Open EHR
- express them in Hl7 v3 R-MIM for use in messages.

I earlier assumed that conversion from R-MIM to ADL was doable, but apparently it is not.
But from a table with technical operational materials (step 2 above) we must be able to go both ways depending on need and national strategy?

I look forward to further harmonisation work on archetypes and templates. HL7 template group is currently working on applying ADL / CEN 13606-2 for further work, but given the discussion above, we might need to look for a model that allows us to express it operational, but unbound to specific technology.

William Goossen

2

Dear William,

CEN/tc251 EN13606 part 2 describes “this model that allows us to express it … unbound to specific technology”.

Further there is the list:

  • Clinical concept descriptions:
    – Excel sheets, expressed as text in columns,
    – CEN/tc251 or openEHR Archetypes, that are formally expressed as constraints on an underlying UML model (part 1 of EN13606),
    – HL7 Templates, that are formally expressed as constraints on a derivative of an underlying (Viso) model (the HL7 v3 RIM).

At this point in time CEN and HL7 are in the process of harmonising part of of the EN13606 with the work on the Clinical statement.

The moment when HL7 starts to deploy the method, described in the HL7 Development Framework in stead of the Message Development Frame work, more intermediate artefacts of HL7 will be expressed in UML.
Then HL7 Templates and CEN/openEHR Archetypes can become the same thing. Not only expressing the same thing but being the same thing at the level of the computer.

Gerard

– –

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 653 108732

3

In een bericht met de datum 5-5-2006 9:40:03 West-Europa (standaardtijd), schrijft gfrer@luna.nl:

Dear William,

CEN/tc251 EN13606 part 2 describes “this model that allows us to express it … unbound to specific technology”.

Further there is the list:

  • Clinical concept descriptions:
    – Excel sheets, expressed as text in columns,
    – CEN/tc251 or openEHR Archetypes, that are formally expressed as constraints on an underlying UML model (part 1 of EN13606),
    – HL7 Templates, that are formally expressed as constraints on a derivative of an underlying (Viso) model (the HL7 v3 RIM).

At this point in time CEN and HL7 are in the process of harmonising part of of the EN13606 with the work on the Clinical statement.

The moment when HL7 starts to deploy the method, described in the HL7 Development Framework in stead of the Message Development Frame work, more intermediate artefacts of HL7 will be expressed in UML.
Then HL7 Templates and CEN/openEHR Archetypes can become the same thing. Not only expressing the same thing but being the same thing at the level of the computer.

Gerard

See our agenda for the next year,

thank you Gerard,

William

4

Dear William

I agree with all that you say - in openEHR we do feel that we have some ownership of the term archetype for this purpose, but we can give it up for love! We do need to agree on an underlying recording model and it needs to be as powerful as possible and have as few clinical concepts as possible. The richness of the underlying recording model means we do not have to repeat the same expression all over again each time we create an archetype - we do not have to say who recorded it, who supplied the information, how we deal with other things. This is agreed to be done in the environment in a manner akin to the information or recording model.

By having no clinical concepts in the recording model, it means clinicians can decide from base how to express their concepts - they do not have to set attributes or make arbitrary choices between meaningless possibilities.

I believe that the benefit from starting from openEHR is clear - or else we go into another 5 year loop to do it all again and I have to tell you it is not so easy to get this working and correct. Why not make your spreadsheets from there if you want spreadsheets. It will as straight forward as possible, and there is a lot of work to do to make the archetype publication work better, enable governance and everything.

We have to accept that the RMIM process is not amenable to clinical direction - you are almost alone in mastering it and even then you use spreadsheets rather than tools to specify things. I would love to get your models into English and openEHR. It would probably take a couple of days max - and then start a debate within the clinical community.

I propose to post on the clinical list a problem soon and I am sure you will have some ideas about it. If you made your clinical models available as openEHR archetypes this would advance clinical computing 5 years in one step - we could criticise them and have a debate - in their current form it is not possible. It would also show that we do not have to be religious about expression - and we could use them in trials of openEHR based in Dutch speaking countries and beyond. We would of course like you to look at the current set of archetypes on the Ocean site in this process.

If not, could you supply me with any English translations so that I might do this for others - it is quite a straight forward process!

Nothing like an open invitation, and thanks so much for dinner in Holland. Cheers, Sam