Greetings!
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.
Best regards,
Bill