Archetype ontology
Hello all This is a useful discussion - I am much more with Karsten than Gerard on this - all the 'proofs' in the world amount to nothing in the digital world - as things can be altered at any point anyway. The GnuMed trust solution does get someway towards this. The technical solutions offered at the moment really do not match the reality and until we have working EHR systems and integration, these sorts of debate need to stay in the background. They do not really impinge greatly on the EHR requirements. But keep it up! Sam Heard -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Karsten Hilbert Sent: Sunday, 15 September 2002 6:57 PM To: Gerard Freriks Cc: David Guest; Openehr-Technical; Ton Smit Subject: Re: Archetype ontology 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 ? 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). This isn't about 100% proof, this is about level of trust, feasability, deniability and due process. Even with signing screenshots. 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 ? Lastly, one simple question. How does TNO propose to handle the audit trail of signed screenshots simply in terms of storage requirements ? 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. 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
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 Karsten.Hilbert at gmx.net 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 -- private -- 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 Karsten.Hilbert at gmx.net 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.
Archetype ontology
On 16-09-2002 03:03, Thomas Beale thomas at deepthought.com.au 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. -- private -- 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
Archetype ontology
On Sat, 2002-09-14 at 23:29, Gerard Freriks wrote: Text as pointers or URL's it is all fine with me. But he signes what he sees. I think I've got it, Gerard. What are you signing is that a certain dataset was available to you on a particular day for a particular patient. You are not signing that you have understood or even looked at it but that it was available. Wouldn't a hash of the data be both smaller and a more reliable attestation of the data available? David -- David Guest GPG key ID BE79B742 @ pgp.mit.edu Fingerprint: 2609 DB95 C040 5902 BA0C 4D3C F1F2 EA62 BE79 B742 -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20020915/3a1df681/attachment.asc
Archetype ontology
Melvin Reynolds wrote: Once again I agree (mostly!) - and certainly did not want to imply different levels of medico-legal requirement within any particular jurisdiction. The integrated healthcare record is very usefully regarded as a single repository which contains, either directly or by reference, all the data that relates to the process of actually clinical care (not the facilitating aspects of the healthcare infrastructure*) - but upon which there are appropriate views according to the use context. However, the difficulty I have is with the throwaway statements (perhaps just intended as 'shorthand' but if so not sufficiently specific to be helpful at this stage of development and email communication) which if taken literally will result in flawed design: generally not come from messages - there is no other place for this data to come from but the GP application generally and there is no other place is the problem here, often would be more accurate because, as an example, the giving of vaccinations to children in school is not likely to be noted through the multiple GP systems related to the children - but through a Community system (of whatever sort) - and then messaged back to the EHR as seen by the GP - so there's clearly an other place. Similarly Social history information may well arrive from the Social services system ... ah well - I guess I was talking in the idea future world of EHRs being everywhere, not today. In the future of a shared care, community-based EHR I would expect both types of carers you mention to be entering the data into the EHR, not in some other system... maybe I am wrong here. Anyway, I accept what you say - let's just say that now and in the future, in many instances, the data for the transaction types i mention will come from GPs and other carers accessing and modifying the EHR. instead come through the application / EHR kernel API, fine, so long as this means: through *an* application *and/or* the kernel API yes - whatever application being used. and create EHR data on the fly. fine, so long as this means, for example: receive (and store) message data, acknowledge message data if appropriate according to implementation requirements, assign message data to EHR as agreed by all users of EHR *or* reject message data for EHR as agreed by all users of EHR (but in this case log receipt of message data even if not available for 'default display'). well I wasn't talking about messages here - I was talking about communication through a network-visible API, which is what you get with .net, SOAP, Corba etc. This should have read Sorry if I have missed *something*. I guess from mails on another thread that these issues will get another airing in Baltimore. What it underlines for me is the need for precision in our use of terms - and I plead guilt to imprecision when doing/saying things in haste, and sometimes at other times too :). me too;-) - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype ontology -- on the horizon a huge extra payload ?
If health and social care continue to converge as is happening in the UK then the protocol of Soc Services is to also record things that may have been considered appropriate in principle but which the individual professional based on knowledge of the individual client circumstances chose explicitly NOT to do. This and the current discussion about 'signing' could have major ramifications on size and performance of records management systems. Any comments? Jean Roberts st dguest at zeeclor.mine.nu writes On Sat, 2002-09-14 at 21:03, Gerard Freriks wrote: Karsten, And others, What is your idea? - Can you agree with me that it is possible to proof that information was in a database at a certain time in most systems? Certainly. That's what Horst's gnotary is about. http://www.gnumed.net/gnotary/ But most systems are unable to proof what was seen on a screen and signed before being committed to the record or sent to an other entity? - What are the consequences of the extreme but defendable position of TNO-PG? Gerard The logs would show that all the relevant patient data had been downloaded to the client. I think it is asking too much of the process to also verify that the doctor saw it on the screen, was in a fit state to process the data and come to a logical conclusion. In my experience only the clinical note written on the day can concisely log what data was processed to come to the clinical management plan. Having pointers to the relevant data is helpful (e.g. see last entry 5 July 2002; Dr Jones' letter, 26 February 2000, histopathology skin 14 September 2002). I once thought a drag and drop hyperlink might be the best way to do this but text entry is as efficient; just not as cool. Is this what you are trying to achieve? David Phoenix Associates, 19 Church Meadow, Ipstones, Staffs, ST10 2LS UK email : jean at hcjean.demon.co.uk http://www.hcjean.demon.co.uk tel 07771 804472 or tel/fax+44 1538 266944 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype ontology
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 ? 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). This isn't about 100% proof, this is about level of trust, feasability, deniability and due process. Even with signing screenshots. 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 ? Lastly, one simple question. How does TNO propose to handle the audit trail of signed screenshots simply in terms of storage requirements ? 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. 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
Archetype ontology
On 15-09-2002 11:26, Karsten Hilbert Karsten.Hilbert at gmx.net 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 -- private -- 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
Gerard, Hopefully these TNO Essential EHR Requirements will be compatible with the ISO 13808 Requirements for an EHR Reference Architecture. The draft 18308 Technical Specification will go for ballot in November so it would be very important that we have the TNO requirements congruent with 18308 before then. I latest draft of 18308 was circulated to TC 215 WG1 on Friday and should be available on the WG1 website within a few days but I will send you a copy directly via separate email. Peter Schloeffel ISO 18308 EHR Requirements project leader -Original Message- From: owner-openehr-techni...@openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Gerard Freriks Sent: Saturday, 14 September 2002 6:23 PM To: Karsten Hilbert Cc: Melvin Reynolds; Thomas Beale; William Hammond; Sam Heard; Openehr-Technical; Ross Anderson Subject:Re: Archetype ontology Karsten, It is the opinion of the Applied Technical Research Institute (TNO-PG), I work for, after having studied European law and Dutch law that possibly the only legally valid proof is a signed 'picture' of what was shown on the screen. E.g. A prescription, an order, a referral. Next to the information formally submitted into the EHR their will be a whole gamut of other secondary information: private notes, not evaluated results and opinions. This 'picture' could be generated from information in a database. Why a 'picture'? Not only the stored information is information; the way it is presented is information as well. How can one be sure that what is stored in the database is what has been presented visibly on the screen? (black characters on a black background, information hidden behind on other window, etc) The question open for debate is: what is this 'picture'? Is it a PDF? Is it Microsoft Word? Is it data in a XML-Document plus the style sheet used? Is it ...? What a signature is and what a signed document is, is more clear in Europe. All this is part of the TNO-PG Essential Requirements for the EHR. Only systems that comply will fulfil all basic requirements as expressed by European Directives and Dutch law (that is derived from these Directives) Gerard Helas. Copies of these Essential Requirements are not available for publication, yet. It is a difficult complex document that is being revised and improved all the time. Until it has been transformed into a usable and easy readable format we only have copies for internal use and for our customers that want to have their products approved. It is our goal to present them to the ISO/TC215 community in due time for consideration. On 14-09-2002 10:19, Karsten Hilbert Karsten.Hilbert at gmx.net wrote: 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 -- private -- 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype ontology
Melvin Reynolds wrote: Thomas, Somewhat to my surprise I find myself agreeing with most of your points in the discussion below. he he he, that's the kind of reply I like to see;-) However, the final statement ... As soon as one starts thinking about what has to happen to turn messages into EHR content, it becomes clearer and clearer that the EHR is nothing like a compendium of messages; for from it - it is a time-based accumulator of EHR information, some of which is sourced from messages, much of which is created by human users of GUI applications. seems like a gross oversimplification of the reality. It is true a readable EHR is not likely to a compendium of messages. But an EHR for use in a primary care context is not likely require to present the same information (in full) as an acute secondary care EHR; and neither are likely to require to present the full audit trail of all messages, requests and reports that would be required of a medico-legally complete (but clinically unhelpful) EHR. Well, that's probably fair enough (although I am not sure I believe that GPs are any less required to have medico-legal protection than any other clinician), but consider that even in a local GP EHR, modifications to things like Current Medications, Family history, Social History, Vaccination record, Therapeutic precautions , Problem list, will generally not come from messages - there is no other place for this data to come from but the GP application. It will instead come through the application / EHR kernel API, and create EHR data on the fly. Now... try to imagine how useful the GP EHR would be minus the items I mention As well as a clarification of scope, it would seem to be important to clarify at what level of context/granularity we are seeking to produce the EHR. do you want to expand on this? Sorry if I've missed anything - but the recent discussions would seem to indicate that I'm not alone if I have. just point it out, and I'll try to explain more what I think, if at least that can help... - thomas - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype ontology
On 13-09-2002 16:51, Melvin Reynolds MelvinR at AMS-Consulting.co.uk wrote: However, the final statement ... As soon as one starts thinking about what has to happen to turn messages into EHR content, it becomes clearer and clearer that the EHR is nothing like a compendium of messages; for from it - it is a time-based accumulator of EHR information, some of which is sourced from messages, much of which is created by human users of GUI applications. seems like a gross oversimplification of the reality. It is true a readable EHR is not likely to a compendium of messages. But an EHR for use in a primary care context is not likely require to present the same information (in full) as an acute secondary care EHR; and neither are likely to require to present the full audit trail of all messages, requests and reports that would be required of a medico-legally complete (but clinically unhelpful) EHR. The information a healthcare provider submits to the record is what he/she sees on the screen. This committed information has to be signed. It is not sufficient that the author is recorded but for legal proof it is necessaryb that he/she signes the text with his/her private key. This is the position we (at TNO-PG) take after having studied the legal literature (1500 pages of texts from EU Directives, Dutch laws, FDA documents and ethics documents) 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. 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. -- work -- Gerard Freriks TNO-PG Zernikedreef 9 2333CK Leiden The Netherlands +31 71 5181388 +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, Could the following be another example? The Blood pressure. The RR as an act, a measurement, a procedure. And the RR as a set of values, the result of the act, the measurement results, the result of a procedure. The act is one thing, an intention. The value as the result of the execution of the intention. The intention can exist without a real value. In ENV 13606 part 2 there are the possibilities to add modifiers (attributes) to 'things' that can express concepts like these. The question is: Will we need a new Concept Information Model (archetype) to distinguish between the two or is one attribute enough? Gerard On 03-09-2002 22:31, Sam Heard sam.heard at bigpond.com wrote: Dear all, I have been working hard to get an ontology of archetypes developed that will show the health domain mapped into the openEHR architecture. I have found a couple of things: 1. That there is often a link between an instruction and subsequent observations - which I think will be more important as knowledge bases are developed in the future. I have called the link an action specification and at present it is modelled as part of the instruction. Let me give a real example. If you prescribe a medicine then there are a number of attributes of that medication order - dose, form, route etc - and there is the frequency of administration. When you record that a medication has been administered - then you record the dose, form, route etc - but not the frequency. The link is the specification of the action - but not the conditional elements of the instruction. Many other things may be specified at the time that they are ordered and there may be protocols etc that are to be followed. For this reason - I have two new subclasses in the ontology (not in openEHR) - openEHR Observation - action and openEHR action specification. This allows me to say which action specification applies to an instruction and which obeservations it applies to. 2. It might be necessary to state the sequence of different instructions. The French oncologists wish to state this for Surgery, Radiotherapy, Chemotherapy etc. Clearly each of these will have a complex action specification. How then to make it clear about the order of the instructions - should one finish before the other starts? I welcome your ideas. I have put the zipped (45K) protege files on www.gehr.org in the Watch this space section. 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 __ - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -- private -- 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
