Shared blood glucose (+HbA1c) templates?

Hi!

If I understand things correctly, the old archetypes…

…have been rejected and replaced by the more generic pattern using terminology e.g. LOINC or SNOMED CT combined with the archetype…

…as shown in e.g. the “glucose parts” of the templates…

I believe this is good and a sensible pattern to make e.g. maintenance and querying easier. However without shared templates several people/projects need to reassemble the pieces over and over again, possibly with slightly different structural and semantic choices.

Questions:

  1. Is the above description of the design intentions correct?
  2. Don’t you think it would be smart to internationally share a terminology bound glucose template based on Laboratory test result (the OBSERVATION archetype including the CLUSTER, not based on a COMPOSITION) that could be reused for many use cases where glucose is needed.
  3. Does anybody happen to have (or be wanting to quickly assemble) and be willing to share such a template based on openEHR-EHR-OBSERVATION.laboratory_test_result.v1
  4. Can such a template include a choice of fasting glucose , measurements after meals etc? And reusable modelling about glucose/insulin challenges?
  5. Would anybody happen to have a template for HbA1c?

Pick one or several questions to answer or comment :slight_smile:

3 Likes
  1. Yes
  2. Sure
  3. Yes
  4. Yes, although details about the challenge (glucose/insulin, dosage, route, etc) might need a CLUSTER archetype which hasn’t been modelled yet
  5. Yes

https://ckm.openehr.org/ckm/templates/1013.26.383

4 Likes

I have suggested doing just this for (say) the top 20 lab panels used ubiquitously in medicine. This means that OPTs could be obtained very easily for the common biochemistry & blood results with almost no design work.

Separate issue: ideally, the lab analyte archetype would have been specialised based on data type (DvQuantity, DvBoolean etc) as well, because that makes lab modelling easier (this is how Intermountain does it, works very nicely).

1 Like

I support this approach. If the archetypes is made to generic they become more like a reference model. I would like to see more concrete archetypes defining such concepts like the 20 most used lab tests.

I disagree!! It becomes very hard to do lab imports because you have to specifically detect those top 20 archetypes by picking up the incoming lab codes, then specifically map these to different archetypes, but handle all the other gnerically. (and there is no fixed top 20 internationally - every lab uses different codes, units etc, the messages carry all sorts of other variable data etc.

There is a place, perhaps for trying to create some embedded templates that pin down some of the semantics but it will be very, very hard to do that internationally. Or a lightweight way of associating a LOINC code with units but more as a lokk up than creating specific archetypes.
It might work for InterMountain because they can pin down their labs to specific use of LOINC codes etc

It is also a lot of work!! Querying becomes harder too because you can’t just query by e.g LOINC code - you have to know exactly what archetype is being used.

The rationale for the current approach is described here https://ckm.openehr.org/ckm/document?cid=1013.17.116

2 Likes

Could you elaborate please? I don’t understand what specialised based on data date means.
Side questions, does intermountain use openEHR?

1 Like

It should be fairly easy to create this as templates, loosely based on the one I uploaded today and linked above. I disagree we should specialise archetypes for this purpose, for the reasons pointed out by Ian. Most of the work involved in creating the templates would probably be to identify the correct concept codes, in all the different coding systems in use for lab results (LOINC, SNOMED CT, NPU, etc, etc).

1 Like

I think we might be at cross-purposes here. My suggestion is to just use the archetype structures that are there, but to template them into well-known panels, with all the relevant codes pre-chosen. In actual use, most or all of the analytes would still be optional, for obvious reasons.

So when you receive results like that, the archetypes are the same as for anything else, but the templates just make life easier for devs dealing with that very common data.

I’ve actually modelled all this out in the ADL workbench (ADL2) a couple of years ago - works fine.

1 Like