# Differential display

**Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153)
**Created:** 2008-08-18 05:06 UTC
**Views:** 4
**Replies:** 27
**URL:** https://discourse.openehr.org/t/differential-display/14819

---

## Post #1 by @system

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


[details="(attachments)"]

![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg)

[/details]

---

## Post #2 by @system

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

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

T: +31 252544896
M: +31 620347088
E: [gfrer@luna.nl](mailto: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

---

## Post #3 by @ian.mcnicoll

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&#39;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

---

## Post #4 by @Stefan_Sauermann

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


[details="(attachments)"]

![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg)

[/details]

---

## Post #5 by @Thilo_Schuler1

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.

<snip>

> 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).

<snip>

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

---

## Post #6 by @thomas.beale

I won&#39;t contribute much to this discussion, except to say that the
&#39;problem&#39; 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 &#39;primary&#39; and &#39;duplicate&#39; or &#39;alternative rendition&#39; or similar\.

\- thomas

Thilo Schuler wrote:

---

## Post #7 by @Heath_Frankel3

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

---

## Post #8 by @system

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

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

T: +31 252544896
M: +31 620347088
E: [gfrer@luna.nl](mailto: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

---

## Post #9 by @thomas.beale

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 &#39;duplicated&#39; section in some way \- e\.g\. a line around it and
&quot;\(duplicate\)&quot; 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:

---

## Post #10 by @Dipak_Kalra

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&#39;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

---

## Post #11 by @Stefan_Sauermann

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

---

## Post #12 by @Andrew_Patterson

> 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&#39;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 &#39;story&#39; 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&#39;t see how you could in good
faith then indicate that any of the coded structured data is
&#39;duplicate&#39; 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&#39;t really exist?

Andrew

---

## Post #13 by @Andrew_Patterson

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

---

## Post #14 by @system

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:


[details="(attachments)"]

![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg)

[/details]

---

## Post #15 by @system

>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:


[details="(attachments)"]

![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg)

[/details]

---

## Post #16 by @ian.mcnicoll

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 &#39;structured
narrative&#39; within the structured / &#39;duplicate&#39; 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\!\):

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

Symptom &quot;Cough&quot; &lt;content ref=1/&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;duration &quot;2 weeks&quot;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Temperature 36 C &lt;content ref=2/&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Blood pressure &lt;content ref=3/&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;systolic 146
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;diastolic 82
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Medication &lt;content ref= 4/&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;amoxicillin 250mg
&lt;/Structured&gt;

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 &#39;section&#39;, which will be required for CDA
compatibility, why not create a simple &#39;Unstructured Narrative&#39;
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

---

## Post #17 by @Colin_Sutton

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


[details="(attachments)"]

![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg)

[/details]

---

## Post #18 by @system

To me?
yes

GF

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

T: +31 252544896
M: +31 620347088
E: [gfrer@luna.nl](mailto: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

---

## Post #19 by @Juan1

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

---

## Post #20 by @system

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:


[details="(attachments)"]

![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg)

[/details]

---

## Post #21 by @system

OK - we seem to have agreement that such a section archetype is useful. We also seem to be comfortable with labelling the subsections PRIMARY and DUPLICATE. Remember that although in CDA the Primary will be unstructured and the DUPLICATE will be structured, in many settings this will not necessarily be the differentiation. The advantage of using a section is that structured data can also be in the PRIMARY subsection.

What should we call the whole SECTION archetype - the root node?

Ideas include:

- duplicated
- CDA section (won't be popular with some)
Let me know your suggestions....Sam

Juan wrote:


[details="(attachments)"]

![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg)

[/details]

---

## Post #22 by @Andrew_Patterson

I think people are mixing up some concepts here \- and I don&#39;t think
it&#39;s a great idea to forge on without really narrowing down exactly
what the use cases are and what their variations are\. I personally
think that at least 3 distinct use cases have been discussed
in this thread \(with albeit quite subtle differentiations\) and I&#39;m
not sure everyone is agreeing with the solutions that they think
they are agreeing with\.

My taxonomy of use cases would be

a\) the MD2 use case \(Ocean need to be able to handle the way
&nbsp;&nbsp;&nbsp;Medical Director generates separate progress notes and structured
&nbsp;&nbsp;&nbsp;measurements, but pastes textual copies of the structured data into
&nbsp;&nbsp;&nbsp;the progress note\)

b\) the simple CDA narrative use case \(There is a general interest
&nbsp;&nbsp;in CDA documents and how they might be done in openehr\)

c\) the strong semantic CDA narrative use case \(Ian and others
&nbsp;&nbsp;&nbsp;are interested in how openehr might handle mixed structured
&nbsp;&nbsp;&nbsp;and unstructured content, where there is strong linkage
&nbsp;&nbsp;&nbsp;between the structured content and its place in the unstructured
&nbsp;&nbsp;&nbsp;&nbsp;narrative\)

