Propositions?

Technical (archive)
1

Hello All,

We are making incredible progress with the openEHR framework! Recently we faced a requirement to create patient-facing data capture tools. Unfortunately we can't seem to find a place in the openEHR model where these types of propositions fit cleanly.

For example if I have a patient intake form that has the question, "Do you have diabetes?" Obviously the patient's answer to the question could be modeled as an observation of "diabetes" mapped by the DV_CODED_TEXT datatype to SNOMED or ICD. However what I don't understand is how the proposition "Do you have diabetes?" should be modeled?

Should a "diabetes" archetype have a proposition field where a question can be stored as a string? How would multiple perspectives be modeled (i.e. question to patient, question to doctor, question to family member, etc.)?

Your assistance in helping me understanding this issue is greatly appreciated.

Kind Regards,

Matias

2

The archetype is the archetype and describes a specific concept.
It does not matter who is using the archetype to provide answer.
The author attribute will indicate whether it is the doctor or patient that filled in the slot in the archetype.

Gerard

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

+31 252 544896
+31 654 792800

3

I'd be very interested in a detailed explanation apropos to Matias' query.
Among other things, this question seems important for home monitoring contexts
as well as questionnaires filled out in the doctor's office.

Normally a contact note is attributed to a provider, so that takes care of the
idea that Dr X records Diabetes or Nurse J records diabetes. However, if Nurse
J is not *diagnosing* diabetes, but recording that the patient *says* they have
diabetes - well, that's different. Presumably the entry could be organised
under the Subjective component of the contact note (?). Nonetheless, it would
seem dangerous to assign the SNOMED or ICD *diagnosis* code for Diabetes (and
of what type?), since a subsequent query could pull this out of context as a
provider diagnosis. How is the best way to represent that 'the patients says
they were diagnosed with diabetes'?

All of the above might seem less academic if the disease in question were one
where the patient was more likely to be in error, or particularly to give a
false positive.

