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 ________________________________________________________ Dr Dipak Kalra Clinical Senior Lecturer in Health Informatics CHIME, University College London Holborn Union Building, Highgate Hill, London N19 5LW Phone: +44-20-7288-5966 Fax: +44-20-7288-3322 Study Health Informatics - Modular Postgraduate Degree http://www.chime.ucl.ac.uk/study-health-informatics On 19 Aug 2008, at 01:05, 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 >
