YES
- If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Issue 1
Hi Ed, One needs to distinguish between System Designers and Application Designers and both can be subdivided further, e.g., Fault-Tolerant. System Designers 'handle' the data and information; Application Designers 'handle' the content. Understanding the difference between data and information is required for both and each has to be aware that some of the data and information may not be present for their consumption, perhaps a majority may be destined for others. A simple analogy is a communications technology, e.g., Fibre Channel networking, in which the data in packets are subject to further structuring beyond the current node. Some of the data can be 'local' and the remainder for remote users. The System/Application Designer retrieves the data, and information, required to perform their tasks and passes the remainder on. Good design includes data/information modification to indicate later that the access has been made. In some cases additional data, and information, is added to indicate that the data, and information, has reached the current node or another event has occurred, e.g., errors reported. The original data is left undisturbed. Such features are desirable, for example, in Fault-Tolerant Networking. An EHR-based system serves many users with different requirements and often little contact between groups of users, e.g., General Practice, Surgery, Mental Health, Public Health and Dental. For whatever reason a record is created, by whom and within an environment it is a container that users can add information but never delete information (persistent monotonically increasing). If at some point a user is moved to consider the content useless they should be able to create their own 'container' and link it to the original. 'Link' is very important since to do otherwise would produce chaos quickly. An EHR-based system compared with my paper-based Healthcare record (well over 100 pounds at present) shows the same separation of disciplines, e.g., GP enters their data, the Surgeon theirs, the Therapist theirs and the Emergency Room theirs, each reminding me it is my responsibility to inform the others of the results. All their 'data' end up in the same bin, i.e., my paper file. I often wondered why they would not or could not read each others reports until I tried to read them myself. I then realized why Attorneys have to summarize medical records and threaten to introduce the medical records into the court records. One could say that it is 'too much information' and one would expect to be prevented in Court from having a GP review and analyze the report from a Brain Surgeon, but in no way would one be allowed to 'edit' even their own historical record. My suggestion is to take what you need from the record, but be sure to take everything you need, and move on. Practitioners can't end up as Data/Information Editors. In creating records follow a set of rules that include 'error on the side of excessive reporting' and ignore potential future comments. Going back to 'fix' the record is really not a good idea. Recall one difference between paper-based records and Electronic Records: the time interval associated with data capture and recording is a lot shorter and hence reduces the amount of time available to reflect on what you are doing. Apart from the 'System/Application Designers' attempt to incorporate redundancy into a records system to enhance recoverability in the presence of hardware failures and software errors, extraneous record data in the opinion of a Practitioner rarely harms them. If it becomes an issue them a discussion with others associated with the record might relieve some tension. A better approach might be to focus on the accuracy and precision of the data, and information, that a Practitioner retrieves from the record. Regards! -Thomas Clark William E Hammond wrote: However, in my opinion, one can have too much data. Information, by definition, is more than data and conveys something understandable and useful that was not known before. Information deals with raising entrophy. Long story short, designers of systems need to undersatnd the difference in data and information - ands, ideally, provide just what is needed when it is needed to address the circumstances of the situation. Ed Hammond lakewood at copper.net lakewood To: openehr-technical at openehr.org Sent by:cc: owner-openehr-technical@
uncertainty in medical problem solving and decision making (Was: Dr R LONJON Confidence indicator !
Hi Arild, Another site is the MIT Group on Clinical Decision Making: [ http://medg.lcs.mit.edu/ ]. ... a research group dedicated to exploring and furthering the application of technology and artificial intelligence to clinical situations. Because of the vital and crucial nature of medical practice, and the need for accurate and timely information to support clinical decisions, the group is also focused on the gathering, availability, security and use of medical information throughout the human life cycle and beyond ... Unfortunately Patient decision-making receives less emphasis and studies seem to miss some fundamental factors (e.g., it is private) [ http://www.ahrq.gov/research/rtisumm.htm ] Regards! -Thomas Clark Arild Faxvaag wrote: Hi all. This is an important topic. Here are some references / pointers for those who wish to read more: Decision making in health and medicine. Integrating evidence and values Myriam Hunink and Paul Glasziou Cambridge university press (ISBN 0 521 77029 7) Society for Medical Decision Making: http://www.smdm.org/ I also recommend journal articles written by Wimla L Patel (Colombia university, New York), for instance: http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrievedb=pubmeddopt=Abstractlist_uids=11418539 (A primer on aspects of cognition for medical informatics) regards arild Faxvaag P 22. apr. 2005 kl. 07.42 skrev Gerard Freriks: -1- Almost never a diagnosis is 100% certain. -2- Almost always a test result has uncertainty attached to it -3- Many times a conclusion is reached based on many uncertain and conflicting facts -4- Quite often a condition, a diagnosis, is assumed that gives rise to a treatment. Not indicating that the patient is suffering from this condition but using treatment as a test procedure. Doing nothing is such a test procedure. Eric Wulff (from Danmark) published philisophical texts about health care and these topics. gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 20 Apr 2005, at 13:58, Thomas Beale wrote: I'm wondering if there is a meta-algorithm of some sort lurking behind the scenes, which takes account of uncertainty in a note, and also severity of non-discounted possibilities, as a way of deciding what to do next. There is undoubtedly published work on this... thoughts? - thomas beale -- Arild Faxvaag associate professor / rheumatologist Adress / Office St.Olavs hospital: Department of Rheumatology, St.Olavs hospital N-7006 Trondheim, Norway Phone Dept of Rheumatology 47 7386 7263 Adress / Office NTNU Norwegian center for electronic patient records research (NSEP) Medisinsk teknisk forskningssenter N-7489 Trondheim Cellphone: 47 9821 6825 http://www.ntnu.no/~arildfa/ (home page NTNU) http://www.usemed.com (weblog on e-medicine) http://www.ehr.ntnu.no/e (Norwegian Centre for Electronic Health Records Research) - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Authenticity Issues [was: Re: Demographics service]
Hi Bish, Periodic and immediate 'Bio' identification would satisfy certain security requirements re authenticity, e.g., official documents (e.g., post surgical release). Your comment re 'thumb imprint', or scan, provides a more secure means of authentication that may be required. Requiring that a 'digital signature' be incorporated within a EHR is a step forward but if all that is required is the presence of a digital signature one can be obtained from multiple sources. As you indicated 'verification of authenticity' is required. Verification, however, can be 'fooled' as well, e.g., where digital signatures are collected in advance into a set of 'secure signatures' the presence of one or more of these signatures within an EHR indicates just that and no more. How is this solved in other fields? 'Bio ID' is one approach, e.g., 'finger and thumb imprint', a digital photo and a voice track, in addition to other digital signatures puts up a much higher wall. I am intrigued by the combination of voice tracks with background syn, e.g., Practitioner and Practitioner + Patient.. An example would be a Hospital Delivery Room (multiple persons) and an automatically generated voice track Properly encrypted the track would be hard to break and/or deny. In other areas similar approaches are available, e.g., encrypted time/date/voice tracks can be integrated into Medical devices and then into EHRs. Side benefits include integration of the time/date into the EHR. A major problem with the photo approach is that some persons become unrecognizable after a 12 hour shift. A problem with ordinary 'digital signatures' is that they can be hacked, patched and the wrong ones, e.g., a reserved place in an EHR for a fixed-length digital signature is bad since one might be able to place another there. Regards! -Thomas Clark USM Bish wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Mar 05, 2005 at 07:34:47PM +0100, Karsten Hilbert wrote: The main issue here is varification of authenticity of digital data entry. There must be some mechanism to ensure that every entry placed in the EHR must be authenticated by the signitory, even if the entry is made by a secretary, DEO or transcription- ist. A first-step solution might be this: - writes are tracked (author, timestamp) - regular clear-text database dumps are taken (say, twice daily) this includes the tracked writes (eg audit logs) - dumps are signed to be authentic by a, say, CMO - dump hashes are timestamp-signed by non-affiliated third parties (say, digital notary servers provided by medical faculties, etc.) This is a logical process to start with. The issue here is acceptance and institution of the 'notary servers' ... these need to find a place within the system universally. [some snipped] Audit trails of visits are only to ensure read access by authorised agencies. Even that does not really add any value. IF access occurred it must have occurred with proper credentials (barring bugs in the software). Yup, as far as the technical side is concerned, this should be the end point that we need to go for presently ... The question is whether those credentials were abused by someone who wasn't supposed to know them or by someone in the know but who wasn't supposed to access that part of the data. One study showed a decrease in the latter when tracking reads was announced to the regular users. These are human shortfalls. The fact is, if a sysadmin is happy to broadcast access passwords to all-and-sundry, ultimately, he/ she is to be held responsible. It is possible to incorporate much more stringent access methods by thumb imprint or pupil signature varification (and methods yet to come). However, such mathods may not be easily deployable or cost effective. Just my 2p Bish -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFCKrmHr5z5toona28RAkTiAJ4hy3mVByXwyOIhPnzFQhoxQ+3powCfbiMq Chr+CL6Y/Z6uAj+fvXReau4= =4UHc -END PGP SIGNATURE- - 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
Governance and Legal Demographics services?
Hi David, Suggest you look at the creating systems for Patient-centered and controlled Healthcare Records that incorporate portions of the Practitioner created and maintained Healthcare Records. Regulations and other 'governance' was designed primarily to target Practitioners and the practice of Medicine. In many cases they are protective. Much like the 'common law' of ancestral England where the intent was to keep the populated well enough for battle. Modern regulations, e.g., Patient privacy, are designed to keep noses out of the Patient's and their Practitioner's business, e.g., Insurance Companies. However, Patient controlled secure Healthcare Record Systems are apparently different under the law, exception for the companies controlling them, so that, with secure coverage for all transactions, the Patient and Practitioner can maintain their relationship in private. Even other Healthcare service providers (e.g., labs) would deal with Patient-Practitioner provided identification objects. There seems to be low impact upon the Practitioner while the Patient has to take some additional control over the management of their Healthcare (e.g., responsible for maintaining the records). As a Patient Advocate I have been looking at the Patient's side of the equation and it is not as bleak as one might think. Even Senior Citizens are becoming computer literate and computer application trainable. The younger generations are already there. Could be interesting for 'Down Under' and Remote Medicine in general. Regards! -Thomas Clark Bigpond wrote: International Law now there's a fascinating issue. We can't even get Australian law to work across 7 states and territories. We have a good chance with HealthConnect and a strong central drive (but). Goodness knows how the USA will achieve it. We are all watching the UK NHS experience with interest. I remember when we were looking at telehealth services across state boundaries and the legal minefield of registration and accreditation let alone litigation. What interesting times we can observe! As always it will not be the technical issues that stop (slow) us - mind you archetypes are a challenge (sorry Sam) and so is the HL7 RIM! In any event it will be the human factors that get us in the end - consumer rights, privacy, professional roles, security, data aggregation and simple fear and stubbornness. At the end of the day what created the medical record and why? Have we lost sight of its use as a simple and effective knowledge management tool for individual clinicians to work in the way that they wanted too -flexible to cope with all their individuality and frailties. This will be the stumbling block as we try, oh so hard to make it a holy grail of health care - it never was and I doubt it ever will be. Hey but isn't it fun! David from Downunder. -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Bob Smith Sent: Saturday, 5 March 2005 11:33 PM To: openehr-technical at openehr.org Subject: RE: Governance and Legal Demographics services? Hello David and Thomas, You said: You speak much sense!! The Legal environment in particular requires reconstruction. When you combine these ideas of Sense Making and Reconstructing the legal environment's relationships to medical communities of _EHR practice we tickle the need for some common upper ontology for the domains of governance which includes the process by which the legal environments are created and maintained in various countries. Several of us involved in a US NHIN_EHR Request for Information process have begun muddling the question of governance in standards bodies such as OASIS and considering the processes by which XML evolved under Jon Bosak and others a decade ago as the basis for building some US Natl Health Info/Knowledge Networks to support standards for _EHR deployment and use. So an intenational awareness is essential, but how far has the openEHR community explored these dynamic issues? And how are the relationships being expressed? Bob -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of Bigpond Sent: Saturday, March 05, 2005 4:25 AM To: openehr-technical at openehr.org Subject: RE: Demographics service You speak much sense!! The Legal environment in particular requires reconstruction. Oh that was the best one I heard today - it's in the order of when the warp drive emerges. Need to think more on your wise thoughts though. David -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of lakewood at copper.net Sent: Saturday, 5 March 2005 3:36 AM To: openehr-technical at openehr.org Subject: Re: Demographics service Hi David, Significant problem! However, software configuration management has solved this
Demographics service
Hi Gerard, Some possible applications and sources: 'coronary and stroke event rates in the population' (project-oriented) http://www.ktl.fi/publications/monica/demoqa/demoqa.htm#Discussion Deaths - lethal Dosage http://www.ohd.hr.state.or.us/chs/pas/ar-tbl-1.pdf UN Statistics http://unstats.un.org/unsd/demographic/sconcerns/disability/disform.asp?studyid=223 Hearing: http://gri.gallaudet.edu/Demographics/factsheet.html Center for Demographic Study http://cds.duke.edu/publications/search/search_results_ALE.htm HIV/AIDS: http://www.dph.sf.ca.us/HIVPrevPlan/HPPC01FnlRpt/ch3p61~1.pdf RAND/HEALTH: http://www.rand.org/health/archive/sociodemographic/ Center for the Advancement of Health: http://www.hbns.org/newsrelease/after8-8-00.cfm Where related to Healthcare demographics the EHRs may have to incorporate the demographics. Regards! -Thomas Clark Gerard Freriks wrote: Hi, What is the definition, scope, function of the concept: demographic server in the context of OPENEHR? Thomas, Sam, Dipak: HELP! Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 06 Mar 2005, at 19:50, lakewood at copper.net wrote: Hi Gerard, My understanding is that demographic services collect, organize and process the characteristics of a 'population'. Presuming this, then I am a member of a large number of 'populations' regardless of intent. Narrowed to Healthcare the number of 'populations' shrinks but not to one. Given the fact that modern 'populations' are not 'stationary' it appears that there are many of us that can claim or hold membership in multiple Healthcare 'populations' which themselves are subject to new additions, e.g., those genetically sensitive to drugs of a particlular family. Identifying the indiviudal may have to be a separate operation. Identifying whether the individual is a member of a 'population', or 'populations's a subsequent task. A 'demographic server' is likely to be specific and limited in scope to address 'super populations', e.g., persons residing within the boundaries of a specific geographical region, e.g., Africa. A 'network' of such server could provide additional coverage. Since one can apply a variety of rules to the specification of an individual 'population', the 'rules' become significant especially where the 'rules' are chosen to affect results, all Diabetes Patients in the London area. Due to a number of reasons one may not be able to claim that London-area Diabetes Patients are the same as those in other regions, and, of course, that the Healthcare systems are the same or equivalent. Foundational is 'personal identification'. Without it a 'demographic server' is handicapped. Hence a good test for the server is a seriously injured person arriving at a Healthcare facility unable to communicate with no other form of identification. Since there are many other 'issues' and 'factors' important to the design, development and deployment of a 'demographic server' one may have to accept discussions that attempt to integrate topics. They are valuable RD efforts are results-oriented expectations are very likely to increase quickly. Regards! -Thomas Clark BTW: I tried to avoid bringing 'Public Health' into a discussion about 'demographic servers'. That would have been lengthy! - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Authenticity Issues [was: Re: Demographics service]
Hi Sebastian, Correct! The lifetime of a digital signature is some environments is quite short, which is why one gets to change it periodically. However, for permanent records the digital signature of the creator can remain fixed since the record is fixed. You are correct re data transmission, but then to Requestor's and Receiver's digital signatures can be used (again short lifetime). While actively being handled/processed an audit trail is handy. A Historical Electronic Record in a Court of Law is required to emulate that of say a paper Historical Record. If the law states 30 years, then make it 30 or change the law. This is probably not feasible since changing this law that has existed for some time may have to satisfy other requirements that lead to its enactment. -Regards! -Thomas Clark Sebastian Garde wrote: Hi, There is another issue with digital signatures in the context of EHRs: Their value decreases over time and with them the value of digitally signed documents as legal evidence. In other words: securely signed documents don't necessarily provide a secure basis for verifying authenticity for the required time-span of EHRs (30 and more years). This is due to the following reasons: - the employed cryptographic algorithms and the keys lose their security qualification in the course of time. (algorithm may found to be insecure, key length may be too short for increased computer power,..) - It cannot be guaranteed that the directories and documents needed for the verification of the underlying certificates are available for 30 years or more. In addition, the use of digital signing procedures is often insecure and information for the subsequent evaluation of the actual security is missing. To achieve high conclusiveness of digitally signed documents and to realize their integration into practical use, the documents complete life cycle ranging from generation of the document, generation of the signature, presentation, communication to (long-time-)archiving and later use have to be taken into account in a comprehensive way. For a truly long-term-solution for EHRs, a solution must be provided for this problem. If you are interested in details, see http://www.archisig.de/english Further, signed data may - of course - not be changed in order to keep electronic signatures valid. But when data has to be exchanged across networks, or in context of systems migration, such changes are inevitably occuring. Trying to avoid this with the help of new standardized and stable data formats contradicts experiences (although openEHR itself might be a solution for this problem). So, procedures are necessary to convert signed documents and preserve their evidence value (legally secure transformation). See http://www.transidok.de/index-en.html for details. Regards, Sebastian Dr Sebastian Garde Faculty of Informatics and Communication Central Queensland University Rockhampton Qld 4702, Australia s.garde at cqu.edu.au Ph +61 (0)7 4930 6542 Fax +61 (0)7 4930 9729 http://infocom.cqu.edu.au/hi -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of lakewood at copper.net Sent: Monday, 7 March 2005 5:20 AM To: openehr-technical at openehr.org Subject: Re: Authenticity Issues [was: Re: Demographics service] Hi Bish, Periodic and immediate 'Bio' identification would satisfy certain security requirements re authenticity, e.g., official documents (e.g., post surgical release). Your comment re 'thumb imprint', or scan, provides a more secure means of authentication that may be required. Requiring that a 'digital signature' be incorporated within a EHR is a step forward but if all that is required is the presence of a digital signature one can be obtained from multiple sources. As you indicated 'verification of authenticity' is required. Verification, however, can be 'fooled' as well, e.g., where digital signatures are collected in advance into a set of 'secure signatures' the presence of one or more of these signatures within an EHR indicates just that and no more. How is this solved in other fields? 'Bio ID' is one approach, e.g., 'finger and thumb imprint', a digital photo and a voice track, in addition to other digital signatures puts up a much higher wall. I am intrigued by the combination of voice tracks with background syn, e.g., Practitioner and Practitioner + Patient.. An example would be a Hospital Delivery Room (multiple persons) and an automatically generated voice track Properly encrypted the track would be hard to break and/or deny. In other areas similar approaches are available, e.g., encrypted time/date/voice tracks can be integrated into Medical devices and then into EHRs. Side benefits include integration of the time/date into the EHR. A major problem with the photo approach is that some persons become unrecognizable after a 12 hour shift. A problem with ordinary 'digital
Demographics service
Hi Gerard, Wish you were right. Comment: Changes in the legal system can be used to prove the continuing existance of Evolution. Regards! -Thomas Clark Gerard Freriks wrote: Life is simple. Once we physicians know what to ask and why. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 05 Mar 2005, at 13:22, Bigpond wrote: And that's the problem that will keep the technical people in money for years to come. Not only must it be feasible it will be demanded by judges and courts if the EHR is to ever be truly adopted. Even now we have rules that all e-mails where a decision is made must be printed out! The paperless world has never been to court. It is feasible of course but complex. Flags are set when pages are viewed, there are intricate audit trails (terabytes). The fact that no one is doing it yet is that the litigation costs haven't risen high enough to balance the need to do it. Once a few specialists are sued for activities that can not be supported by the record and they known they were innocent then we will see some very interesting changes, either a reappearance of paper records (personal) or a new paradigm of image capture. IMHO of course. David - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Governance and Legal Demographics services?
Hi Bob, An 'international awareness' must be developed in advance and evolved continuously. The EHR community is part of the bedrock of future Healthcare policies, procedures and practices. It must be based on facts and incorporate all available information. The Legal community requires facts in the form of admissible evidence and information in the form of testimony, inferences, deductions and interpretation. It renders judgments in accordance with established law and in some cases remedies for parties before the Court. In the presence of this certainty it makes 'big' mistakes and sometimes loses its way. As an example, Forensic Science has upset many judgments and caused the restructuring of many policies, procedures and practices. A complaint often heard is that Forensic Science, and genetics in particular, has in a short time caused more change than years of reasoned thought within the Community. With jurisdictions releasing prisoners from Death Row for crimes they did not commit to ineffective FDA-approved drugs, with fatal side effects, for specific conditions being withdrawn change is 'in the air'. A recent humorous complaint from the bench comments on juries demanding to have Forensic data and analysis prior to deliberations. It might be that 'fact-based outcome-oriented' Healthcare is becoming popular. ... tickle the need for some common upper ontology for the domains of governance which includes the process by which the legal environments are created and maintained in various countries ... the question of governance in standards bodies ... ... This is not an easy task due to the supremacy of the Administrative, Legislative and Judicial branches of governments plus the diversity and number of governments. The following is a simple example of how technology, science and legal processes can work in one jurisdiction. BRAIN FINGERPRINTING *IN THE SUPREME COURT OF IOWA** *No. 122 / 01-0653 Filed February 26, 2003 TERRY J. HARRINGTON, Appellant vs. STATE OF IOWA, Apellee http://www.judicial.state.ia.us/supreme/opinions/20030226/01-0653.asp ... Upon our review of the record and the arguments of the parties, we conclude (1) Harrington?s appeal is timely; (2) this action is not time barred; (3) Harrington is entitled to relief on the basis of a due process violation; and (4) Harrington?s motion for conditional remand is moot. Accordingly, we reverse the district court judgment, and remand for entry of an order vacating Harrington?s conviction and sentence, and granting him a new trial. We deny Harrington?s motion for remand on the basis of mootness ... Brain Fingerprinting Laboratories http://www.brainwavescience.com/Ruled%20Admissable.php ... In order to be admissible under the prevailing Daubert standard, the science utilized in a technology is evaluated based on the following four criteria: (The Iowa courts are not bound by the Daubert criteria used in the federal courts, but they do use them when determining the admissibility of novel scientific evidence.) 1. Has the science been tested? 2. Has the science been peer reviewed and published? 3. Is the science accurate? 4. Is the science well accepted in the scientific community? The judge ruled that Brain Fingerprinting testing met all four of the legal requirements for being admitted as valid scientific evidence. The ruling stated: The test is based on a 'P300 effect.'? The P300 effect has been studied by psycho-physiologists?The P300 effect has been recognized for nearly twenty years. The P300 effect has been subject to testing and peer review in the scientific community. The consensus in the community of psycho-physiologists is that the P300 effect is valid ... This example identifies one approach to modifying existing legal processes. There are close to 200 countries in the UN and each maintains significant diversity. An approach taken within the US is based upon a set of 'Model Codes' (see the Legal Information Institute at: http://www.law.cornell.edu/statutes.html ). A recommended approach to addressing Healthcare under the Law, Legal requirements, handling and interpretations of EHRs, and related Legal processes is to: 1)Expand the Model Codes to cover EHRs 2)Include appropriate provisions with the EHR standards to build-in compatibility with the Model Codes 3)Include processes to handle change. Separate Legislatures and Judicial systems reference the Model Codes now, i.e., When in doubt look at what others have built. Since Judicial systems interpret the laws that the Legislatures have enacted the opportunity to impact the system to achieve goals for the common good in the shortest time lie with the Model Codes. At least this approach can be considered foundational. Regards! -Thomas Clark Bob Smith wrote: Hello David and Thomas, You said: You speak much sense!! The Legal environment in particular requires reconstruction. When you
Demographics service
Hi David, Significant problem! However, software configuration management has solved this before. In the Legal or secure OS environments the contributions of individuals are in fact part of the record even through the 'end-game' is an update that merges the contributions of all, e.g., a composite record. It is critical that 'information' is not lost nor corrupted. Efforts to 'crunch' multiple records into a satisfactory record usually fail this requirement at some point. A reasonable objective is to permit multiple Practitioners to enter information simultaneously, maintain original context and content, build a composite record that is compatible with the target record-handling system, and support 100% re-assembly of all sources of information. A 'build-and-submit' or 'interactive-entry' architecture can yield multiple 'composite' records that may also be linked by one or more events, e.g., surgery and lab work. It may also be necessary to declare a higher-order event (in a record) to which subsequent events can be linked (extra-record, meaning the event can transcend a collection of records, e.g., multiple contacts-same cause). Information organization is a virtue; lack of it may well impact information retrieval. Try coordinating the activities and results of 20+ Software Engineers working on a release. Things happen in parallel. The Legal environment in particular requires reconstruction. Regards! -Thomas Clark Bigpond wrote: The EHR is rather a unique document and a layered approach is necessary as old data must never be altered - may not necessarily be accessible but must never be altered. Errors can be corrected but the error must remain totally accessible in the manner it was presented to the clinician when it was relied upon - eg clinical results, medications. The concept of layering new information on old is important. There does have to be lock outs or transaction controls when new data is being entered in but there is no need for old material (old may be seconds of course)to be locked out cause it can't or shouldn't be changed. If two doctors are entering elements of say a discharge summary then one cannot edit while another is adding - it needs a message indicating someone else is working on the current document and wait. It is more complex than that but the basic principle applies old data never changes even old addresses must stay. Legally it is important to be able to reproduce exactly the circumstances that the computer presented to the clinician at any point in time for inquests, litigation etc. We are dealing with these issues today with our CIS and it is a challenge. David Evans Brisbane Australia - 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
Demographics service
Hi All, Demographics (characteristics of a population) is one element of a larger more complex problem which may be labeled 'Patient Categories and Classifications', or simply 'Patient Boxes'. Conceptualizing the postal annex analogy, the interesting part comes when the available information is processed and placed into a designated box. All those Patients living at some time within 25 miles of a known toxic waste dump (important because the Cancer Death Rate spikes in this area) can be placed in an appropriately labeled box. All those former military personnel who served in the first gulf war go in another box. All those who received surgical care at a hospital identified with MRSA into another box, or a box just for that hospital. How about people who were employed in areas that later were identified as being life-shortening. Pick a job site or a residential location (data supplied upon request). Or perhaps current agriculture workers exposed to chemicals. BTW: Try obtaining a complete medical record for a Patient from their branch of the military. A 'Demographics Service component' is an interesting project but my hunch is that my HMO has not signed onto it. A 'record' transmitted to a local or remote Practitioner should comply with a set of 'necessary' and 'sufficient' tests so that the recipient does not have to dig though unrelated and inappropriate data, and the Patient is permitted to open the Kimono far enough to obtain needed services. The 'all-or-nothing' approach works where all data is relevant and where little data is available. An 80 year old Patient may have suffient data to derail the practitioner and deflect focus from currently needed treatment. There are 'levels' of records and within levels there may be varying needs for different Practitioners. What is 'necessary' and 'sufficient' for each Practitioner? We may be talking about multiple records, e.g., my Internal Medicine Practitioner wanted one set of information, the Surgeon wanted another. Regards! -Thomas Clark Gavin Brelstaff wrote: Yin Su Lim wrote: This discussion document is produced by UCL (CHIME) to highlight issues that have arisen when designing a Demographics Service component. This service component will need to conform to the openEHR demographics package and be able to support the requirements of live demonstrator sites in north London. Any feedback and comments are welcome. This is a _tantalising_ question - that I've ruminated on for some time. First it is not clear why Demographics should be separated out like this from the entire record - it just introduces potential inconsistency due to replication issues or worse mis-identification of a patient. From an evidence-based perspective, it might be best to send and receive a sealed network packet of as much as the patient record as bandwidth permits: That could mean the entire text data - leaving larger payloads such as exam-data/imaging/traces etc to be requested on demand. The receiving medic would then be able to make any decisions on the basis of the best available evidence at that particular time - using the traditional document metaphor. Of course the onus is on client-side to make all evidential aspect of that document visible during any decision making [no mean task]. But surely in an active clinical community the entire patient record cannot be locked out of use while one participant is working on it. Traditional database/directory locking works against rather than for the collaborative process IMHO. Sure participants need to be aware of each others concurrent activity on the same record but they must be given both (1) the means to communicate with each other to decide if either should go first (2) some convenient means to resolve conflicts that would otherwise arise in the patient record due to their individual asynchronous submissions. This is _not_ rollback but is instead a kind of roll-forward and again the emphasis would be on a smart client (able to coherently explain conflicts and choices to resolve them at the point of resubmission) - rather than smart server. The flavor should be that of a Wiki while the overall philosophy should be that of evidential audit/logging: who saw what and what they did when they saw it - for medico-legal purposes. Here the entire patient record would be archetyped as a single document in which Demographics was a self-contained subsection. If you really needed to you could just replicate that already archetype sub-section on a Demographics Server - but that should be a read-only copy - the mastercopy being of course that in the full record. Something like a versioning XML server (xmlDB,Xindice,OracleXML DB) might be the way to go. Just my 2 penceworth - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Fw: His best hope is early parole
Hi All, This is an interesting case that prompts questions regarding EHRs surrounding death of a Patient. It also serves to illustrate how goverment can alter what should be a rather clear, concise medical event that must at some time and in some form be entered into the EHRs. The issues here involve 'statutory death', 'State Agency death', 'Judicial death' and potentially 'extra-judicial' and 'extra-statutory death'. One also has the problem of accumulating additional EHRs beyond some 'death state' to comply with a variety of other policies, procedures, contracts, statutes and 'State Agency requirements'. I was asked to comment on this. My response is private. For purposes of this list my position is that some provisions should be made to handle these weird cases. There is as of this date no solution to this case. Regards! -Thomas Clark = *How dead can you get?* mailto:metro at modbee.com?subject=How%20dead%20can%20you%20get? /Last Updated: February 3, 2005, 04:35:23 AM PST/ Just what does it take to be declared dead in California? We thought a person declared brain dead was legally and physiologically dead. Brain dead is technically dead. By that standard, Wasco State Prison inmate Daniel Provencio surely qualifies as dead. Why then is he being treated as if he is alive ? even a threat to escape? Provencio has been in a Bakersfield hospital since he was shot in the head with a foam bullet by a prison guard. Members of Provencio's family told the Bakersfield Californian that doctors declared him clinically dead Jan.20 after tests found no brain activity. California law requires two such examinations by two doctors, and Provencio passed both tests. Yet Provencio's mother said Wasco Warden P.L. Vazquez expects Provencio to serve out his sentence from a hospital bed. Provencio is on a mechanical ventilator and a feeding tube. And he's shackled to the bed by both ankles. He's being guarded by prison guards around the clock at a cost of $1,056 a day. You think anyone has noticed this guy is dead? No, we are not making this up. The Department of Corrections is considering a compromise to allow the dead man to be released on early parole. This is beyond preposterous. It began Jan.16 with an alcohol-fueled brawl between two inmates, according to KGET-TV. Provencio apparently tried to prevent guards from intervening. Inmates, said KGET, brewed fruit and other foods into an intoxicant. A guard shot Provencio in the head, though foam bullets are meant for legs and arms. Booze and brawls? Shooting inmates in the head? Shackling and guarding a dead inmate? What is going on at Wasco? The Department of Corrections needs to get control of this institution. And it needs to end the macabre saga of Daniel Provencio, deceased. http://us.rd.yahoo.com/evt=30648/*http://movies.yahoo.com/movies/feature/jibjabinaugural.html - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Age
Hi Karsten, The *definition* of a lightyear is *fixed*, i.e., the 'distance light travels in a year', and not directly measurable, e.g., tag a photon and measure its progress thoughout one year. The problem is that the *distance* each photon travels in a year may not be the same. You are correct re 'speed of light'. The *definition* of a lightyear was created and agreed upon to facilitate measurement. The 'trap' is trying to turn this 'convenience' into a physical constant.. Regards! -Thomas Clark Karsten Hilbert wrote: And not constant either, at that. Bugger. http://www.everything2.com/index.pl?node_id=29831lastnode_id=11221 I stand corrected as I was being imprecise. I was referring to a) the speed of light is depending an material, and b) the speed of light seems to not be constant over time even in a given material. However, the *definition* of a lightyear certainly *is* constant so you are correct. Karsten - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Age
Hi All, Light has successfully been slowed and stopped, i.e., encapsulated in a material) for a significant period of time. Lasers are used to send it on its way. Destroyed a niche in my memory banks when it was announced. Do not see a substitute for the 'old-light', aka the 'new-light'. Regards! -Thomas Clark David Guest wrote: Karsten Hilbert wrote: Age=: Time since an reference event took place and is expressed as: lightyears, years, months, days, minutes, seconds (and parts thereof) Lightyears is a measure of distance, not time. In fact it is *the* measurement of distance. And not constant either, at that. Bugger. http://www.everything2.com/index.pl?node_id=29831lastnode_id=11221 David - 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
Age
Hi All, One should include mental age as well. EHRs should not presume a Patient's mental capabilities closely track their physical age. This would be a recipe for disaaster under its own terms since 'young' physical age and 'senior' physical age represent gray areas regarding mental competence, etc. These gray areas are recognized in most legal systems. Regards! -Thomas Clark Gerard Freriks wrote: Hi, There are two concepts with the name 'age'. Age as a number. Age=56 Age as a process. baby, youth, post conception, gestational, As with many concepts we have two different concepts with the same name in daily life. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 26 Jan 2005, at 17:58, Sam Heard wrote: Tom and others The idea of age as a complex notion - post-conception, gestational (LMP) ie it can involve pre-birth periods - even well into life. This apperas to be important for decision support. I wonder if we need to model this as an archetype for demographics - but it needs to be in the EHR - age crops up in lots of evaluations (problem, family history) so we might need to have it as a formal TYPE! That is - we can use it consistently in various settings. I would argue that gender is of the same nature - with social gender, physical gender and genetic gender as the key concepts. No doubt there are others but these two are worth thinking about carefully. Sam - 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
Modelling Episodes in openEHR
Elkin, Peter L., M.D. wrote: Dear Thomas, I favor the episode being a single point of audit (regardless of the timeframes at which an episode starts and stops). So all encounters and non-encounter events would indeed be part of an episode of care. This brings continuity to the notion of an episode of care. Episodes allow the summarization of the care which has occurred during the episode and there should be a provision in the OpenEHR architecture to affix this information to the Episode for further reference. Warm regards, Peter Peter L. Elkin, MD Professor of Medicine Director, Laboratory of Biomedical Informatics Department of Internal Medicine Mayo Clinic, College of Medicine Mayo Clinic, Rochester (507) 284-1551 Fax: (507) 284-5370 *From:* owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] *On Behalf Of *Thomas Beale *Sent:* Thursday, December 02, 2004 5:36 AM *To:* Openehr-Technical *Subject:* Modelling Episodes in openEHR Dear all, the definitional debate about what an episode will of course continue long into the future, and we will not solve it here - indeed there will never be a single definition. But we can in the abstract identify a couple of solid concepts: - episode of care by a care delivery enterprise / health care provider - provider-centric - episode of course of illness / situation - patient-centric; finishes at death, return to health, or stabilisation (chronic problems) A long-term effort into these types of concepts is the CEN TC/251 Continuty of Care work (prEN13940), led by Fran?ois Mennerat, who is on this list. The current draft of this standard is hosted on the openEHR website at http://www.openEHR.org/downloads/prEN13940_2004E_041107.zip (600k zip file of 2Mb Word document), and is worth a read. Notable definitions from this work include: - *period of care* (was period of service): situation during which one or more /contacts /occur between a /subject of care/ and one or several /health care professionals/, in the framework of a /care mandate/ held by a /health care pro/vider - *episode of care*: situation during which /health care activities/ are performed by one /health care provider/ to address one /health issue /- *cumulative episode of car*e: situation encompassing the occurrence of all /health care activities// /related to only one /health issue thread /In the above, period of care appears to be the same as what I have informally called episode of care above; while cumulative episode of care appears to correspond to the second informal definition. People may like to use the prEN13940 definitions. In any case, the practical problem we have is to provide a way to model episodes (however defined) for users of openEHR, while retaining data and service interface interoperability. To model patient-centric clinical episodes (of illness, pregnancy etc) we believe that the current approach of using LINK objects to connect Entries, Compositions to be the best one. An animated slide presentation done by Dipak Kalra, using EN13940 terminology shows how this works in a particular example - see http://www.openEHR.org/downloads/CONTSYS-EHRcom.ppt (143k powerpoint). The other kind of eposide - period of care/service - we believe can be done using Folders. After some discussions recently with Dipak Kalra, we would suggest the following two ways of doing it in openEHR. 1. One episode = an openEHR Folder. Remember that a Folder in openEHR is a reference list, like a little index to particular groups of Compositions. A given Composition can appear in more than one Folder. The Folder can be named as being an episode (Folders inherit name from LOCATABLE) and every relevant Composition deemed by the provider to be in that episode can go in. If a Composition wants to be included in more than one episode (if you are the kind of provider that uses the 2nd EN13940 definition above), or in sub-episodes, then it can. 2. The Folder when committed to the EHR as part of a Contribution which causes the EHR Directory to be updated (remember all Folders in a given EHR are part of the Directory structure), the date of committal is recorded, as for any openEHR data commit. 3. A special Composition is defined in an archetype(s) as being for the purpose of episode administrative information, and contains one or more Evaluation type Entries, which provide whatever administrative details are required for episodes in your establishment. 4. When the episode is deemed to have started - which may be clinically before the creation of the Folder on the EHR system, this special Composition is created/updated to indicate that
RFC CR-000101 - request for comments - deadline 23 july 2004
Hi All, 'hierarchical', at a minimum, shouldn't be used to describe physical/chemical processes, e.g., flight dynamics and control of the 747 I just rode. Space has to be included in this; OK throw in the Universe we are in and all the others we do not know about. The brain, as a chemical engine, and the storage of information in it, as a first-order approximation, is parallel in nature; otherwise you probablably would not be able to perform activities and visualize simultaneously. 'hierarchical', and its uses, can be pinned human attempts to inject order. e.g., heirarchical classifications. Some attempts at controlling parallelisms, e.g., symmetric multiprocessor systems, are controlled to the point where they cannot be labeled are parallel systems. Parallel systems do exist, e.g., independent, communicating systems that coordinate processing to achieve specific goals, objectives and performance, e.g., space missions (constraint-based control; close control impossible). 'concurrently executing processes' can be considered parallel systems. Of course goals, objectives and performance impose operational constraints, e.g., constraint-based system. Examples come from high performance data processing, control applications (e.g., nuclear reactors), and manufacturing. 'hierarchical' control systems require that control be exercised continuously, on a regular schedule, or when events require it. Continuous systems under my control would not permit 'sleep' time; regular systems would mean I would have to adapt to the schedule, and event-driven systems would mean I would be awoken frequently. These type systems are limited in number throughout the world populations. It is true that the sun has imposed a hierarchical ordering to daily activities for farmers but it is also true that the sun is close to the model of a 'parallel' system than a 'hierarchical' system. In your own words: 'as the human mind perceives it' hierarchical implies human ordering, e.g., a model reduced to a chalk talk session. 'hierchical' applied to nature has some serious obstacles to overcome, e.g., Quantum Mechanics. Regards! -Thomas Clark Karsten Hilbert wrote: - every concept, everything in existence (as the human mind perceives it) is hierarchical, to microcosm as well as towards macrocosm Including the brain itself ? Karsten - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Data Security was: Basic EHR functionality
Hi Tim, Security policies are included as are implementation approaches. Regards! -Thomas Clark Tim Churches wrote: On Wed, 2004-03-10 at 19:10, Thomas Clark wrote: Hi Tim, Might want to add: Computer Security Basics http://www.oreilly.de/catalog/csb/toc.html IEEE; Compartmented Mode Workstation: Prototype Highlights http://csdl.computer.org/comp/trans/ts/1990/06/e0608abs.htm CMU; Trusted Operating Systems http://www.sei.cmu.edu/str/descriptions/trusted_body.html Operating System Security http://www.cs.ucd.ie/staff/tahar/home/courses/4thyear/chapter4/ppframe.htm From Security protocols to System Security http://www.hpl.hp.com/techreports/2003/HPL-2003-147.html Trusted Computing Platforms http://www.hpl.hp.com/techreports/2002/HPL-2002-221.html ASPECT - a tool for checking protocol security http://www.hpl.hp.com/techreports/2002/HPL-2002-246.html Resilient Infrastructure for Network Security http://www.hpl.hp.com/techreports/2002/HPL-2002-273.html Security Infrastructure for A Web Service Based Resource Management System http://www.hpl.hp.com/techreports/2002/HPL-2002-297.html Trusted Solaris Developers Guide http://docs.sun.com/db/doc/805-8060?q=compartmented+mode+workstation Trusted Network Environment http://www.tinfosol.com/lab/lab.html RFC 1825 - Security Architecture for the Internet Protocol http://www.faqs.org/rfcs/rfc1825.html RFC 1827 - IP Encapsulating Security Payload (ESP) http://www.faqs.org/rfcs/rfc1827.html Secure Trusted Operating System (STOS) Consortium http://www.stosdarwin.org/ The Blue Book http://secinf.net/info/rainbow/tg29.txt UK Security Citations Bibliography http://chacs.nrl.navy.mil/xtp1/uksecbib.html All of those deal with security implementation issues i.e. how you achieve certain objectives. The BMA security policy sets out what those objectives ought to be. Defining the security objectives, which in turn ought be be informed by specific threat models, needs to be done before you can consider which security technologies are appropriate. But yes, most of those are appropriate. Tim c Regards! -Thomas Clark Tim Churches wrote: On Tue, 2004-03-09 at 23:20, Thompson, Ken wrote: 2) A mechanism on the patient record itself that displays a list of all users that have accessed the record (with date and time). This will probably be made available to the patient at some point, so they will actually provide a critical part of the checks and balances in the system. This is similar to the mechanisms envisaged under the Consent and notification secion of the now-famous BMA Security Policy, developed by Ross Anderson - see http://www.cl.cam.ac.uk/users/rja14/policy11/policy11.html This is still the gold standard for EHR security policies, IMHO, yet most people I have met who are involved in EHR work and who know of it (curiously many seem ignorant of it) tend to dismiss it, not because the policies are unsound (although they do need minor tweaking here and there), but because implementing them is very difficult in practice - particularly the multilateral as opposed to multilevel access control policy. In fact you need both, but of the two, the former is more important. In other words, role-based access control, where the roles are specific to each patient, as well as to each health professional. - 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
Data Security was: Basic EHR functionality
Hi Tim, One I failed to include is: RFC 3586 - IP Security Policy (IPSP) Requirements http://www.faqs.org/rfcs/rfc3586.html Some of the included links support searches, e.g., The CMU link returned over 2200 hits on a search for 'security policy'. Lots of policy-related information that is appropriate. Regards! -Thomas Clark Tim Churches wrote: On Wed, 2004-03-10 at 19:10, Thomas Clark wrote: Hi Tim, Might want to add: Computer Security Basics http://www.oreilly.de/catalog/csb/toc.html IEEE; Compartmented Mode Workstation: Prototype Highlights http://csdl.computer.org/comp/trans/ts/1990/06/e0608abs.htm CMU; Trusted Operating Systems http://www.sei.cmu.edu/str/descriptions/trusted_body.html Operating System Security http://www.cs.ucd.ie/staff/tahar/home/courses/4thyear/chapter4/ppframe.htm From Security protocols to System Security http://www.hpl.hp.com/techreports/2003/HPL-2003-147.html Trusted Computing Platforms http://www.hpl.hp.com/techreports/2002/HPL-2002-221.html ASPECT - a tool for checking protocol security http://www.hpl.hp.com/techreports/2002/HPL-2002-246.html Resilient Infrastructure for Network Security http://www.hpl.hp.com/techreports/2002/HPL-2002-273.html Security Infrastructure for A Web Service Based Resource Management System http://www.hpl.hp.com/techreports/2002/HPL-2002-297.html Trusted Solaris Developers Guide http://docs.sun.com/db/doc/805-8060?q=compartmented+mode+workstation Trusted Network Environment http://www.tinfosol.com/lab/lab.html RFC 1825 - Security Architecture for the Internet Protocol http://www.faqs.org/rfcs/rfc1825.html RFC 1827 - IP Encapsulating Security Payload (ESP) http://www.faqs.org/rfcs/rfc1827.html Secure Trusted Operating System (STOS) Consortium http://www.stosdarwin.org/ The Blue Book http://secinf.net/info/rainbow/tg29.txt UK Security Citations Bibliography http://chacs.nrl.navy.mil/xtp1/uksecbib.html All of those deal with security implementation issues i.e. how you achieve certain objectives. The BMA security policy sets out what those objectives ought to be. Defining the security objectives, which in turn ought be be informed by specific threat models, needs to be done before you can consider which security technologies are appropriate. But yes, most of those are appropriate. Tim c Regards! -Thomas Clark Tim Churches wrote: On Tue, 2004-03-09 at 23:20, Thompson, Ken wrote: 2) A mechanism on the patient record itself that displays a list of all users that have accessed the record (with date and time). This will probably be made available to the patient at some point, so they will actually provide a critical part of the checks and balances in the system. This is similar to the mechanisms envisaged under the Consent and notification secion of the now-famous BMA Security Policy, developed by Ross Anderson - see http://www.cl.cam.ac.uk/users/rja14/policy11/policy11.html This is still the gold standard for EHR security policies, IMHO, yet most people I have met who are involved in EHR work and who know of it (curiously many seem ignorant of it) tend to dismiss it, not because the policies are unsound (although they do need minor tweaking here and there), but because implementing them is very difficult in practice - particularly the multilateral as opposed to multilevel access control policy. In fact you need both, but of the two, the former is more important. In other words, role-based access control, where the roles are specific to each patient, as well as to each health professional. - 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
Antw: Re: Antw: Re: Open Source EHR at the Americal Academy of Family Physici...
Hi William, YES! From the IT viewpoint there will be limited responses on the 'health oriented search engines' that would be of significance to the operational aspects of a global distributed co-operative information system. Should I require detailed information on the proper content of an EHR or a medical/health condition I would include a PubMed search. As you imply 'research' belongs in a /'health orinted'/PubMed search. When you cross the border into topics involving deployment try leaving 'health oriented search engines' behind and climb into the IT world. At some point research should turn into reality. Prior to reaching that 'border' research has to adopt. Tried the same exercise using PubMed. Recognize from an IT viewpoint the terms often do not match, e.g., performance, scalability, sustainability (e.g., web services). A SUMMARY is included at the end of the following data. PUBMED SEARCH -- PERFORMANCE; search: SNOMED performance (8 hits; first 3) *1)The CardioOP-Data Clas (CDC). Development and application of a thesaurus for content management and multi-user teleteaching in cardiac surgery.* *Friedl R, Klas W, Westermann U, Rose T, Tremper J, Stracke S, Godje O, Hannekum A, Preisack MB.* Dept. of Heart Surgery, University of Ulm, Germany. reinhard.friedl at medizin.uni-ulm.de *2)Evaluation of a method that supports pathology report coding.* *Hasman A, de Bruijn LM, Arends JW.* Department of Medical Informatics, University of Maastricht, The Netherlands. hasman at mi.unimaas.nl *3)Integrated patient data for optimal patient management: the value of laboratory data in quality improvement.* *Emons MF.* Protocare Sciences, 2400 Broadway, Suite 100, Santa Monica, CA 90404, USA. SCALABILITY; search: SNOMED scalability (1 hit): *Scalable methodologies for distributed development of logic-based convergent medical terminology.* *Campbell KE, Cohn SP, Chute CG, Shortliffe EH, Rennels G.* Stanford University School of Medicine, CA, USA. campbell at informatics.com As the size and complexity of medical terminologies increase, terminology modelers are increasingly hampered by lack of tools and methods to manage the development process. This paper presents our use and ongoing evaluation of a description-logic classifier to support cognitive scalability of the underlying terminology and our enhancements to that classifier to support concurrent development utilizing semantics-based concurrency control methods. Our enhancements, collectively referred to as the Galapagos, consist of several applications that take locally-developed terminology enhancements from multiple sites, identify conflicting design decisions, support the modelers' reconciliation of the conflicting designs, and efficiently disseminate updates tailored for locally enhanced terminologies. We have tested our ideas through concurrent evolutionary enhancement of SNOMED International at three Kaiser Permanente regions and the Mayo Clinic. We have found that the underlying environment has met our design objectives, and supports semantic-based concurrency control, and identification and resolution of conflicting design decisions. PMID: 9865041 [PubMed - indexed for MEDLINE] EFFECTIVENESS; search: SNOMED effectiveness (1 hit): *Integrated patient data for optimal patient management: the value of laboratory data in quality improvement.* *Emons MF.* Protocare Sciences, 2400 Broadway, Suite 100, Santa Monica, CA 90404, USA. (a repeat) RELIABILITY; search: SNOMED reliability (2 hits): *1)Evaluation of a method that supports pathology report coding.* *Hasman A, de Bruijn LM, Arends JW.* Department of Medical Informatics, University of Maastricht, The Netherlands. hasman at mi.unimaas.nl *2)[Medical data in pathology--evaluation of a large collection. (530,000 diagnoses coded in SNOMED II)]* [Article in French] *Baumann RP.* Institut neuchatelois d'anatomie pathologique, Neuchatel RELIABILITY; search: SNOMED reliability (5 hits): *1)Using semantic distance for the efficient coding of medical concepts.* *Bousquet C, Jaulent MC, Chatellier G, Degoulet P.* Medical Informatics Department, Broussais Hospital, Paris, France * 2)Analysis of 24,444 surgical specimens accessioned over 55 years in an ophthalmic pathology laboratory.* *Spraul CW, Grossniklaus HE* *3)Coding medical information: classification versus nomenclature and implications to the Israeli medical system.* *Vardy DA, Gill RP, Israeli A.* Soroka University Medical Center, Beer-Sheva, Israel *4)A Russian version of SNOMED-International.* *Emelin IV, Levenson R, Perov YL, Rykov VV* *5)Classification of perinatal deaths.* *Wigglesworth JS.* Histopathology Department Hammersmith Hospital, Royal Postgraduate Medical School, London COMPLAINTS; search: SNOMED complaint (no hits): ERRORS; search: SNOMED error (6 hits): *1)A randomized controlled trial of the accuracy of clinical record retrieval using
Antw: Re: Open Source EHR at the Americal Academy of Family Physicians ...
Hi Tim, Pieces of the 33 hits are included below: -Sarcomatoid carcinoma of the cervix -An evaluation of the usefulness of two terminology models for integrating nursing diagnosis concepts into SNOMED Clinical Terms -Improved coding of the primary reason for visit to the emergency department using SNOMED -Which coding system for therapeutic information in evidence-based medicine -Automating SNOMED coding using medical language understanding: a feasibility study -An evaluation of the utility of the CEN categorical structure for nursing diagnoses as a terminology model for integrating nursing diagnosis concepts into SNOMED -Semantic features of an enterprise interface terminology for SNOMED RT -Evaluation of a method that supports pathology report coding -Evaluation of SNOMED3.5 in representing concepts in chest radiology reports: integration of a SNOMED mapper with a radiology reporting workstation -Representation by standard terminologies of health status concepts contained in two health status assessment instruments used in rheumatic disease management -An evaluation of ICNP intervention axes as terminology model components -[Medical data in pathology--evaluation of a large collection. (530,000 diagnoses coded in SNOMED II)] -Scalable methodologies for distributed development of logic-based convergent medical terminology -The role of peer review in internal quality assurance in cytopathology -Evaluation of a lexically assign, logically refine strategy for semi-automated integration of overlapping terminologies -Phase II evaluation of clinical coding schemes: completeness, taxonomy, mapping, definitions, and clarity. CPRI Work Group on Codes and Structures -The surgical pathologist in a client/server computer network: work support, quality assurance, and the graphical user interface -Comparison of the reproducibility of the WHO classifications of 1975 and 1994 of endometrial hyperplasia -Planned NLM/AHCPR large-scale vocabulary test: using UMLS technology to determine the extent to which controlled vocabularies cover terminology needed for health care and public health -Mass screening for cervical cancer in Norway: evaluation of the pilot project -The LBI-method for automated indexing of diagnoses by using SNOMED. Part 2. Evaluation -Representing HIV clinical terminology with SNOMED -The LBI-method for automated indexing of diagnoses by using SNOMED. Part 1. Design and realization -A comparison of four schemes for codification of problem lists -Can SNOMED International represent patients' perceptions of health-related problems for the computer-based patient record? -Extraction of SNOMED concepts from medical record texts -Terms used by nurses to describe patient problems: can SNOMED III represent nursing concepts in the patient record? -[Descriptive epidemiology from autopsies at the Ospedale Maggiore di Milano from 1986 to 1987] -[Development of a findings and results data system for forensic medicine autopsy cases] -Medical linguistics: automated indexing into SNOMED -Evaluation of the CAP microcomputer-based SNOMED encoding system -[A new microglossary for biopsy pathology] None of these hits can be related in any significant way to to the implementation and deployment of a system with SNOMED functionality, i.e., based wholly on SNOMED or integrating it as a plug-in or an integral function. My original posting included some major review topics typically encountered in a software product design (the focus immaterial). There is an old saying where I come from: Quiting playing with the design and produce something before the competition does. Design, develop, deploy sustain and upgrade later. The motivation to charge for SNOMED may well prompt competition to action . Right now, in my opinion, SNOMED needs relevant Google/developer entries. Additional comments in your text. Thanks! -Thomas Clark Tim Churches wrote: On Fri, 2003-09-26 at 04:04, lakewood at copper.net wrote: 3)Rigorous testing, including scalability, of SNOMED seems to be sparse: PERFORMANCE; Google search: SNOMED performance | http://etbsun2.nlm.nih.gov:8000/publis-ob-offi/pdf/2000-tal-ob-Ft.pdf (1 hit) SCALABILITY: Google search: SNOMED scalability | (no hits) EFFECTIVENESS: Google search: SNOMED effectiveness | (no hits) RELIABILITY: Google search: SNOMED reliability | (no hits) AVAILABILITY: Google search: SNOMED availability | http://quickstart.clari.net/qs_se/webnews/wed/bx/Bga-mckesson-info-sols.Rn1s_Dl9.html (1 hit); DIFFERENT KIND OF 'availability', i.e., availabile for use COMPLAINTS: Google search: SNOMED complaint | (no hits) ERRORS: Google search: SNOMED error | (no hits) SUSTAINABILITY: Google search: SNOMED sustain | (no hits) OK! I give up! SNOMED, it appears, has never been subjected to any kind of analysis. It appears to be in the same category as home repair contractors who provide an on-the-spot 'tail-light' warranty. Only a tiny percentage of the
Requested Proposal to the US Uniform State Law Committee
Hi All, Submitted a request to the Uniform Law Commissioners (http://www.nccusl.org/nccusl/DesktopDefault.aspx) to consider a project for ELECTRONIC HEALTHCARE RECORDS. The next meeting will be in January, 2004. If a project is approved the Commissioners will address a Uniform Code for the 50 states in the US for ELECTRONIC HEALTHCARE RECORDS. Such a project would consider the legal relationship with the federal government and the current state of HIPAA. -Thomas Clark - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Anyone in Portland, Oregon?
Hi, Is anyone from Portland, Oregon on this list? -Thomas Clark - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
What HIPAA means to you - a brief description
Hi Chris, Privacy is a major 'topic'. Others include 'security' onsite, in transmission, retention, archiving, copies, modifications and signatures. Some jurisdictions have well-developed laws (and model code as well) covering electronic records in eCommerce (includes the US and Clinton's eSign bill). It is easy to see the parallel between the EHRs and the ERs in eCommerce, e.g., an ER is an ER is an ER regardless. Spring 2003 HIPAA summary: http://www.dicksteinshapiro.com/seeninprint/publications/pdf/HLBSpring03.pdf Reviewing the 'Security Rule' is interesting. Swiss Cheese! 'de-identified' information as an exclusion should be a joke. Compare with the model code for eCommerce. Use of words like 'may' in legislation translates into a 'wish' that the tooth fairy is coming tonight. Electronic eCommerce has moved ahead in many areas with contracting being a significant area: http://library.lp.findlaw.com/articles/file/00053/002195/title/subject/topic/computers%20%20technology%20law_digital%20signatures/filename/computerstechnologylaw_1_72 Electronic eCommerce already covers a major part of the globe. EHR systems need to get the 'regional' environment working before the national and global. But coming up with something unique to OpenEHR will likely doom the project. SUGGESTION: What is good for electronic eEcommerce can be modified to suit EHRs. Having said that I am back to the model codes. HIPAA just doesn't hack it. What does? A model code is needed for the world. ONE REASON: HIPAA places emphasis on the responsibility of Providers for security. That doesn't compute in a single-Provider office. Why? The Patient-single-Provider environment has more security leaks that one can easily describe. Add a Payer and it becomes impossible. Put it in front of a court and you are asking for major complications. COMMENT: No more HIPAA-type legislative acts. Do the global model code somebody; do it once. If a set of global Healthcare applications are to be built to service EHRs it cannot be dependent upon daily legislative changes and court rulings (at all levels). This will not work without the ability to excise one or more areas, e.g., regions, to avoid complications, e.g., jurisdictional-oriented changes. Globally Patients, Providers and Payers may buy into this in a big way. It is their governments, judicial systems and administratin of justice organizations that are complications here. They need to buy into a model code for global EHRs. COMMENT: Retrieve some laws still on the books in various states in the US. They constitute a legal joke. Some codes give mules the right-of-way requiring motor vehicles to stop at the side of the road. Others require a chain to be drawn across the road at sundown and on weekends. Others prohibit many things that are taken for granted by the current populace. Why haven't they been removed? Because things change constantly and one never knows when it might be a good idea to run mules down main street. A model code-based legislative act needs to supercede and eliminate all conflicting laws. Change must be necessary and properly integrated. -Thomas Clark Christopher Feahr wrote: Tom, Are your remarks here concerned only about *privacy* laws with respect to EHR... i.e., patient and provider rights with respect to access and disclosure? I can't think of any other general aspect of law that would apply to EHR... at least not one that would benefit from the uniform model code that you describe. In the US, the conflict and overlap between state laws and HIPAA is actually part of the motivation for writing the HIPAA Privacy Rule. It is expected the state laws will be eventually become aligned with and modeled after HIPAA in the privacy area, although there is no mechanism to ensure that. Incidentally, there are also areas of state-federal conflict like prompt pay laws, with respect to the HIPAA Transaction Rule... with no help in sight. Personally, I don't think legislatures should be making ANY rules that are specifically about electronic records and information sharing... at least, not until we have some sort of information authority or technical review board to pass these proposals by. Well-meaning politicians have written the Transaction Rule with the intent of helping patients and providers. But the ill-conceived rule ends up increasing everyone's cost and helping no one. -Chris At 06:11 PM 8/26/2003 -0700, lakewood at copper.net wrote: Hi Bill, Thanks for the post. I did intend to use HIPAA as an example of a legislative act that is poorly written without the assistance of a uniform model code. It was enacted to keep the payers happy and not the Patients. Poor results occur when things are not grounded on solid fundamentals. There is a Uniform Commercial Code that has evolved over many years and has been modified and improved over these years. It has been
certification and verification of OpenEHR
Patrick Lefebvre wrote: Hi All, --- (...) Been off looking at some operational considerations associated with supporting, maintaining and updating global EHRs. The following types of users were considered: 1)CREATORS 2)REVIEWERS 3)ADMINISTRATORS 4)CERTIFIERS This idea of certification is not only good for EHRs. Self-proclaimed openEHR-conformant software sould also be tested by general, public certification tests, including EHRs archetypes examples. Independent organisms should also deliver their stamps, in a scheme like: Veritas has controlled this software to be openEHR-compliant with the specifications issued by... (openEHR, CEN, ISO, HL7 ?) . -- Patrick Lefebvre Ce que j'?cris n'engage que moi, et ce jusqu'? ma prochaine id?e. - If you have any questions about using this list, please send a message to d.lloyd at openehr.org Hi All, Certification should be identified as well. This should include information such as: station, date, time, source, results, requestor. With this information tracking can be performed so that actual/potential problems can be isolated. -Thomas Clark - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Distributed Records - An approach
Hi Norbert, Excellent example! It is easy to imagine that a poll taken in the US would show that a majority of the public would believe this could not happen. -Thomas Clark - Original Message - From: norbert Lipszyc i...@club-internet.fr To: Denis Nosworthy Denis.Nosworthy at swsahs.nsw.gov.au; 'Tim Churches' tchur at optushome.com.au; Sam Heard sam.heard at bigpond.com Cc: Christopher Feahr chris at optiserv.com; lakewood at copper.net; openehr-technical at openehr.org Sent: Friday, August 08, 2003 12:22 AM Subject: Re: Distributed Records - An approach Identification, and authentication, has the been the subject of many EUropean projects recently, mostly based on the use of smart cards. As one example I can cite Smart-IS AM (an IST project of the European COmmission) which has defined a common smart-card module for authentication and another one for electronic signature. Therefore the technical ways of solving this problem exist. The problem is social. In those countries where a national identity card exist, there is acceptance for a unique identification for health records also. In the others, such as the UK, there is a lot of resistance and this will be solved only wen patients actually see the advantage for their health to have a unique identification. Once again, this will come only slowly. There was one tragic example of the need for a positive unique authentication tool in France where in a public hospital came two women with the same, identical demographics (names, birth date and place town of residence). One came for a normal check on her pregnancy, the other for abortion and ablation of ovaries due to a medical condition, and the hospital made the mistake. This only points to the need, not the aceptance of a positive authentication tool for people, but such examples can emphasize to the public the reason for the need, mostly if the identificaiton is different for health systems and other types of needs. In short the technical tools are now available through the results of several European projects. Norbert Lipszyc - Message d'origine - De : Denis Nosworthy Denis.Nosworthy at swsahs.nsw.gov.au ? : 'Tim Churches' tchur at optushome.com.au; Sam Heard sam.heard at bigpond.com Cc : Christopher Feahr chris at optiserv.com; lakewood at copper.net; openehr-technical at openehr.org Envoy? : vendredi 8 ao?t 2003 01:05 Objet : RE: Distributed Records - An approach I have been reading these threads with interest over the last few days and I think the majority of the comments are extermely value and add to the debate. The focus is obviously on the structure and some of the mechanics of the process but let me throw something else into the melting pot that is an issue which does not seem to have received much airplay in the recent past anyway. It is the issue of identification and matching of clients. Far be it from me to raise the Australia Card issue again but the EHR ain't (excuse my English) going to work unless the industry can crack this nut in such a way that it is universally accepted by most Australians. Research that we have done over the past couple of years has indicated clearly that the majority of people we have surveyed (upwards of 3000 as part of another project) appear to have little concern about using an EHR however enacting the implementation of an Australia Card' is another issue altogether. I would be interested in the comments from those who have been close to the action about what their own views are and what they perceive the client view to be. Regards, Denis Nosworthy. CIO, South Western Sydney Area Health Service -Original Message- From: Tim Churches [mailto:tchur at optushome.com.au] Sent: Friday, 8 August 2003 06:49 To: Sam Heard Cc: Christopher Feahr; lakewood at copper.net; openehr-technical at openehr.org Subject: RE: Distributed Records - An approach On Fri, 2003-08-08 at 06:06, Sam Heard wrote: Christopher It has been good to read this thread - but I have to wade in here. In designing openEHR I have had a few principles in mind. 1. The technical solution should impose no constraints on social behaviour. This means to me that if we want one EHR for each person that is patient held or one repository for the entire country the system should work. This is the only correct approach. Small, limited scope EHRs can always be amalgamated later to create larger scope EHRs. However, grand, all-encompassing EHR schemes are, at this stage, in most countries, bound to flounder on both socio-political and technical rocks. We should be worry about crawling across the room competently first, but forearmed with the knowledge that in a decade or so we will be running marathons (and hence should start out with an approach which can go the distance apologies for the mixed metaphors there). 2.
Distributed Records - An approach
Hi Dennis, The personal card is a great approach. Unfortunately there are many people who will not have access to the cards. Alternate means could be employed to handle the IDs. Multiple ways of generating/retrieving the Patient's ID should be available. The smart card is a good approach for many other reasons as well, e.g., storage of critical medical information. -Thomas Clark - Original Message - From: Denis Nosworthy denis.noswor...@swsahs.nsw.gov.au To: 'Tim Churches' tchur at optushome.com.au; Sam Heard sam.heard at bigpond.com Cc: Christopher Feahr chris at optiserv.com; lakewood at copper.net; openehr-technical at openehr.org Sent: Thursday, August 07, 2003 4:05 PM Subject: RE: Distributed Records - An approach I have been reading these threads with interest over the last few days and I think the majority of the comments are extermely value and add to the debate. The focus is obviously on the structure and some of the mechanics of the process but let me throw something else into the melting pot that is an issue which does not seem to have received much airplay in the recent past anyway. It is the issue of identification and matching of clients. Far be it from me to raise the Australia Card issue again but the EHR ain't (excuse my English) going to work unless the industry can crack this nut in such a way that it is universally accepted by most Australians. Research that we have done over the past couple of years has indicated clearly that the majority of people we have surveyed (upwards of 3000 as part of another project) appear to have little concern about using an EHR however enacting the implementation of an Australia Card' is another issue altogether. I would be interested in the comments from those who have been close to the action about what their own views are and what they perceive the client view to be. Regards, Denis Nosworthy. CIO, South Western Sydney Area Health Service -Original Message- From: Tim Churches [mailto:tchur at optushome.com.au] Sent: Friday, 8 August 2003 06:49 To: Sam Heard Cc: Christopher Feahr; lakewood at copper.net; openehr-technical at openehr.org Subject: RE: Distributed Records - An approach On Fri, 2003-08-08 at 06:06, Sam Heard wrote: Christopher It has been good to read this thread - but I have to wade in here. In designing openEHR I have had a few principles in mind. 1. The technical solution should impose no constraints on social behaviour. This means to me that if we want one EHR for each person that is patient held or one repository for the entire country the system should work. This is the only correct approach. Small, limited scope EHRs can always be amalgamated later to create larger scope EHRs. However, grand, all-encompassing EHR schemes are, at this stage, in most countries, bound to flounder on both socio-political and technical rocks. We should be worry about crawling across the room competently first, but forearmed with the knowledge that in a decade or so we will be running marathons (and hence should start out with an approach which can go the distance apologies for the mixed metaphors there). 2. Linking records is non-existant at the moment and we can move incrementally towards an environment where we know where health information about an individual resides. Once you start to send EHR data from one site to another in openEHR then the links will build automatically. Remember, sometimes the patient will not want their information to flow! and while the technical view of security checks seems omnipotent, partitioning will always be safer. Every Monday morning, anyone working in this field should re-read the BMA criteria for privacy of patient data, as drawn up by Ross Anderson in the mid 1990s - see http //www.cl.cam.ac.uk/users/rja14/policy11/policy11.html A few moments reflection on these principles reveals that there are many very complex problems for which definitive or even satisfactory solutions don't yet exist - for example, if a patient consents to access to their EHR by clinician A, under what circumstance can that consent be extended to other clinicians, and is the extension of consent transitive, and/or commutative? This extends to knowledge that an EHR record for a patient exists (or even that the patient exists), not just to the contents of that EHR. Very tricky stuff indeed, which is usually swept under the carpet in an intra-institutional setting, and increasingly in vertically integrated healthcare organisations - but organisation won't be able to do that forever, and these issues certainly can't be ignored for community-wide EHRs. It will take many, many years, and many many (probably failed) attempts before well-accepted solutions to these problems are available. In the meantime, start small... 3. openEHR offers a one to one transform for all information in EHRs. Our idea is that openEHR servers
Distributed Records - An approach
Hi All, With a background in fault tolerant computing I have a built-in penchant for distributed files that are exact/backup copies of a master. Works wonders for financial transactions. I don't believe that this model fits EHRs especially since one can conceive of parallel, e.g., close proximity in time, operations directed at modifications originating at geographically distant locations.These operations, even they occur across town (Clinic and distant Lab) create problems for record management. Tying record management to physical location is not a solution. Remote medicine complicates this immediately. However, a constant occurs immediately, presuming that we do not have to deal with human clones (put a dash-number in the ID). The Patient ID is it. Traditional approaches would require that in all the world there is only one unique person being considered. (hopefully). Hence each region could contain entries on residents, transients, visitors. tourists, etc. that somehow make contact with healthcare facilities/Practitioners in the region. Registering the IDs and updating the regional databases requires that only those regional Patients be administered. National and international databases can be established that will receive and store regional registrations of Patient IDs, allowing one to scan these databases to determine who holds regional records on individual Patients. One can then retrieve all the records or part of them. This substantially reduces the need for storage and bandwidth to manage records on a global scale. I presume that there is no need to have matching records for individual Patients in all regions this Patient has been in an made contact with the healthcare industry. If I take a cruise on the Rhine and require medical attention it makes no sense to burden whatever region manages that healthcare system with anything more than they had a tourist with a weak stomach. It would be nice to have a distributed registry that would show where I had to stop off and get some help. At least the Public Health personnel would appreciate it. The important thing to me is to be able to access all the known records and bundle them in a way that is appropriate for the healthcare personnel handling my latest complaints. BTW: The Fault Tolerant/Highly Available Systems can make sure that the information requested is available but the applications have to structure it. -Thomas Clark - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
certification and verification of OpenEHR
Hi Chris, One thought to keep in mind regarding: The EHR efforts seem to want to standardize both the data AND the horse it rode in on.: The DATA embedded in an OpenEHR standardized system can be both extracted and modified. My hunch is that the final OpenEHR standardized system may still be too 'heavy' for many Patient and Practitioner systems to handle effectively. I would opt for DATA EXTRACTION to be followed by user-based formatting and storage prior to data processing. Getting the DATA back into the OpenEHR system would be the final step. A single practitioner is unlikely to have access to resources capable of handling more than a relatively small number of Patients and hence may require access to a subscription service than 'extends' resources. Extending a standardized OpenEHR system into such a service might be 'overkill'. Better ways to approach this type of problem exist. -Thomas Clark - Original Message - From: Christopher Feahr ch...@optiserv.com To: Tim Churches tchur at optushome.com.au Cc: Thomas Clark tclark at hcsystems.com; Thomas Beale thomas at deepthought.com.au; openehr-technical at openehr.org Sent: Monday, August 04, 2003 2:35 PM Subject: Re: certification and verification of OpenEHR Tim, I can imagine several workable funding models for healthcare. The one we have in the US is simply the straightforward selling services for $, perverted by the brokerage model that insurance has superimposed on it. In my personal opinion, neither model makes sense for a service like healthcare... a service that even the most Scrooge-like among us believe everyone should be have in a time of need. So I think we are in agreement that a national health service is more socio-ethically correct than the U.S. mercantile model. I have not studied the metrics for success of the NHS model, but your numbers sound credible. We are good at a lot of things in the US, but we seem to struggle with and mostly reject the value proposition inherent in considering the needs of the greater community along with one's own. That's why US feet have so many bullet holes in them! With regard to EHRs of all sizes... yes, they will look different, and if some of those differences were not there, a higher level of interoperability MIGHT result. But again, I contend that it is the DATA that is most desperately in need of a standard. The EHR efforts seem to want to standardize both the data AND the horse it rode in on. I think that is too much... and will simply not be adopted fast enough to ever reach critical mass. The real question is, Where is the best place to start enforcing a degree of uniformity? I believe it is best to begin with an understanding of how healthcare processes are alike around the world then derive a common set of functional requirements that support the universe of [important/critical] care processes... then build a model of the DATA to support the functional requirements. If we can massively involve providers in such an effort, I believe providers would accept standardizing at the process/requirement level... because they already feel like they are doing that with our published evidebce-based practice guidelines but they will argue til the cows come home about what the darned records should look like! Eventually we might have to create standards for giant data repositories... the big EHR-in-the-sky... but maybe not. If there aren't very many such repository systems, or if a very large one (say, one maintained by the US govt.) made its architecture specifications public, then that might be all the world requires as a de facto standard. We may have too many cooks in the EHR kitchen at the moment. Many of these proposed record models look useful, but which flavor(s) of which ones are likely to become the ubiquitous standard? (The rest will have to go away or risk diluting the success of the ONE... thus, reducing interoperability for ALL). It just doesn't seem to be the right place to be digging for what we are after. Regards, -Chris Christopher J. Feahr, O.D. Optiserv Consulting (Vision Industry) Office: (707) 579-4984 Cell: (707) 529-2268 http //Optiserv.com http //VisionDataStandard.org - Original Message - From: Tim Churches tchur at optushome.com.au To: Christopher Feahr chris at optiserv.com Cc: Thomas Clark tclark at hcsystems.com; Thomas Beale thomas at deepthought.com.au; openehr-technical at openehr.org Sent: Monday, August 04, 2003 1:16 PM Subject: Re: certification and verification of OpenEHR On Tue, 2003-08-05 at 03:44, Christopher Feahr wrote: Tim, RE: That might be an accurate description of the US healthcare system, but thankfully the US system is restricted (more or less) to the US, despite attempts to export it and despite attempts by misguided politicians elsewhere to copy it(snip)... Thus, although dreams of regional or national EHRs seem far-fetched in
certification and verification of OpenEHR
Hi Chris, Great response! Would like to learn what the US Providers want and need from a system like the proposed OpenEHR project. Contributors to the project are at liberty to publish; but the remaining, quite numerous, Providers may well be unaware of the existence of such projects and unable to respond. 'Pass the baton to the healthcare associations' seems appropriate. Why not have them poll their members? Nothing like designing a system that a majority of the users reject. -Thomas Clark - Original Message - From: Christopher Feahr ch...@optiserv.com To: Thomas Clark tclark at hcsystems.com; Thomas Beale thomas at deepthought.com.au; openehr-technical at openehr.org Sent: Monday, August 04, 2003 10:20 AM Subject: Re: certification and verification of OpenEHR Thomas, Thanks! And I hardly know where to begin responding... but I do like all of your comments. The thing about providers being considered a homogeneous group of individuals working for the common good is really a matter of philosophical and, perhaps, spiritual orientation. I agree that we (providers) do not always behave this admirably! But you are also DEAD ON with your comments suggesting that single-minded user-focus (on the user's OWN needs, as opposed to the needs of the greater healthcare community) is related to most users being permanently stuck in survival mode. Businesses are struggling to survive... more and more BECAUSE of the escalating costs of driving the health care bus through the information quagmire. Insurance interests ARE taking more control over who does what in healthcare... but not [always!] out of a megalomaniacal interest in controlling providers... but mostly to get control of the COSTS that providers seem to be powerless to control themselves again, because providers have pathetic software... because no one can build the software they need... because we lack sufficient standards to give application developers sufficient confidence that doctors would actually buy the software if they did build it! We are not trying to decide whether breaking out of this death-spiral is a good idea. Our only task now is to decide HOW to break out of it. It's not sufficient to say that providers have what they deserve because they've refused to agree on something better (for their patients)... unless we first imagine and then create for them a mechanism whereby they CAN agree. Ideally, we should have one geo-politically neutral SDO maintaining robust communications with a solid, global network of medical subject matter experts. Then we build straw man model-components and run them through our expert vetting pool until no one has substantial objection. Eventually, these converge into a generally accepted model of the persons, places, things, actions, relationships, and data elements of healthcare... the aspects of these things that our distributed panel of experts agree are or should be always true. There is much (about the process of CARE) that the industry can and will agree on. (much of this agreement already exists as evidence based practice guidelines or standard of care). We need a way to further formalize that agreement into a technical model of *core* healthcare processes and information. Then we can build on it. As healthcare-paradigms shift, we will have to absorb the shift into the model, just as practitioners will have to implement the shift in real care processes. Obviously, we require a model-technology that is flexible enough to be changed... but remember, this is a MODEL... of a REAL process. If the process can be changed (and society agree that is SHOULD change)... and that change impacts information management... then the world has no choice. We must change both the model and the real processes and the information structures and record architectures... to accommodate the better way of caring for people. We never want to change... yet we always do. The proponents of change always want it to go faster, but I am learning that rapid change ALWAYS causes unnecessary suffering within a system as brittle, fragmented, and interdependent as healthcare. The minute we stop kicking at it, however, it STOPS changing! So the collective government role is NOT to write regulations like HIPAA that foist a particular IT-paradigm onto 500,000 providers by a deadline. The proper government role is to FUND the mechanism whereby provider (and other user) needs can be abstracted into a standard. Then... with a robust and RELIABLE standards floor beneath our feet, we let COMMON SENSE be the driver to build, purchase, and implement interoperable software. Christopher J. Feahr, O.D. Optiserv Consulting (Vision Industry) Office: (707) 579-4984 Cell: (707) 529-2268 http //Optiserv.com http //VisionDataStandard.org - Original Message - From: Thomas Clark tclark at hcsystems.com To: Christopher Feahr chris at optiserv.com; Thomas
certification and verification of OpenEHR
Hi Thomas, Thanks for the response! The regional approach serves the project well initially. The original post should have included some idea of what I think a 'tool' would be. Top-down, it should permit a proper user to identify the subject (difficult in some cases, e.g., where only an infant or unconscious Patient is involved). Where identification not immediately available, shortcut to a temporary ID that can be upgraded later. The following is limited to ADMITTING. Given the ID one can access an graphical tool that can: -create notes and records -scan local databases/events, e.g., healthcare facilities, police, fire, charities -search regional/state/national/international databases, e.g., healthcare facilities, police, fire, charities -create UNKNOWN PERSON events if unsuccessful; confirm ID if successful -create action/task list for facilities (current and others) -synthesize appropriate initial records, e.g., in-facility work-flow -access EHR records from appropriate databases -verify/certify EHR records -check for 'OPEN' activities and update; if none, create an 'OPEN' activity -Bundle records and notify appropriate personnel -Place on an 'ACTIVE' list for further processing PREFERENCES -Platforms: windows/Linux/Unix -Interface: Graphical -UI: drag-and-drop enabled -Implementation Language: OO language with common databases interfaces -Database (examples): mysql, postgresql, Oracle, sleepycat NOTE: multiple databases recommended This describes multiple open-source projects. Hence the real issues are related to: -What information is needed? -What local/regional/national/international services are required? -How is the information presented? -What can the user do with it? -What are the security requirements? -Who gets the results? -What events have to handled? -What are the support activities? Example would be audit/legal requirements. -What can be put together as a design/development/deployment environment? Basic tools with basic functionality should be able to be developed within the OpenEHR project. These would, however, be greatly enhanced through adoption by a hospital group, especially a teaching hospital group. -Thomas Clark - Original Message - From: Thomas Beale tho...@deepthought.com.au To: openehr-technical at openehr.org Sent: Sunday, August 03, 2003 8:31 PM Subject: Re: certification and verification of OpenEHR Thomas Clark wrote: What was your study to do with? this is the meat of the problem... STUDY: -several counties in California and Nevada ranging from agriculture to forestry and their current healthcare systems -current budgetary constraints and potential for new funding -can they develop county-wide and state-wide healthcare systems that incorporate an OpenEHR-based system -can they get support from the federal government -how are they handling HIPAA -can they integrate individual and small groups of Practitioners -can they handle current levels of care for current populations -are their open-source solutions currently available that could be used by county personnel to introduce and maintain a EHR/EMR system I certainly can't answer all these questions, and clearly answers would take time to emerge based on actually doing some trials there. However, I think we can say the following: - openEHR is certainly destined for regional EHR systems, with mixed users, including small providers (and big ones) - there are open source solutions which are leaning toward openEHR eventually becoming the EHR engine, including Torch (http //www.openparadigms.com/), Gnumed (http //www.gnumed.org/resources.html), openEMed (http //sourceforge.net/projects/openmed). A community worth belonging to is the Open Source HealthCare Alliance (OSHCA), see http //www.oshca.org/. - openEHR is an open community, and is essentially an open but disciplined software engineering enterprise, so people in the community can make changes and have influence. US govt support is always an interesting question - the US government is congenitally doomed to think that solutions from outside the US a) don't exist, b) are rubbish or c) should be secretly replicated and then badged as US innovations. This is not a point of view held by all experts or developers inthe health IT domain, particularly OS developers, but it is certainly entrenched. Breaking it requires internal advocacy on the part of the enlightened! NOTE: -restricted to individual counties and counties that have an established inter-county organization i.e. ones who can agree to set up compatible information governance and sharing agreements? -homeless and transient healthcare a major problem and remains so. I think that the approach of indexes/health resource location service + ad hoc requests/replies will be the go for transients. Homeless people is a challenge in the health system in general, and I suspect a lot of the problem is outside the realm of IT, i.e.
Toolsets, Integration and Language Translation
Hi All, COMMENTS (SHORT LIST): 1)TOOLSETS Should support: a)Humans (practitioners, administrators, support personnel, patients and their support groups) This should support visualizations, e.g., VIEW/MODIFY/JOIN/SEVER/PARTITION/INTEGRATE, for a human operator b)local/remote software processes/procedures/intelligent agents This should support software-controlled communications and groups of software packages that will permit automatic and user-controlled data-related operations, e.g., merge notes and records, monitor notes and records, respond to and generate events, evaluate, verify, certify notes and records. Should be able to distinguish in the future whether a human operator or a software package. INTEGRATION'S Should support: a)multiple users/software packages/both, e.g., trade/log/modify notes globally, cross-border/cross-discipline communications/records/notes in real-time/query-response/delayed b)update records and notes to reflect integrations/agreements/disagreements/issues/TODOs c)incorporate place/system/platform/packages/contributors/comments into notes and records so that future communications/records will be able to precisely identify/evaluate/review/contact prior communicators EXAMPLE: See 'smartie' buried in the information at: http://www.openclinical.org or: http://www.smartie-ist.org/ Reading MedNotes makes smartie a handy tool. A similar tool should be available to read the 'dissimilar' MedNote-type files from a GUI tool capable of supporting the desired operations. NOTES: -Developing this tool is not a small task! -The number of different types of MedNotes is currently an unknown PROPOSAL: Need additional input on information that should be integrated with the GUI tool. Comments/suggestions welcomed. -Thomas Clark - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Patient Privacy: Impact of Outsourcing
Hi All, The following link is to an article appearing in the San Francisco Chronicle online version, May 14, 2003 entitled: LAZARUS AT LARGE Kaiser exporting privacy http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2003/05/14 /BU307139.DTLtype=tech Unfortunately this has been predicted by many. Rushing out to contact members of the US congress requesting a new privacy and security bill would be too late and probably wasted effort. It should highlight the need for very stringent security mechanisms and procedures that continually monitor and track data transmission and storage at a minimum. In previous emails 'Secure Data Store' facilities have been mentioned. This is just one example why they are needed. -Thomas Clark - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Record Level Data Security; storage plus fixed andmobiletransmission
Hi Gerard, There has to be medical/Patient/healthcare records and related documents but they must be linked. Storage must be provided for the above, permanent, temporary and intermediary (e.g., dialog between practitioners). Event-based entries into medical/Patient/healthcare records would be structured and most likely result in modifications of permanent records. 'related documents' may become part of a permanent record, e.g., commentary on the Patient (object). They may, however, contain information transitory information useless in a permanent healthcare record, e.g., scheduling, but significant during a course of treatment. There is another type of information related to administrative activities that would be attached to the permanent record. Billing, insurance, etc has to be accommodated. This would be little interest to practitioners and can reside in a separate database (e.g., relational). Must be linked. Both the medical/Patient/healthcare records and documents are subject to the same security requirements and both can be transmitted using the same network services. For example, both can be served from a secure, XML-based application server. The secure transmission of a 'record' can be discussed separately from the content of other records that are encapsulated within it. The naming might be confusing here. The 'record' is likely to be a sequence of 'blocks' of information of whatever structure and format, e.g., FibreChannel protocol (frame-based transmission of blocks of information). Looking at the content of the information received that structure could include healthcare records of any defined type. An advantage of this approach is the simplicity of appending additional record-based information to the end of the received file. Two disadvantages: 1)it has to be stored someplace 2)multiple users would require additional structure and processing to keep things in order Neither of these are major. To this point it is mechanistic and transparent to a Practitioner. One should be able to access the received data and all additions. Whether the Practitioner can edit the appended data is a separate issue. This 'interface' can be common; beyond this things get more involved since other factors are operative. Record Level Data Security has little to do with legal, social control and organizational aspects These aspects change things. Everything from a facility security policy to what the staff does regarding record operations can change between facilities. Importantly different facilities can interact uniquely with the information available for inclusion and modification. Related problems have to be resolved between Practitioners, legal jurisdictions and human organizations. Apart and separate from the records-based issues, there can be a significant need for systems that support communications between practitioners, e.g., secure Chat and document transmission. Something of value arising from this type communication could be included in the permanent record by a practitioner. Solving the 'social control and organizational' problems will take considerably more time and is likely to require continual attention thereafter. -Thomas Clark - Original Message - From: Gerard Freriks gf...@luna.nl To: lakewood at copper.net; openehr-technical at openehr.org Sent: Sunday, May 11, 2003 4:31 AM Subject: Re: Record Level Data Security; storage plus fixed andmobiletransmission Dear Thomas, At OpenEHR there is an emphasis on the exchange of documents but also on storage of objects in systems. What you are referring to is the first topic (messages). Gerard On 2003-05-03 19:52, lakewood at copper.net lakewood at copper.net wrote: Hi Gerard, Record Level Data Security has little to do with legal, social control and organizational aspects. I agree that these are important, and in many cases more important, than record level data security. They are more complex issues that are dependent upon factors varying from culture to informal/private business arrangements. To be complete others would have to be added. The approach taken was to start at a level where secure global electronic data interchange of healthcare records is possible, a possible model being the Association For Payment Clearing Services. http //www.apacs.org.uk/downloads/List%20of%20Standards5.pdf The perceived need is secure, standard record formats so that information can be accessed even though it was created under a system using a different record format. -Thomas Clark - Original Message - From: Gerard Freriks gfrer at luna.nl To: lakewood at copper.net; openehr-technical at openehr.org Sent: Saturday, May 03, 2003 2:40 AM Subject: Re: Record Level Data Security; storage plus fixed and mobiletransmission On 2003-05-02 22:43, lakewood at copper.net lakewood at copper.net wrote: Security begins at the data storage level. Unless it can be
NIST: Automated Security Assessment Tool; need something similar
Hi All, The following is a link to the NIST Automated Security Assessment Tool. For OpenEHR one tool will be insufficient. Something similar is feasible for the low-level (network/system) OpenEHR project. http://csrc.nist.gov/asset/ -Thomas Clark - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
openEHR security; Directed to Thomas Beale
Hi Karsten, Comments in text. -Thomas Clark - Original Message - From: Karsten Hilbert karsten.hilb...@gmx.net To: openehr-technical at openehr.org Sent: Thursday, May 08, 2003 2:04 AM Subject: Re: openEHR security; Directed to Thomas Beale Tracking is super-important. Include the image. Of course one does. If you have the image you store it. My preference is for an object-oriented database since I might want to retrieve all ER-related information quickly (includes narratives and images). What do you do when your object-oriented application falls over ? Here, an open source application/database is even more important than in plain relational DBs. There should be sufficient redundancy in the application to enable a recovery. Granted there are a lot of them that do not support this in an acceptable manner, some not at all. Highly available systems and networks go part of the distance; redundancy in applications and storage another bit; redundancy in archiving and retrieving another bit; redundancy in updating. No guarentees however, e.g., the network inject nasty problems. Tough question; answers can range from hardware-OS-local/distributed applications to hardware failures and software errors. Checkpoint and backup. If content is there upon retrieval it likely was not there upon creation. I am completely puzzled by this assertion. Please explain. Thanks, Karsten Recognize the thought but the above looks ill-formed. Refers to: 1)Information not present in prior history 2)Initial contact does not contain a reference 3)No input during treatment, etc 4)Information present upon discharge. Gap in the 'chain-of-events'. I could also have been ready to call it a day. The above, however, is a major problem that may or may not be related to the update of the records, e.g., generated a paper record whose content was never entered into the record. Suppose you look at a record one month later where this occurred at another facility. What would you conclude? Interesting example from the legal world: 1)Patient has never had a broken right arm 2)Patient enters a nursing room 3)Patient remains for six months 4)Upon discharge Patient has experienced a broken right arm 5)No entry in the record regarding the event and perhaps subsequent treatment Hence, regardless of the competence of the record-based system there will be situations where some things will remain the same. -- 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
openEHR security; Directed to Thomas Beale
Hi Matt, Comments in text. - Original Message - From: Matt Evans m...@totalise.co.uk 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
Trusting the contents of EHRs
Hi Tim, Never trusting the record is in itself justification for OpenEHR and interfacing it with all other EHR/EPR/EMR systems. I do not 100% trust the contents of the records supported by the EHR/EPR/EMR systems. The basic rationale is that the information is generated by related devices and human beings, e.g., the process of communication between humans is not without difficulties. What these record systems do is generate and maintain accurate and precise records of what someone has reduced to an electronic format. One could employ software applications that would attempt to make sense out of it and perhaps provide a more relevant/germane interpretation, but the record remains. I can understand that Practitioners suspect the record. Mine involves multiple Practitioners in multiple Healthcare organizations (I have moved some). They do not speak the same 'language', which is probably why the Patients are subjected to multiple identical tests for no obvious reason. The record systems will not improve the correctness of the content. A bad diagnosis remains just that. The record system will make it available quickly and reliably. Another software application may put together some of the pieces so that an improvement is possible, but then a Practitioner would probably have to design that as well. Not trusting the content of the records is a Practitioner problem. Electronic records are likely to remove most of the problem areas in existing systems, e.g., the copy machine ate that page. A group of monkeys locked in a room with a number of computers taking record-based inputs may create actual records but neither of us could really understand or use the data. This comes from the same scenario applied to music. Bach would have no competition. I have one hope for the Patient's sake; the Practitioners should at least rotate the questions. -Thomas Clark - Original Message - From: Tim Churches tc...@optushome.com.au To: openhealth-list @ minoru-development . com openhealth-list at minoru-development.com Cc: Karsten Hilbert Karsten.Hilbert at gmx.net; openehr-technical at openehr.org Sent: Monday, May 05, 2003 3:10 PM Subject: Trusting the contents of EHRs --=-O//NjGR3MyktaTNFkz0f Xontent-Type: text/plain Content-Transfer-Encoding: quoted-printable Cross-posted from the openehr-technical list: On Tue, 2003-05-06 at 03:39, Thomas Clark wrote: The presumption that a Patient is 100% lucent in a stressful situation is subject to debate, e.g., accidents, flu, labor and delivery. =20 Retrieve the information from the Patient; analyze it; compare it with th= e record, if available, but give it a proper weighing. Don't forget the symptoms and the reasons the Patient ended up in the facility. =20 It is an information retrieval/analysis/credibility/reliability problem. = The information needs to be sorted. About a year ago a friend of mine suffered a myocardial infarct at the unexpectedly early age of 53. Thanks to very swift thrombolysis, he survived with virtually no ill effects. However, during his stay in hospital, he was amazed that he was asked the same basic set of questions over and over again by different people, despite them having his clinical record in front of them, with that information neatly recorded there by an intern. He found that surprising. When he related this to me, I expressed no surprise at all - one of the first things you learn as an intern working in a hospital is that you should never trust the accuracy or completeness of someone else's entry in a medical record. So wherever possible, you always check the facts. Later, doing general practice locums, the wisdom of that view was confirmed. But I learnt to rely on records made by colleagues whom I knew and trusted. Now, this is, I suspect, a rather common attitude, and is something which seems to have been rather glossed over in all the discussions and studies of the benefits of an EHR. There's no doubt that, eventually, medical culture would change sufficiently to trust what is in an EHR, but how long would that take? Has anyone systematically investigated this question? --=20 Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http //members.optushome.com.au/tchur/pubkey.asc Key fingerprint =3D 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0 --=-O//NjGR3MyktaTNFkz0f Xontent-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA+tuE4eJFGqer5k9ARAvcnAKC4+s0dhOX6KBwNDTJ5C7Alu7hdlACfeqsT pdIExqkFcaqZ4QU57Xf2saM= =K4OW -END PGP SIGNATURE- --=-O//NjGR3MyktaTNFkz0f-- - 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
Trusting the contents of EHRs
Hi Tim, Do not have a link handy but I do recall that the EMR discussions in the NHS introduced this and discussed it at length. Structuring data entry format went a long way toward improving it. I'll see if I can come up with a link. -Thomas Clark - Original Message - From: Tim Churches tc...@optushome.com.au To: lakewood @ copper . net lakewood at copper.net Cc: Tim Churches tchur at optushome.com.au; openhealth-list @ minoru-development . com openhealth-list at minoru-development.com; Karsten Hilbert Karsten.Hilbert at gmx.net; openehr-technical @ openehr . org openehr-technical at openehr.org Sent: Monday, May 05, 2003 7:44 PM Subject: Re: Re: Trusting the contents of EHRs lakewood at copper.net lakewood at copper.net wrote: ---snip--- Not trusting the content of the records is a Practitioner problem. ---snip--- Indeed, although in their defence, almost every Practitioner will have anecdotal evidence justifying their lack of faith in the record. My question was, has anyone considered this issue in detail? How pervasive is the level of distrust, how variable is it with respect to system and data source, what will it take to change these attitudes? I suspect that information about quantitative test and investigation results contained in an EMR/EHR are probably quite well trusted (hopefully justifiably), but softer, more qualitative information less so eg does the patient have any medication allergies? There is plenty of room for doubt and variable interpretaion regardless of whether that question is answered in the positive or the negative. Of course, these are broad sociological questions, and these are the wrong forums in which to ask such questions. I was just curious to know if anyone was aware of any specific research being undertaken to address these questions? yes, I am about to do a PubMed search now... Tim C - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Record Level Data Security; storage plus fixed and mobiletransmission
Hi Gerard, Record Level Data Security has little to do with legal, social control and organizational aspects. I agree that these are important, and in many cases more important, than record level data security. They are more complex issues that are dependent upon factors varying from culture to informal/private business arrangements. To be complete others would have to be added. The approach taken was to start at a level where secure global electronic data interchange of healthcare records is possible, a possible model being the Association For Payment Clearing Services. http://www.apacs.org.uk/downloads/List%20of%20Standards5.pdf The perceived need is secure, standard record formats so that information can be accessed even though it was created under a system using a different record format. The goal is access to all relevant/germane information. Hence, interchangeability is crucial. I admit that 'legal, social control and organizational' issues are much harder to solve which is why, in the short term, I am staying away from them. -Thomas Clark - Original Message - From: Gerard Freriks gf...@luna.nl To: lakewood at copper.net; openehr-technical at openehr.org Sent: Saturday, May 03, 2003 2:40 AM Subject: Re: Record Level Data Security; storage plus fixed and mobiletransmission On 2003-05-02 22:43, lakewood at copper.net lakewood at copper.net wrote: Security begins at the data storage level. Unless it can be protected at this level more sophisticated techniques applied to transmission and content will not be as effective as desired. Three common approaches are: 1)Data security 2)Data management and 3)Access to storage media-resident data, e.g., somebody's disk drive You leave out completely the legal, social control and organisational aspects. Technology isn't a silver bullet. Gerard -- 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
openEHR security; Directed to Thomas Beale
Hi Gerard, Good list of requirements. My question concerns contact between Healthcare Practitioners and others which may include geographically remote locations and roving, e.g., in-hospital via wearable or hand-held units. This contact would extend beyond that of the Practitioner-Patient. A good example would be Remote Surgery with requirements that amount to secure, continuous audio/visual connections. Another would be my clinic where they have migrated to computer systems within the exam room and at other points of contact. If a process, procedure, technology is already in use would it be integrated within the OpenEHR scope, requirements, goals and implementation? Judging from the difficulty getting something implemented it would seem that somewhere, sometime someone was able to justify the project and get it implemented. -Thomas Clark - Original Message - From: Gerard Freriks gf...@luna.nl To: Bill Walton bill.walton at jstats.com; openehr-technical at openehr.org Sent: Saturday, May 03, 2003 2:37 AM Subject: Re: openEHR security; Directed to Thomas Beale On 2003-05-02 19:25, Bill Walton bill.walton at jstats.com wrote: Hi Gerard, Gerard Freriks wrote: /snip/ In other words: the OpenEHR can assume that the Access Control function operates as if it is a fire wall that executes a set of rules and that the Audit trail is the log with violations (Exceptions) the fire wall had to grant. The operation of the 'firewal' and audit trail are outside the scope of Open EHR. While I support the concept of seperating the access control functionality from the storage / retrieval functionality, I'm afraid I have to disagree, with all due respect, to the segregation of the audit trail and to what I understand your definition of what needs to be contained in the audit trail. The notion that the audit trail only log exceptions will be a non-starter here in the U.S., I think. I understand your remarks. But. The following information must be added to get a fuller picture of how I envisage things: -0- The context for my remarks is the discourse, using human and computer processable documents, between health professionals over time and space. My context is not updating databases using messages. -1- Electronic systems must provide at least the same quality in all aspects when compared with paper based systems. The quality can be better but never less. -2- Of course persons entering the system are logged -3- And only information is readily available to which one has rightful access because one is working in the same department the patient is in. All access to the information will not be logged in the audit trail. (paper based systems don't record where the eyes hit the paper and ink) I assume a high degree of social control in a department. -4- Audit trails in the sense that is recorded why, what, when, from where, by whom has used the exception path to reach information are needed when the requestor is overruling the access controls. -5- the preferred way of obtaining information must stay (as it always was) direct contact between health professionals either orally or by writing. My fear is that because anything can be recorded and tracked or traced we feel obliged to do so in the electronic domain. Example: The Data Registrars Office in the Netherlands is of the opinion that access to electronic medical records can be granted only by using two ways authentication (password AND biometrics) The only justification is that it is possible. But it is unaffordable and to complex to organise in the healthcare domain) -- 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
Record Level Data Security; storage plus fixed and mobile transmission
Security begins at the data storage level. Unless it can be protected at this level more sophisticated techniques applied to transmission and content will not be as effective as desired. Three common approaches are: 1)Data security 2)Data management and 3)Access to storage media-resident data, e.g., somebody's disk drive These can occur long before access security is needed in a Healthcare environment, but are also appropriate for data storage and access within a Healthcare environment. DATA SECURITY Good example is the CDSA project gratis from Intel: http://www.intel.com/labs/archive/cdsa.htm http://www.opengroup.org/security/l2-cdsa.htm which relieves upon: 1)digital certificates and 2)portable digital tokens Neat stuff since already the Healthcare Computer System Administrator has capable security tools. The Secure Data Store Admin should have these available as well. Target systems include Windows and Linux and security adaptability is supported. Fixed data transmission environment have multiple techniques for securing data during transmission, e.g., SSL, HTTPS and these work well between fixed Healthcare environments, e.g., Hospital-Clinic. Mobile applications are crucial. Mobile Healthcare applications are not exempt from data security requirements. Data transmission security mechanisms for fixed environments do not work well in mobile environments and hence new techniques have been developed. The following link covers Java in a mobile environment: http://www.javaworld.com/javaworld/jw-12-2002/jw-1220-wireless.html Presuming that the data is now available at a Healthcare environment the following may apply: 1)data storage, management, handling and transmission can be similar to that described previously 2)Healthcare-specific systems (e.g., GNUmed: http://www.gnumed.org/development/home.html and OpenEHR) can be interfaced to the data obtained from external sources 3)Bi-directional record translations are possible (may be required) 4)Data security and privacy issues remain COMMENTS 1)A single Healthcare facility complete with a familiar set of EHR/EPR software, process, procedures, techniques and trained personnel may represent a single intelligent node existing in a 'fabric' containing Patients, related services, non-conforming practitioners and other similarly intelligent node. 2)The intelligent nodes are not likely to be exact copies. 3)The processes, procedures, technologies, etc that have been used to interface perhaps dissimilar intelligent nodes in other environments apply 4)Content is important to a Practitioner where it is relevant/germane 5)The goal is to provide the Practitioner with relevant/germane information and nothing else SUGGESTIONS 1)Develop a secure data storage, management, handling, transmission system that delivers secured data to a systems available to a Practitioner 2)Develop applications that perform similar activities within a Healthcare environment 3)Develop security applications that will access. manage, handle and filter the data for the practitioner. exercising control over disposition, e.g., spawning copies/partial copies/forwarding/audits/time-limit functions, communicating with external users, etc. 4)Add new facility-unique security that will precisely identify content, e.g., digital watermarks. 5)Handle redundant data and secure data destruction. 6)Security plug-ins for practitioner- and facility-specific data security Lots of stuff available! -Thomas Clark - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
