Re: [Gnu-arch-users] EMR EBM EBMgmt

[Thomas Lord]

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