Forum: Ruby on Rails [Possible spam] New project - any volunteers?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Bill W. (Guest)
on 2006-02-07 18:23
(Received via mailing list)
Greetings!  (and apologies upfront for any duplication as a result of my
cross-posting)

It's been five weeks now since I began working with RoR.  My experience
has been incredibly positive.  So much so that I'm emboldened to
undertake a project I'd previously concluded I no longer had the
technical chops to even _start_.  I've included a brief description of
the project below in the hopes that some of you might be interested in
participating.

Best regards,
Bill

----------------------  Project summary --------------------

The initial deliverable, to be released the first week of June, is a web
site that allows healthcare consumers (you and me) to create a personal
EMR (Electronic Medical Record; specifically, a record conforming to the
new ASTM Continuity of Care Record standard) and save it to their local
PC where it can be burned to CD or copied to a USB device to be carried
on their person.  Healthcare providers will be able to use the site to
update it when patients visit to keep it current.

The benefits to healthcare consumers include:
1) Saves time / eliminates hassle (hand the receptionist your disk
instead of filling out all those forms)
2) Helps ensure personal safety (EMT / ER personnel have basic info that
might save your life when seconds count)
3) Delivers these benefits without multiplying the risk to personal
privacy (the way a 'central' database would)

(NOTE: I'm not sure I can have it ready by June, but I plan to provide a
fourth benefit to consumers WRT vastly improved automated search
capabilities for Clinical Trials into which an individual might be
accepted.)

The benefits to healthcare providers include:
1) provides a potential market differentiator WRT attracting new
patients
2) if they already have an electronic medical records (EMR) system, it
will reduce the acquisition cost of new patients in that they will be
able to fully utilize the MR record the patient presents
3) if they do not already have an EMR system, this give them an entry
point that addresses one of the major barriers to adoption: the cost of
getting existing records into the system (patients do most of the data
entry for them)
4) it gets the politicians off their backs ("98% of US physicians now
accept patient's medical records in electronic form" instead of
"Physicians are slow to adopt IT...")

The benefits to the RoR community include:
1) increased visibility of RoR in general (EMRs are a hot topic and I
have plans that will ensure the site gets national attention)
2) introduction of RoR to the medical community, many of whom are
aspiring and/or practicing software developers
3) additional validation of the RoR platform as viable for 'real'
systems.

My plan is to have the software to create and read the data available to
both healthcare consumers and providers in June.  Assuming an uptake,
the need to manage this data will emerge very quickly for both consumers
and providers who do not currently have an EMR system (the vast majority
of physicians in private practice here in the US).  I believe RoR is a
viable platform for an open source solution on that front too, so the
work will continue.

If you have any interest in participating on any level, please let me
know.

Thanks for reading this far.

Bill
removed_email_address@domain.invalid
David Genord II (Guest)
on 2006-02-07 20:03
(Received via mailing list)
It sounds like you want to handle some very sensitive information. I
would suggest being very careful how and where you tread.
Ben M. (Guest)
on 2006-02-07 20:16
(Received via mailing list)
Yeah, before you get too much further you should take a look at the
HIPAA regulations. I'm
no expert, but I think you could be legally liable if your software
violated HIPAA.

b
David M. (Guest)
on 2006-02-07 23:09
(Received via mailing list)
As others have said, I think you may be in for a challenge in terms of
meeting the various privacy and security requirements for this type of
data.

For a start (and I'm no lawyer, nor am I privy to your local laws),
you might need to consider the following:
- how is all the existing information about a patient going to get
into the system?  This is surprisingly difficult; a doctor can't just
hand over this sort of info to a $10/hour data entry person, and most
doctors will baulk at entering large amounts of data into the system
themselves.  Some medical history info may still be kept on paper
cards, particularly for older patients who may have used the same
doctor for 50 years; you might consider this "too difficult", but
older patients are generally going to be those who seek medical
attention more often so they could be your best "customers"
- how are you going to consolidate data for a single patient, from all
the various medical people (e.g. MD, gynecologist, mental health
worker, physiotherapist, urologist, cardiologist, ...) he/she might
have been seeing?  I think you probably need to get at least a
sizeable subset of all the info about a single person for your system
to be a success, otherwise it doesn't offer a compelling advantage
over current systems
- a doctor may need to access information about a patient, but only
with the patient's consent.  How can you do this?
- a doctor may/should be able to access *some* information about a
patient without their consent, in some circumstances (e.g. if the
patient can't communicate, or in a life-threatening situation).  How
can you do this, while supporting the previous point?  How do you
prevent this being misused?
- should a patient be able to update their own medical information?
For example, if the patient starts a course of some diet product that
was bought over-the-counter from a chemist, then voluntarily stops
taking it, probably no medical person will be aware that the product
is no longer being used by the patient.  Can your system support
updates from Joe Public, with all his boneheadedness?  If so, what
liability cover do you have surrounding Joe's incompetence?
- if a patient awards power of attorney to someone else, should that
person be given access to the patient's medical information?  In
particular, if a patient has been granting access to doctors to
his/her information, but is now no longer capable of doing so, can
that ability to grant access to information be transferred to someone
else?  If so, how can you prevent this being misused?
- when a doctor needs to access information about a patient, he/she
may only be entitled to access specific pieces of information with all
else being off-limits.  How will you allow this?
- a doctor may need to update information about a patient; does this
require the patient's consent?  How many places does the information
currently reside in, and who has/should have the ability to update
those information repositories?
- you need to either have, or be able to access, some sort of central
repository about medicines so your system can decide what information
needs to be updated on your system (e.g. "patient is allergic to
penicillin") and what is irrelevant (e.g. "patient was given aspirin
to cure headache")
- if medical records are going to be stored on a patient's PC/USB/CD,
what encryption are you going to put in to ensure the data can't be
used by someone else if they access the PC/USB/CD?
- if this takes off, how will you prevent people aggregating the data
of many patients for marketing and/or other purposes?  There are valid
research purposes for aggregating data, and doctors often are paid by
drug companies to supply suitable data for aggregation (in at least
some parts of the world), so I'd expect this could be a fairly
fundamental requirement of your system if it's going to take off (if
not, how will doctors be compensated for their loss of income from
drug companies?).  What controls need to be in place surrounding
aggregated data?

I looked into doing this a few years back, and concluded that the
challenges surrounding data security/access were too complex - there's
much easier ways to turn a buck - and the likelihood and cost of
litigation was just too high.  Things may have changed since then, and
tools like RoR certainly potentially make the development easier, but
IMHO the development itself wasn't difficult - fully specifying and
then addressing the issues surrounding information access were the
challenge.

Good luck if you decide to go ahead with it.

Dave M.

-
This topic is locked and can not be replied to.