Paul wrote: > Well, yes.. we have a module within OpenMRS that allows data entry > using Microsoft InfoPath client. However, we're using the client > that's a part of any base Microsoft Office install. From our > perspective, that was as close to commodity software as you could get.
OK. I wasn't sure about this because I have the full Australian version of Microsoft Office 2003 installed on my Windows box here at home, and it doesn't include any InfoPath client - so when I try to access a data form on the demo OpenMRS system I just see the InfoPath XML form definition, not a rendered form. > Why do we use InfoPath alongside OpenMRS? A little background might > be helpful. In short, we're big fans of the MVC design pattern. In > our data model, you've maybe understood the concept dictionary > approach, but you might not have noticed our "form" objects. No, that's the first thing I looked at, as it is the issue that has vexed us. > In our > world, a patient has 1 to n encounters, and within each clinical > encounter, 1 to n "forms" can be collected. Forms are merely > collections of data, made up of 1 to n fields. Each field points to > a concept in our system. That's almost identical to the data model used in NetEpi Collection, except that instead of "encounters" each patient/person has zero or more "cases" or "syndromes" (with associated case definitions). But each case in a person has zero or more forms of different types associated with it, in either a 1-to-1 relationship or a 1-to-many relationship. We also capture the relationship between cases and their contacts (since the focus is communicable disease outbreaks), but that is analogous to the Relationships entity in OpenMRS. We don't have a concept dictionary, however. We did think about it, and have implemented such a thing (called a "metadata database") for our population-based computer-assisted telephone interview survey system, but the communicable disease people didn't want to be constrained by a concept dictionary. However, we plan to retrofit one, which will use SNOMED CT as well as LOINC and local concepts. That is, if openEHR doesn't become a viable option first, as it promises to handle much of this (i.e an evolvable "concept dictionary" with constraints etc, and terminology bindings, all drivig data storage and retrieval. > We've abstracted out these notions for > storage in our repository, so that we can render these forms using a > number of different data entry mechanisms, perhaps even > simultaneously. IE, web page, OCR'ed form software, PDAs, etc. Our > first, most pressing data entry need was through our web interface > however, so we went down the path of looking at open source MVC-based > data entry techniques. We naturally zeroed in on XForms. > Unfortunately, XForms technology is still quite green, and > implementations are either feature poor or just don't feel right. Xforms is a quagmire best avoided. > Microsoft InfoPath, however.. is pretty damn impressive. InfoPath > can take form schemas that we render in XML, and the application > allows one to both render style sheets for the user interface around > these schemas (complete with constraints around the metadata we > define in our dictionary) and then additionally serves the client > rendering engine that works seemlessly with the browser experience. > What does InfoPath generate upon completion of a form? Believe it or > not, clean XML... which we convert to a HL7 R01 message. We're > really happy with it, and are eagerly awaiting another open source > product that has these InfoPath-like features. OpenOffice has some > early signs of this functionality, so we're looking forward to that. OK, interesting. As far as I can work out, here in Australia InfoPath is only available as part of a Microsoft "enterprise agreement", which in turn is only available to very large companies, if they chose to go down the Microsoft-everywhere-for-everything path. Certainly the consumer, small business and educational versions of MS Office don't include InfoPath here in Oz, so hardly anyone has seen it. I'd be interested in seeing it in action, but not sure how. > I'd be happy to set you up with an example of this if you have > interest. We've used it for tens of thousands of direct data > captures from paper forms in Western Kenya, and the data entry team > loves it. Ok, most interested. > Once again, we made conscious decisions to compartmentalize > proprietary software solutions for specific uses, and have built with > full anticipation that an open source equivalent could sweep in and > replace it. Ideally, we just let people choose the data entry > mechanism they like best. > >> Or do >> users need to have an InfoPath "runtime" package installed on their >> (presumably Windows-only) client workstations? > > Yep, that's all that's required. MS Office 2003 needs to be > installed (along with SP2), and OpenMRS data entry functionality with > InfoPath works. OK, seems like that only applies in some countries. >> Or is OpenMRS just using >> the InfoPath form layout XML format, and provides its own form > engine to >> interpret and render those XML form definitions on users' computers? > > Nope, we let InfoPath do what it does best.. render XML forms and > provide a rich end user experience around this functionality. > They've done it right with this product, and the OSS community will > pick up on this soon enough. Hope so. In the meantime, looks like we need to keep enhancing our own forms interface in NetEpi. AJAX-enable Web Forms 2.0 stuff looks promising, though, and all you'll need is a recent Web browser. Trying to get users to install OpenOffice is a not really an option for us - too many widely flung users in too many disparate locations. > I hope what I wrote above answers your questions? Yup, thanks. Tim C
