|
I
would have thought this would be a frequently used pattern for recording pre-EHR
notes into a patient history, and "Duplicate" would be more exactly expressed as
"Data extracted from primary record"
Since
that data would be used by a query, the query should return both sections and
leave the application (and user) to decide which to
display.
Regards,
Colin
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 |
This e-mail message has been scanned for Viruses and Content and cleared by
MailMarshal
IMPORTANT NOTICE: This e-mail and any attachment to
it are intended only to be read or used by the named addressee. It is
confidential and may contain legally privileged information. No confidentiality
or privilege is waived or lost by any mistaken transmission to you. The CTC is
not responsible for any unauthorised alterations to this e-mail or attachment to
it. Views expressed in this message are those of the individual sender, and are
not necessarily the views of the CTC. If you receive this e-mail in error,
please immediately delete it and notify the sender. You must not disclose, copy
or use any part of this e-mail if you are not the intended recipient.
|