Generic vs specific archetype modeling

Clinical (archive)
1

Dear all,

I have a question and I wonder which choice other people would make in such a situation.

A simple example to explain the situation: Imagine I want to record a few labtests in a template.

There are a few choices:
1) Use a generic lab-test archetype, and clone it inside a template and give it a label which explains its specific purpose.
2) Specialize a generic lab-test atchetype so it gets an archetype-id which explains its specific purpose.

Both have advantages (and the advantages are the disadvantages of the other):

1) Advantages are:
- easy to maintain a single generic archetype
- working constructively on a generic archetype library like CKM.

This construct has one important disadvantage (please correct me if I am wrong)
In the ADL paths to the data-items it is not anymore recognizable which specific item was examined in the lab-test, because all lab-test items in a template offer the same paths. This gives difficulties, for example, when querying.
The archetype is the base of information, not the template. So information in the template is not available on archetype-level.

2) This situation avoids the problems caused in situation one. The specific information about the (as in example) lab-tests is available on archetype-level. Another advantage is that it will be possible to add terminology binding (LOINC, SNOMED) to the archetype, because the archetype is specific. And as we all (I think) agree terminology binding is one of the most important keys to interoperability. Especially for lab-test, to be sure a dataset is describing a specific labtest, it is internationally recognized to use LOINC for that. (It is almost complete, and internally descriptive, and it is free accessible to all)

But this construct also has one big disadvantage: When thinking this through, it will come to thousands of (as in example) lab-tests archetypes (all specialized from one generic lab-test-archetype). If these were all posted in a single library, that library would become unmaintainable. When you change the generic archetype, you have to change all specialized archetypes, in order to adapt the change
And another thing, in extrema, an archetype-library would become like a LOINC-database, for every LOINC-code a labtest-specialization. Maybe we could generate archetypes from the LOINC databasase? One good software-routine could handle this easily.
Would we still be in need of lab-test archetypes then, one could ask?

Mitigating this point, not many institutions will need all LOINC situations in one template. So the specializations are only necessary of more (as in example) lab-tests are grouped together in one template.

So, how do others, reading on this list, solve this problem?
Or are there any thoughts about this?

Thank you very much in advantage for sharing
Bert

2

Hi Bert,

all these problems went away with ADL2 some years ago. See my post on the technical list.

- thomas

3

Hi Bert,

all these problems went away with ADL2 some years ago. See my post on the technical list.

Hi Thomas, what problem went away?

I cannot find an answer to my question in this reply. I try again

The question was, do I need to specialize an archetype to make it specific (lab-test, for example) so it will get a a specific ADL-path to a data-item which can be used in a query?
(I used the other text to describe advantages/disadvantages of the choice)

Can you please respond to this question?

Thanks
Bert

4

If you specialise an ADL2 archetype with a path like /events[id4]/items[id12], you will get paths like /events[id4]/items[id12.1] if you specialise the id12 node. A query engine can easily search for ‘id12.*’ (regex) or ‘id12%’ (SQL) to match data based on either the parent or the child. Note also that a ‘template’ in ADL2 is just an ADL2 artefact, with the same rules for paths, specialisation and so on. Here’s a simple example: parent archetype: child archetype: So, normally, you want to specialise and you will get appropriate search results, whether you use the parent or child archetype archetype paths as the search key. Does that answer the question? - thomas

(attachments)

fnbebnhionleikig.png
odhbknddicpllnlo.png

5

Not not really, and I am not looking for a defence, I am looking for a solution to a real life problem.
But I am sure, you will not give it to me.

I was asking people (using 1.4, majority of the openEHR users) how they deal with the choice: specializing or using generic archetypes, and what do they do with the archetype-paths.

This question is not answered. Thanks for trying.

Best regards
Bert

6

Thomas, I try once more. It is a really important question to me.
Suppose you have many specializations from one archetype (which can a choice in the lab-test-example), then this construct will not do.
You will not be able to distinguish one path from another, except for the archetypeID, this is the same in ADL2.

(the confusion comes from the other message I posted to the technical list, which was really another (but related) subject)

And below is my question, You did not answer it yet, I cannot recognize the answer to this in your replies.
ADL2 does not solve this problem.

7

The last option is advised on CKM, that is why I come to this question:

See: openEHR-EHR-CLUSTER.laboratory_test_panel.v0
It has in its use-description following: The name attribute of the Laboratory test panel/Result value element is normally replaced in a template or at run-time to carry the name of the specific analyte e.g. 'Haemoglobin'

This name-attribute does not appear in the archetype-paths, so it cannot be queried.

Or am I misunderstanding something?

8

Hi Bert,

Your question is timely as we are just about to put the lab test series of archetypes out for review along with some implementation guidance.

The approach we have decided to take at the international level (and in line with UK and Norwegian approach) is to work very largely with the generic lab test and lab panel archetypes rather than developing specific archetypes for various analytes and panels.

There are 2 reasons:

  1. Creating specialised archetypes for every analyte and panel variant would be an enormous effort for us to model.

  2. We know from experience that where( in the majority of cases) lab results are going to be pulled from an incoming lab message (probably HL7v2), working with a generic structure that is well aligned to the established V2 pattern, is much easier for integrators to work with, especially when there is enormous variation in the use of codes around the world.

We will be creating some specialised patterns when it is apparent that these are helpful but the aim is to stick with the generic set a far as possible.

This does of course mean that querying is reliant on the use of some sort of external terminology (LOINC, SNOMED) or controlled vocabulary i.e no querying on atCodes, but this is perfectly do-able in openEHR and AQL.

You can see an example of the proposed generic lab test pattern used in a template at

http://clinicalmodels.org.uk/ckm/#showTemplate_1051.57.92

In usage we are carrying the result analyte name ‘e.g. Creatinine’ on the /name attribute of the at0001|Result Value| node inside Lab panel.

This is fully queryable e.g.

select a_a/items[at0002]/items[at0001] as Result_value
from EHR e
contains COMPOSITION a
contains CLUSTER a_a[openEHR-EHR-CLUSTER.laboratory_test_panel.v0]
where a_a/items[at0002]/items[at0001]/name/defining_code/code_string = ‘365755003’ AND a_a/items[at0002]/items[at0001]/name/defining_code/terminology_id/value = ‘SNOMED-CT’
offset 0 limit 100

Based on implementer experience, I am pretty sure that this is the only sane approach at international level.

At national or application level, it might be possible to create specialised archetypes to mimic known specific analytes or panels but you would definitely want to do this in a way that was sympathetic to the external terminology driven approach above IMO.

Personally I would not create specialisations but use templates to overlay the generic pattern with known terms, by using default values. That is the approach we are using in the GEL project when we some lab tests are being entered manually, rather than via a lab-feed or where a report is constrained to carry very specific lab analytes.

Hope this helps,

Ian

9

Hi Ian, thanks for also recognizing this problem and your reply and explanation.

I agree that it is not doable to create a specialization for every lab-test possible, I was only joking to indicate how ridiculous that would be.
It would maybe be possible in another software-structure-situation, but that is not the case, and certainly not now.

I think it is a great help to renew the labtest archetype as you propose. It will make kind-of-labtest distinguishable on dataset-level which is sufficient.
(There will only be a problem for those labtest which have no LOINC or SNOMED code (yes, there are some)).

But when I look at the template you linked, and especially the laboratory result, there are two things which I don't understand.

The item items[at0002]/items[at0001] (Result Value) in this archetype has become a choice between Text and Quantity. Where do you leave the result value when you use that item to describe the SNOMED (or other) code?
And what do you do when there is no external code for the lab-test?
Wouldn't it be better to have it as separate fields?
One for the (choice between) Text/CodedText representing the kind of lab-test
The other for the Quantity result value.

A questions:
When do you expect this changed lab-test-panel-archetype in new version on openehr-CKM?

Bert

10

Hi Bert,

The item items[at0002]/items[at0001] (Result Value) in this archetype has become a choice >between Text and Quantity. Where do you leave the result value when you use that item to >describe the SNOMED (or other) code?

The name of the analyte is on items[at0002]/items[at0001] (Result Value) /name

The result of the analyte is on items[at0002]/items[at0001] (Result Value) /value

“archetype_node_id”: “at0002”,
“items”: [
{
“@class”: “ELEMENT”,
“name”: {
“@class”: “DV_CODED_TEXT”,
“value”: “Creatinine”,
“defining_code”: {
“@class”: “CODE_PHRASE”,
“terminology_id”: {
“@class”: “TERMINOLOGY_ID”,
“value”: “SNOMED-CT”
},
“code_string”: “70901006”
}
},

And what do you do when there is no external code for the lab-test?

This is not uncommon i.e local lab codes. I would either handle the local lab code as above, and put in a mapping to the equivalent LOINC/SNOMED code, or put the mapped code into
(Result Value) /name

Wouldn’t it be better to have it as separate fields?
One for the (choice between) Text/CodedText representing the kind of lab-test
The other for the Quantity result value.

We discussed this option but decided that using /name was a better fit for the way that we handle other observable-type names in other archetypes. e.g Systolic, pulse rate etc.

A questions:
When do you expect this changed lab-test-panel-archetype in new version on openehr-CKM?

It is already there…

http://openehr.org/ckm/#showProject_1013.30.26

We are (ably led by Silje and team + Norwegian lab / systems vendors) finalising the models but there are unlikely to be any major late-breaking changes.

Ian

11

Sorry Ian, the choice - icon displayed in the template representation on CKM misleaded me. Now I understand and I take back my question.

Bert

12

I must say, the use of the name-attribute for storing terminology surprises me. This opportunity never came to my mind.

It is a good option, it makes it possible to use clones in templates and still having a kind of terminology binding, although, not at the usual place, so a bit hidden.

It also allows distinguishing cloned archetypes in templates by its function.

It solves quite some trouble we have right now.

Thanks, you saved my day

Best regards

Bert Verhees

13

Hi Ian, I followed your advise, to use the name-property in the template to assign a name to the connected CLUSTER. That works fine, in the OET file is a property added to the connected CLUSTER archetype.

Now we need to make it a CodedText (because we need terminology), however, the template editor does not support that, to say, the interface does not seem to support that.

Now I can hack it into the OET XML file, but that is not acceptable for the customer I work with/for.

So the problem remains, using the (for example) lab-test more times in clone to the template, makes the different labtest available for querying, but only at the level of name, it is not possible then to add any way of terminology binding.

(Although the reference model supports using the the name-property, the template-editor does not support using a CodingText, like you

How can we solve that problem?

Thanks very much for your efforts to explain this. I wonder how others solve this, it looks to me a very common occurring problem, it is, I think, not very special to have the wish to LOINC-code a labtest, and using the generic labtest archetype.

It is also mentioned in the use-instruction in the archetype

Thanks very much
Bert