[Gnumed-devel] address@hidden: RE: Differential display]

[Karsten Hilbert]

FYI: a relevant thread from the OpenEHR community regarding
duplication of data and storing data textually vs
structurally.

GNUmed tries to combine the best of both worlds in its
database schema: It allows storage of structured data (such
as the BP mentioned below) but displays it in the textual
(narrative) data *as if* it was textually entered (instead
of a copy of the structural data).

Karsten

----- Forwarded message from Heath Frankel <address@hidden> -----

> Subject: RE: Differential display
> X-Mailer: Microsoft Office Outlook 12.0
> 
> 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
> 
> > -----Original Message-----
> > From: address@hidden [mailto:openehr-technical-
> > address@hidden On Behalf Of Thomas Beale
> > Sent: Tuesday, 19 August 2008 7:59 AM
> > To: For openEHR technical discussions
> > Subject: Re: Differential display
> > 
> > 
> > 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:
> > > 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
> > > ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > openEHR-technical mailing list
> > > address@hidden
> > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> > >
> > 
> > 
> > --
> >     *Thomas Beale
> > Chief Technology Officer, Ocean Informatics
> > <http://www.oceaninformatics.com/>*
> > 
> > Chair Architectural Review Board, /open/EHR Foundation
> > <http://www.openehr.org/>
> > Honorary Research Fellow, University College London
> > <http://www.chime.ucl.ac.uk/>
> > 
> > 
> > *
> > *
> > 
> > _______________________________________________
> > openEHR-technical mailing list
> > address@hidden
> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> 
> _______________________________________________
> openEHR-technical mailing list
> address@hidden
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

----- End forwarded message -----

-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346