gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: patrick blanchard
Subject: Re: [Gnu-arch-users] EMR EBM EBMgmt
Date: Tue, 14 Aug 2007 13:16:40 -0500



On 8/14/07, Thomas Lord <address@hidden> wrote:
Mitch Amiano wrote:
> There exists a general market (and a size-able one at that) for
> content management systems which do not deal with code "source as
> lines of text" as it were, but rather as networks of elements inserted
> as XML. The XML provides tree structures through various interfaces,
> mostly but not only document editing interfaces. A quick look at
> http://xml.coverpages.org/healthcare.html shows a plethora of activity
> in this area.

I agree about that market and thank you for the link to what looks a
useful resource.

pb:
yes, although I have not dug to the root of the initiative, and any potential bias (but http://xml... is my first clue). As a Fellow of AAFP, the first link I read was here: http://xml.coverpages.org/healthcare.html#ccr

specifically, some highlights:
The Continuity of Care Record (CCR) is a core data set of the most relevant and timely facts about a patient's healthcare.

Data sets for extensions of the CCR to address such areas as clinical specialties and disease management are not included in the specification.

Whether this initiative has the support of other standards bodies and potential primary and secondary users or if it can be aligned with other efforts, such as the EHR Functional Model, open EHR, the HL7 CDA and so forth remains to be seen.

From my experience, working on the 'core data set' is missing from most if not all EMRs. Many promised it would happen, but it has not yet materialized. EMRs utilizing RDBs are working from the top down and have not yet reached bedrock.

>
> The value to the user, if I can read into Thomas' response, is the
> ability to use the system to query and retrieve on the basis of the
> structures, not just to store and seal it.
>

That's an example of a benefit to the user.    Other benefits of an
XML-based format include:  exchange formats "for free", directly
executable data type (aka schema) definitions (also in XML), generic
stores and processors, etc.   I realize that that list starts to sound
more like "benefits to the programmer" rather than "benefits to the
user" so, another way to say it is that XML-based approaches give
customers a lot of liberty to invent new database structures because,
from just a definition of the new structure, the customer can get a
working database, working exchange format, and to some extent a working
UI pretty much "for free".

The medical record standardization efforts you link to above are a good
example:   domain experts in medicine concentrate on applying their
knowledge to things like translating a paper Continuity of Care form
into an XML type.    Increasingly, we should expect the results of such
efforts to be more and more "directly executable" -- those guys are
doing the heavy lifting of writing entirely new applications.

pb:
Lawrence Weed first published a paper on EMRs in the late 60s.
WEED LL.
MEDICAL RECORDS, PATIENT CARE, AND MEDICAL EDUCATION.
Ir J Med Sci. 1964 Jun;17:271-82. No abstract available.
PMID: 14160426 [PubMed - indexed for MEDLINE]

Later, he wrote a book Medical records, medical education, and patient care;: The problem-oriented record as a basic tool- I read it cover to cover in 1992. In the book, he gave fresh perspective on the linking of medical literature to the patient in the office in front of the physician. Today, he is founder of www.pkc.com

However, there still is not a EMR capable of 'linking' knowledge. Proprietary code and profiteering prevent real progress envisioned by Dr. Weed. I paid a consultant to link www.pubmed.gov w/ a website in my office - because I didn't know how to do it. It works and I think is the information gathering arm of the 2 armed beast of knowledge coupling. But, it remains unlinked from the EMR I was using.

> Doesn't a HIPAA compliant system also have to restrict access on the
> basis of roles and privileges? So you'll need some sort of access
> control lists or other security controls to even get in the door.

It's even worse than that.   To really get anywhere you not only access
controls based on roles and privileges, but you need to innovate a
little bit about how to implement those.    The problem is that, as an
industry, health care needs to learn to maintain widely distributed,
portable records.   Yet, during transport from one end-use to another,
we should expect this data to pass through plenty of untrusted
processes.    Therefore, I predict (not very boldly -- it's obvious),
that standards for encrypting XML content,  standards for signing XML
content, standards for distributed management of "identity", and
standards for managing public cryptography keys are going to become very
important in the near future.

pb:
Security innovations are as old as the hills, but became a software problem when computers developed the capability of partitioning user information (R. Stallman knows this better than anyone).

In the 'real world' trenches of medicine, security of a properly configured LAMP server surpasses "paper" and all EMRs. Security is not the EMR's role, although they think it is. Although GNU/Arch may not provide the security level needed, proper configuration of the LAMP server hosting GNU/Arch can provide more than enough security for HIPPA, and plenty more. In fact, a LAMP server will probably raise the bar for HIPPA as to computer security. IME, opening a MS server to the internet for tech support is risky. Most RDB companies provide their service accross the internet (and it's a booming business). MS Windows is a terrible security risk and I know if first hand. In 2002, tech support logged in and infected my network w/ nimda. I never found the smoking gun, but it was a wakeup call as to what HIPPA really means for binary data; nothing. Frankly, HIPPA amounts to nothing more than simply verifying the user and restricting roles. That's old school for LAMP. HIPPA is not a deal breaker for GNU/Arch.

from the CCHIT website:

CCHIT was founded in 2004 with support from three leading industry associations in healthcare information management and technology - The American Health Information Management Association (AHIMA), the Healthcare Information and Management Systems Society (HIMSS) and The National Alliance for Health Information Technology (Alliance). In September 2005, CCHIT was awarded a contract by the U.S. Department of Health and Human Services to develop, create prototypes for, and evaluate the certification criteria and inspection process for EHRs and the networks through which they interoperate. More information on CCHIT and a list of CCHIT Certified products is available at www.cchit.org.


> One last comment - where's the money for it going to come from?

Are you asking me or Patrick?


Health records are not my primary focus -- I'm aiming for a bigger
target with health records as a potentially tasty application.  I'm
doing "lower level" work that "enables" stuff like health record
applications.

My plan, such as it is, is to try to make money "on the margins" of a
distributed, anarchic build-out of an important new open source
technology.   Right now, the work I'm doing is an investment being made
by fiance and I -- I leverage some of this work for my part-time day job
and we invest some of our household income in my spending plenty of
additional time on this "practical research".  I think that when I
"release early" the open source results,  astute people in the open
source community will likely want to use the code, probably fork it and
improve it on their own, turn into direct-to-customer products of their
own, etc.  By making money "on the margins" I mean that I intend to
charge small amounts for the download of some (GPLv3) components, charge
for documentation downloads, charge for a la carte consultations,
etc.    That's chump change per transaction but, for a family business,
chump change can quickly add up.    Of course, I'll also keep my eyes
open for unique direct-to-customer niches that, by luck, I'm the best
positioned to pounce on, build some equity, sell a company (or just
operate one), and "win big".
This being open source, the "big" investment building out this new
technology is likely to occur (if it does at all, knock on wood), in a
distributed, incremental way.    My job as an open source researcher is
basically just to create the "frame" -- to create the new market for
that incremental, distributed investment by "shaping" the technology the
right way.


-t

pb
I hope you join in... https://sourceforge.net/projects/medsystemsgnu/ , or at least lob some advice when you see me struggle.

5 years ago I dropped 8k into Praxis EMR www.infor-med.com with the understanding that I would be provided 'lifetime' support. For me, that meant 25 years of practice before retirement. That 'lifetime' support has been shifting horizons for the last 24 months and 2 weeks ago, after a hard crash of a dual AMD64 running 4GB, MSwindows server, I was locked out of 5 years worth of patient information. Without getting into the nasty details, I informed my staff to utilize PraxisEMR only for archiving information, and sent the following email to the company..

Hello Mr. Gutierrez,

I am using Praxis only for retrieving archived data and have returned to paper charts again.

Unfortunately, Praxis does not have the capability of printing the entire chart at once; it never has and continues to crash (softly now) when more than one visit is selected for printing. So, as we require the information, it is carefully selected from Praxis and printed for the new paper chart.

As you know, I have over 5 years of paient information archived in Praxis.

Your suggestions for developing a successful exit strategy from Praxis would help.

Thank you,

Patrick Blanchard, M.D.
Board Certified in Family Medicine
Fellow, American Academy of Family Practice


-----Original message-----
From: "Martin Gutierrez" address@hidden
Date: Mon, 06 Aug 2007 08:32:07 -0500
To: address@hidden
Subject: praxis don't open

> Dear Doctor Blanchard,
>
>  
>
> By the time our team got to your practice, your office was closed.
>
>  
>
> Please have your staff call us at 818 592 2900. We'll like if you could
> restart Client 32 on your server and let us know, so we can log in an check
> how is running after the last recovery
>
>  
>
> Warmest Regards,
>
>  
>
> Martin Lucas Gutierrez
> Director of Customer Support
> Infor-Med Corporation
> 6271 Variel Avenue, Suite A
> Woodland Hills, California 91367-2512, USA
> Phone:  818-592-2900
> Email: <address@hidden>
> URL:  http://www.infor-med.com < http://www.infor-med.com/>
>
>  

So, no response, and I don't really expect one, and I'm on my own. Where is the 'lifetime' support?'.

As to my business, it's like yours Thomas, and I hope you the best. Your motive are admirable. FWIW, I donate every now and then, but not near as much as what I recieve in return. Frankly, I don't think MedSystemsGnu will be a money making machine, but thats not its point either. But look at CUPS, and we will never know the details, but someone somewhere is financially better off; http://apple.slashdot.org/apple/07/07/12/1342258.shtml

OK, today when I woke up, a goal of mine was to get GNU/Arch running on a PII w/ 128MB RAM. So, it's back to the salt mines, to round at the hospital and also to finish my paperwork from yesterday's clinic!

Patrick




reply via email to

[Prev in Thread] Current Thread [Next in Thread]