Encoding concept-relationships in openehr archetypes.

Technical (archive)
1

Dear Tom et al:

This is my "de-lurking" for the list. For those of you who dont' know me, I'm
a computing academic whose area of interest will be adequately characterised by
my question...

I'm trying to represent the structure of "normal" values of fields in
archetypes. I can see that there is of course some provision for a set of
allowed values, a default value and (in quantities) min and max. I want to go
further (because the information could be very useful in the user interface and
to integrate with decision support).

For instance, I'd like to design fairly specific chronic disease management
archetypes. Without worrying whether it's clinically particularly worthy, take
as a convenient example the hypertension in diabetes algorithms at
http://www.tdh.state.tx.us/diabetes/algorithms/PDFfiles/HYPER.PDF.

My PhD student, Sistine Barretto, has made a map of the relationship of
concepts from that guideline (see
http://winston.unisa.edu.au/demo/Share/Ontology.doc - and the goal here is not
to get too picky about the use of the term "ontology" either).

From this analysis it falls out (unsurprisingly) that there are a set of drugs

(in particular, some drug types as well as a set of generics organised into
types) that are in the scope of compliance with the guideline. There are also
some relevant comorbidities and various other concepts (observations and
actions).

How can I (should I?) represent the set of likely (in scope) drugs such that,
for example, a user interface could put them as options in a menu?
Furthermore, how can I relate the comorbidities and other indications for the
drugs to the values for a drug name field in a specialised medication
archetype?

Admittedly, I'm slipping into the realm of decision support, but I think it
really is simply the structure of the domain of normal values in this specific
application. I'd like to use archetypes to represent this, just as a I might
use them to represent the min and max of a given quantity. Is the capability
all there already? If not, what's missing?

Cheers,
Jim Warren

Assoc. Prof. Jim Warren
Director, Health Informatics Laboratory
Advanced Computing Research Centre
University of South Australia

2

Hi Jim,

Sistine's document looks good. Unfortunately, the information being
presented
does not lend itself to a two-dimensional format. Combining information
sources/handling and decision-based processes and structuring them into a
presentation format is tough. Any attempt to do so is helpful, however,
developing an active presentation for a Practitioner is more difficult.

DRUG DATABASES
Electronic prescription is an area of interest. The commercially available
drug
databases do not include all potential/known side-effects, e.g., some cover
around 70%. They also do not provide adequate warnings that this is the
case.

These same drug databases are selective in what drugs they include and do
not include all known derivations and names.

Hence, building a UI that places 100% reliance upon such a drug database
would produce non-trivial "errors and omissions". To make such a drug
database useful additional information would have to be provided to the
Practitioner so that an individual decision could be made.

This database becomes a tool in the hands of the practitioner who must then
decide what to do with it. Precise, consistent decision support becomes a
victim.

This is unfortunate as in the omission of many compounds and techniques that
are in common use and have been selected because of their beneficial
effects.
Practitioners may in need of information related to these non-standard items
and if they are, the 'roadmaps' provided are not going to be effective.

SPECIFIC CHRONIC DISEASE MANAGEMENT
Developing an archetype (pattern, model, prototype) is really a good idea if
it
includes the Patient and accepts variability and responses therero.

I lost track of the number of people who have been on a program that has
made one or more aspects of their life totally miserable. In some cases this
cannot be helped; in others the response of the practitioners has be to
modify the drugs being consumed and/or prescribing additional drugs.

Success must be measured by the Patient showing up for the next appointment.
My focus is on Patient Centered Healthcare. Current programs, in my opinion,
are running 'open-loop' (started professional life as a control systems
engineer).
Nature, as well as aircraft and rocket systems vendors, run 'closed-loop',
which means that information is returned to the source so that decisions can
be
made regarding performance and effectiveness.

One would avoid taking a trip on a commercial aircraft that avoids this
technique. Perhaps people seek out herbalists because all they get from a
medical Practitioner is another prescription, ignoring the current situation
where the Patient cannot pay for the drugs.

The UK NHS audit show that a substantial percentage of the drugs prescribed
for Patient after surgery get entered in the circular file upon exiting the
hospital
(I believe about 75% was reported). That should be a message to someone.

One would not want to run an economy nor a government 'open-loop',
exceptions for certain groups, yet Patient feedback is regularly prevented,
ignored or voided, e.g., HIPPA regulated permit Patient access and
modification
as many other do now.

Patient feedback is not all that difficult to accommodate. Automatic medical
diagnosis software applications have been handling it for years. The
efficiency
has been notable, along with the increased Practitioner productivity. I am
NOT
advocating elimination of the Practitioner; rather the inclusion of Patient
feedback,
onsite or not, and its integration into diagnosis and treatment.

I remain searching for answers to the questions:
1)How does one measure the performance of the Healthcare industry?
2)How does one measure the effectiveness of diagnosis and treatment?
3)How does one handle change? (variability?)

Each of these must include the Patient. Maintaining robots involves
feedback;
however, this is usually accomplished by different personnel.

