Archetype ontology
Karsten I do not go with the screen shot idea - the issue here is the accountability and if the information is stored in an explicit manner and the rendition can be stored (XSLT or application) then it will be clear what the person saw - the problem with screenshots is the plethora of views that might be used in a single consultation. And can we be sure that the screen was paged down? And what was the resolution of the screen - and the visual acuity of the practitioner - and what parts of the screen did their eyes stray to... Our research in GEHR had a clear outcome - clinicians did not want this sort of EHR and it served no useful purpose. Cheers, Sam Dr Sam Heard The Good Electronic Health Record Ocean Informatics, openEHR 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.gehr.org www.openEHR.org __ > -Original Message- > From: Karsten Hilbert [mailto:Karsten.Hilbert at gmx.net] > Sent: Saturday, 14 September 2002 5:49 PM > To: Gerard Freriks > Cc: Melvin Reynolds; Thomas Beale; William Hammond; Sam Heard; > Openehr-Technical > Subject: Re: Archetype ontology > > > > So an EHR is a series of signed, authored messages that can be used in > > court. Without the fulfillment of the requirements, the EHR is > nothing but > > information written in the sand before a wave of the sea washes it away. > This is, however, the way medicine worked for thousands of > years, and reasonably well, obviously. It is trust that > defines the doctor-patient relationship, not proof. > > > What an application does with the information on a screen and in its > > database is much less relevant from a legal perspective. > > What is signed is relevant. > Are you suggesting applications should store digitally signed > screenshots ? > > Regards, > > Karsten Hilbert, MD > GnuMed i18n coordinator > -- > GPG key ID E4071346 @ wwwkeys.pgp.net > E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype ontology
Hi All, I am rather late to this thread, but it seems to me that there are a number of alternatives here: a) Do nothing b) Have a reasonably secure system, but no signing c) Sign the content in the database d) Sign what was on the screen and store the signed image You can spend all day arguing about which one to adopt, but the reaility is the is no one true answer to this as it is all horses for courses. In an evnrionment where everyone is trustworthy or the conseuqneces of violation are low then (a) is an option. In some environments where the system administrators and developers can be trusted then option (b) is enough. In other environments where no one can be trusted then even (d) might not be enough. What you need to do is tailor your choice of what you sign (or even if you sign anything) based on the potential risks and the consequences if that risk occurs and wether you are willing to spend the money to prevent it from occurring. cheers, Andrew On Sun, 15 Sep 2002, Gerard Freriks wrote: > On 15-09-2002 11:26, "Karsten Hilbert" wrote: > > > 1) How do I know that the passphrase I typed in to be used for > > the secret key is used to sign what I see on screen and > > nothing else ? > > > Because a special secure device does all the encrypting. > After having inserted the Health professional Card > > > > > > 2) How does the court know that a signed screenshot was > > actually shown on screen and not just fabricated and never > > shown ? (It is my responsibility to _inspect_ what is being > > shown but I cannot prove that signed "screenshots" were > > actually displayed (on current-day systems). > > > > Because the secure device is able to place the information on the screen. > > Having a screenshot provides a richer picture than a set of bits and bytes > down deep in the database. > > > > > This isn't about 100% proof, this is about level of trust, > > feasability, deniability and due process. Even with signing > > screenshots. > > >>> > > True. > I'll have more confidence in a message displayed on a screen than bits and > bytes in a distributed database in an Health Information Infrastructure > > > > Or did I miss something ? > > > > Since it is my responsiblity to carefully inspect the > > on-screen information I could just as well extend that view to > > that it is my responsibility to use a system that I can trust > > to show me what is actually in the database. Thusly I could > > just as well sign database content. Gerard himself remarked > > that we cannot sign that anyone actually reviewed any > > information, only that it was made available. The latter can > > be at the level of a screenshot - or at the level of database > > content. After all it is my responsibility to inform myself > > no matter where I get the information from. Say, I am using an > > SQL shell and sign screenshots of my queries. Does this mean I > > am not liable for the anaphylactic reaction just because I > > didn't do the query for the known penicillin allergy ?!? > > Obviously not, although I understand your position to be: "It > > hasn't been shown to me hence I am not to blame." What other > > purpose might a signed screenshot server ? To shift blame to > > the EHR software manufacturer ? > > > > The whole thing has to do with liability and legal proof. > > If next to the information in a database the style sheet used to display is > stored, it is possibly good enough for legal proofs. > > > Lastly, one simple question. How does TNO propose to handle > > the audit trail of signed screenshots simply in terms of > > storage requirements ? > > > > This is a simple problem. > Now every year one hospital needs 1 kilometre of shelf space. > > Have you ever compressed XML documents? > Have you ever looked at diskspace and prices? > > > >> Making a hash of a screen dump indicates: This is the information as I saw > >> it on a screen and take responsibility for it by signing. > > Nah, I doubt you really believe in the coherency of this > > statement. A screendump merely shows what a screen _may_ have > > looked like. > > > > I think it is fully coherent. > > Yes. But systems that have been certified will have a perfect screendump. > This is something that can be tested easily. > > To proof that in a distributed environment all informationsystems worked > 100% is much more difficult? > Right? Or wrong? > > Gerard > > > > > Karsten Hilbert > > -- -- > Gerard Freriks, arts > Huigsloterdijk 378 > 2158 LR Buitenkaag > The Netherlands > > +31 252 544896 > +31 654 792800 > > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > _-_|\Andrew Goodchild / * DSTC Pty Ltd \_.-._/ Brisbane, Australia vhttp://staff.dstc.edu.au/andrewg/ - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype ontology
Andrew Goodchild wrote: >Hi All, > >I am rather late to this thread, but it seems to me that there are a >number of alternatives here: > >a) Do nothing >b) Have a reasonably secure system, but no signing >c) Sign the content in the database >d) Sign what was on the screen and store the signed image > >You can spend all day arguing about which one to adopt, but the reaility >is the is no one true answer to this as it is all horses for courses. In >an evnrionment where everyone is trustworthy or the conseuqneces of >violation are low then (a) is an option. In some environments where the >system administrators and developers can be trusted then option (b) is >enough. In other environments where no one can be trusted then even (d) >might not be enough. > >What you need to do is tailor your choice of what you sign (or even if you >sign anything) based on the potential risks and the consequences if >that risk occurs and wether you are willing to spend the money to prevent >it from occurring. > I think this is a good overall comment. To which I'll add that what needs to be shown to have been understood in court are simple clinical or other facts, in the form of propositions, not screen bit patterns. In court, it will nee to be shown that that clinician understood fact A, B and C before attesting the addition to the EHR. Screen shots are not the way to do this. I suggest that a "standardised XML rendition" of the EHR entries in question are the way to go. Also, we should be careful to differentiate between "attestation" - the act of the clinician agreeing that he/she has in fact seen and understood what is on the screen be fore committing it to the EHR, and "signing" which is an attestation that some lump of content was created by a certain person, and not someone else. I don't think "signing" guarantees anything about comprehension, just that a particular stream of bytes emanated from a source which is positively identified as "Dr so-and-so". - thomas beale > > >cheers, Andrew > > >On Sun, 15 Sep 2002, Gerard Freriks wrote: > >>On 15-09-2002 11:26, "Karsten Hilbert" wrote: >> >>>1) How do I know that the passphrase I typed in to be used for >>>the secret key is used to sign what I see on screen and >>>nothing else ? >>> >>Because a special secure device does all the encrypting. >>After having inserted the Health professional Card >> >> >>>2) How does the court know that a signed screenshot was >>> actually shown on screen and not just fabricated and never >>> shown ? (It is my responsibility to _inspect_ what is being >>> shown but I cannot prove that signed "screenshots" were >>> actually displayed (on current-day systems). >>> >>Because the secure device is able to place the information on the screen. >> >>Having a screenshot provides a richer picture than a set of bits and bytes >>down deep in the database. >> >> >> >>>This isn't about 100% proof, this is about level of trust, >>>feasability, deniability and due process. Even with signing >>>screenshots. >>> >>True. >>I'll have more confidence in a message displayed on a screen than bits and >>bytes in a distributed database in an Health Information Infrastructure >> >> >>>Or did I miss something ? >>> >>>Since it is my responsiblity to carefully inspect the >>>on-screen information I could just as well extend that view to >>>that it is my responsibility to use a system that I can trust >>>to show me what is actually in the database. Thusly I could >>>just as well sign database content. Gerard himself remarked >>>that we cannot sign that anyone actually reviewed any >>>information, only that it was made available. The latter can >>>be at the level of a screenshot - or at the level of database >>>content. After all it is my responsibility to inform myself >>>no matter where I get the information from. Say, I am using an >>>SQL shell and sign screenshots of my queries. Does this mean I >>>am not liable for the anaphylactic reaction just because I >>>didn't do the query for the known penicillin allergy ?!? >>>Obviously not, although I understand your position to be: "It >>>hasn't been shown to me hence I am not to blame." What other >>>purpose might a signed screenshot server ? To shift blame to >>>the EHR software manufacturer ? >>> >>The whole thing has to do with liability and legal proof. >> >>If next to the information in a database the style sheet used to display is >>stored, it is possibly good enough for legal proofs. >> >>>Lastly, one simple question. How does TNO propose to handle >>>the audit trail of signed screenshots simply in terms of >>>storage requirements ? >>> >>This is a simple problem. >>Now every year one hospital needs 1 kilometre of shelf space. >> >>Have you ever compressed XML documents? >>Have you ever looked at diskspace and prices? >> >> Making a hash of a screen dump indicates: This is the information as I saw it on a screen and take responsibility for it by signing. >>>Nah, I doubt you really believe
Archetype ontology
On 16-09-2002 03:03, "Thomas Beale" wrote: > I think this is a good overall comment. To which I'll add that what > needs to be shown to have been understood in court are simple clinical > or other facts, in the form of propositions, not screen bit patterns. In > court, it will nee to be shown that that clinician understood fact A, B > and C before attesting the addition to the EHR. Screen shots are not the > way to do this. I suggest that a "standardised XML rendition" of the EHR > entries in question are the way to go. > > Also, we should be careful to differentiate between "attestation" - the > act of the clinician agreeing that he/she has in fact seen and > understood what is on the screen be fore committing it to the EHR, and > "signing" which is an attestation that some lump of content was created > by a certain person, and not someone else. I don't think "signing" > guarantees anything about comprehension, just that a particular stream > of bytes emanated from a source which is positively identified as "Dr > so-and-so". > > Slowly we are making progress. I agree that there are several reasons to sign and possibly we need ways to indicate this. I agree that there are several contexts. The lonely healthcare provider on his IT island, the one that exchanges information with a few other colleagues, the healthcare providers that are part of a complex network for the exchange of messages, the ones that are part of an higly integrated system of systems. The more complex the more detail has to be stored explicitly. I agree that 'screenshots', 'pictures' can be engineered in several ways. The most likely candidate is XML-document and XML-stylesheet. But perhaps there are others. Gerard Ps: sorry for having an extemist view. -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype ontology
Sam, There is a difference between looking at various screens during a consultation and the signing of part of the information that needs to be signed. E.g. Orders, communications with others. It is clearly not necessary to make movies of what was presented on the screen during the consultation. Gerard On 16-09-2002 01:45, "Sam Heard" wrote: > Karsten > > I do not go with the screen shot idea - the issue here is the accountability > and if the information is stored in an explicit manner and the rendition can > be stored (XSLT or application) then it will be clear what the person saw - > the problem with screenshots is the plethora of views that might be used in > a single consultation. And can we be sure that the screen was paged down? > And what was the resolution of the screen - and the visual acuity of the > practitioner - and what parts of the screen did their eyes stray to... > > Our research in GEHR had a clear outcome - clinicians did not want this sort > of EHR and it served no useful purpose. > > Cheers, Sam > > Dr Sam Heard > The Good Electronic Health Record > Ocean Informatics, openEHR > 105 Rapid Creek Rd > Rapid Creek NT 0810 > Ph: +61 417 838 808 > sam.heard at bigpond.com > www.gehr.org > www.openEHR.org > __ > > > >> -Original Message- >> From: Karsten Hilbert [mailto:Karsten.Hilbert at gmx.net] >> Sent: Saturday, 14 September 2002 5:49 PM >> To: Gerard Freriks >> Cc: Melvin Reynolds; Thomas Beale; William Hammond; Sam Heard; >> Openehr-Technical >> Subject: Re: Archetype ontology >> >> >>> So an EHR is a series of signed, authored messages that can be used in >>> court. Without the fulfillment of the requirements, the EHR is >> nothing but >>> information written in the sand before a wave of the sea washes it away. >> This is, however, the way medicine worked for thousands of >> years, and reasonably well, obviously. It is trust that >> defines the doctor-patient relationship, not proof. >> >>> What an application does with the information on a screen and in its >>> database is much less relevant from a legal perspective. >>> What is signed is relevant. >> Are you suggesting applications should store digitally signed >> screenshots ? >> >> Regards, >> >> Karsten Hilbert, MD >> GnuMed i18n coordinator >> -- >> GPG key ID E4071346 @ wwwkeys.pgp.net >> E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype ontology
>> Lastly, one simple question. How does TNO propose to handle >> the audit trail of signed screenshots simply in terms of >> storage requirements ? >> > This is a simple problem. > Now every year one hospital needs 1 kilometre of shelf space. Well, the treeware equivalent of what we are talking about here is: Any time I look at the paper chart I'll make a copy of the page I look at, date and sign it and add it to the ever-growing chart, e.g. any time I invoke a screen I should need to sign what I saw, right ? > Have you ever compressed XML documents? I thought we were talking screenshots here ? Binary data ? Already compressed ? > Have you ever looked at diskspace and prices? Yes, and I have looked at my salary. I am talking GP level here. >>> Making a hash of a screen dump indicates: This is the information as I saw >>> it on a screen and take responsibility for it by signing. >> Nah, I doubt you really believe in the coherency of this >> statement. A screendump merely shows what a screen _may_ have >> looked like. > I think it is fully coherent. Are you telling me you mean "a signed hash of a screendump proves that I saw the screendump" ?!? > To proof that in a distributed environment all informationsystems worked > 100% is much more difficult? > Right? Or wrong? Right. Karsten Hilbert -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
