Paul wrote: > Hi Dave, > > Our API is built around the standard health "objects" within the > OpenMRS data model (ie, person, encounter, order, observation, etc) , > as a way of abstracting out CRUD-type operations to the database. > There are layers of API calls on top of this bedrock which provide > business type functionality (user authentication, medical logic > services, etc). Maybe I'm misunderstanding your question, but > wouldn't "standard" APIs necessitate that the database schemas > underneath those calls are represented the same as well? > > 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. > 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 ). > 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/ > 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. 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 > --- 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 >>> >>> _ > > >
