In een bericht met de datum 6-9-2005 22:32:06 West-Europa (zomertijd), schrijft sam.heard at oceaninformatics.biz:
Hi All, Interesting concepts discussed here: An EHR for a clinician deals with two major classes of information: 1. Classes that describe the situation of the patient (different levels of detail, changes over time, enourmous sets sometimes) 2. Classes that describe the behaviour of care professionals ( a single medication description, giving information, asking consent, performing a procedure,a gain many). Often # 2 are triggered by #1. And #1 and # 2 can have different time formats (past, present, future). However, a proper EHR should allow to include 'future' things that could or should happen. E.g. in care planning it is important to have a start value of the situation of the patient, compare this with historic description of this situation when available, state a goal of what to expect in an overseable time, and then check for the actual outcome e.g. after care has been carried out. If an EHR can only store what has already happened, so the past, it becomes useless for supporting clinical practice. It is interesting that the concepts of trigger is fundamental to HL7 dynamics, and the 'mood' of the action / obs (so #1 and # 2) are already available in the RIM classes: INT, RQO, GOL, EVN are very powerful to support the dynamics of monitoring and workflow. Key components of EHR. See also the ISO TS on the EHR in which both data / structures and dynamics are the first 2 chapters. Sams distinction between action required versus for your information only is interesting and probably would need further development on message and on EHR level. And again: from the perspective of clinical documentation and care planning the disctinction between message and EHR is arbitrary: we have systems that are integrated or that are coupled, that have similar functionalities. Key is that we analyse #1 and # 2 appropriately, model it for ICT and only then develop the tech stuff in which it works. My 3 Euro cents, William > Onderw:Re: 'Actionability' of orders > Datum:6-9-2005 22:32:06 West-Europa (zomertijd) > From: sam.heard at oceaninformatics.biz (Sam Heard) > Sender: owner-openehr-clinical at openehr.org > Reply-to: <A HREF="mailto:openehr-clinical at openehr.org">openehr-clinical > at openehr.org</A> > To: gfrer at luna.nl (Gerard Freriks) > CC: d.kalra at chime.ucl.ac.uk (Dipak Kalra), > thomas.beale at oceaninformatics.biz (Thomas Beale), openEHR-Clinical at > openehr.org (openEHR-Clinical) > > > > > Gerard > This area is interesting. At a recent meeting of Standards Australia it was > determined that an extract should say if it is for information only or there > is, within it, the expectation that some action is required. This should, we > felt be boolean ie unambiguous. It took some time to come to this - but an > example is an extract containing a medication order that is sent to the > pharmacy (action required) and copied to the specialist (no action required). > > The openEHR instruction class that is almost fully specified now and will be > in version 1, will take this sort of thing to a new level. > > We need more debate on this, Sam > > Gerard Freriks wrote: > >> Hi, >> >> Reading an HL7 list. >> >> >> >> >> To me it seems there is exchange of the same data for two reasons. >> 1- an order, an instruction, an advice, a professional opinion, a letter, >> a lab result, itself, etc >> 2- the documentation of , the provision of information about, the order, >> the instruction, the advise, the opinion,the letter, the lab result, etc. >> >> >> Eg: the prescription on paper handed to the patient, the prescription >> electronically that is sent and serves as a kind of trigger event to make >> acts >> happen at the receiver side. >> And the documentation of acts in a system about the real world. >> >> >> What they have noticed is one of the fundamental criticisms on the RIM by >> the philosophical ontologists. >> >> >> In CEN it is simple we deal only with the EHR and considers the EHR a >> documentation device that deals with reason two only: documentation of what >> has >> happened. >> A lab test that is sent to an EHR system as data (information about the >> patient) is received and stored in the in-tray of the system. >> The physician reads the data and accepts it to the healthcare record at >> that moment he documents the reception of the lab results and make them part >> of >> the EHR. Then he is able to formulate a comment about them or act up on >> them. The comments or the actions will be documented again in the EHR. >> >> >> In CEN we deal with the EHRextract for exchange only. The extract is an >> abstract of that what has been documented. >> >> >> >> >> Question: Is data that is not yet documented part of the extract? >> If so. How is that indicated? >> If not what should we do? >> I think it should not, because the EHR is there to document what has >> happened in the view of the healthcare provider. >> Orders, instruction, letters them selves are outside of the scope of the >> EHR. >> >> >> I think that next to the EHR extract we need something that indicates that >> it is not an extract of what is documented but something that is an order, >> instruction, advice, a letter, a lab result, that is data to the receiver >> until he documents the reception and accepts it to his record system. >> I prefer a new construct that carries the notion that it is a trigger. >> Since the content of this new construct will be the same information as an >> EHR-extract I foresee an envelope for the EHR indicating that it is an >> extract of a document and an envelope indicating that it is a trigger. >> The signature placed on the extract of the document indicates: I sign this >> and take responsibility for the content of the extract. >> The signature placed on the trigger indicates: I order you, I instruct you >> to do something and I take responsibility for that order, instruction. >> >> >> Gerard >> >> >> >> -- <private> -- >> Gerard Freriks, arts >> Huigsloterdijk 378 >> 2158 LR Buitenkaag >> The Netherlands >> >> >> T: +31 252 544896 >> M: +31 654 792800 >> >> >> >> On 17-aug-2005, at 17:45, Lloyd McKenzie wrote: >> >> >>> We have a circumstance in community prescribing where there is a >>> central EHR record of prescriptions. In some circumstances, the electronic >>> rendition is 'actionable', meaning that any pharmacy can download and >>> submit a >>> dispense on the prescription. In other cases, the electronic rendition is >>> 'non-actionable', meaning that a pharmacy can only dispense against the >>> prescription if they have a paper copy of the order. >>> >>> The way we're thinking about dealing with this is by the presence or >>> absence of a 'pre-condition' on the on the order indicating that a paper >>> copy of >>> the order must be reviewed prior to dispensing. (classCode = >>> VRF-verification, performer.participationMode = WRITTEN). If the >>> pre-condition is >>> present, then the order is 'non-actionable'. If there's no pre-condition, >>> then >>> the order is 'actionable'. >>> >>> I'm posting this because I feel it's a fairly generic problem, and likely >>> spans areas outside of just pharmacy. Are people comfortable with modeling >>> things this way? If not, what are your recommendations? >>> >>> Thanks for your thoughts. >>> >>> >>> Lloyd >>> >> >> >> >> > -- > > > Dr. Sam Heard > MBBS, FRACGP, MRCGP, DRCOG, FACHI > > > CEO and Clinical Director > <A HREF="http://www.oceaninformatics.biz/";>Ocean Informatics Pty. Ltd. > </A>Adjunct Professor, Health Informatics, Central Queensland University > Senior Visiting Research Fellow, CHIME, University College London > Chair, Standards Australia, EHR Working Group (IT14-9-2) > Ph: +61 (0)4 1783 8808 > Fx: +61 (0)8 8948 0215 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20050906/3628f2d7/attachment.html>
