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" <[email protected]> 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. 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 EHR components with a > knowledge framework built around that, instead of enormous, > unmaintainable databases and chaotic cross-feeds etc. > > >>can you define this role in more detail to do with EHRs? Do you mean > >>senior medical staff? > >> > >> > > > >CREATORS > > > >The bulk of Patients are handled by staff, some untrained, e.g., admitting. > >They > >(admitting, etc) require automatic, form-based software applications and > >lots of it. > > > >RNs and LVNs carry the load; fewer numbers of doctors do the major work, > >senior medical staff, where present, and chasing funding and performing > >administrative duties. A local county hospital can admit a Patient and setup > >billing but does not know how long a Patient is resident or when they > >actually > >leave. The floor nurse has to check the beds and report on who is in and who > >is out. > > > I guess this is really an argument for a proper analysis of time-wasting > admin procedures, and how better IT systems can reduce the loss and get > doctors back to working with patients. > > >Certainly better than nothing but needing considerably more. The hospital > >Administrator was just involved in a serious controversy because of a budget > >item for an ABSOLUTE BOTTOM-LINE Catscan system (first in the county). > >There will be no computer system connection. > > > >This has been added to show that there are many Practitioners and staff that > >SHOULD be CREATORS but cannot be because of UNAVAILABILITY. > >A local county resident can travel globally with the assurance than NO > >medical > >record could be accessed by any regional, national or foreign Practitioner. > > > I would say that that is the situation for most patients globally... > > There is a lot of other interesting stuff in this post which I'm sure > the list will be interested in chewing over... > > - thomas beale > > > > - > 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
