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
============
Matias Klein
Ethidium Health Systems
3993 Huntingdon Pike - Suite 108
Huntingdon Valley, PA 19006-2623
USA
Office: (215)938-8630
Fax: (215)938-7301
http://www.ethidium.com
Thomas Beale wrote:
> 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
>
>
>
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
