Usage of Blood glucose archetype for self-monitoring

Clinical (archive)
1

Hello,

i am involved in a project that supports diabetics in self-monitoring
their health status by collecting observations of daily living
(http://www.empower-fp7.eu/about/collecting-observations-of-daily-living/).

We are currently defining the knowledge models by using the archetype
methodology. I think the archetypes for Body weight, Blood pressure and
Medication action can be reused without problems for the purpuse of
self-monitoring by the patient.
As far as Blood glucose is concerned I am not sure if the labtest
archetype (openEHR-EHR-OBSERVATION.lab_test-blood_glucose.v1) is
appropriate for self-monitoring as it was defined as a labtest
originally. In contrast to the labtest that is performed on serum of the
blood, the patient measures blood glucose by using hand-held meter using
test strips and capillary blood. Therefore I doubt that the two
measurement methods are comparable. Moreover the whole Protocol section
of the existing Blood glucose archetype is dedicated to labtests and not
applicable to the self-measurement.

I would like to hear your opinion if the existing Blood glucose
"labtest" archetype should be used for collecting measurements done by
the diabetic himself, or if you suggest to introduce a new archetype for
Blood glucose self-measurements.

Thank you for any hints and comments.
Hans Demski

Helmholtz Zentrum München
Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
Ingolstädter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
Registergericht: Amtsgericht München HRB 6466
USt-IdNr: DE 129521671

2

Hi,
I agree with that. Indeed the test aren´t comparable. This creates the necessity of re-defining the concept of Blood glucose. I suggest to create an archetype such " blood glucose monitoring", that includes the different technics for glucose blood measurement , as “serum glucose measurement” mainly known as “Glycemia”, Home blood glucose monitoring (with glucometer) and Glycosylated hemoglobine, or something like that.

Andres Gamboa
M.D, Msc Biomedical Engineering

3

Hi

I would be interested in Ian McNicoll’s point of view. Personally, I do not find the measurement of blood glucose different for home monitoring as long as it is clear that this is the method. Self or carer entry of data, a device suitable for near patient testing - these could be at a clinic or done by a nurse or doctor.

I would use the blood glucose measurement for all measurements of this as I think it is the same thing. Others?

Cheers, Sam

4

Hi Again!

Well first i would like to say that this kind of discussions are very enriching for me since I can learn so much, from all of you. I´m young and very curios and with lot of things to learn. Don´t want to seem like I´m arrogant.

Regarding to EHR there are still lot of issues not resolved yet and one of the main problems resides in the difficulty of consensus in clinical concepts when one is trying to model the medical knowledge. I think that despite the possible controversy about the concepts (clinically speaking), what it is important in my personal opinion (And I would like to add that Im not an expert in the area, just very interested in this matter) is that the concept represented in the archetype must be clear enough to allow an accurate assessment. Since glucometers are biosensors they could have error, that depends of the device used to measure (and there are several) and sometimes they must be calibrated and so forth in order to make this measure more accurate and close to labtest results (gold standard). So comparing its results with labtest results can be misleading. That´s why in a previous email I suggested to treat them as different concepts. Now I suggest that maybe this matter should be discussed by clinicians that work in diabetes and reasearchers, and reviewed by engineers in order to find the most convienent solution, and in some way to standarize the concept. There´s a lot of people dealing with the same issue in diabetes. I think this link could be useful http://care.diabetesjournals.org/content/26/suppl_1/s106.long
There you can find the recomendations of the American Diabetes Association for blood glucose monitoring.

Lot of regards

Andrés

5

There’s a spectrum, from lab test done in the lab - sometimes on capillary (neonates!) , through to ward tests managed by the lab, through outpatient tests somewhat administered by the lab, through to outright home testing, maybe somewhat mediated by some commercial lab service in the background (even if just a manufacturer)

The important thing is whether the existing archetype allows the correct attribution, and allows the right kind of loinc codes for the method (or something else). Perhaps some judicious redefinitions to excise the “labness”?

Grahame

6

Hi all,

Hans and I had a discussion about this topic before he posted this and my (and also Heather’s) initial feeling was that it would be a shame if we require two different archetypes for one concept.

To me, the concept seems to be the same, even if measurement differs and with it the margin of error. I suggest that the margin of error is not suitable as a differentiator of two concepts.
If a different margin of error requires different archetypes, the same, at least in principle, would be required for lab tests in different labs with different machines etc (even if maybe the margin is not as wide) or for Blood pressures measured by different methods.

That said, it may well be that the lab test archetype needs some changes to accomodate the different methods (in a similar way as we differentiate the method for measuring a BP, e.g. palpation and auscultation in the archetype).
(At the very least the use and misuse needs to be clarified).
The RM has a “provider” attribute which may already be sufficient to differentiate the two cases.

If this problem turns out to be applicable to many other concepts as well, a more generic approach to document details about a lab-test with the ability to link the real concept may be required - maybe terminology can help here or slots.

Whatever we do, I think we need to be guided by the “One archetype per concept”-principle!
If archetypes need to be changed to be able to very clearly differentiate, search and filter by the one or the other type of measurement that is of course fair enough.

Cheers
Sebastian

7

Hi Hans, Andrés,

Very interesting question. We faced this issue when modelling for a
paediatric hospital and after some discussion decided to use the
standard lab_test-glucose archetype but considered adding a Method
element to protocol, to carry 'Test strip - visual; Test strip -
automated; Laboratory analyser' as internal coded tests.

It is certainly clear that we may need to identify the methodology,
and according to the guidance paper that Andres provided, we many also
need to specify whether this is a whole-blood or plasma /
plasma-calibrated measurement.

My own feeling is that we should try to incorporate these within the
same archetype. The general archetyping philosophy is try to try to
model the clinical record and not the device or methodology.

@Hans - I agree that there is a fair bit of lab-related overhead in
protocol but this would just be templated out, so that would not debar
use of the archetype for this purpose.

I look forward to hearing other opinions. I willtry ot get some
opinions from clinicians and other lab/diagnostics experts

8

Sorry to break in on a detail, but I think it is important. I changed the title.

Who is "we"?
Is that the same as "they"?
I think so.

I don't think that such a restriction does right to the complexity of health care-organization around the world, different cultures around the world, different business models, different users, different levels of education.

It is also my daily experience, people, companies do not let themselves restrict, they write archetypes whenever they want, and find for interoperability a message-format, like in the Netherlands, we have well defined HL7 messages.
And this is only the Netherlands and western Europe.
If in such a small piece of Earth, there is already dissatisfaction about, rebellion against, ignoring of this restriction, how will this be if other countries want to use the OpenEHR concept?

I think it will not work.
I think OpenEHR then will isolate itself, because that is not what many people want.

And also, regarding to multi-level modeling, there is no modeling at all, because the community does not allow the users to design.
The leading community ("we") wants the users to use their archetypes, not write their own.
What is then the difference with a classical software company where a product and data-structure is received, and requests for change from the customers, are impossible, or bring up many dollar signs in the eyes of the vendor.

I don't think the customer wants to know how a product is designed, if that is of no consequence for him/her.
Why the customers, if they would agree with this, would ever need an archetype editor is not clear to me.

It is the flexibility, and independence, no vendor-dictatorship, which are important reasons people in my environment use OpenEHR.
It works different in my environment, where maybe ten different software projects are using an OpenEHR kernel, people get inspired by the archetypes from CKM, the experience of the writers helps them, but they don't let themselves control by the philosophy of restriction behind.

I think, that "we/they" will lose the concept of a single-managed archetype repository. The kernel-concept allow the use of other archetypes and write own archetypes, and that is what people will do.

When "we/they" recognize this, than "we/they" can take measures to guide this process, because if it will not be guided, automatically, "we/they" get out of control.

That would be a pity, wouldn't it?

Have a nice day
Bert Verhees

9

Hi Bert,

Thanks for chipping in and giving me the opportunity to clarify and extend:

The one archetype per concept principle applies on different levels for me.
We were talking about the “international” openEHR archetypes at present, so what I really mean here is that within one consistent eco-system of archetypes there should only be one archetype per concept.

This one consistent eco-system can be anything from the “international” space via national and regional initiatives or your own system.

E.g. nationally, like Nehta, you may want to enable semantic interoperability between various national solutions.
That’s great. What is also great is that the knowledge gained by Nehta developing / adapting the international archetypes used as a starting point, can be fed back into the international space.

What “we” certainly aim for is that the “international” archetypes are more than a good starting point, namely that they are of such high quality and so comprehensive that you want to use them.
Initially, you’ll need to make some changes for sure, but the more feedback is incorporated into the international archetypes over time, the better they get (I hope) and over time I believe the requirement for changes diminishes.

There is no clear-cut top-down or bottom-up approach to get there, it is a rather messy inside-out long-term process based on opportunities that arise.
I don’t see a way around that. As you say, “we” [whatever “we” means] cannot nor want to restrict you or anybody else developing their own archetypes from scratch.

If your eco-system is the system you develop and your business doesn’t require you to look beyond your one system, then I would say that you don’t need to worry.
Take the international archetypes as a starting point (or not), develop whatever you need and be happy with it.
By all means even use a completely different modelling philosophy that uses ten different archetypes per concept if that is easier.

You say "It is the flexibility, and independence, no vendor-dictatorship, which are important reasons people in my environment use OpenEHR. "
Absolutely!
But one thing: interoperability is on a different level then in comparison to systems that are based on the same set of archetypes, e.g. for decision support based on it, etc.

Regards
Sebastian

10

Now, what is needed is a definition for the word “concept”. Because there is a lot of difference between a low education approach of some measurement at home and a complex measurement in the hospital, and even inside the hospital there can be differences, measurements done at the bed, measurements done in a lab. Archetypes must reflect the need of datastructure at a detailed level that is needed in a specific situation. So the concept blood-pressure is not fine grained enough, it must, for example, also indicate, blood-pressure measured by a home-user. Or you end up with archetypes full of optional structures: If done at home, skip 80% of the archetype. One of the arguments for Open Source is the Chinese saying: Let thousand flowers bloom. You can only learn from others if you give freedom to others. (Chinese people themselve could learn from their sayings :slight_smile: And in this perspective, CKM is very good, because a lot of knowledge come together, and the archetypes are very helpful for the people I work with, as examples. I don’t write archetypes, but I see a lot of archetypes, and I see people starting to write them for the first time, and I always point to CKM to help them. But there is a problem with the archetype-ID concept. People very fast write ID’s with obvious names. I always teach them to add their company-name, or projectname in the conceptname part, so there is some uniqueness in the names, but of course, this is no guarantee. But I don’t think we can solve this problem now. I just mention it. Very true, but I don’t see that work, only at a local level, where you feed a decision support system with the use of known archetype-paths inside that location. I am afraid, that is the daily reality, and I tend to think that it is unavoidable. But of course, this is only a personal opinion. But if I am right, then it would be good to do something with the Archetype-ID specification, to guarantee better uniqueness. Best regards Bert Verhees

11

Thanks Bert

The tension between sharing data and having a simple system do what you want it to do quickly has been a massive headache for the industry. Massive systems are configured wherever they are implemented - large meetings, ongoing discussions and the result is that it does something like that group wanted but may be not for long.

The alternative is to do this in a cooperative space and let the clinicians drive that process. The international aspects of the standardisation become clear but are not initially overwhelming.

The blood glucose reading is a classic example. We could have a lot of different approaches - but actually we want to compare blood glucose measurements and the method and sample are of minimal concern. They may be of major concern if the reading is abnormal or within a very narrow range (when the method and measurer might be very important). Clinicians may agree that near patient testing and laboratory analysis will come closer together rather than further apart as miniaturisation becomes the norm. I just saw a company providing something that will measure a heap of variables through the skin…not sure on the accuracy but I sense the investment provided means that it is likely to be good.

You did raise the issue of archetype IDs which remains an issue. We can control these in CKM instances but not outside, so we will have to be careful about this going forward. I would suggest that we configure the archetype editor to deal with local archetype names using a suitable additional name part.

We have talked about this a great deal and the difficulty with specialisation is the main issue. We may move to meaningless IDs (? within SNOMED). There is a proposal to record compliance with multiple archetypes to deal with specialisation. It does need to cater for local specialisation that never gets to the central archetype store.

Cheers, Sam

12

The alternative is to do this in a cooperative space and let the clinicians drive that process. The international aspects of the standardisation become clear but are not initially overwhelming.

I agree, and just for that reason, it does not look right to me to restrict clinicians to give their own vision on a specific concept, because then they may be forced to use a name which is already in use, and this is, of course, not permitted.

You did raise the issue of archetype IDs which remains an issue. We can control these in CKM instances but not outside, so we will have to be careful about this going forward. I would suggest that we configure the archetype editor to deal with local archetype names using a suitable additional name part.

We have talked about this a great deal and the difficulty with specialisation is the main issue. We may move to meaningless IDs (? within SNOMED). There is a proposal to record compliance with multiple archetypes to deal with specialisation. It does need to cater for local specialisation that never gets to the central archetype store.

And also, clinicians have no way to find out if a name is already in use, somewhere on the world, maybe even inside the same hospital.
It is the classical problem of using meaningful identifiers.
It is impossible to guarantee the uniqueness of an archetypeID, and clashes will be inevitable.

The argument of restricted eco-systems in data-exchange is a way around, but restrictive.

To avoid unnecessary restriction of information-exchange is one of the goals of OpenEHR.
To avoid restriction on knowledge exchange should also be one of the goals.

Meaningful archetypeID's are an obstacle in the context of these goals.

A solution would be that in stead of CKM as an archetype-repository, CKM would be a name-server for archetypeID's and concepts, and eventually, if people would want their archetype to be published and discuss it, it remains possible.

In that way, clashes are not likely, and the restrictions which come from the current situation are resolved.

This is just a quick idea which probably needs improvement.

Best regards
Bert Verhees

13

Bert,

Namespacing archetype ids is another possible solution if you want to maintain meaningful archetype ids.
(This requires some thinking as to when/if a namespace changes when the "controlling" organisation changes - e.g. if you offer to hand over an archetype of yours to the international space - especially if is in use by yourself.)

Sebastian

14

Bert,

Namespacing archetype ids is another possible solution if you want to maintain meaningful archetype ids.
(This requires some thinking as to when/if a namespace changes when the "controlling" organisation changes - e.g. if you offer to hand over an archetype of yours to the international space - especially if is in use by yourself.)

As far as I can see, this looks to me a very good solution. But there must be a controlling organization which registers the names.

Bert

15

And we are back to OIDs?

Jussara Rötzsch
Md, MSc
Director, OpenEHR Foundation
Owner, Giant Global Graph ehealth Solutions

16

I'd strongly recommend we implement the namespace approach ASAP.
I've recently did some modelling by reusing a mix of Nehta and openEHR archetypes - and had to manually rename archetypes with same name but slightly different content. Very confusing and un-maintainable.

Cheers,

-koray

17

I'd strongly recommend we implement the namespace approach ASAP.

I think so too, and to get it started, only the archetype-ID specifications need to be changed, and the ADL-parsers, perhaps, to be modified.

The next step must be a name-registration, and the kernel-specs need to be changed, so that, before accepting an archetype as valid, it checks at the name-registration if it is registered.

The registration involves good design, f.e. it must be able to check if a poster is allowed to use the a specific namespace.

I am glad my concerns are shared and I leave further thinking to the OpenEHR community.

As soon as possible, I will register my namespace rosa.nl :slight_smile:

Thanks
Bert

18

OIDs!!! Yes!!! We need them!! Please!

Greetings from Vienna,

19

OIDS are a possibility but I think reverse_urls are easier to manage
and understand for human beings. Archetypes end up as physical files
on people's systems and OID's become nightmare in these circumstances.

So something like

org.openEHR::openEHR-EHR-OBSERVATION.blood_pressure.v1.adl

Have a look at this presentation for some of the ideas floating about.
I have this a priority to present this formally to the community.

http://www.openehr.org/wiki/download/attachments/38895631/Clinical+Knowledge+Governance.pdf?version=1&modificationDate=1350405129538

Ian

20

Dear Ian,
OIDs are a requirement in some legislations, including the Austrian EHR space.
Can you please explain why they "become a nightmare"? I am sure they can, but I would like to hear your exact view.

I understand the OID is not the only "name" of the archetype, just one of the unique means of identification. On top of that you can of course keep any naming / file / structuring / keywording / etc measures in place as you need them, so that you can find your way on the PC and elsewhere.

Greetings from Vienna

Stefan Sauermann

Program Director
Biomedical Engineering Sciences (Master)

University of Applied Sciences Technikum Wien
Hoechstaedtplatz 5, 1200 Vienna, Austria
P: +43 1 333 40 77 - 988
M: +43 664 6192555
E: stefan.sauermann@technikum-wien.at

I: www.technikum-wien.at/mbe
I: www.technikum-wien.at/ibmt
I: www.healthy-interoperability.at