Funny scenario:
A robot that has been modified to exhibit symptoms related to a severe
chronic
disease. How would the Engineering Technician handle this? How would the
Medical Technician handle this?

Feedback is essential to proper diagnosis and treatment.

Good effort! Good luck!

-Thomas Clark

3

Thomas,

DRUG DATABASES

Electronic prescription is an area of interest. The commercially available
drug databases do not include all potential/known side-effects, e.g., some cover
around 70%.

These same drug databases are selective in what drugs they include and do
not include all known derivations and names.

This database becomes a tool in the hands of the practitioner who must then
decide what to do with it.

drugref.org aims to become such a tool

Karsten

4

Hi Karsten,

Appreciate the posting! I would like to see this and similar projects
expanded
and globalized.

Would really like to see non-prescription and herbal medicines integrated as
well. The Open-source developer community should start such a project
(e.g., sourceforge.net).

Another suggestion would be a project to perform Quality Assurance on these
drug databases, since the Healthcare Community seems to presume
correctness.

Just more rambling!

-Thomas Clark

5

Thomas,

I would like to see this and similar projects
expanded and globalized.

Would really like to see non-prescription and herbal medicines integrated as
well. The Open-source developer community should start such a project
(e.g., sourceforge.net).

drugref.org IS globalized ?
drugref.org IS open source ?

Anyone is free to suggest/add herbal/OTC medicines ?

Another suggestion would be a project to perform Quality Assurance on these
drug databases, since the Healthcare Community seems to presume
correctness.

The internal structure is based on levels of open peer review.

Karsten

6

Hi Karsten,

Apologies! Should have explained myself better.

drugref.org was published 1/26/2003. It needs additional publication
and time before acceptance and receiving participation from people with
a 'medical, pharmaceutical, or biochemical degree'. It needs expanded
scope as well since side effects are major concerns with drugs and
drug databases.

Since I have a collection of Engineering, Computer Science and Law
degrees, plus personal experience, I am not included within the
stated membership. Restricted globalization might be a better title.

As for open-source, this is one area where source code control is a
necessity. SQA (Software Quality Assurance) has stringent
requirements often not met with open peer review.

-Thomas Clark

7

Jim

I believe that archetypes will be what decision support and the EHR share -
these models enable the sort of generic functionality that you are looking
for. The question then is - what knowledge should be in the archetype, and
what should be in a knowledge base.

Normal values is very problematic to put into the archetype for the
following reasons:
1. They vary with age and other person characteristics
2. They vary with national attitudes and values
3. They vary with units and measuring devices

So, my answer is that you are slipping into the realm of decision support,
but that the sort of values you would like to get at in the EHR should be
expressed as archetypes (and paths).

Cheers, Sam

8

Thomas,

drugref.org was published 1/26/2003. It needs additional publication
and time before acceptance and receiving participation from people with
a 'medical, pharmaceutical, or biochemical degree'.

True.

It needs expanded
scope as well since side effects are major concerns with drugs and
drug databases.

I am sure the drugref people would like to hear your
suggestions.

Since I have a collection of Engineering, Computer Science and Law
degrees, plus personal experience, I am not included within the
stated membership. Restricted globalization might be a better title.

Ah, well, this time you're reading too much into the letter
:slight_smile: I am quite sure Horst/Ian would openly welcome your
participation.

As for open-source, this is one area where source code control is a
necessity. SQA (Software Quality Assurance) has stringent
requirements often not met with open peer review.

One idea was to have med/pharm schools make their students
adopt a drug as an assignment and take care of that drug for a
semester the data being reviewed by an (assistant) professor
or some such (not my idea but rather, I think, Tim Churches'
or Tim Cooks or ...). Given enough schools doing this the
quality would be pretty high. Still, commercial firms may want
to sell the service of independantly reviewing the data and
reselling that review/"approval" which IMHO is fully legal with
drugref's current license.

Karsten

9

Hi Karsten,

At all levels (e.g., records, applications, storage/retrieval, security) it
would be beneficial to enlist the aid of SQA Engineers in an attempt
to break the code. Better before than after.

I'll see if there are some of these folks with spare cycles.

-Thomas Clark

10

This is a post we didn't resolve, and I would like to re-address the question. Unfortunately, I cannot resolve either of your links Jim...can you provide new URLs?
- thomas

Jim Warren wrote:

11

Hi Tom,

Hypertension guideline can now be found here:
http://www.tdh.state.tx.us/diabetes/PDF/algorithms/HYPER.PDF

Ontology doc should now be accessible (server was down I think):
http://winston.unisa.edu.au/demo/Share/Ontology.doc

Cheers,

Sistine

12

Hi,

Is it?
Is it about how to represent the domain "normal values"?

Or is it more general: Are concepts related?
Then the problem is: what relations are there between concepts (archetypes)?
What semantics of these relationships between archetypes (concepts) do we
need to describe reallity (including decision support)?

Gerard

