Re: Differential display

[Sam Heard <sam.heard@oceaninformatics.com>]

Title: sam.heard signature

Hi Andrew
In Australia it is the MD2 use case - but not only MD2. We will see this amplified with CDA where sections have the text and there is no effort to display the duplicated structural information. You are correct - if the textural note kept a link to the structured content then it would allow us to determine which was duplicate.

The problem has arisen as the degree to which information is duplicated in the textural note differs - sometimes it is 100% (eg MD) and in other applications it is not. So some want to display the text and non-duplicated data.

It was my feeling that we would do well to have a section that people can display as they wish that allows this to be expressed.

I am not so concerned about the section name - my real point is that we need to agree:

Do we have a section which contains the non-duplicated and duplicated data - so there is a link between them (even if the application cannot maintain this or it has come from CDA) or do we just have a simple section for duplicated structured data. The problem with a simple section is we will not be able necessarily to validate what the issue is if it is free standing.


So the two options would look like this:

Option one (Compound section)

SECTION: Duplicated
    SUBSECTION: Primary
          Document: "Saw JJ today and seemed OK. A cough for 2 weeks. Temp 36, BP 146/82"
    SUBSECTION: Duplicate
          Symptom "Cough"
               duration "2 weeks"
          Temperature 36 C
          Blood pressure
                systolic 146
                diastolic 82

OR

Document: "Saw JJ today and seemed OK. A cough for 2 weeks. Temp 36, BP 146/82"
SECTION: Duplicate
       Symptom "Cough"
            duration "2 weeks"
       Temperature 36 C
       Blood pressure
             systolic 146
             diastolic 82

As you can see, I favour the former.

Cheers, Sam



Andrew Patterson wrote:

Actually the use case is as follows:
    

We can call it the MD2 use case! :)

  

This may not seem idealistic but this the reality of what existing systems
do and existing users are used to.  If openEHR is to be taken up by existing
system vendors and accepted by their users, we must support this existing
non-idealistic paradigm in a way that does not too much overhead on the
system and its implementers.
    

I don't understand why this requires anything special at all regarding
archetypes? Surely it is a composition with some sections, and in
those sections might be an uncoded 'story' about the encounter, and
then some other coded archetypes.

If there is duplication of information, then IMHO
they will need to see the duplicate information - once, as you say, they have
copied the structured content into the note as text it has indeed lost its
connection to the original data. I can't see how you could in good
faith then indicate that any of the coded structured data is
'duplicate' information unless you could
actually ensure that the text is also still present in the uncoded
story - and if you can do that strong linking check with
any degree of reliability then the whole problem doesn't really exist?

Andrew
_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


  

--

	Dr Sam Heard Chief Executive Officer Director, openEHR Foundation Senior Visiting Research Fellow, University College London
	214 Victoria Avenue Chatswood, NSW, 2067 Phone: +61 2 9415 4994 Mobile: +61 4 1783 8808	21 Chester Cres London E8 2PH Phone: +44 20 7249 7085 Mobile: +44 77 9871 0980

_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical