Bhupinder Singh <bobdog at sancharnet.in> wrote: > You have factored the details relating to reporting. A major issue is the > transmission and reading of the result by the clinician. Ther is to be time > event to be recorded as to when the clinician who has direct control of the > patient has read it. A legal issue that will come up at times is that the > report shall be claimed to have been sent and the consultant clinician > shall claim not to have received it and thus not having read it. A timed > event for both these activities need to be available. Further there is a > need for alerting the clinicians once the report is ready.
Agree with all this. However, the EHR on its own cannot force people to read things. So applications need to create alerts as necessary, and then what happens next is dependent on policies. For example, one strategy is: * if an item is added to the EHR, say a prelim test result at time t1, and a clinician in the group having access to the EHR makes a decision and commences an action (e.g. new investigation which is more expensive) for this patient at time t5, then a reasonable rule of operation is that the clinician must have made this decision with knowledge of the result recorded at t1, since in a shared EHR to which he/she has access, there is no reason why not; if they have not done so, they might be in breach of their duty. The arguments against this working might be that if the EHR is bady organised, there might be no easy way to find the relevant item(s) whcih might influence the decision at time t5. So at least problem-threading and/or episode classification is needed... Another strategy would be: * the clinician receives an alert of some kind (e..g email) and is required to go into the EHR and change the test result in a field which means "seen and accepted by treating clinician; dated xx/xx/xx hh:mm:ss". This acceptance is now in the EHR, and it can be seen that it must have been part of the basis of the next actions by the clinician. However, later actions by others might still occur without knowledge of this accepted test result - unless the first strategy is followed. So - I think that the first strategy is at least needed, but it does not mean that there does not need to be countersigning etc within the clinical workflow somewhere the question is - how much of this finds its way into the EHR? - thomas beale > > There is a need to have the ability to generate an Interim report and then a > final report. It is the interim report that shall have to be avilable to few > and the detailed subsequently. Both these have to be a part of the EPR to > substantiate the clinican actions in case of a abnormal event when the > action of the clinician results in a abnormal event in the patients > recovery. > > Even when the sample is haemolysed a track of the sample needs to be kept in > the EPR of the patient. > > Bhupinder > > ----- Original Message ----- > From: "Sam Heard" <sam.heard at bigpond.com> > To: "Openehr-Technical" <openehr-technical at openehr.org> > Sent: Wednesday, October 22, 2003 4:02 PM > Subject: Pathology requirements CONTRIBUTION - 2 versions at once > > > CONTRIBUTION - 2 versions at once > > > > There is a particular problem with results that are deemed to be incorrect > > as the specimen is damaged - haemolysed blood samples being the most > common > > (See textural results to quantities thread). If the machine read data is > to > > be preserved in openEHR then this would need to be over written with the > > correct result and both compositions saved at the same time - otherwise > some > > other agent might base some process on the interim situation where the > first > > composition is saved even for a microsecond. We think this relates to > > machine processed data - but keeping medical student entries might be > dealt > > with in some environments in the same manner. > > > > ACCESS CONTROL to interim reports > > > > There will be times when the access to an interim report needs to be > > controlled - such as an abnormal result from a lab that has not been > signed > > off by the final arbitor...but it may need to be available to a particular > > team. Our access control models need to deal with this. > > > > Cheers, Sam > > ____________________________________________ > > Dr Sam Heard > > Ocean Informatics, openEHR > > Co-Chair, EHR-SIG, HL7 > > Chair EHR IT-14-9-2, Standards Australia > > Hon. Senior Research Fellow, UCL, London > > > > 105 Rapid Creek Rd > > Rapid Creek NT 0810 > > > > Ph: +61 417 838 808 > > > > sam.heard at bigpond.com > > > > www.openEHR.org > > www.HL7.org > > __________________________________________ > > > > - > > If you have any questions about using this list, > > please send a message to d.lloyd at openehr.org > > > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org -- Deep Thought: http://www.deepthought.com.au openEHR: http://www.openEHR.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
