My family and I are moving in the coming months. My wife will be attending a new school in the fall. Among the many hassles of moving are locating and transferring medical records to new doctors and clinics. During our time in Minnesota, we've visited several clinics and hospitals, so our medical data is spread across a dozen different networks. Collecting this data is a chore. And reciting it to every new medical provider is frustrating, especially knowing someone else has already typed this stuff into the computer. For obvious reasons, there are many software companies competing in the Electronic Health Record (EHR) industry. I haven't spent much time researching the field, but I have to imagine there is no shortage of bloated standards and next to nil interoperability. With President Obama pushing for electronic health records, this could be an opportunity for the Haskell community to deliver a common framework that the US, and maybe the rest of the world, could build upon -- a longshot I realize. At the core, the fundamental problem is not that complicated. It's just storing and retrieving a person's various health events: checkups, prescriptions, procedures, test results, etc. The main technical challenges are database distribution and patient security. Both are fun problems, and our friends at Galios continue to show how effective Haskell is at building secure systems. Any thoughts? Ideas? -Tom BTW, Anyone looking to rent a house in Eden Prairie, MN? A Haskell employer is just 4 miles down the road (Eaton).
On Mon, Jun 1, 2009 at 11:18 PM, Tom Hawkins
My family and I are moving in the coming months. My wife will be attending a new school in the fall. Among the many hassles of moving are locating and transferring medical records to new doctors and clinics. During our time in Minnesota, we've visited several clinics and hospitals, so our medical data is spread across a dozen different networks. Collecting this data is a chore. And reciting it to every new medical provider is frustrating, especially knowing someone else has already typed this stuff into the computer.
For obvious reasons, there are many software companies competing in the Electronic Health Record (EHR) industry. I haven't spent much time researching the field, but I have to imagine there is no shortage of bloated standards and next to nil interoperability. With President Obama pushing for electronic health records, this could be an opportunity for the Haskell community to deliver a common framework that the US, and maybe the rest of the world, could build upon -- a longshot I realize.
At the core, the fundamental problem is not that complicated. It's just storing and retrieving a person's various health events: checkups, prescriptions, procedures, test results, etc. The main technical challenges are database distribution and patient security. Both are fun problems, and our friends at Galios continue to show how effective Haskell is at building secure systems.
Any thoughts? Ideas?
-Tom
A good place to start is http://en.wikipedia.org/wiki/HL7 , which is a not-for-profit organization which tries to define interfacing standards between medical devices and medical records providers. I haven't worked much with their standards so I don't know how useful they'd be. I think they might be geared towards vendor-to-vendor interop. As for the legacy of people who thought it wasn't complex: http://histalk.blog-city.com/guest_article__repeat_after_me_healthcare_data_... I don't agree with everything the guy wrote, but it's an interesting article. As for knowing how to use the data once you've got it, there were some recent news articles about the Google personal-health-record (PHR) importing billing codes and trying to use them to reconstruct a clinical history to not-so-great effect. And I would say that the security problem is more than a technical problem - the big security issue in medical record interchange is privacy. What data can flow between healthcare organizations? What information can individual organizations restrict access to? How can we get the patient's input in how their data can move between healthcare organizations? Should we? And how should data move to organizations that are both providers and payors? Does it matter? Maybe I'm drifting a bit far afield from Haskell ... Antoine
On Tue, Jun 2, 2009 at 12:12 AM, Antoine Latter
A good place to start is http://en.wikipedia.org/wiki/HL7 , which is a not-for-profit organization which tries to define interfacing standards between medical devices and medical records providers. I haven't worked much with their standards so I don't know how useful they'd be. I think they might be geared towards vendor-to-vendor interop.
As for the legacy of people who thought it wasn't complex: http://histalk.blog-city.com/guest_article__repeat_after_me_healthcare_data_...
I don't agree with everything the guy wrote, but it's an interesting article.
In an industry like this that generates so much data, I think all parties are tempted to record and track as must as possible. But after all the lab results, x-rays, and MRIs, it's the two or three paragraphs of a doctor's dictation that matter. Maybe patients and doctors would be best served if they had an easy way to store, retrieve, and query these dictations. I see this as an abstracting database problem: - records (dictations) are write-once-read-only data pertaining to a subject (patient) - some users (doctors, patients) are allowed to view a subset of records on a subject - some users are allowed to create new records on a subject - some users are allowed to change capabilities of other users Then, built on top of an abstract distributed data storage problem: - a network of computers store a collection of write-once-read-only data chunks (encoded, fragmented records) - chunks are distributed to minimize access time - chunks are distributed to maintain data integrity through system failures Both of these abstract problems can be used for many things outside the medical field. So even if an electronic health record project does not pan out, the code could find its way into other applications. -Tom
Tom Hawkins wrote:
At the core, the fundamental problem is not that complicated. It's just storing and retrieving a person's various health events: checkups, prescriptions, procedures, test results, etc. The main technical challenges are database distribution and patient security. Both are fun problems, and our friends at Galios continue to show how effective Haskell is at building secure systems.
Any thoughts? Ideas?
Actually, it's a lot more complicated than that, albeit not for "technical" reasons. There's a great deal of legislation about what can and cannot be done with medical records: who can have access to them, under what circumstances, how they can be transmitted, stored, etc. This is more than just boilerplate code--- clinics can be audited to prove proper handling and can loose their licenses or worse for improper handling of records. Additionally, the requisite formats do require a lot of boilerplate code since the protocols were defined back in the paper age and medical legislation moves at the speed of mountains. I worked briefly on an open-source database project for managing a medical clinic's records (so, not even for dealing with the public in any way). The technical feat isn't that difficult, as you say, but the human engineering involved can be quite complex--- and the human programming will have major effects on the design, in order to forbid invalid or unacceptable behavior. It's not a project to undertake lightly or without corporate funding. Medical record management is a market that has very low penetration from the F/OSS movement, which in turn places a burden on smaller clinics, so I'm all for anyone who's willing to invest in an open solution :) -- Live well, ~wren
The Dutch government has been trying to get something like this for years; parliament is asking every new minister why the promised heaven has not yet arrived, only to hear that more consultants are needed. I have been to hearings of our parliament and I can tell you such events are extremely informative and make you loose any hope that something good will come out of this soon; there are just too many stakeholders, and no so-called "problem-owner"s except you. Simple questions asked, for which there often is no answer is: - who owns the information? - are you allowed to change information which you own? - should docters pay for the right to enter information in this system, or be paid for the service they provide if they enter information? Instead of trying to change the world you may run a small wiki (I run Twiki) server on your home machine where you just store the information you collect, and enter your information while you are having a consult through your iPhone! When you leave the room you ask your docter whether what you have entered is a correct view of this situation ;-}I think this will solve the major part of your problem, and maybe it opens the eyes of the medical establishment. Doaitse Swierstra On 2 jun 2009, at 11:18, wren ng thornton wrote:
Tom Hawkins wrote:
At the core, the fundamental problem is not that complicated. It's just storing and retrieving a person's various health events: checkups, prescriptions, procedures, test results, etc. The main technical challenges are database distribution and patient security. Both are fun problems, and our friends at Galios continue to show how effective Haskell is at building secure systems. Any thoughts? Ideas?
Actually, it's a lot more complicated than that, albeit not for "technical" reasons. There's a great deal of legislation about what can and cannot be done with medical records: who can have access to them, under what circumstances, how they can be transmitted, stored, etc. This is more than just boilerplate code--- clinics can be audited to prove proper handling and can loose their licenses or worse for improper handling of records. Additionally, the requisite formats do require a lot of boilerplate code since the protocols were defined back in the paper age and medical legislation moves at the speed of mountains.
I worked briefly on an open-source database project for managing a medical clinic's records (so, not even for dealing with the public in any way). The technical feat isn't that difficult, as you say, but the human engineering involved can be quite complex--- and the human programming will have major effects on the design, in order to forbid invalid or unacceptable behavior. It's not a project to undertake lightly or without corporate funding.
Medical record management is a market that has very low penetration from the F/OSS movement, which in turn places a burden on smaller clinics, so I'm all for anyone who's willing to invest in an open solution :)
-- Live well, ~wren _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (4)
-
Antoine Latter -
S. Doaitse Swierstra -
Tom Hawkins -
wren ng thornton