I don&#39;t think the solution to all these is the same\. I think a
PRIMARY/DUPLICATE archetype is not at all useful for \(c\),
maybe a good idea for \(b\), and probably not a good idea for \(a\)
\(but that use case is so broken that it may be the best
that can be done\)\.

Do othere see these 3 cases as distinct? From an IT perspective I think they
are different but I am not clinical\.

Andrew

---

## Post #23 by @Thilo_Schuler1

Hi guys,

thanks Andrew this is helpful! See my remarks below...


> I think people are mixing up some concepts here - and I don't think
> it's a great idea to forge on without really narrowing down exactly
> what the use cases are and what their variations are. I personally
> think that at least 3 distinct use cases have been discussed
> in this thread (with albeit quite subtle differentiations) and I'm
> not sure everyone is agreeing with the solutions that they think
> they are agreeing with.
>
> My taxonomy of use cases would be
>
> a) the MD2 use case (Ocean need to be able to handle the way
> Medical Director generates separate progress notes and structured
> measurements, but pastes textual copies of the structured data into
> the progress note)
>
> b) the simple CDA narrative use case (There is a general interest
> in CDA documents and how they might be done in openehr)
>
> c) the strong semantic CDA narrative use case (Ian and others
> are interested in how openehr might handle mixed structured
> and unstructured content, where there is strong linkage
> between the structured content and its place in the unstructured
> narrative)
>
> I don't think the solution to all these is the same. I think a
> PRIMARY/DUPLICATE archetype is not at all useful for (c),
> maybe a good idea for (b), and probably not a good idea for (a)
> (but that use case is so broken that it may be the best
> that can be done).
>
> Do othere see these 3 cases as distinct? From an IT perspective I think they
> are different but I am not clinical.

