I’ve finally finished up the initial release of my first Healthcare on Rails app; hereinafter known as CCRedit.
The application, including all the source code, is available on RubyForge at http://rubyforge.org/projects/ccredit Step-by-step installation instructions (like ya’ll need it ) are available by clicking on the Wiki nav button on the project menu bar. You can be up and running on your desktop or laptop in well under 30 minutes. The RubyForge project summary reads:
CCRedit is a fully-functional Ruby on Rails application that allows a user to create, read, update, and write Continuity of Care Records ( http://www.centerforhit.org/x201.xml ) embedded in PDF-Healthcare files for use in New Patient Registration.
My intent in releasing this is to improve the uptake of Ruby and Rails within the Healthcare IT community. There is a possibility, and not a ‘remote’ one, that the app will become the ‘reference implementation’ for CCR editors (it’s the only one that’s been released open source). With respect to potential uptake in the healthcare community in general, the Biomedical community has been a big user of Perl due to its pattern matching, and we all know that Ruby offers all that and a bag of chips! And Docs in general are notorious hackers. I’m of the opinion that, with just a taste, Rails will attract them in droves. All of which will, hopefully, lead to opportunities for Ruby on Rails developers in this increasingly hot space!
For support, I’ve set up a Google group at http://groups.google.com/group/ccredit/
The project is released under the MIT license which is the same license used by Rails.
I’m very happy to be able to announce this and I hope some of you will find the time to check it out and provide some feedback. Any and all comments / criticisms / suggestions are welcomed. And of course, I welcome you to join in the development effort! The top four items on my list moving forward are currently:
Administration - The lists of items displayed on many of the screens (e.g., the items on the ‘Family History’ tab) is database-driven. First up on my list is a set of admin screens that make it easier to change these. Currently they’re set via the SQL script that creates and populates the tables. (The functionality here implies a need for login and RBAC capabilities. I’m not sure yet what the priority for those will be.)
Google - The ability to fully comprehend the Google CCR-subset will be added.
Templating - The layout of the content on the image in the PDF is table-driven. Figuring out the x-y coordinates for the individual items is very tedious. There’s a need, probably for a separate desktop application, to make the specification of the layout easier.
Selective import - The feedback I’ve had from several physicians re: accepting PHRs indicates the fear of being held liable for knowledge of content they might not even know they’ve received ranks high on the list of reasons not to ‘get on board’. As it stands, CCRedit can easily be set up so that the PDF files it creates simply do not contain the CCR. That is, the only thing the doc would receive would be printed out on their registration form. In the longer term, that’s obviously sub-optimal. I have a design in mind, one I’ve already partially prototyped, that will allow the receiver to specify / limit the content imported.