Differential display

Clinical (archive)
1

Dear All (cross post)

We are working in an environment where many applications and CDA messages have information that is displayed as text and repeated information in structured form. This also arises in applications which have a formatted document plus structured information (typically in primary care).

I am proposing that we have a section archetype to manage this. The archetype display script would not display any information about the section itself (it would be invisible) and would display the first subsection but not the second. The section archetype would be:

  • Differential display

  • Display

  • Entries here will display

  • Non-display

  • Entries here will not display
    This does mimic the CDA approach but does have the added benefit that the displayed information can be structured as well (a requirement from our customers who want to mix the textural content and structured medication orders (ie not duplicate these in the textural display).

If this archetype arrived somewhere where it was not known the generic display script would show the non-display information (twice). This would be unlikely to cause errors especially as there would be a heading Non-display.

So that is the approach that we have considered. There is an alternative - just have a non-display section. This has the advantage that it could be added when required on an adhoc basis. The major problem that I can see is that it would not be clear which part of the record held the information that was redundant (ie where it was being displayed).

I would be interested in people’s views of this approach to the redundant structured data problem that arises from CDA and word processor style record applications.

Cheers, Sam

Cheers, Sam

(attachments)

OceanInformaticsl.JPG

2

HI,

Am I wrong to observe that the differential is not Display and Non-Display,
but Structured and Non-Structured?

The problem with the suggestions by Sam is that part of the information that is received is not visible.
In order to accept data from a third party I need to see and judge both the visible and invisible parts of the Template.

Gerard

– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

3

I am not sure we can be certain that the structured data is definitely
repeated or that one or other section is redundant I would tend to go
with Gerard's suggestion of structured / unstructured and leave the
issue of what to display to the consumer.

Ian

Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian@mcmi.co.uk

Clinical Analyst - Ocean Informatics ian.mcnicoll@oceaninformatics.com

Consultant - IRIS GP Accounts ian@gpacc.co.uk

Member of BCS Primary Health Care Specialist Group – www.phcsg.org

4

Hy!

I like this. CDA work is active here in Austria, and I would be very happy to see anything that connects CDA to archetypes.

You might then have to deal with nested archetypes, like how does a specific piece of information (an existing archetype) look within a CDA section (to be developed in the exercise you suggest) ?

Could this be done on some examples, eg. discharge information, laboratory reports, radiology reports, medication?

These are part of the Austrian EHR and would possibly attract an Austrian workforce with a bit of support. I myself can speak for the laboratory report, and we would try to participate actively and contribute.

See you around,

Stefan Sauermann

(attachments)

OceanInformaticsl.JPG

5

Hi everybody

I know CDA which requires all information to be in human-readable, textual form (Level 1). Optionally there can be references to machine-readable entries (Level 3). This design makes sure no information is disclosed from a clinician that views the document only with as simple XSLT-transformed XHTML.

I must admit I didn’t quite understand the use case.

This does mimic the CDA approach but does have the added benefit that the displayed information can be structured as well (a requirement from our customers who want to mix the textural content and structured medication orders (ie not duplicate these in the textural display).

Maybe you could explain it a bit further.

But in general I feel - probably similar to Ian and Gerard - it is not a good idea to bring view-related stuff into an archetype. Thus, I wouldn’t call it “display” and “non-display”.

However, think the there is a gowing need to have a possibility to easily use archetypes together with HL7 CDA. As Stefan also pointed out, many national ehealth programs have opted to use this part of HL7v3! This is a chance for openEHR as it is way ahead of the HL7 template initiative with respect to clinician involvement, which is crucial.
So maybe, we could discuss whether to create an CDA-compatibility SECTION archetype with a Level1 and a Level3 section.

Cheers, Thilo

6

I won't contribute much to this discussion, except to say that the
'problem' here is /duplication/ of information - that is, the same
information occurring in a document or being created in a system in two
different ways, usually narrative and structured, but not always this
combination. CDA is always constructed of narrative, with optional
structured content which in theory duplicates the narrative content, or
may be a subset of it. The problem for clinicians therefore is to get
rid of the duplicate stuff for display.

So the need to display or not is a consequence of the duplication which
is the underlying problem. Perhaps a better name for the 2 parts would
be 'primary' and 'duplicate' or 'alternative rendition' or similar.

- thomas

Thilo Schuler wrote:

7

Actually the use case is as follows:

As part of a clinical encounter the practitioner authors a textual clinical
note to be included along with structured content. BP is entered in a
structured form and the system copies the result into the textural clinical
note automatically as is done in a lot of existing clinical systems (which
are traditional primarily texturally oriented, with a little bit of
structured data). So the textual clinical note contains a combination of
manually entered content and system generated content from structure
content, the user has the ability to edit and remove the auto generated
content which may deviate from the original content entered in a structured
manner. Therefore, the textual note and the structured data need to both be
viewable because there is no way of knowing what structured content was
duplicated in the textual note and what original content was manually
entered in the textual note. Once the structured content is copied into the
textual note, it has lost its connection with the original content.

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 would suggest that duplication of data is better than accidently hiding
data, especially when the users are used to having two ways of displaying
the same data.

Heath

8

Hi,

I agree with Heath’s opinion.
It is better to present both alternatives and let the application/user decide what he wants to see in reality.

But for admission to a record the rule must be: see and inspect both before accepting.

Gerard

– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

9

Ok - so we know that some data are duplicated, but not how well, or to
what extent. If Sections were used to mark this, ten it is up to the
applicatoin to decide how to render it. A safe rendering might be to
mark the 'duplicated' section in some way - e.g. a line around it and
"(duplicate)" somewhere - how this is done is up to the application
system. Hiding may be safe in some environments that are dealing with
content whose creation they know about, but it is always the choice of
the application.

The thing to remember if Section archetypes are used is that the
presence of this duplication thing must be known ahead of time, which it
sounds as if it normally would be, because it is to do with how
applications are constructed.

- thomas

Heath Frankel wrote:

10

Dear All,

If we are to take forward this important area we must first confirm
the requirements. These are not clear from the discussion so far.

A detailed consideration of this topic took place during the
development of EN13606-1, including examination of CDA R2's approach.
You might therefore wish to review Part 1 in taking forward this
topic. I would be interested to learn of relevant requirements that
this does not meet.

With best wishes,

Dipak

11

It is true that “CDA which requires all information to be in human-readable”.
We had a case where we naively felt that it might be useful to display the “same” information in a different way.
In the laboratory report many will very likely code the single lab test using LOINC, or SNOMED, or both, in CDA level 3. The human user will not be interested in this code, so it does not go to the screen. On the screen the descriptive text is displayed, out of the LOINC database.

Things get complicated when

  • there is no LOINC / SNOMED Code available, because the test is new and not coded yet
  • there is a LOINC Code but there is no translation of the decriptive text available.
  • you optionally want to add the laboratories own old and proprietary code and description, just machine-readable, so that readers can still match the results to older existing reports and generate trends.

There might be similar cases where you want to hide some of the more machine-readable parts of the information from the user, and want to express a very clear relation between the machine-readable part and the human readable part.

Would that be an argument for something in the line of “display” / or “non -display” things in an archetype? (You might call it differently).

See you,
Stefan Sauermann

12

Actually the use case is as follows:

We can call it the MD2 use case! :slight_smile:

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

13

Woops, forgot to CC the clinical list as well..
(make sure you fix the to/cc if you reply to this post or
I will have created some sort of cross post list monster)

Andrew

14

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:

(attachments)

OceanInformaticsl.JPG

15

From discussions on the technical list:

It appears the best approach is to have a section which has two subsections
Duplicate
Primary
Duplicate

We would leave the display concerns to the environment but a simple display script for such a section would involve displaying data in the first section and either not displaying the second or displaying it in small text in a box or on a tab or something.

Does that sound OK?

Cheers, Sam

Andrew Patterson wrote:

(attachments)

OceanInformaticsl.JPG

16

Hi Sam,

Having re-examined your original post, can I suggest a further possibility?

You mentioned that your customer wants to embed some of the structured
content (medication) within the narrative. Can I suggest leaving the
narrative section as pure text and considering using 'structured
narrative' within the structured / 'duplicate' section This is
becoming an increasingly popular approach and I think will become the
predominant solution, eventually making the unstructured narrative
part of CDA redundant and allowing easier support for the kind of NLP
driven interfaces that Peter Elkin and NHS CUI have been developing.

To use your example, something like the following would appear in the
structured section equivalent (very rough schematics!):

<StructuredNarrative>Saw JJ today and seemed OK. <content ref= 1>A
cough for 2 weeks.</content><content ref=2>Temp 36</content><content
ref= 3>, BP 146/82<content><content ref= 4>Prescribed Amoxycillin
250mg tid</content></StructuredNarrative>

Symptom "Cough" <content ref=1/>
            duration "2 weeks"
       Temperature 36 C <content ref=2/>
       Blood pressure <content ref=3/>
             systolic 146
             diastolic 82
       Medication <content ref= 4/>
            amoxicillin 250mg
</Structured>

There have been some attempts to do this sort of thing with CDA:

e.g. Johnson SB, Bakken S, Dine D, et al. An Electronic Health Record
Based on Structured Narrative. J Am Med Inform Assoc.
2008;15(1):54-64.

+ the NHS has some similar HL7 based constructs for handling
structured narrative within GP2GP messages in England.

I am supposed to be figuring our how best to do this in openEHR for my
MSc project.

For the pure narrative 'section', which will be required for CDA
compatibility, why not create a simple 'Unstructured Narrative'
archetype containing only a single Text node, rather than a series of
sections?

Ian

Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian@mcmi.co.uk

Clinical Analyst - Ocean Informatics ian.mcnicoll@oceaninformatics.com

Consultant - IRIS GP Accounts ian@gpacc.co.uk

Member of BCS Primary Health Care Specialist Group – www.phcsg.org

17

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

(attachments)

OceanInformaticsl.JPG

18

To me?
yes

GF

– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

19

Really i see that ‘duplicated’ section like the codified entry in CDA, that is the machine readable information and the section like the narrative section in CDA (the human readable information), in few words i like this approach, and made the openEHR archetypes more compatibles with CDA Docs, i think so. This discussion where a topic between me and Diego Kaminker (Chair man HL7 Argentina Foundation) this weekend in a CDA Course in Cali-Colombia, and the conclusion of that discussion where that archetypes could be more flexible whit approachs like Sam’s

20

Thanks Ian

I guess the advantage of only using the section is that archetypes can be developed as you say. This section just aids in being able to link narrative and structured data in a way that allows the duplication to be handled. At the moment I favour a Document archetype with an embedded multimedia for any sort of text which will allow all sorts of structuring and links to be possible. Once we have a tight grip on the requirements, the DV_PARAGRAPH might provide the basis for the sort of structured narrative you are proposing.

Any way, this section does not preclude any of the responses you are proposing.

Cheers, Sam

Ian McNicoll wrote:

(attachments)

OceanInformaticsl.JPG