IMHO (b) and (c) are not distininct as CDA R2 currently already supports "structured narrative" (as in Ian's post) via the <originalText> tag from a Level 3 entry to a Level 1 text via a reference: see [http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm#CDA_Section_Narrative_Block](http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm#CDA_Section_Narrative_Block)). Thus, in order to express *any* CDA document in openEHR we have to be able to handle this.
As Sam suggests DV_PARAGRAPH (see [http://www.openehr.org/releases/1.0.1/architecture/rm/data_types_im.pdf](http://www.openehr.org/releases/1.0.1/architecture/rm/data_types_im.pdf)) seems suitable, however it has never been implemented or used so far for what I know...

Regarding (a): It is important that due to CDA human-readibility principle narrative+multimedia (see [http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm#entry](http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm#entry)) are the *only* authenticated content in a CDA document. As only this form is required to be faithfully displayed by everybody. Therefore, I would think, in case structured entries contradict the narrative (through secondary corrections as Heath depicted) the narrative "wins".
Consider the following scenario: A doctor receives a CDA document. Her CDSS makes a suggestion based on some coded entries which are in this scenario contradictory to the narrative. The doctor will always have to evaluate the patient, his local notes as well as the narrative from the transmitted CDA document before making the decision whether to actually do what the CDSS suggests. In this scenario the doctor would spot the contradiction and decide whether the suggestion still applies since she will be legally liable. This is why med school won't be shorter in the age of CDSS, but in general medicine will be safer as doctors overlook less. From a clinical point of view I feel this is reasonable.

So CDA R2 in my opinion covers (a), (b), and (c). It is its clever close-to-reality design that has made it the most successful part of HL7v3, not the underlying RIM. As written in my previous post we must find a way to align CDA and openEHR.

Cheers, Thilo

---

## Post #24 by @Thilo_Schuler1

Hi Dipak,

I have quickly looked at EN13606-1 (a draft form 2.10.2006). Could you explain a bit further how it deals with the mix of flexible textual and structured information. Especially in the use case when textual representations are generated from structured input and secondarily changed (contradiction!).

Thilo

---

## Post #25 by @Karsten_Hilbert

Changed data simply is \(a\) new \(version of what previously
existed\) in the EMR\. It has to be treated as just that,
unique data\.

Karsten

---

## Post #26 by @Andrew_Patterson

Thilo,

> IMHO \(b\) and \(c\) are not distininct as CDA R2 currently already supports
> &quot;structured narrative&quot; \(as in Ian&#39;s post\) via the &lt;originalText&gt; tag from a
> Level 3 entry to a Level 1 text via a reference: se

Yes, I meant they were distinct in terms of support in openEHR \- that
\(b\) is perhaps easier to support than \(c\)\. But you are right that
\(c\) is a superset of functionality that is currently supported by
CDA and hence to covering CDA fully would cover \(b\) and \(c\)\.\.

> required to be faithfully displayed by everybody\.  Therefore, I would think,
> in case structured entries contradict the narrative \(through secondary
> corrections as Heath depicted\) the narrative &quot;wins&quot;\.

I agree that the narrative form &quot;wins&quot; but I think the HL7 people
would be horrified by the thought that CDA structured content
was generating textual content which could then be secondarily
changed \- it is a clearly broken use case and noone would
design new software that way \- but I understand that there
are some legacy systems in Australia that do it this way and
that Ocean needs to come up with solutions around this\. But
I am quite keen that solutions to this particular outlying
use case don&#39;t impact on solutions to \(b\) and \(c\) unless
we all understand the ramifications\.

Andrew

---

## Post #27 by @thomas.beale

Andrew Patterson wrote:
>
> I agree that the narrative form &quot;wins&quot; but I think the HL7 people
> would be horrified by the thought that CDA structured content
> was generating textual content which could then be secondarily
> changed \- it is a clearly broken use case and noone would
> design new software that way \- but I understand that there
> are some legacy systems in Australia that do it this way and
> that Ocean needs to come up with solutions around this\. But
> I am quite keen that solutions to this particular outlying
> use case don&#39;t impact on solutions to \(b\) and \(c\) unless
> we all understand the ramifications\.
>

well, Ocean is just one vendor that has products that have to interface
with Medical Director, which is the most widely entrenched GP desktop
package in Australia\. I think the main thing is how the semantics of
data in a package like MD translates to archetyped structures, which are
independent of the vendor product trying to extract data from the GP
dekstop\.

\- thomas beale

---

## Post #28 by @Peter_Scott

Sam come and visit us at HIC on the MOnday if you want:
MO uses GELLO for visibility within the archetype \(as well as other things\)\. Would like to show you\. We also can do the permanent non display bit by tagging a snomed code binding and then the HL7 splits it off and it isn&#39;t sent in a message\. The latter is a HL7/PIT solution\. The former is interesting :\-\)

I understand the issue about CDA at least in part\. Another thing we do for nodes is just set them as invisible as an attribute of the node This is usuing the MO template editor\.

Regards
Peter Scott

---


**Canonical:** https://discourse.openehr.org/t/differential-display/14819
**Original content:** https://discourse.openehr.org/t/differential-display/14819