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
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.
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.
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) 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.
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!).
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: 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 "wins".
I agree that the narrative form "wins" 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't impact on solutions to (b) and (c) unless
we all understand the ramifications.
I agree that the narrative form "wins" 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'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.
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'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.
