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 firstname.lastname@example.org
on 2006-02-07 18:23
on 2006-02-07 20:03
It sounds like you want to handle some very sensitive information. I would suggest being very careful how and where you tread.
on 2006-02-07 20:16
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
on 2006-02-07 23:09
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. -