Tim, --- In openhealth@yahoogroups.com, Tim Churches <[EMAIL PROTECTED]> wrote: > > Paul, > > A question regarding OpenMRS data entry forms. I notice form this wiki > page: http://openmrs.org/wiki/FormEntry_Technical_Overview - that > Microsoft InfoPath is used for form-based data collection in OpenMRS. I > think, and correct me if I am wrong, that means that sites running > OpenMRS need to license Microsoft InfoPath, which is part of the > enterprise version of Microsoft Office, and/or Microsoft SharePoint > Server, in order to serve up InfoPath forms? Is that correct?
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. 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. 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. 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. 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. 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. 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. > 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. > I'm not asking these questions by way of criticism (for use of a closed > source solution) - pragmatism should always win over open source purism > if there is no other way, in my view. I am just curious about how you > arrived at this particular mix of Microsoft and OpenMRS software? We > wrestled with the problem of online forms for NetEpi Collection, and > seriously investigated the XForms standard for defining form layouts, > validation and other runtime behaviour using XML, but decided to ignore > it because a) it was vastly over-complex and b) hardly anyone seems to > be implementing it - Microsoft have Infopath/SharePoint instead, and > others are working on "Web Forms 2.0", which is much simpler (and which > we may eventually adopt). We also looked at Adobe Acrobat, because the > full version of Acrobat allows you to define data entry forms which can > be both printed (for handwritten completion) and/or filled in online, > using the free Acrobat Reader software. I note that STC, which is > probably the largest and best known vendor of closed-source public > health software, uses Adobe Acrobat for its user-defined custom data > entry/paper-based data collection forms. > > In the end, we implemented our own forms engine, which stores > definitions in simple XML documents held in the database. The result is > adequate, but it is not as slick or as capable as we would like, and was > a lot harder to do than we thought. I'm not absolutely convinced it was > the right decision. > > Tim C I hope what I wrote above answers your questions? Best, -Paul
