Joseph Dal Molin wrote: > Open source efforts/software like OpenMRS, WorldVistA (VistA Office > etc.), OSCAR etc. that are focused on diffusion/uptake and continuous > improvement. All need to have practical tools methods etc. to work > effectively in the heterogeneous health IT ecosystem. Building on Tim's > view: > > >> I believe that with a modest upfront investment one can go a long way > >> toward interoperability. The > >> open source community should be leading in this area, because of the > >> increased cooperation. > > What would that modest investment be? Who would be willing to > collaborate to make it happen? How does a practical approach dance > effectively with and benefit from the vision/work of the > "interoperability" expert community? How can we leverage the OSHCA > meeting in May to help the open source health community take the > leadership role? > > > Joseph > The above quote was from me, not Tim. I don't know if he has the same view or not. The "modest investment" is in the design of a system up front. It always saves time to go through a design process rather than just start coding. The design process involves understanding and documenting the underlying abstractions of the process. This can lead to well-designed interfaces which properly divide up the labor involved more efficient development. It is at this point that one reviews the literature to see how well the interfaces match to existing standards or systems. The collaboration could be in the sharing of the design processes involved in the software development. Get someone from the HSSP community to discuss the interoperability vision and its impact. I don't know how this can take advantage of the upcoming OSHCA meeting, since it is far beyond my means or time to attend the meeting that far away.
Dave > > Will Ross wrote: > >> What a wonderful discussion. I am so glad to have Regenstrief's >> OpenMRS at the table! I also know there are other lurkers out there >> (you know who you are!) who can add to the robust discussion. But my >> purpose here is to highlight one point. Paul, Dave and Tim have all >> mentioned not allowing the pursuit of "perfect" semantic >> interoperability to interfere with simple incremental improvements >> that can be realized immediately. This is in fact one of the >> hallmarks of the decades of dramatic real-world demonstrations that >> Regenstrief has brought to central Indiana. And it is the central >> tenet of the Connecting For Health (USA version) effort to make >> records portable and electronic without requiring a rip and replace >> changeout of all legacy health record systems. And it was one of >> the key points in Andy Grove's "Shift Left" address at Stanford this >> past november. >> >> http://news-service.stanford.edu/news/2006/november8/med- >> grove-110806.html >> >> But we all know this is a marathon, not a sprint. This year's TEPR >> conference is the 23rd annual meeting devoted to the immanent >> transition from paper to digital charting. >> >> http://www.medrecinst.com/conference/tepr/index.asp >> >> Meanwhile, in my rural region of California, 2007 may be the year we >> see adoption of EHR rise above 10% among small practices. The >> arrival of new FOSS projects like OpenMRS can only help improve our >> rate of adoption. >> >> With best regards, >> >> [wr] >> >> - - - - - - - - >> >> On Feb 17, 2007, at 9:24 PM, David Forslund wrote: >> >> >>> Tim Churches wrote: >>> >>>> David Forslund wrote: >>>> >>>> >>>>> I've seen no real >>>>> effort in the open source community to embrace interoperability. >>>>> Certainly interoperability has >>>>> been opposed by much of industry until recently, but there is no >>>>> good >>>>> reason for the open source community to not embrace it. >>>>> >>>>> >>>> Dave, interoperability, although good in theory, is not an end in >>>> itself. Thus you have to ask the question: in the settings in >>>> which open >>>> source health information systems are or are likely to be >>>> deployed, what >>>> are the "business drivers" or the "business case" for >>>> interoperability, >>>> and what sort of interoperability? >>>> >>>> Thus, although there is indeed no good reason not to embrace >>>> interoperability, there may be, in many open source deployment >>>> settings, >>>> no good reason to embrace it, either, given that supporting >>>> interoperability is not without some cost. >>>> >>>> >>> I agree with you, with a caveat. If you plan for interoperability, >>> the >>> cost isn't very high. Adding it >>> later is much more expensive. For the patient, the value of >>> interoperability is very high. Clearly >>> for implementers, the demand for interoperability is not high since it >>> might take away from the >>> local business model. >>> >>>> For example, the COAS specs document is 260 pages long, but if you >>>> go to >>>> the "Interoperation" chapter in it, it refers you to four other CORBA >>>> specifications, each also several hundred pages long, which need >>>> to be >>>> assimilated first. So that's a thousand pages. And that's even before >>>> one works out how to implement all this. That's the cost. So unless >>>> there are strong reasons to do this, in the always-resource- >>>> constrained >>>> world of open source development, it is no wonder it is hardly ever >>>> implemented. >>>> >>>> >>> Have you tried to read WS-Services documentation? It is far more >>> complex than the CORBA specs. >>> Clearly the OMG specs requires an implementer to understand something >>> about CORBA and IDL, >>> but these have been available in book stores for years and there are >>> numerous free implementations >>> around with voluminous tutorials. The discipline of having well- >>> defined >>> interfaces between services >>> is well worth the time invested to understand them. You don't have to >>> read all of CORBA to understand >>> the value of COAS. The UML models contained should go a long way to >>> helping you see the value >>> of the approach and adopting some of the interface principles which >>> would make the implementation >>> of interoperability much easier in the future. And there are >>> implementations that can be studied. >>> >>>>> Sending HL7 messages over SMTP encrypted email is a wonderful >>>>> idea for >>>>> someone who is trying to get the most amount of money for support >>>>> from a >>>>> customer, but has little to do with building truly distributed >>>>> systems. >>>>> >>>>> >>>> Tell that to the people using encrypted SMTP mail. I suppose it means >>>> what one means by "truly distributed systems". >>>> >>>> >>> Of course. I'm speaking of a system that supports the ability to be >>> viewed as a "single" system distributed >>> over a network of machines. P2P is far from a "single" system image. >>> >>>>> I think that one should avoid asynchronous, time-delayed >>>>> coordination of >>>>> updates to the same record in multiple locations. What we have done >>>>> in COAS is to basically provide versioning of a record so >>>>> that all versions are available. >>>>> >>>>> >>>> That skirts the issue of coming up with the currently definitive >>>> version >>>> of a record for analysis purposes, but doesn't solve it. Which >>>> version >>>> should be used when analysing the data? >>>> >>>> >>> There obviously is no way of telling this. This depends on how it is >>> used and the type of analysis. >>> One might want to analyze what changes have occurred in the record for >>> audit purposes. Typically >>> one is only interested in the latest version of a record. If you >>> want >>> an algorithm to create a "new" >>> version of a record based on previous versions, this could be done, >>> but >>> I don't believe there is >>> one good solution to this problem. >>> >>>>> The B-Safer web application in OpenEMed was used in a >>>>> distributed environment. We had very heterogeneous feeds >>>>> (available in >>>>> the clients/translate directory) from a variety of data sources >>>>> (no two alike). Users of the data had views that >>>>> were potentially different for each site. >>>>> >>>>> >>>> Differing views are what need to be avoided (at least eventually, >>>> when >>>> all nodes in a network have caught up with each other). >>>> >>>> >>> Not necessarily. The different views in our case were driven by the >>> security requirements of not >>> being able to see other participants data except in the aggregate. In >>> the GCPR project the views >>> were to be in the form that the user was familiar with. So that a DoD >>> record would take on a VA >>> view when viewed by someone in the VA so that they would see a >>> uniformity of records. And >>> vice versa for a DoD person viewing VA data. >>> >>>>> It does appear that programming languages seem to be the biggest >>>>> barrier >>>>> for this particular >>>>> open source community. Some like Java, some like Python, some >>>>> like PHP, >>>>> etc. That was >>>>> the value of the IDL used in COAS, because it is language >>>>> independent >>>>> and really quite easy to read as an interface (as opposed to >>>>> trying to >>>>> read WSDL). >>>>> >>>>> >>>> If I type "python IDL" into Google, I get hits for Python and IDL, >>>> the >>>> matrix language (like Matlab), but not IDL as in COAS. In other >>>> words, >>>> CORBA support is not exactly mainstream, or even a well-supported >>>> niche. >>>> Neither is openEHR (yet, maybe some day). >>>> >>>> >>> Of course, but IDL is an ISO standard. Frequency of appearance in >>> Google doesn't always >>> mean much since it has a hard time deciphering the context. The >>> OMG IDL >>> is near the top >>> of the list. I'm not sure what this has to do with anything, however. >>> >>>>> It is important >>>>> for interoperability to have interfaces specified in a language- >>>>> neutral >>>>> way, so that, in fact, >>>>> Python built systems can interoperate with Java, etc. >>>>> >>>>> >>>> Well, it depends what the aim is. If clinic A simply needs to >>>> share data >>>> with clinics B and C, and none of them currently have information >>>> systems, then installing the same software in all of them and >>>> using less >>>> general means to share data between those clinics may be the easiest >>>> path to take. Yes, that's short-sighted, but in many places it is >>>> important to walk before you can run. In any case, systems are not >>>> set >>>> in stone - all information systems have a limited life span and it is >>>> wrong to forgo an adequate but sub-optimal system now while >>>> waiting for >>>> a perfect system tomorrow. With open source, you can largely have >>>> both. >>>> >>>> If the aim is to drop software into the midst of a modern large >>>> hospital >>>> in a developed country, then what you say is correct. >>>> >>>> >>> These are certainly the drivers that keep people from sharing data >>> over >>> a larger region. They obviously >>> have merit which is why people have followed them. I agree with the >>> statement, however, to think globally >>> and act locally. The interoperable interface standards can actually >>> make things easier when working >>> locally and prepare one for the future. People underestimate the >>> importance of sharing their data >>> over a wide area. This may be even more important for a third-world >>> country that wants to have >>> remote medical assistance. I don't advocate waiting for the >>> "perfect" >>> system. But using modular >>> techniques with well defined interfaces actually allows one to evolve >>> into the future at a lower cost, in >>> my opinion. Others may not share this view, of course. >>> >>> I believe that with a modest upfront investment one can go a long way >>> toward interoperability. The >>> open source community should be leading in this area, because of the >>> increased cooperation. Unfortunately, >>> it seems to be lagging behind. >>> >>> Dave >>> >>>> Tim C >>>> >>>> >>>> >>> >>> Yahoo! Groups Links >>> >>> >>> >>> >>> >> [wr] >> >> - - - - - - - - >> >> will ross >> project manager >> mendocino informatics >> 216 west perkins street, suite 206 >> ukiah, california 95482 usa >> 707.462.6369 [office] >> 707.462.5015 [fax] >> www.minformatics.com >> >> - - - - - - - - >> >> "Getting people to adopt common standards is impeded by patents." >> Sir Tim Berners-Lee, BCS, 2006 >> >> - - - - - - - - >> >> >> >> >> >> >> Yahoo! Groups Links >> >> >> >> . >> >> > >
