Hi Sam, First of all congratulations and thanks to everybody who contributed to the new website. It's really a great improvement.
Op 31-okt-2007, om 8:40 heeft Sam Heard het volgende geschreven: > Hi Stefan > > It is worth noting that the CARE_ENTRY class - which is the > immediate ancestor of the OBSERVATION, EVALUATION, ACTION, > INSTRUCTION classes has an attribute called GuidelineID - which is > a reference to the guideline or protocol used. I believe this is > what you are looking for - but it does require identification of > the Protocol for you to use this. I think this could indeed be what I'm looking for, but have some additional questions. I guess my main question is a bit similar to those in the device discussion. Let me see if I can explain it. It might well be that this is more a question for the technical list. But since I'm not a technical person, let me try to ask this in 'lay mans' terms. I think that we all agree that in evaluation archetypes such as 'diagnoses' there should be a list of criteria (the guideline or protocol) which are used to reach that diagnosis. My point/ question is: should one enter (by hand or by the application that is used) these criteria everytime a diagnose is made, or can we create a separate guideline/ protocol archetype to which we can refer. If one chooses the first option one should fill out the criteria each and every time, when writing down a diagnosis. Of course this can be automated by the application that is used. Thing is that the knowledge will be stored locally at application level. My feeling is that your suggestion to use the GuidelineID is in conjunction this option. Point is that if I refer to an external guidelines, data in that guideline isn't 'archetyped' and can't be used for computational purposes. So I have to translated those into an archetype. Alternatively one refers to to actual version of the guideline/ protocol which is stored through a separate guideline/protocol archetype. By doing so guidelines/protocols can be be stored/ monitored/ approved centrally. Furthermore they can be (re-)used by others and queried for, etc. I can imagine that one would like to query for all diagnosis X which comply to the guidelines Y and Z The similarity with the device discussion that one could enter every time all the details of a device (type, brand, certified. service date. calibration date, etc. etc.) in the appropriate archetype or, similarly as above, refer to an device archetype. Another thought, although I'm not sure whether that's valid is that in case of the first option those evaluation (such as diagnosis) and observation (such as blood pressure) archetypes would become rather 'bulky' if we have to include all these variables as well. By referring to a separate archetype one could safe a lot of 'space'. Hope this explanation helps and I'm curious to hear your viewpoint. Cheers, Stef > > Cheers, Sam > > Stef Verlinden wrote: >> Dear all, >> >> From the lengthy and educative discussions on this mail list, the >> last couple of weeks, the following occurred to me: >> >> - observations are to do with gathering evidence >> - an evaluation is an activity of comparing data to a knowledge >> base (and draw a conclusion based on that comparison (SV)) >> >> (Both excellent definitions provided by Thomas Beale) >> >> The other thing that occurred to me is that the ?assessment? of >> data quality is an evaluation too, based on a knowledge base, >> which knowledge is summarized in a protocol. As one might recall, >> I?ve been struggling were to put the data quality protocol and the >> outcome of the evaluation. This ?insight? makes it much easier >> from my point of view, I can just ad an evaluation archetype data >> quality. >> >> Over thinking this I wondered if we should give these knowledge >> bases/ assessment protocols a firmer position in the evaluation >> archetypes >> >> To explain this I would like to start with a question: what?s the >> purpose of an EHR? >> >> I don?t know if there is a better definition but from my point of >> view it?s something like: to capture all healthcare related data >> of a patient/citizen in such a manner that his/her medical >> situation is represented as good and as complete as possible and >> that the (relevant) data is (re-) usable by all health care >> providers (and ultimately the agents) involved in a certain process. >> >> My interest is especially in the (re-) usability of available data >> and evaluations, since this is essential to improve the quality >> and efficacy of our healthcare system. On top of that, if the data >> is of good quality, some (parts of) processes can be fully >> automated which could even further increase quality and efficacy. >> >> If we look at the re-usability of data (as put down in >> observations), this is provided for in the current openEHR EHR. >> One can use this system to capture and share ?evidence?. >> >> This shared ?evidence? can then be (re-) used by any healthcare >> provider involved in the process to asses it to the desired >> protocol (either in ones head of written down in paper) to >> evaluate it. Everybody re-evaluates the available data every time >> in order to draw his/ her ?own? conclusion. This is a perfect >> valid way to do it, albeit cumbersome. >> >> If we look at the re-usability of evaluations, we still miss two >> things. >> >> I?ll enlarge the ?problem? a little in order to make it, but the >> point is that trust and re-usability are essential components for >> a, not only functional but, widely accepted and used EHR system >> >> Firstly: In order to be able to re-use an evaluation one needs to >> know against which protocol this conclusion is drawn. Only if this >> protocol aligns with or is similar to the protocol used locally, >> one can consider re-using the evaluation. >> >> To give an example: the diagnosis criteria for rheumatoid >> arthritis (RA) are not ?engraved in stone?. It varies over time >> and it varies locally. So in one situation RA is diagnosed if X >> joints are inflamed for Y weeks but in another situation the >> diagnoses is only given if at least one ?large? joint is involved >> and/or if Z joint are inflamed for Q weeks (I made this up, so >> don?t hold this against me:-) ). So if one doesn?t know which >> protocol is used to evaluate it, the diagnose RA doesn?t mean too >> much. >> >> Secondly: In order to obtain a reliable conclusion one needs to >> use ?evidence? of ?good quality?. Even if the protocol is known, >> an evaluation won?t be re-useable if the data quality of the >> underlying ?evidence? is poor/ unknown. Who would trust an >> evaluation if it?s possibly based on false assumptions? >> >> Similarly as with the evaluation of a medical situation, data >> quality has to be assessed against a (locally accepted) protocol. >> This assessment leads to a conclusion (f.i. good/poor/undetermined >> data quality). Also here, that conclusion isn?t worth much if it >> isn?t known against which protocol the assessment is made. >> >> I?ve looked into the current evaluation archetypes and although >> there is some room to reference to additional information (f.i. >> ?reference, useful information about this condition? in the >> EVALUATION.problem-diagnosis AT), there is not a dedicated place >> for the protocol used to draw a certain conclusion. >> >> So my suggestion is to add a field (?protocol used for >> evaluation?) to all the evaluation archetypes, in order to >> stimulate the re-usability of, not only observations but also, >> evaluations. >> >> Cheers, >> >> Stef >> >> PS Needless to say that I?m not a big fan of knowledge bases or >> protocols, which are only present in the head of a healthcare >> provider >> _______________________________________________ >> openEHR-clinical mailing list >> openEHR-clinical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > > -- > <OceanC_small.png> > Dr Sam Heard > Chief Executive Officer > Ocean Informatics > Director, openEHR Foundation > Adj. Professor, Central Queensland University > Senior Visiting Research Fellow, University College London > Aus: +61 4 1783 8808 > UK: +44 77 9871 0980 > <OceanC_small.png> > _______________________________________________ > 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-clinical_lists.openehr.org/attachments/20071107/f0b7f76b/attachment.html>
