IBM Open Healthcare Framework

drbowen wrote on Friday, August 11, 2006:

Ivan Oprencak of the IBM Open Healthcare Framework (OHF) at Eclipse.org has been working with OpenEMR as part of the OHF.  IBM announced yesterday:

“IBM brings electronic medical records one step closer through open technology.”

Here is the full text:

http://domino.research.ibm.com/comm/pr.nsf/pages/news.20060809_openhealthcare.html

sunsetsystems wrote on Friday, August 11, 2006:

Does this offer any immediate opportunity for us in terms of storing encounter data is a structured and standardized way?  That would certainly impact development of better alternatives to the current hodgepodge of encounter forms.

Rod

drbowen wrote on Friday, August 11, 2006:

I would be interesting to have this discussion with Ivan and his team.

sunsetsystems wrote on Friday, August 11, 2006:

Yeah.  I may be pursuing this project with user-customizable encounter templates, and it would be very cool to use a suitable data dictionary of consult items.

Rod
www.sunsetsystems.com

markleeds wrote on Friday, August 11, 2006:

I thought our modular encounter form system was a good thing.

I think that more people are designing their own forms tailored to their practices than we may be aware of.

sunsetsystems wrote on Friday, August 11, 2006:

Yes but it needs to be a lot easier.  Many docs would like to make their own professional-grade templates without having to hire a programmer (or be one).  I know there’s a “form generator” out there but we need to do better.

Rod
www.sunsetsystems.com

markleeds wrote on Friday, August 11, 2006:

formscript.pl does not require any programming skills.  No more computer skills than are necessary to install OpenEMR.

Still, I totally agree that we need an easy interface for users who don’t want to ever see a command line prompt, or who don’t have access to the server.

Here’s my idea:

First, keep support for the forms we have now.  There’s nothing like a hand-crafted form.  There is no limit to the features and control that can be built into a these kinds of forms.  An easy form building interface will impose limits.

Next, we can have a form building screen that can be popped up from the administration/forms page.  It could be similar to the interfaces used by popular portals like Yahoo to design personalized interfaces (as in my.yahoo.com).  Standard widgets can be selected and placed relative to the existing widgets on the form.

I recommend that these forms not be turned into traditional forms in the forms directory.  They should have their attributes (the types of widgets and relative placement etc…) stored in a database table.  A Form Interpreter can be used to ‘trick’ the system into thinking that these forms are traditional forms.  Data could be stored in a table that will include fields like the following:

form_id
field_name
field_data

or whatever.  Basically, form data would be stored not all in a single record, but over a series of records for each form entry.  This would allow the flexibility to change a form or delete a form without losing usefulness of the data.

So, to summarize, I am proposing continued support for existing forms, and a new form system where form attributes are stored in the database rather than in files and interpreted by new form interpreter code to allow the existing user interface to remain consistant.

I would be happy to do work on this project.  I think we need more discussion, debate, and direct input from more actual users to determine the best course of action.  It’s difficult for programmers and advanced users to have insight into what will be easy for the typical user.  Of course, most registered users on this site are probably advanced.

sunsetsystems wrote on Friday, August 11, 2006:

Mark, your thinking is roughly similar to mine.  And I would not dream of doing away with current forms.

However I’m not ready yet to disocciate clinical data from forms.  If for example we delete a form and expect its data to remain useful, we’re going to need some very sophisticated structuring of that data.  That’s what prompted my initial reply to this topic.

Rod
www.sunsetsystems.com