Hi Matt, Comments in text.
----- Original Message ----- From: "Matt Evans" <[email protected]> To: "'Thomas Clark'" <tclark at hcsystems.com>; <openehr-technical at openehr.org> Sent: Monday, May 05, 2003 7:09 AM Subject: RE: openEHR security; Directed to Thomas Beale > Hi Thomas, > > I forgot I had set up an inbox rule for posts from this forum so have > probably missed the last 40 or more posts. Will have to go back through them > all to see exactly what has been covered. > > Thank you for your useful description. > > I had meant to put my case as a clinican but as this is the 'technical' > forum I don't know if it was the right place. Your 'case as a clinican' is in the right forum. It is at the top of the heap. The development should support the clinician at all levels. A 'cold turkey' visit with a Patient (no prior contact) is the worst case. Focusing on this for the moment, the need is to conduct a Patient Query-Response diagnosis to build a basic information base that includes some prior information as well as the reason(s) why they are there. At first glance it would appear that there is no need for a system such as OpenEHR during this brief contact. The reality is that the opposite is true. Faced with handling a potential SARS Patient worrying about retrieving precise, accurate information from them about non-SARS history might be wasted effort and highly frustrating, e.g., sorting "relevant"/"germane" information could impact the schedule and result in dumping portions later on (mental state is operative). Presuming that the Patient just arrived from the recesses of China an initial effort might be an attempt to: 1)determine if that recess has an EHR/EPR/EMR based system that can be accessed, assuming that your site supports OpenEHR. 2)make contact with the Patients record-based system, if possible, and resolve access-related difficulties (e.g., get permission from the Patient or recess-local officials, since this would be a public health issue, to access the information) 3)Assuming the information is made available, perform a translation into English if available; if not, make contact with a translator 4)Make sense of the record, if possible; if not, make contact with a translator 5)Retrieve "relevant"/"germane" information; if not possible, make contact with a translator 6)Retrieve extra-record information, e.g., public health officials; if not possible, make contact with news sources 7)Build an EPR that contains prior information (OpenEHR-compatible) 8)use an appropriate software application to analyze the EPR and highlight loopholes and significant information 9)update the EPR with information related to the Patient's family and contacts 10)update the EPR with current information 11)attempt to update the recess-local EHR/EPR/EMR database 12)continue OpenEHR record processing and update (local and recess-local) Seems like very heavy involvement of OpenEHR at the initial point of contact. Note the presumption regarding the existence of intelligent medical/health software applications. > > I agree that the described approach makes sense and offers a great deal of > customsation regarding access. What I am concerned about, I suppose, is how > the system will be implemented. These concerns stem from some examples I > have heard - for instance an orthopaedic surgeon only requiring information > to perform an operation. Perhaps this is an inaccurate example? > Hope the prior description covers the needed suport of a global, Enterprise system capable of securely accessing and updating local and remote data sources > My viewpoint is that I spend up to an hour when assessing a patient > carefully extracting as much information as possible. My colleagues rely on > the thoroughness of this information to look after this patient. We also > rely on full access to the entire medical record (ever recorded) in order to > safely and holistically care for our patients. I would hope I would have > full access to the medical record in order to fulfill my clinical > responsibilities. > Opinion: A thorough, in-depth attempt at retrieving information from a Patient who is in considerable pain or who is marginally present is probably not an effective approach. A person that sustained a head injury in a car accident would be more interested in receiving treatment than answering a long list of questions. Probably would not remember the answers later. The need for OpenEHR- like and -compatible systems is obvious. The information base is reviewable, verifiable, consistent and can be readily retrieved and updated, e.g., tied to medical devices and mobile/remote Practitioners. > In my field, it is not unusual for patients to either provide unreliable > details or to conceal facts. We often rely on recorded facts rather than > what we are told. In these circumstances I have concerns about the patient's > right to keep private parts of their records. I believe that the suggestion > that a patient may essentially exclude sections of their notes from viewing > represents a major shift in the way we work. I would also argue that it's > difficult for a patient to know when this concealment may put themself or > others at risk. > Recorded facts are subject to bias, bad retrieval methods, mistakes and failures of the recording mechanisms. Would not bet my life on it (I am enrolled in an HMO and have personal experience of inadequate record-keeping, e.g., showed up for surgery to discover that I was not in the database due to the fact that I was put on another list for surgery). > Is the intended approach that the viewer would know there was information > that they could not view or that it is simply hidden? The viewer should have access to "relevant"/"germane" information, which information that there is additional information available. With the Patient sitting in front of you Patient permission can be requested. Patient incapacity is recognized in most legal jurisdictions. If there are no other legally responsible parties present, then emergency premission is available, which should permit the practitioner to access the entire record. Opinion: You might have more difficulty interpreting the record than gaining access to it. Only recently have Practitioners been using word processing applications to update EHR/EPR/EMR database entries. 'database' might still be unknown in certain areas. My HMO is trying to modernize. Neither my Doctor nor I have seen it for three years, but he knows me by now and I refresh his memory every time I need to him. Perhaps in another year my records will be on-line; maybe not. This is California, I am sure of it. > > Matt > > >-----Original Message----- > >From: Thomas Clark [mailto:tclark at hcsystems.com] > >Sent: 02 May 2003 04:18 > >To: Matt Evans; openehr-technical at openehr.org > >Subject: Re: openEHR security; Directed to Thomas Beale > > > > > >Hi Matt, > > > >Fragmented records and securing individual and groups of > >records is a common > >approach. It is very much like taking a 300 page document and > >building a > >security system that enables security: > >1)covering the entire document > >2)separate security covering chapters and > >3)separate security for tables, graphs and figures. > > > >Access to the document is the first step; access to a specific chapter > >requires separate authentication; access to tables, etc can > >require separate > >authentication. This focuses a specific reader's requests to > >those portions > >that are "relevant"/"germane". > > > >"one authentication" systems, e.g., password to your windows > >PC or Linux > >workstation are really ancient security systems. There are > >typically more > >ways to break-in than log-in. > > > >Recall than system and network managers are often the targets > >of security > >probes because they can access your raw data at will; that may > >include your > >sensitive data. If you grant access to the entire EHR for a Patient to > >anyone successfully passing a "one authentication" gate you > >are likely to > >experience some real "pushback". Your obligation as a > >designer is to ensure > >that "relevance" and NEED TO KNOW are essential elements of > >the security > >system and that a successful authentication carries with it an > >assurance > >that the requestor is provided access to only "relevant"/"germane" > >information. > > > >-Thomas Clark > > > > > >----- Original Message ----- > >From: "Matt Evans" <mge at totalise.co.uk> > >To: <openehr-technical at openehr.org> > >Sent: Thursday, May 01, 2003 2:30 PM > >Subject: FW: openEHR security; Directed to Thomas Beale > > > > > >> >[...] > >> >> At all points NEED TO KNOW > >> >> governs access > >> >[...] > >> > > >> >Except that the Need-To-Know paradigm doesn't work very well > >> >in healthcare. The provider may not know what she needs to > >> >know at the time of the patient encounter. The patient can't > >> >possibly correctly decide what her doctor must know in order > >> >to be able to make the right decisions (of course, the patient > >> >is fully able to decide what she *wants* the doctor to know). > >> >Etc. > >> > > >> >Medicine is neither the military nor a secret service, literally > >> >(it's not mass media either, on the other end of the spectrum). > >> > > >> >Just a clinician's muttering ... > >> > > >> >Karsten > >> >-- > >> > >> Karsten, > >> > >> I agree and have concerns about being expected to take responsibility > >> without access to all the facts. > >> > >> I suppose this may not be an issue as I suspect that most > >people won't > >> restrict the information in their file. > >> > >> However, to fragment a medical file into bits I can and can't see is > >similar > >> to taking the view that mind and body are separate entities. > >> > >> If something is restricted, will I know there is something > >there that I > >> can't see? Or will I be blisfully ignorant? How can I know > >if a piece of > >> information is irrelevant unless I can see it to assess it? > >> > >> More mutterings! > >> > >> Matt > >> > >> > >> - > >> 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
