Hi Stef, I would probably disagree with you philosophically about the need to absolutely verify the provenance of any clinical assertion. Whilst this might be desirable, I am not sure it is acheivable and we will be relying on trusting colleagues 'opinions' for some time to come. Nevertheless, I accept that there are definitely circumstances where the simple assertion "Allergic to penicillin', recorded in one setting will not be sufficient(or too simplisitic) for onwards processing in another setting e.g to trigger decision support. However I would still maintain that we want to record this assertion consistently, no matter the particular GUI configuration. i.e Even if "Allergic to penicillin" is insufficient for my use, I would still like to receive that partial information in a consistent, queryable fashion, accepting that in some circumstances Allergic to penicillin Y/N is a perfectly legitimate approach to data capture.
I am just digesting this recent paper by Alan Rector http://www.cs.man.ac.uk/~rector/papers/Whats-in-a-code/Whats-in-a-code-rector-corrected.pdf Where he makes the useful distinction between Clinical Findings and Clinical Observables This roughly equates to the SNOMED classes but is more abstract from Rector's paper ================================ Findings? are things that apply to only some patients ? e.g. diseases, injuries, symptoms etc. The existence of a ?finding? is significant information, regardless of its detailed description. ?Observables? are characteristics of all patients but with different values or states ? values measured by laboratory tests, examinations, or other means For example, only some patients have head injuries. The presence of a head injury is information. By contrast, all patients have a serum potassium concentration; the information is in the value of that concentration. =================================================================================== I am limping towards an understanding is that when we use the DV_BOOLEAN pattern, we are turning a statement that would traditionally be recorded as a Finding 'The patient is allergic to penicillin' into an Observable, essentially treating 'Penicillin allergy' as a testable patient state with a value T/F Both kinds of statement are legitimate, the problem is that we do not have an automatic way of making them semantically equivalent. In addition what seems to be a simple boolean observable may actually have many more states in more demanding clinical contexts. e.g "Is the urine red" => "Colour of urine : read , yellow, green, purple etc etc" If we add negation into the mix this becomes very challenging but when developing useable systems, this is exactly the kind of documentation we have to provide to developers and to clinical users who quite probably do not appreciate that their locally acceptable and GUI efficient requirement for 'Penicillin allergy Y/N' is not compatible with the way that most clinical decision support operates. If we can find a way of asserting equivalence between these 2 modes of clinical expression, this would be a major breakthrough. What I am suggesting is that it might be possible to define an element which was fundamentally a DV_CODED_TEXT list, but which in some circumstances (where the number of states is 2 or less, after template level constraint), that can be expressed as a boolean for GUI purposes. I am re-reading Erik's comments to see where that takes us!! Ian Dr Ian McNicoll office +44 (0)1536 414994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 10 February 2011 11:20, Stef Verlinden <stef at vivici.nl> wrote: > And it's to simplistic too. In that case one also would like to know > allergic to which specific type(s) and/or components of penicillin. In that > case I also would like to know how that was tested, when and who did that > etc., etc. > So I guess what's I'm trying to say is: What's the value of such forms and > should we discuss this at this level? I guess that doctors always will keep > using local forms for all sorts of purposes and at their own responsibility > but I don't think we should try to standardize these form as well. > I we're able to record the symptoms/abnormalities/functions found or > exluded, by whom using which method it's up to the person who has access to > that data how to interpret it and to evaluate if he/she can draw a > conclusion based on his/ her standards. > Like I said earlier an diagnose RA from hospital A can be a different > disease from the one meant by the diagnose RA from hospital B and unless I > have access to the underlying data I can't and won't use the the diagnose. > > Cheers, > Stef > > Op 10 feb 2011, om 11:47 heeft Ricardo Correia het volgende geschreven: > > Of course, this would for sure have bad implications regarding the size of > forms and time to fill them > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
