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: > 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: openehr-technical-bounces at openehr.org [mailto:openehr-technical- >> bounces at openehr.org] 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 >>> openEHR-technical at openehr.org >>> 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 >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > 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/> * *
