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 On Tue, Aug 19, 2008 at 3:02 PM, Dipak Kalra <d.kalra at chime.ucl.ac.uk>wrote: > 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 > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080821/139065f6/attachment.html>