I assume that the prompt would NOT be modelled in the archetype, but perhaps
implied by the actual code used and otherwise left up to the application to
provide. (Again, I'm not sure - please enlighten me!)

Jim Warren

Assoc. Prof. Jim Warren
Advanced Computing Research Centre
University of South Australia
Mawson Lakes SA 5095 AUSTRALIA

4

Matias Klein wrote:

Hello All,

We are making incredible progress with the openEHR framework! Recently we faced a requirement to create patient-facing data capture tools. Unfortunately we can't seem to find a place in the openEHR model where these types of propositions fit cleanly.

For example if I have a patient intake form that has the question, "Do you have diabetes?" Obviously the patient's answer to the question could be modeled as an observation of "diabetes" mapped by the DV_CODED_TEXT datatype to SNOMED or ICD. However what I don't understand is how the proposition "Do you have diabetes?" should be modeled?

This is definitely an archetype question, and Sam or someone else will most likely post a good clinical response to this. What I will say for the moment:

* the reference model will allow you to do what you want

* if you want to capture user input which says "does / does not have X", then the X is in the question, or what we think of as the 'name' of the data node. So the ADL archetype fragment might look like:

LIST matches {
    items cardinality matches {0..*} matches {
       ELEMENT [at0045] matches { -- "diabetes"
          name matches {
             [local::at0145] -- "do you have diabetes?"
          }
          value matches {
             BOOLEAN matches {*} -- True and False allowed
          }
       }
       ELEMENT [at0046] matches { -- "hypertension"
          name matches {
             [local::at0146] -- "do you have hypertension?"
          }
          value matches {
             BOOLEAN matches {*} -- True and False allowed
          }
       }
       ELEMENT [at0047] matches {
             -- etc
       }
    }
}

In this archetype, the actual questions are expressed as archetype-local coded "terms" (try and do that in snomed!); this may not be necessary, if your software can generate sensible questions like "do you have <thing>?" where <thing> can be substituted from the archetype.

But - from a medical point of view, this is only summary information - it's only useful for the patients who say 'no', or for a summary part of the EHR. For those who say yes, you (or someone) probably wants to characterise their problem properly - since "has diabetes" covers NIDDM, IDDM, advanced, newly diagnosed, even gestational diabetes, if we take the question literally. Well...you know all this of course, the question is - how to model a more sophisticated version of this data? This is where a different archetype design is needed. The idea might be to capture diabetes information within a family history archetype; or a diabetic diagnosis archetype, or a general problem diagnosis archetype. I'll leave it to others to provide models for this.

The main point is to create data which makes for sensible querying. With the archetype fragment above, you have to query for paths from e.g. a problem diagnosis archetype where "diabetes" is part of the path (i.e. part of the names); then when you find instances of that, you have to find the ones with True as the value. If you capture data in the form name = "problem"; value = "diabetes mellitus", then you can query using the standard path something/something/problem and find instances with the value "diabetes mellitus".

- thomas beale

5

Matius

Thank you for your email. You are correct in your assertion. I have felt that this is not summary data and as an Entry should go in an archetype called questionnaire.

Archetype can then have a question and an answer. Such data is usually derived from the EHR in the long run - I call it cross sectional data - it is not persistent as it is false the next day if they are diagnosed tomorrow.

Observation
    concept = questionnaire item
  Element "Do you have diabetes?" value BOOLEAN

You may have many of these - I believe processing will need to be undertaken by the designer of the questionnaire - but these may with time become standardised. You could map the element term to the code for Diabetes Mellitus in SNOMED.

How does this sound?

Sam

Matias Klein wrote:

6

Gerard

The alternative suggestion is to allow the patient to add information to the EHR problem list - ie enter diabetes mellitus as a problem. It is true that the Entry will be known to have come from them. The composition will also come from them and unless the world changes a little - will not be accepted as valid without some clinical input.

Cheers, Sam

gfrer wrote:

7

Jim

Patients often report that they have diabetes and clinicians usually believe them. Infact it would be negligent not to without good reason. So we are used to doing that. Entering the problem in their problem list is something that increases the scope of the information.

We have added diagnostic criteria to diagnosis - so we might be able to keep track of these in future.

In the non communicating health world we and Jim are used to the scenario is more problematic. The future (and openEHR) will hopefully remove the need to enter data in multiple ways.

Specifically - openEHR can attribute the composition, the entry and the addition to the problem list. We believe this is sufficient. A patient reporting diabetes would not be entered as a diagnosis unless the clinician judged this to be the case. Recording that a patient said it is possible as free text, or as the answer to a question as I have stated earlier.

Cheers, Sam

Jim Warren wrote:

8

Hello Everyone,

Before replying I wanted to give this issue some serious thought. Ultimately I believe this problem comes down to rendering. Since I feel that proper rendering of archetypes is central to lossless interchange, IMHO this is going to have a major impact on the viability of openEHR as a widespread EHR interoperabilty standard.

Obviously Tom, Sam, and the rest of the openEHR team already recognize this issue because I noticed that the LOCATABLE class has a 'presentation' field which is modeled as a String. Unfortunately this is hardly enough for complete interoperability.

Enhanced viewing of information is essential. What if I want all users of my archetype to see information in the same way?

Clearly it's a great step in the right direction to be able to send an
openEHR document to another EHR system and have some degree of semantic
interop, but if the archetype can't be properly rendered, there is only marginal value in the transaction.

If a structured document fits the openEHR RIM (i.e. FOLDER -> SECTION -> ENTRY) then I can at least partially render it, but possibly not with
the correct style and context. Unfortunately, the result is only partial interoperability.

Coming back to the issue of propositions... A proposition can be thought of as merely a way to view concepts which are embedded within the question and answer. Tom already stated this. However, I feel the EHR should be able to extracted and compose these concepts into a final concise report or note.

Think about multi-dimensional questions for a moment:

     - Do you have X?
         - If so, when was it diagnoses?
             - If before 1930, did you receive procedure Y?

Granted this can be modeled as a questionnaire list with three separate
questions. However as a GUI designer, you only want to show the second and third parts when appropriate.

I know this can be delegated to the software, but if I "hard code" this
into my system, the same functionality will not be available to others.
  In addition, on someone else's system, presentation of the complete
tree of non-relevant questions could interfere with the understanding of
the relevant data.

In Thomas' proposed modeling of the patient questionnaire, each of the
three archetypes has its question modeled as the 'name' of the
archetype. As he noted, this leads to horrible paths (i.e.
/patient1001/history/past/do you have X?/).

In the end, the concepts we want added to the patient's health record are:

Concept 1: Has X (condition)
Concept 2: Received Y (procedure)

The result is a concise and clear addition to the patient's health history. Adding the three questions only clutters the practitioners ability to understand the patient's health.

I know this issue may be outside the scope of openEHR, but I
think the model should have a more elegant method of supporting it.
Perhaps some type of stylesheet include directive along with strong suggestion to adhere to an existing presentation standard should be added? Otherwise maybe some sort of mapping syntax between views and archetyped structures could be detailed?

You thoughts are appreciated.

-Matias

9

I don’t deal directly with clinical EHRs, but it seems one way to handle it would be to list it as diabetes, but also have a status field. The options could be:
diagnosed
probable
suspect
patient-reported
etc.

Then if you want to know who has diabetes, you can run a query on the SNOMED code + status= “diagnosed”.

10

Matias Klein wrote:

Hello Everyone,

Before replying I wanted to give this issue some serious thought. Ultimately I believe this problem comes down to rendering. Since I feel that proper rendering of archetypes is central to lossless interchange, IMHO this is going to have a major impact on the viability of openEHR as a widespread EHR interoperabilty standard.

Obviously Tom, Sam, and the rest of the openEHR team already recognize this issue because I noticed that the LOCATABLE class has a 'presentation' field which is modeled as a String. Unfortunately this is hardly enough for complete interoperability.

you are right that we do recognise it - and have for a long time. But the 'presentation' attribute is not really a reflection of what we think should be done about it; in fact it has been removed in 0.9 (to be declared officially any second now;-) since no-one can think of a way to define its contents interoperably.

The big picture, as we see it (and we are in no way expert on this yet!) is that there needs to be libraries of clinical visual components which can be a) assembled on the screen in real time to make friendly forms, and b) which formally related to underlying archetypes. So for example, you might define 2 visual components to display systemic arterial blood pressure - the typical terse one something like:

