David Forslund wrote: > Tim Churches wrote: >> Paul wrote: >>> Part of the challenge our team continually struggles with involves >>> finding that right balance between being pragmatic and creating a >>> framework that's everything to everyone, and potentially smolders >>> under it's own weight. >>> >> Yes, this is an absolutely central problem, and we also wrestle with it >> all the time - the trade=off between specific solutions to specific >> requirements, which are much simpler and quicker to implement, and more >> general solutions to more general requirements, which are much harder to >> design and implement. >> > People may not agree with the COAS effort of the OMG, but this was > exactly its goal and I believe it achieved it. It provides an > underlying basic support for interoperability of medical records. It > doesn't provide all the business logic for healthcare which isn't > required for interoperability.
I was referring to making aspects such as the user interface and business logic as general as possible, while still keeping users happy by providing a slick, fiendly and productive interface and associated conveniences. Inter-system interoperabilty is alo important, but it is only one part of the picture. What OpenMRS (and NetEpi) are about is providing generic meta-applications which can be easily customised, ideally with little or no programming, for particular settings and tasks. Business logic and user interface design is crucial for this - and both business logic and user interfaces ultimately need to be tied into a storage back-end - ideally via abstraction layers. >>> We made a fairly conscious decision for >>> example, not to try to represent the HL7 RIM, as it's been our >>> experience that work in that domain is high on promise but lacking in >>> successful, well vetted implementations. If on the other hand, you >>> believe there's a way to adapt our API approach to be more closely >>> aligned with existing "standards", yet allowing us to continue our >>> EAV, concept modeling approach to repository design, I'd love to hear >>> your thoughts. >>> >> The openEHR model is probably relevant - it can be viewed as a more >> evolved form of the "two-level" model which OpenEMR (and the Regenstrief >> Clinic for several decades before that) uses. The openEHR people have >> put forward their work as the basis for an ISO standard - only a >> proposed standard at this stage. There is a java-based open source >> openEHR kernel currently available, but it is still in beta or >> incomplete (I think), and there are some other open-source tools for >> working with openEHR archetypes, but relatively few people have much >> experience with this technology and those that do have not published >> descriptions of their experience except anecdotally (eg "it seems to >> work"). So, openEHR has promise but it is a rather untrodden path at >> present, and a complex and twisting one at that with steep (learning) >> hills (curves) along the way. We are keeping a watching brief on openEHR >> for potential use in our NetEpi suite of public health/epidemiology >> tools (see http://www.netepi.org ). >> > I should note here that the COAS model supported the GEHR model which > was the predecessor to OpenEHR. It specifically took into account in > the standardization process. I still believe that a COAS interface can > be used with OpenEHR, but I don't have the time to actually demonstrate > this. COAS has been shown to work in fairly interesting situations > including epidemiology. Our implementation is available, of course, as > open source. What is curious is that there have been, so far, no other > open source projects which have attempted to follow this > interoperability path even though an open source example of it has been > out there for more than 7 years. After finally locating the COAS documents (with Dave's help), I read them about 18 months ago but found them impenetrable and rather complex - perhaps most people are, like me, too stupid to be able to follow the COAS example? The openEHR stuff I can follow, just. And since no-one else (except Dave) was doing COAS, I didn't think we should either - there are very strong network effects (as in http://en.wikipedia.org/wiki/Network_effect ) with these things, or in COAS's case, anti-network effects. >>> Today, our vision of interoperability is through standard HL7 >>> messaging, and web-services where they make sense. >>> >> That seems sensible. Have you looked at Mirth? http://www.mirthproject.org/ >> > Messaging is fine, although using HL7 for interoperability has its > issues. I think a service oriented approach is much more powerful and > provides a stronger layer of interoperability. It is this approach that > is being used in the HSSP effort: http://hssp.wikispaces.org as a joint > effort of HL7 and the OMG. To vastly oversimplify it, the HSSP effort is > taking the PIDS/COAS specifications and updating them to the current > popular technologies. There are RFP's out there that people could join > in to help set these standards. Yes, NEHTA, the top-level e-health authority here in Australia, is heavily promoting a web services approach, although many people are getting on perfectly well with HL7 messaging over encrypted SMTP e-mail, using HL7 ACK/NACK at various levels for handshaking to ensure reliable delivery (or notification of non-receipt). It has the advantage of using ubiquitous, well-understand services (SMTP/POP3 email, as provided by thousands of Internet service providers or by one's own off-the-shelf Linux system), and it works well over intermittent or unreliable networks. Not that I am a fan of HL7 - actually, I regard it as a dog's breakfast (functional, after a fashion, but terribly inelegant). And in practice HL7 2.x is more a point-to-point interface because ever application adopts its own interpretation of the HL7 standards - so heaps of message format and semantic "debugging" is always needed. But I've learnt that if you don't use HL7, no-one else wants to talk to you... Dave, how well do Web services handle intermittent (eg dial-up, wireless and/or very unreliable) Internet connections with very long latencies and low bandwidths, compared to simpler message-based systems? Most developing countries and rural areas in many developed countries only have very poor connectivity, sometimes having to fall-back to sneaker-net (eg floppy discs or memory sticks carried by hand or by physical snail-mail between systems). >> >>> Those who want to >>> extend our code functionality will be able to do so through "modules" >>> which are code extensions ala Firefox. >>> >>> Federation is rising higher on our lists as an important feature of >>> the platform. People are needing this functionality within >>> implementations. From our perspective, the secret sauce to make that >>> happen is robust person matching algorithms between systems, as we >>> already have the capability to link OpenMRS medical concepts to >>> standardized vocabularies. That being said, we are in the planning >>> stages (as of literally the past 3-4 weeks) to add statistical >>> matching algorithm functionality to our framework. Some of my >>> colleagues @ Regenstrief have a lot of experience in that space, and >>> are interested in adding that to our code base. So stay tuned, but as >>> it stands right now, federation could be achieved if MPI functionality >>> was in place. >>> >> > I should mention that federation with COAS/PIDS was designed in from the > beginning and has been > demonstrated for quite some time now. The implementation of COAS that > OpenEMed has includes > the capability of having dynamic data collection without changing the > underlying database schema. > The key issue in federation is to be able to federate across > heterogeneous systems that all utilize > an interoperable set of interfaces. PIDS/COAS can be significantly > improved on (and will be shortly), but > they provide an excellent example of how to go about this and shouldn't > be ignored. Is there a demo system and some brief documentation or reports on this which we can look at? Would be interested in studying how it works, but only if I don't have to read Java source code. It is asynchronous, time-delayed co-ordination of updates to the same record in multiple locations that is the big issue for us. Tim C >> Yes, we also see federation as a key issue. Basically, we think that >> NetEpi needs to be able to operate as a multi-master federated database >> (i.e. any record can be created, edited or deleted on any node of the >> federation), but over potentially low-band and very low reliability >> network links (i.e. subject to frequent and prolonged network >> partition). Furthermore, all this needs to be tightly integrated into >> the application so that update conflicts can be handled nicely. The >> ability to dynamically evolve (on-the-fly) data collection forms and >> other aspects of the database schemas is also a large added >> complication. We have some ideas, proven in practice in other, >> non-health settings, about how to tackle these challenges, but think >> there is perhaps 6-12 person-months work in it to get it to >> production-ready stage - it is very complex. Would be happen to exchange >> ideas with members of the OpenMRS team on this. >> >> Finally, can someone from OpenMRS give a presentation atteh OSCHCA >> conference in Kuala Lumpur in may 2007? I suggested OpenMRS as a >> potential conference topic to the organising committee, and I am sure >> they would be delighted if someone could talk about it. >> >> Tim C >> > > Dave >> >>> --- In [email protected], David Forslund <[EMAIL PROTECTED]> wrote: >>> >>>> Paul, >>>> I have a question as to the interoperability of OpenMRS. At what >>>> level can or could it interoperate with other systems? It seems to have >>>> its own API rather than some of the "standard" APIs out there. This >>>> information says that OpenMRS isn't another "stovepipe", but only talks >>>> of how others can use it as a building block for their system. It is >>>> clearly >>>> open, but this alone doesn't mean that it is interoperable with other >>>> existing >>>> systems. In addition, can it be used in a "federated" environment where >>>> information is linked together from a variety of locations? >>>> >>>> Thanks, >>>> >>>> Dave Forslund >>>> >>>> Paul wrote: >>>> >>>>> I stumbled across this mailing list in my Google travels, and I >>>>> thought I'd drop a quick note to you all, as you seem like likely >>>>> allies in the type of work our group is fostering. I'm one of the >>>>> co-founders of the OpenMRS (http://www.openmrs.org >>>>> <http://www.openmrs.org>) collaborative, and >>>>> we're always looking for folks interested in creating HIT >>>>> infrastructures for developing countries. Here's a quick overview of >>>>> our project: >>>>> >>>>> ------ >>>>> >>>>> I. What is OpenMRS? >>>>> Our world continues to be ravaged by a pandemic of epic proportions, >>>>> as over 40 million people are infected with or dying from HIV. The >>>>> vast majority of these people (up to 95%) are in developing countries. >>>>> The severity of this pandemic necessitates rapid, coordinated efforts >>>>> toward HIV prevention and treatment which rely upon efficient >>>>> information management. In 2004, researchers at the Regenstrief >>>>> Institute (http://www.regenstrief.org <http://www.regenstrief.org>) >>>>> served as consultants to scale >>>>> up a pre-existing MS Access®-based HIV management system within >>>>> western Kenya. Their response was to begin the design and development >>>>> of the AMPATH Medical Record System (AMRS). >>>>> >>>>> When work on this project began in earnest, the team investigated >>>>> other "best of breed" solutions. It became clear that the >>>>> overwhelming need for basic clinical data management (often to provide >>>>> outcome data to funding agencies) along with the needs for rapid >>>>> solutions in the face of limited technical resources typically led to >>>>> disparate, "stovepipe" efforts which often stored computer >>>>> uninterpretable clinical data that rarely scaled well in both size and >>>>> functionality. To combat these common shortcomings, the AMRS team >>>>> evolved their early work into a collaboration with Harvard's Partners >>>>> In Health (PIH) initiative (http://www.pih.org <http://www.pih.org>). >>>>> The product of this >>>>> collaboration, OpenMRS (http://www.openmrs.org >>>>> <http://www.openmrs.org>) represents an earnest >>>>> attempt to create the foundation for collaborative medical record >>>>> system development within developing countries, by serving as a common >>>>> foundation and set of open-source "building blocks" from which >>>>> fledgling implementations can begin constructing health information >>>>> systems. >>>>> >>>>> II. Who is OpenMRS for? >>>>> OpenMRS is for people that need to implement medical record systems. >>>>> It is a scalable health-centric database design, a Java-based library >>>>> of API calls to this schema, and a default implementation of those API >>>>> calls in the form of a web application. It has also evolved a modular >>>>> architecture which provides third party developers with a framework to >>>>> customize extended functionality of this base architecture. >>>>> >>>>> III. How much does OpenMRS cost? >>>>> OpenMRS is a free program, and the source is released under a close >>>>> equivalent of the Mozilla Public License. >>>>> >>>>> IV. Where is OpenMRS being used? >>>>> OpenMRS is currently implemented in Kenya, Rwanda, South Africa, >>>>> Uganda, amd Tanzania. Further implementations are underway in multiple >>>>> other locations throughout Africa through the work of such groups as >>>>> the Millenium Village Project and FACES. Over nine million discrete >>>>> observations have been collected for over 42,000 HIV patients with >>>>> over 450,000 encounters within the AMPATH implementation in Kenya. >>>>> The MRC team in South Africa is leading the effort to form an >>>>> implementers group to aid in further implementations. >>>>> >>>>> V. Why should I use OpenMRS? >>>>> At this stage, OpenMRS requires fairly sophisticated awareness of how >>>>> to install and develop medical record systems. It is not a >>>>> shrink-wrapped project, by design. However, teams in several >>>>> developing countries are in various stages of implementing OpenMRS at >>>>> this time. To serve less technically inclined future implementations, >>>>> the collaborative is working toward a pre-built implementation that >>>>> would allow more clinic sites to take advantage of a sophisticated, >>>>> scalable system without needing the expertise to maintain and support >>>>> and this work at low levels. OpenMRS is driven by a concept >>>>> dictionary, allowing for the collection of coded, reusable data >>>>> without requiring changes to the data model. Furthermore, OpenMRS has >>>>> not been developed with exclusive notions of providing only HIV care, >>>>> so it can be adapted for use in tuberculosis, malaria, or general >>>>> medical care. Finally, OpenMRS is based upon the cumulative >>>>> experience of over 40+ years at Regenstrief Institute, international >>>>> leaders in the development of medical information systems within the >>>>> United States. >>>>> >>>>> ------ >>>>> >>>>> We would love to hear from folks, in particular who have the following >>>>> skill sets: >>>>> >>>>> 1) database performance optimization >>>>> 2) OLAP / reporting database design >>>>> 3) Hibernate ORM >>>>> >>>>> Additionally, new Java programmers are always welcome to join us. I >>>>> hope to be able to contribute to your conversations in the days to >>>>> >>> come. >>> >>>>> Best, >>>>> -Paul >>>>> >>>>> --- >>>>> Paul G. Biondich, MD, MS >>>>> Investigator, Regenstrief Institute, Inc. >>>>> Assistant Professor of Pediatrics / Informatics >>>>> Riley Hosptial for Children / IU School of Medicine >>>>> E: [EMAIL PROTECTED] <mailto:pbiondich%40regenstrief.org> >>>>> O: 317-278-3466 / 317-630-7070 >>>>> >>>>> _ >>>>> >>> >> >> > > >
