Hi Tim, > > 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.
Nice to see some other folks struggling with this as well (grin). A strong driving force for our work was an attempt to be as accessible as possible intellectually, without losing technical competency in the process. We want implementers in these developing countries (who often lack PhD-level CS backgrounds, and for that matter are self taught) to learn how to fish instead of being fed. Therefore, we tend to shy away from a lot of the OMG work, for example. My personal bias is that projects such as these can be conceptually beautiful (and I really like to model in these ways), but this often limits those who can contribute in substantive ways. We really wanted to be focus on being inviting to a potential developer, and strive to foster collaboration. :) > 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 assume that by "two-level" you refer to our notions of concept dictionary tables as relationships to observation style tables? Thanks for the reminder on OpenEHR. We've taken a look at this work, and perhaps we should take a look again (we started OpenMRS modeling in early 2004). > > 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/ Sure have. We actually use HAPI as our foundation, however. > 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. We'd relish this conversation. I think our design goals around federation might be a little broader than what you're describing however. In my simplistic view of HIE, it's all about uniquely identifying users, patients (or people depending on your level of abstraction), and concepts to create consolidated patient-centric records across multiple systems. Strong use of standardized vocabularies and dictionary/EAV-based data models take care of concept matching. MPIs take care of the other two. It's plausible that depending on the environment, implementations of OpenMRS will value demographic attributes differently. In fact, we allow implementers to define their own within the framework. That being said, we want to support federating two data sources as if they've completely naive to each other, at least on the OpenMRS side. > 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. That's a kind offer, Tim. I can start by saying that time of the year will be tough for me to make personally, but can likely speak for the rest of the collaborative in saying that we'd love to contribute, but we're almost all academic informatics folks, and are resource-limited. I'm sure if there was a way to offset travel expenses, that Burke or Hamish or one of our core developers might be willing to make the time for this. As a FYI to you, we intend to hold our second annual OpenMRS implementers meeting in Cape Town in mid-April, final date to be determined soon. I'll make sure to share this info with anyone interested sometime soon. The first annual meeting was a great success, with over 100 attendees at the meeting's peak. Folks on this list from Africa in particular are very welcome to join us. Best, -Paul
