Hi guys, thanks Andrew this is helpful! See my remarks below...
On Thu, Aug 21, 2008 at 3:11 AM, Andrew Patterson <andrewpatto at gmail.com>wrote: > I think people are mixing up some concepts here - and I don't think > it's a great idea to forge on without really narrowing down exactly > what the use cases are and what their variations are. I personally > think that at least 3 distinct use cases have been discussed > in this thread (with albeit quite subtle differentiations) and I'm > not sure everyone is agreeing with the solutions that they think > they are agreeing with. > > My taxonomy of use cases would be > > a) the MD2 use case (Ocean need to be able to handle the way > Medical Director generates separate progress notes and structured > measurements, but pastes textual copies of the structured data into > the progress note) > > b) the simple CDA narrative use case (There is a general interest > in CDA documents and how they might be done in openehr) > > c) the strong semantic CDA narrative use case (Ian and others > are interested in how openehr might handle mixed structured > and unstructured content, where there is strong linkage > between the structured content and its place in the unstructured > narrative) > > I don't think the solution to all these is the same. I think a > PRIMARY/DUPLICATE archetype is not at all useful for (c), > maybe a good idea for (b), and probably not a good idea for (a) > (but that use case is so broken that it may be the best > that can be done). > > Do othere see these 3 cases as distinct? From an IT perspective I think > they > are different but I am not clinical. IMHO (b) and (c) are not distininct as CDA R2 currently already supports "structured narrative" (as in Ian's post) via the <originalText> tag from a Level 3 entry to a Level 1 text via a reference: see http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm#CDA_Section_Narrative_Block). Thus, in order to express *any* CDA document in openEHR we have to be able to handle this. As Sam suggests DV_PARAGRAPH (see http://www.openehr.org/releases/1.0.1/architecture/rm/data_types_im.pdf) seems suitable, however it has never been implemented or used so far for what I know... Regarding (a): It is important that due to CDA human-readibility principle narrative+multimedia (see http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm#entry) are the *only* authenticated content in a CDA document. As only this form is required to be faithfully displayed by everybody. Therefore, I would think, in case structured entries contradict the narrative (through secondary corrections as Heath depicted) the narrative "wins". Consider the following scenario: A doctor receives a CDA document. Her CDSS makes a suggestion based on some coded entries which are in this scenario contradictory to the narrative. The doctor will always have to evaluate the patient, his local notes as well as the narrative from the transmitted CDA document before making the decision whether to actually do what the CDSS suggests. In this scenario the doctor would spot the contradiction and decide whether the suggestion still applies since she will be legally liable. This is why med school won't be shorter in the age of CDSS, but in general medicine will be safer as doctors overlook less. From a clinical point of view I feel this is reasonable. So CDA R2 in my opinion covers (a), (b), and (c). It is its clever close-to-reality design that has made it the most successful part of HL7v3, not the underlying RIM. As written in my previous post we must find a way to align CDA and openEHR. Cheers, Thilo > > Andrew > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080821/c9935d3f/attachment.html>