Admittedly, I'm slipping into the realm of decision support, but I think it
really is simply the structure of the domain of normal values in this
specific
application. I'd like to use archetypes to represent this, just as a I might
use them to represent the min and max of a given quantity. Is the capability
all there already? If not, what's missing?

-- <private> --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800

13

Gerard

I am using the term 'assumed' value in the archetype editor. This seems
helpful as it means that it does not have to be recorded and it is normal
practice. A single BP reading is assumed to be sitting - possibly lying -
but not standing. Weight is assumed to be measured in light clothing and
without shoes...

For legacy systems this approach seems beneficial as there will be a lot of
data missing!

Cheers, Sam

14

Hello all,

I recently had a little free time to read you: thank you for your work !

Thomas Beard gave me a brief archetype "short definition" (still in use ?).
It was: "concepts defined by constraints".

One formal remark: usually constraints (i.e. Horn clauses) can freely be added, so the model is open to expansion without reconception (adding constraints to a set reduces the size of the set, and does not redefine it).

By this way, an archetype could address at least 3 functions:
A* serve as a possible definition of the concept: so retrieve information even when it is not explicitly specified;
B* serve as a definition of what a concept possibly underlies: so, let the possibility of proposing a data input prototype;
C* serve as a definition of what a concept needs to be correct: so, check the correctness/acceptability of an input;

Some examples/explanations of what I mean (sorry for my poor translation):

"proteinuria", "declive oedems", and "hypoalbuminemia".
     So I may search for in a specific record or set of records.
     And so, if I also have another definition of the same concept, my research results will possibly be a wider set.
     Remark: This function/spec applies to data retrieval and mining (and may be used for verifying data correctness), but does not affect the existence of the EHR, nor the openEHR standard as an EHR data transmission and interoperability standard.

B: I have recently discovered the evolution to separate the notion of (data input) information prototypes. (Ph Ameline will recognize the concept of "fils guides"). I strongly support this notion. I add the idea that, in some cases, information prototypes could be deduced from specified archetypes.
     Remark: This function/spec also applies to EHR applications "in use", but does not affect the existence of the EHR, nor the openEHR standard as an EHR data transmission and interoperability standard.

C: Analyze the correctness/ acceptability of data.
     What for ? a few examples:
     * Accept data input; for example,
        > accept only valid values of glycosemia (which implies having recognized the concept),
        > accept toxoplasmosis serology prescription to gender female/ possibly pregnant people (which means ability to search the corresponding information in the EHR, and also means the possibility to force/violate the constraint : ie facing a suspect retinopathy);
     * Trigger events/alarms/reactions on data occurences: for example,
        > beep when systolic blood pressure is under 5 (which means having the specification of the range of normal values);
        > beep when a cephalosporin is prescribed to a patient allergic to beta lactamins (which means dealing with ontologies);
        > beep when a patient's size/weight ratio indicates obesity (which means dealing with formulas);
     * Validate / Propose posology: for example,
        > compute the mg/kg ratio and propose the according posology of a relevant treatment;
        > compute the corporal surface ratio and propose the according posology of a relevant treatment;
        > compute the creatinin clairance ratio and propose the according posology of a relevant treatment;
        in a more general form, facing a treatment, compute the relevant ratio/ bounds and propose the according posology;
        > compute cost/ complications/ efficiency ratio and propose alternative treatments;
     * Check/Transmit for the visibility of data to users. for example,
        > tell that patient habits in an EHR (for example: "zoophilia with a macacus rhesus") may be transmitted to a concerned physician ("infectious disease ?") but not to a non-physician (nurse ?, social worker ?, boss ?, wife/husband ?, family ?, moral league ?, health insurance provider ?, bank ?). The EHR is not/must not become the way to practise a coming out. This applies to EHR "in use", but also to transmitted EHRs.

In my meaning, some archetypes applies to EHR data (for examples, the patients tells the physician: "this is not to be transmitted" or "this is to be transmitted to physicians only", or "my religion is to be transmitted to the concerned nurse") and some may apply to all EHRs.

I would suggest the future standard to be :
* simple -initially, as simple as possible, so it could be quickly generalized-;
* open to evolution/adaptation;
* open to increase of the archetype/prototype database by addition of archetypes/prototypes;
* open to the electronic transmission of archetypes/prototypes in electronic form (and within EHRs);

> Or is it more general: Are concepts related?

Yes

> Then the problem is: what relations are there between concepts (archetypes)?

Do we need to define them all in the standard (if yes, we are sure to omit some) ?
Can't we nominate a "archetypes relationships ontology group" to do the work,
publish his work in a pre-adopted, free "general relationships ontology",
and concentrate on what a generic relationship is ?

> What semantics of these relationships between archetypes (concepts) do we
> need to describe reallity (including decision support)?

Is this a priority ? Is it needed to publish the standard (my idea/Murphy law:
"any exhaustive enumeration only takes an infinite time to enumerate").
May be using cases and generalizing...