Paul wrote: > Dave, > > Thanks for your thoughts. These discussions can get religious fairly > quickly, so I'll just say that the bottom line for us is a simple one: > we're supporting an open-source collaboration less to meet/support > longstanding specifications that have fairly low uptake to this point, > and more to create economies of scale in our work. We don't have the > luxury of time when it comes to HIV care in Africa/developing world. > If there were tangible reasons to work within these frameworks (ie, we > could insert functionalities into OpenMRS, bring on a team of new > developers, etc), then we'd certainly consider any possibility. > However, it seems like a trap to spend time building on top of specs > for the sake of doing the "right thing". > > >> 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 personally love efforts like the COAS. Intellectually sound, gives > me ideas, etc. I think it starts to falter as a starting point of > work though, b/c of the lack of critical code mass around it. That > combined with the extra inertia involved in following the spec place > it in the position it's in now. We are focused on giving people > something to touch and feel first and foremost, which compels them to > understand the underbelly of how we got there, as they inevitably want > to extend the functionality to meet their specific needs. Another > heart and mind won over in the process. :) > > >> 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. >> > > I follow the HSSP work. In particular, the DSS initiative. > > >> 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. >> > > I'll take a look at OpenEMed. I assume this is your work? :) I work > during my day job, amongst a very large federated repository called > the Indiana Network for Patient Care (INPC), which stores well over > 1.2 billion observations for over 2 million patients. We actually > have aggregated a majority of all inpatient data for the metropolitan > Indianapolis area through a federated, centralized approach which > shadows hospital EMRs into their own standardized database located at > Regenstrief. These shadow repositories are aggregated through a > master provider and master patient index. It's been our experience > thus far, that what's really necessary is less code interoperability > and a greater focus on data interoperability. Differing sites have > differing functionalities and clinical workflows. Therefore we're not > too sure that inertia needs to be spent upon making sure that higher > level system functions are synchronized. Who knows though, we might > be making a big mistake. :) > > Best, > -Paul > > I understand and appreciate your viewpoint. Good specifications can enable the differing functionalities and workflow and still support interoperability. I think more than data interoperability is important. A common Service Oriented Architecture adds significant value and can reduce the cost of data interchange. Some common functionality required by most is an MPI or an Entity Identification Service. This is critical when moving between providers. A record locator service follows right after this. Much has been done in this area. It would be good to see this community contribute to the larger community in this area. OpenEMed has been around quite awhile. It is probably too late for OpenMRS to look at it. It might have been useful to look at OpenEMed when OpenMRS was started up.
Dave
