[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] EMR EBM EBMgmt
From: |
Thomas Lord |
Subject: |
Re: [Gnu-arch-users] EMR EBM EBMgmt |
Date: |
Mon, 13 Aug 2007 16:15:26 -0700 |
User-agent: |
Thunderbird 1.5.0.5 (X11/20060808) |
patrick blanchard wrote:
The short list:
I think version control may be useful for Electronic Medical Records
(EMR), and improving patient care by linking Evidenced Based Medicine
(EBM) and Evidence Based Management (EBMgmt). Do you?
My answer is "Yes, but...."
The "Yes" part is things like: revision control audits changes --
something we want for PHRs (personal health records); revision control
involves access control, something else we want for PHRs; revision
control enables distributed (open-source style) development of changes
to PHRs; revision control (in the modern sense of Arch or Git or
Monotone or Darcs or Baz ...) enables distributed data sets so my PHR
doesn't have to be 0wn3d by some singular service provider; revision
control enables change auditing which is especially important when we go
back and try to trace out the reasons for medical outcomes; ... and
lots more...
The "But" part is that we have a "category problem". Revision control
offers all the great things listed in the previous paragraph, and more,
but.... so does the category "global distributed file system". And,
really, neither of those categories intrinsically begins to address (or
even make a good framework for addressing) the domain-specific data
types we expect in PHRs.
So, "version control may be useful" but that may not be the most
immediately useful way to look at it. Maybe we want a versioning file
system, for example. And, anyway, the particular nature of the data
has to be discussed.
Stay tuned. I'm working on defining a new category.
The long list:
In the late 80's I started w/ a proprietary DB for medical charting.
It didn't work. Until 2002 I practiced medicine with paper charts but
changed to a proprietary electronic medical record system based on
Oracle and also served as a beta site for the company. Two weeks ago I
left the software; a buggy bloated front end to Oracle isn't the
answer. Unfortunately, the company is ignoring my request for
developing a sucessful exit strategy from their software (5 years of
3k patient's information suffering from vendor lock). Any Oracle DBA's
out there willing to help? I have what appears to be a 4GB .dmp file
that I was hoping to xfer to MySql so at least not be dependent upon
their front end to retrieve archived information.
In the mean time, I finished a shell script for a Fujitsu scanner that
is working nicely. (see attachement) It's included mainly as an
indication of my scripting ability; it interfaces w/ Hylafax too. I
know C but mainly for microprocessors, and am reading the llama book
(I like Perl, it reminds me of C). And here are 3 websites I run
(dspavr.* 1.net::dspcypher.*1.net::iknomed.*1.com::) //remove the *1
and :: -the last is my personal site. I use SVN mostly because that's
what sourceforge has as an option, along w/ CVS. However, I plan to
install a Arch server later this week.
Frankly, I don't think a relational database is the answer - it's
overkill and adds 2 troublesome layers; one for complexity and another
for skirting other more fundamental problems in the medicine that no
one wants to admit. << more later, if needed.
Perl for a front end (GUI or shell or CGI) and Arch for the backend
sounds like a real possibility. I would like to know your perspective
on the matter.
Thanks,
Patrick Blanchard, M.D.
Board Certified in Family Medicine
Fellow, American Academy of Family Physicians
Hold that thought, for a few weeks, if you will.
You can watch dasht-exp-1a.com for news (and I'll try to remember to
post here). There currently is not any news on that web site. That's
a few weeks away.
Thank you, very much, for bringing the problem domain you are working on
to this table. I'm not quite ready yet to hand you a "magic hammer"
so please don't plan around assumptions of new tools coming to the
rescue right away, from the Arch world --- but thank you so much for
raising and connecting EMR/PHR-stuff to this technology. You're (only
slightly, I hope) ahead of your time in your technical perspective on
that socially important domain -- and I'm working on closing that gap.
And, yes, relational databases in their current commodity form are
pretty heavy components to take on compared to the utility they give back.
-t