certification and verification of OpenEHR
Christopher Feahr wrote: Dear Group, I have just recently joined your listserve, and have been actively participating in the HL7 EHR ballot discussion for only a few weeks. During the four years prior to that, I had been swimming in the HIPAA-EDI ocean, trying to figure out how the operational costs for 450,000 smaller providers would ever be lowered under our transaction rule. The answer is, they won't... costs will increase. While HIPAA is arguably another story, but I believe that the failure of the transaction rule to be embraced by our fragmented US provider community is closely related to the elusive success of the standard EHR effort. I have the distinct sense that our global EHR conversation is much closer to the heart of The Beast for small providers than the HIPAA slugfest will ever be... and much more likely to bring sanity to providers lives. Hence, my keen interest in it. Nevertheless, I sense an implied constraint throughout most of the discussions I have listened to... caused I think, by the almost single-minded focus on the attributes of the information *container*, rather than on the health information, itself. Containers and container systems were certainly a major constraint in the days of paper, and most providers still seem to cling to that primary repository or medical chart model even after going paperless... as doctors like to say in the US. EHR discussions seem to presume that we are still constrained by an overwhelming need for a monolithic, physical record system that has to live somewhere... all in one piece. Constraining every enterprise system to the same physical record architecture is always denied as an ultimate objective of EHR... although that *would* be a path to a fairly high level of user-system interoperability... it's just that no one would agree to do it. I see the state of thinking as follows: - existing providers, including hospitals, labs, GPs, will in many cases keep their existing EMR systems (all different etc) - the shared-care health record is likely to be installed as a new system on a regional or even national basis in some places. - what is standardised is the shared-care EHR and its interfaces. EMR systems have to send some percentage of their innformation to the EHR - most likely, GPs will start using the EHR directly - providers that decide to adopt the same technology as the shared care EHR will obviously have an easier time of shipping information in and out Our analysis so far is that these EHRs will have to be consolidated rather than purely federated (i.e. pieces integrated in real time for display), since there are many problems with relying on feeder EMR systems to be responsive for real-time queries. These include different querying languages, different security models, differing latencies, network unavailability etc. Another major reason for consolidation is that soure systems may have all kinds of detail which is of no long term interest to the shared care, longitudinal EHR - hence some kind of filtering between feeder systems and the EHR has to occur. (Defining the filter functions will not necessarily be that simple.) A third major reason is that doing writes to the EHR can only be realistically be done to one place with a defined architecture. Doing distributed writes to a multitude of different back-ends has been proven many times to be nearly impossible to do reliably; to make it reliable would cost exorbitantly. The kind of communication needed to enable EMR - local shared care EHR communication can be based on contractual agreements set up in advance. Regional EHRs would take care of most people, most of the time. However, there stil needs to be a way of enabing ad hoc requests and replies for situations in which patients have health problems in unexpected places. There also need to be communication mechanisms for patients who are always mobile, such as military, aid workers etc. These mechanisms will be virtual federation, supported by resource location/indexing systems. So in the end, I believe a distributed system of consolidated EHRs, with will be the way to go. EHR Dream #2 seems to be a Big-EMR-in-the-sky, with which all user systems could remain synchronized. Again, that would certainly lead us toward a useful level of interoperability, assuming that the most trustworthy entity (the U.S. govt.? United Nations?) agreed to maintain the repository-in-the-sky, to which over one million enterprise systems would have to be rigorously mapped. But even if that were reasonably implementable, it makes providers uncomfortable... the idea of their records being stored with millions of foreign records in some far off place (like India), rather than in the safety of their back rooms... or just down the street... or at least in the same state or county. Have we asked providers to sit down and *really* articulate these fears?? These are paper-tiger issues. firstly, anyone who thinks it is a
certification and verification of OpenEHR
I should have also mentioned another reason why local EMRs have to be left intact, at least for the time being - it is te psychological one that their owners will not feel as if they are having their system taken away from them. - t - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
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. identification, compliance, recalls etc. But we do need to design for the reality of processes which don't go according to plan - we certainly cannot design for perfect patients. Here in Australia dodgy/multiple patient identifiers are a big problem in rural indigenous population, and somewhat so elsewhere. Connecting fragments of health information together form inside multiple patient contact points where the id information is unreliable is a known challenge, and I have seen some good work in France on this (based on the idea that even if you can't figure out who this person _really_ is, you don't care that much; what you do care about is determining if the various fragments of health inforation actually relate tothe same person, to give some hope of building a coherent picture of them). openEHR is trying to be cognisent of such problems - the EHR design makes nearly no assumptions about ids - that problem is outsoruced to the demographic system. Status/state of execution of treatment regimes, recalls etc we think will be pretty well handled by archetyped state machines and process models which are under development now in the workflow area. But - making sure this stuff works will of course be up to the whole community to be invlved in design, implementation testing and feedback. -within each county there are major disconnects between different departments and services -county healthcare services are over-burdened, under-funded, under-staffed and in constant danger of closure i think these points relate to deployment strategies (if you were ever to get that far;-) - don't change the work practices of clinical allied health workers in a revolutionar way (make it evolutionary), and make sure the overall and ongoing costs can be met, including retraining etc. But the promise of clinician involvement in writing their own archetypes and templates could also have a benficial effect - this is where the health workers get to be inthe driving seat. Compared to the classic kind of IT in most current systems, this is one area we hope will drive engagement and positive reception of things like openEHR. -governments seem to make matters worse -charities and welfare agencies are unable to participate for a long list of reasons -in-place IT Departments are over-loaded this last one could be radically changed it things moved to standards-based relatively lightweight back-end
FW: Encoding concept-relationships in openehr archetypes.
This is a post we didn't resolve, and I would like to re-address the question. Unfortunately, I cannot resolve either of your links Jim...can you provide new URLs? - thomas Jim Warren wrote: Dear Tom et al: This is my de-lurking for the list. For those of you who dont' know me, I'm a computing academic whose area of interest will be adequately characterised by my question... I'm trying to represent the structure of normal values of fields in archetypes. I can see that there is of course some provision for a set of allowed values, a default value and (in quantities) min and max. I want to go further (because the information could be very useful in the user interface and to integrate with decision support). For instance, I'd like to design fairly specific chronic disease management archetypes. Without worrying whether it's clinically particularly worthy, take as a convenient example the hypertension in diabetes algorithms at http://www.tdh.state.tx.us/diabetes/algorithms/PDFfiles/HYPER.PDF. My PhD student, Sistine Barretto, has made a map of the relationship of concepts from that guideline (see http://winston.unisa.edu.au/demo/Share/Ontology.doc - and the goal here is not to get too picky about the use of the term ontology either). From this analysis it falls out (unsurprisingly) that there are a set of drugs (in particular, some drug types as well as a set of generics organised into types) that are in the scope of compliance with the guideline. There are also some relevant comorbidities and various other concepts (observations and actions). How can I (should I?) represent the set of likely (in scope) drugs such that, for example, a user interface could put them as options in a menu? Furthermore, how can I relate the comorbidities and other indications for the drugs to the values for a drug name field in a specialised medication archetype? Admittedly, I'm slipping into the realm of decision support, but I think it really is simply the structure of the domain of normal values in this specific application. I'd like to use archetypes to represent this, just as a I might use them to represent the min and max of a given quantity. Is the capability all there already? If not, what's missing? Cheers, Jim Warren Assoc. Prof. Jim Warren Director, Health Informatics Laboratory Advanced Computing Research Centre University of South Australia - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -- .. CTO Ocean Informatics - http://www.OceanInformatics.biz openEHR - http://www.openEHR.org Archetypes - http://www.oceaninformatics.biz/adl.html Community Informatics - http://www.deepthought.com.au/ci/rii/Output/mainTOC.html .. - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
certification and verification of OpenEHR
Congratulations for your comments and remarks; it is the most interesting message I have read for months. However I have to disagree with what could be interpreted as a negative comment against suppliers. I use to tell the users (hospitals and specially the doctors) that ?People get what they deserve... -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20030804/b4993d20/attachment.html
Encoding concept-relationships in openehr archetypes.
Hi, Is it? Is it about how to represent the domain normal values? Or is it more general: Are concepts related? Then the problem is: what relations are there between concepts (archetypes)? What semantics of these relationships between archetypes (concepts) do we need to describe reallity (including decision support)? Gerard On 2003-08-04 5:38, Thomas Beale thomas at deepthought.com.au wrote: Admittedly, I'm slipping into the realm of decision support, but I think it really is simply the structure of the domain of normal values in this specific application. I'd like to use archetypes to represent this, just as a I might use them to represent the min and max of a given quantity. Is the capability all there already? If not, what's missing? -- 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
certification and verification of OpenEHR
Thomas, Thank you for your comments. At the moment, the healthcare industry relies on a federated, duplicative system of paper and electronic records. The fragmentation of provider-resources and of healthcare tasks themselves, combined with the long life spans and great mobility of patients are probably the main causes for a person's health data to be spread around so much. I don't foresee any social or other changes that would ever drive the data to be more contiguous. In a particular instance of CARE, however, it can be vitally important to create an ad hoc, record or view of SOME of the patient's health data... just enough to support what the clinician or administrator needs to do at that moment. Each user will want his local EHR system designed expressly to support his local needs... and he will want to maintain a local repository of all the data he has created or collected about his patients. I think that's a good idea. If agencies like CDC were to also create giant, global repositories for specific purposes... say, to collect data about all communicable disease events in the world... then each provider system might be required (perhaps by regulation, in the U.S.) to continuously update this disease registry with defined report-messages. The resulting CDC repository would, in addition to its utility in helping CDC control spread of disease, also become a useful historical record of a person's diseases over his lifetime... but not necessarily a record of all the patient's surgeries, dental procedures, eyeglass prescriptions, etc.. Presumably other repositories would be built by people who cared about those areas of public health. Each user of health information essentially maintains a repository. Large repositories, constructed for specific purposes, would have a secondary utility as points of synchronization for doctor's records. If 6 different doctors are treating Mrs. Jones over a 10 year period, but during the last year she has seen primarily her oncologist... each time the oncologist updates a cancer registry or other big data repository, that little part of her federated, global health record is essentially updated for all interested providers to see. As her other5 doctors connect to these registries (for reasons having nothing to do, necessarily, with Mrs. Jones) their systems will also notice the presence of an updated record for Mrs. Jones... downloading her latest cancer status info, what drugs she is taking now, new drug allergies discovered, etc what ever these 5 other provider systems have been programmed to care about... and her local records in those 5 other offices become [more] current. I'm not sure we are quite ready to think about the big EHR-in-the-Sky repository that exists ONLY for the purpose of keeping local user records in synchrony... although we seem to be drifting toward that model and it is probably an achievable model. The main repository for such a model could live nicely in India or anywhere. I am NOT a security expert, but I know that you would have at least a couple mirror sites and other redundancy built in. AND... perhaps of greatest comfort to providers... each provider's local EHR system remains always intact and always kept up-to-the-minute through record refreshes each time he connects to the [hopefully, small number of] global repositories. Step #1 still seems to be agreement on ONE standard information model... with only the constraints that are invariably required for each particular element of health data. Archetypes that express additional business rules about the information and relate it to other information elements will be much more difficult to agree on. I think we should try to standardize that layer eventually, but that will require a very efficient mechanism to be constructed for getting input from doctors without them having to attend standards meetings (because they won't attend!). In my view, the EHR effort... partly by virtue of the inclusion of the record concept... is starting at too complex a level... at a point where we are almost designing a particular business management system in the standard. A rule-free standard model for the INFORMATION should exist first. From what I understand, SNOMED CT is a very good start on that. Also as a standard, we should make an effort within each care domain to model the actors, places, and things in healthcare, the relationships between them that are always true, and the relationships among the information elements that are always true. This can serve as a useful framework or high-level model for the much more granular and often unique process and information models of each local user-enterprise. -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: Thomas Beale tho...@deepthought.com.au To: openehr-technical at openehr.org Sent:
certification and verification of OpenEHR
Hi, The 'users (hospitals and specially the doctors)' are contributors to the fragmentation and isolation that prevails in the healthcare fields globally. Other contributors include governments at all levels, insurance companies, regulators and judicial systems at all levels. Which political systems attempt to support individuals with rights, rules, regulations that ensure proper, sufficient, competent healthcare practiced by properly trained, administered and regulated Practitioners? There are some but too few. I am mindful of the state of the healthcare industry in the US and the EU and often debate the differences. Setting levels of expectation at just a percentage of GDP is insufficient. Finding someone in the EU that will trade insurance premium payments with me is considerably harder to accomplish. Yes I believe that politics plays a role in healthcare, especially since governments are great 'allocators of resources'. Having said this I should point out that individuals are ultimately responsible for their governments and hence responsible for the allocation of resources to healthcare. We are contributors as well. I agree that in some respects 'users (hospitals and specially the doctors)' 'get what they deserve...'. Drilling deeper into each category (hospitals and doctors) has convinced me that this requires modifications since individual cases point out that control is absent. Doctors working for US HMOs are a case in point. Where you find the healthcare industry today is exactly where they put themselves. Historically they have received widespread unquestioning support which has gradually eroded. People understand the needs better and realize that there is a better way. Suppliers are typically business selling products and services into an industry that has established requirements, needs and objectives. They have some impact on the market based upon the products and services they provide. Would not place them in the key groups of parties responsible for the current for the current healthcare industry. The OpenEHR project is not a solution to the current state of the healthcare industry. It does, however, represent a trend that can place tools in the hands of Practitioners and Patients permitting them exercise control over information in a cost-effective and efficient manner. The 'users (hospitals and specially the doctors)' are quite diverse globally. A basic requirement for the OpenEHR project should be adaptable structure and applications. -Thomas Clark - Original Message - From: HOPTIMIS at aol.com To: tclark at hcsystems.com Cc: chris at optiserv.com ; thomas at deepthought.com.au ; openehr-technical at openehr.org Sent: Monday, August 04, 2003 1:28 AM Subject: Re: certification and verification of OpenEHR Congratulations for your comments and remarks; it is the most interesting message I have read for months. However I have to disagree with what could be interpreted as a negative comment against suppliers. I use to tell the users (hospitals and specially the doctors) that ?People get what they deserve... -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20030804/ace44cfa/attachment.html
certification and verification of OpenEHR
Philippe, Thank you for the comments. I believe that we will have islands of health information for a very long time... for many reasons, some of which are not technically sound, but more the result of convention. On the other hand, the islands do facilitate an inherent security and fault-tolerance. Bombing one island would never destroy the greater system. We just need to ensure that each island is able to connect periodically to a global repository-network... for updating/refreshing... and that we have robust access control and ways to determine how reliable the data is. 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: Philippe AMELINE philippe.amel...@nautilus-info.com To: openehr-technical at openehr.org Sent: Monday, August 04, 2003 1:42 AM Subject: Re: certification and verification of OpenEHR Hi, Constraining every enterprise system to the same physical record architecture is always denied as an ultimate objective of EHR... although that *would* be a path to a fairly high level of user-system interoperability... it's just that no one would agree to do it. I see the state of thinking as follows: - existing providers, including hospitals, labs, GPs, will in many cases keep their existing EMR systems (all different etc) - the shared-care health record is likely to be installed as a new system on a regional or even national basis in some places. - what is standardised is the shared-care EHR and its interfaces. EMR systems have to send some percentage of their innformation to the EHR - most likely, GPs will start using the EHR directly - providers that decide to adopt the same technology as the shared care EHR will obviously have an easier time of shipping information in and out There is certainly a feeling in the air that each place of care can't remain a care island in the ocean. We probably can talk a very long time about models, architectures, standards... in order to allow various form of communication. As someone that as been working on very practical solutions in that field for some years, I can introduce (very) shortly two major concepts : - Be usefull It certainly seems to be a dumb advice ; of course no one will ever build a useless system ;o) However, since we are talking about communication, the system must be usefull for each and every party. So, if you want to adress the continuity of care issue, the system must be usefull for the patient, the GP, the hospital practitionner and so on. I mean they must use it, and not only benefit from it ; so I mean the patient must use it and not only be the center of it. - Subsidiarity It is a complex word, but the meaning is simple : let the wider system concentrate ONLY on functions that narrower systems can't offer. For us it means two orthogonal considerations : a genuine functionnal axis (put the proper functionnalities on the proper system), and a data storage axis (store the proper data on the proper systems). Best regards, Philippe - 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
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 tcl...@hcsystems.com To: Christopher Feahr chris at optiserv.com; Thomas Beale thomas at deepthought.com.au; openehr-technical at openehr.org Sent: Sunday, August 03, 2003 12:50 PM Subject: Re: certification and verification of OpenEHR Hi All, I would like to add a big 'RIGHT-ON' to Christopher's contribution! From the operations viewpoint cost is a major factor and when significant precludes participation by parties and organizations that should be involved. Also, the healthcare industry cannot be described as a homogeneous group of individuals working for the common good, and perhaps the Patient's health. What is noticeable is that different groups/disciplines rarely communicate effectively and are often at odds over even small matters with 'turf control' a common factor. I recently attempted to get a handle on how county operations handle everything from budgets to HIPAA. Unfortunately even
certification and verification of OpenEHR
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 the US, they are achievable elsewhere, I think, and perhaps within a decade. I share your concerns about the US healthcare model, which differs mainly in the area of payment. Allowing 6000 insurance companies to become so firmly wedged between patients and providers was NOT a good idea. The only possible benefit to patients and the common good is risk-mitigation... something that the US govt. is in a MUCH better position to do fairly, and something that commercial health plans have not really given us anyway. In fact risk mitigation by my rules being obviously better than shouldering the full risk, has become the chief subscriber-retention strategy for many health plans. Some people even choose to remain in jobs and careers they despise, in order to have SOME health coverage. But it took us 40+ years to get into this jam in the US and we cannot expect to back out of it overnight. If there is anything inherently unfair about the US situation (besides the government failing to accept its role of chief risk-mitigator) it is the lack of representation of provider needs in the general area of information management and standards development. I believe that we could live with the US payer-model if our govt. found a way to even out the $-risk of health problems for all patients... assure that all Americans had access to a reasonable level of care... and funded a mechanism for discovering and publishing provider requirements in the form of at least a national, if not global standard. -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 tc...@optushome.com.au To: Thomas Clark tclark at hcsystems.com Cc: Christopher Feahr chris at optiserv.com; Thomas Beale thomas at deepthought.com.au; openehr-technical at openehr.org Sent: Sunday, August 03, 2003 1:59 PM Subject: Re: certification and verification of OpenEHR - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
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 tc...@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 the US, they are achievable elsewhere, I think, and perhaps within a decade. I share your concerns about the US healthcare model, which differs mainly in the area of payment. I would say it differs mainly in funding. Payment implies a market and transactions, and many healthcare systems just don't operate like that. For example, the public hospital system (about 75% of all acute beds) here in NSW doesn't - they are block funded, not paid on a patient-by-patient basis. Attempts elsewhere to introduce an artifical market into a centraly-funded model eg funder-provider split have met with only partial success elsewhere. It is a mistake to assume that the only way to organise the delivery of healthcare is as a market in which services are bought and sold. Allowing 6000 insurance companies to become so firmly wedged between patients and providers was NOT a good idea. The only possible benefit to patients and the common good is risk-mitigation... something that the US govt. is in a MUCH better position to do fairly, and something that commercial health plans have not really given us anyway. In fact risk mitigation by my rules being obviously better than shouldering the full risk, has become the chief subscriber-retention strategy for many health plans. Some people even choose to
versioned parties (was Re: certification and verification ofOpenEHR)
Tim, Data mining and ad hoc queries does not sound out of scope to me. Sounds like a primary use for the EHR-data. 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 tc...@optushome.com.au To: Thomas Beale thomas at deepthought.com.au Cc: openehr-technical at openehr.org Sent: Monday, August 04, 2003 3:23 PM Subject: Re: versioned parties (was Re: certification and verification ofOpenEHR) Alas, the nature of discovery dictates that that one does not always (in fact, rarely) know what questions need to be answered (which statistica) in advance. But making ad hoc queries against massive data warehouses efficient is outside the scope of this list (but of considerable interest to future epidemiologists). Tim C - 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 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.