11

Hi,

XFORMS perhaps?
http://www.w3.org/TR/xforms/

Gerard

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

+31 252 544896
+31 654 792800

12

gfrer wrote:

  XFORMS perhaps?

http://www.w3.org/TR/xforms/

Gerard

What about Relaxatron?

http://www.xml.com/pub/a/2004/02/11/relaxtron.html

Unlike W3C schema it makes it simplifies the process
of defining constraints on structured documents.
The RelaxNG bit does the rules about document section,
subsection, data type, etc, while
the Schematron bit does the fancy stuff like data ranges, units
and co-occurance relations [e.g. if the patient is male then
don't allow the pregnancy section, etc]

I've been contemplating, on and off, how it might be compiled down
into web page GUIs.
The basic idea would be to serve and maintain the EHR as a single
XML document and apply stylesheets (CSS/XSL) at the client
[e.g. using Mozilla or IE6] to make it
interactive or not as the case may be. In effect any GUI interaction
on the client - through FORM variables etc - would be editing the
XML document locally. Eventually the client uploads back to the
server where the 'exact-same' RelaxNG-Schematron rules would be
used as a check to validate it or not.
If the GUI is implemented properly- it would always validate.

As far as I can see this will need more than mere stylesheets on the
client - it will need scripting (Javascript urgh!). In particular,
if the FORM is going to assist the user make choice then some how
the selection of choices needs to accompany the arrival of the XML EHR.
I.e. the population of drop-down menus is not part of the patient's
record it is part of the assistance-to-the-medic and IMHO would be
the stuff that 'clinical visual components' [See Thomas Beale above]
are made of.

Just my eurocents worth :slight_smile:

\Gavin

Gavin Brelstaff - BioMedical Area, CRS4 in Sardinia
Loc. Pixina Manna Edificio 1,
C.P. n.25, 09010 Pula (CA) Italy.