Sam come and visit us at HIC on the MOnday if you want:
MO uses GELLO for visibility within the archetype (as well as other things). 
Would like to show you. We also can do the permanent non display bit by tagging 
a snomed code binding and then the HL7 splits it off and it isn't sent in a 
message. The latter is a HL7/PIT solution. The former is interesting :-)

 I understand the issue about CDA at least in part. Another thing we do for 
nodes is just set them as invisible as an attribute of the node This is usuing 
the MO template editor.

Regards
Peter Scott

---- Original message ----
>Date: Mon, 18 Aug 2008 14:36:42 +0930
>From: Sam Heard <sam.heard at oceaninformatics.com>  
>Subject: Differential display  
>To: Openehr-Technical <openehr-technical at openehr.org>,openEHR-Clinical 
><openEHR-Clinical at openehr.org>
>
>   Dear All (cross post)
>
>   We are working in an environment where many
>   applications and CDA messages have information that
>   is displayed as text and repeated information in
>   structured form. This also arises in applications
>   which have a formatted document plus structured
>   information (typically in primary care).
>
>   I am proposing that we have a section archetype to
>   manage this. The archetype display script would not
>   display any information about the section itself (it
>   would be invisible) and would display the first
>   subsection but not the second. The section archetype
>   would be:
>
>     * Differential display
>          * Display
>               * Entries here will display
>          * Non-display
>               * Entries here will not display
>   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).
>
>   If this archetype arrived somewhere where it was not
>   known the generic display script would show the
>   non-display information (twice). This would be
>   unlikely to cause errors especially as there would
>   be a heading Non-display.
>
>   So that is the approach that we have considered.
>   There is an alternative - just have a non-display
>   section. This has the advantage that it could be
>   added when required on an adhoc basis. The major
>   problem that I can see is that it would not be clear
>   which part of the record held the information that
>   was redundant (ie where it was being displayed).
>
>   I would be interested in people's views of this
>   approach to the redundant structured data problem
>   that arises from CDA and word processor style record
>   applications.
>
>   Cheers, Sam
>
>   Cheers, Sam
>
>   --
>
>    Dr Sam Heard                
>    Chief Executive Officer     
>    Director, openEHR Foundation
>    Senior Visiting Research Fellow, University
>    College London              
>                                21 Chester Cres         
>    214 Victoria Avenue         London E8 2PH           
>    Chatswood, NSW, 2067        Phone: +44 20 7249      
>    Phone: +61 2 9415 4994      7085                    
>    Mobile: +61 4 1783 8808     Mobile: +44 77 9871     
>                                0980                    
>________________
>_______________________________________________
>openEHR-clinical mailing list
>openEHR-clinical at openehr.org
>http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

Reply via email to