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