EMR philosopy w/ financials was Re: EMR EBM EBMgmt

View: New views
4 Messages — Rating Filter:   Alert me  

EMR philosopy w/ financials was Re: EMR EBM EBMgmt

by patrick blanchard-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



On 8/14/07, Mitch Amiano <mamiano@...> wrote:
Thomas Lord wrote:

> Mitch Amiano wrote:
>> There exists a general market <snip/>
>> 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.
>
>
>>
>> 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.
>
OTOH, I would suggest to anyone initiating a project such as was
suggested, be extremely disciplined and NOT be distracted by the
plethora of XML efforts. Choose a path and go down it, with a specific
set of users in mind, possibly even using your own "non-standard" tag
set. Trying to be compliant with everything, nothing will be completing
or it will be so convoluted it is incomprehensible.

An appealing aspect of the DITA XML methodology with respect to the
problem of bridging to different XML tag sets, above-and-beyond using
one-of XSLT transforms, is the ability to cross-translate DITA documents
between domain-specific DITA tags and the more generic Topic types. It
is inheritance: "Topic" in DITA is as "Object" is to Smalltalk. The
exiting DITA-Open Toolkit transformations are keyed off of a kind of
"base-class/instance-of" attribute built-into the stock schemas and
modified in schemas used for specializations.

>
>
>> 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.
>

A few months ago, I applied to NCSU, and was told that I had to be
immunized. Well, I was, but long story short my records consisted of the
doctor scribbling a note on a prescription pad - and it didn't meet the
criteria. So I'm getting shots in my arms, and cursing the doctor, who
has long since passed on. In any case, I'd add to the above, that I
could have trivially forged a document that would have looked perfectly
valid - the doctor, after all, is dead, his office and records gone. So
(a) society is expecting a far higher standard of proof regarding
digital content than what one could possibly expect from a paper trail
and (b) it was primarily my interest that was harmed through the lack of
thoroughness and diligence regarding records management.

They are my records, and while I shouldn't be allowed to falsify someone
else's entries, or muck with some other's version of the same records,
by the same token I should have complete access to the content as it
pertains to me. From that aspect, I think Arch philosophically is
appealing.

Yes, they are your records. HIPPA, and the guarded release of medical information itself is possibly a wolf in sheep's clothing; designed to mitigate legal risk to the business of medicine. Unfortunately your personal experience of financial loss, and exposing yourself to the health risk of repeat immunizations (you did read the potential complications of the immunizations didn't you?) is a common occurance; the identification of it by the patient is not so common however. Can it be traced to the state of medical charting? Not all of it, but it certainly adds mud to the murky water.

>> One last comment - where's the money for it going to come from?
>
> Are you asking me or Patrick?
>
Definitely posing that question to Patrick. I recognize from listening
in on the Arch list that you've been through the wringer financially
while working on Arch.

I'm playing Devil's advocate rather than looking at it as the techie I
am at heart.  Regardless of how many neat open source projects that
could be leveraged to address one aspect or another of medical records
management, it still costs people time, effort, and resources to attempt
such an endeavor. People have to eat; better still if they can pay their
own medical expenses too, and have something left over. I'm not a big
mover and shaker, but I would think it would be best to identify one
aspect or two of the problem that is REALLY PAINFUL to someone with
money, so that you can get them to start transferring capital to you in
exchange for addressing their perception of the pain.

Another way to put it: Patrick, are you viewing this as an "internal" IT
problem, or have you considered the problem/solution in terms of a
business model? 

internal IT problem (I don't like paper, and I don't like current EMRs) -- the 'itch'. As to the business model, it's up for grabs, but I would tend to follow Thomas' thread on the matter. MedSystemsGnu is GPL3.

 Doubtless there is a market for medical records
management for doctor's practices, clinics and hospitals. What about for
the client or families? It would have been worth about a hundred bucks
to me in the case I outlined above, to get a valid immunization record
and avoid the hassle of being poked with a needle. (Perhaps it's about
time someone created a medical records "credit union" as it were, and
separate the ownership of the records from the institutions.)

Where is the barrier? Not w/ you, but w/ the current state of EMRs and paper, and the pervasive philosopy of medicine and sharing information w/ the patient. 'Let's not make it too easy' might be a silent mantra heard amidst hallways of hospitals and clinics. At least the silent mantra sheds some light on a fact of medicine; sometimes the client knows more than the professional and the man behind the curtain is....well...falliable.

>

> 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
>
>
>



_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@...
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/

Re: EMR philosopy w/ financials was Re: EMR EBM EBMgmt

by Mitch Amiano :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

patrick blanchard wrote:
>
>
> On 8/14/07, *Mitch Amiano* <mamiano@...
> <mailto:mamiano@...>> wrote:
>
>     Thomas Lord wrote:
>     > Mitch Amiano wrote:
>     >> There exists a general market <snip/>
>
<snip/>

>
>     They are my records, and while I shouldn't be allowed to falsify
>     someone
>     else's entries, or muck with some other's version of the same
>     records,
>     by the same token I should have complete access to the content as it
>     pertains to me. From that aspect, I think Arch philosophically is
>     appealing.
>
>
> Yes, they are your records. HIPPA, and the guarded release of medical
> information itself is possibly a wolf in sheep's clothing; designed to
> mitigate legal risk to the business of medicine. Unfortunately your
> personal experience of financial loss, and exposing yourself to the
> health risk of repeat immunizations (you did read the potential
> complications of the immunizations didn't you?) is a common occurance;
> the identification of it by the patient is not so common however. Can
> it be traced to the state of medical charting? Not all of it, but it
> certainly adds mud to the murky water.
Yeah. I was due for a booster on one of them anyway, but I felt the
other one was unavoidable.

>     One last comment - where's the money for it going to come from?
>     >
>     > Are you asking me or Patrick?
>     >
>     Definitely posing that question to Patrick. I recognize from listening
>     in on the Arch list that you've been through the wringer financially
>     while working on Arch.
>
>     I'm playing Devil's advocate rather than looking at it as the techie I
>     am at heart.  Regardless of how many neat open source projects that
>     could be leveraged to address one aspect or another of medical
>     records
>     management, it still costs people time, effort, and resources to
>     attempt
>     such an endeavor. People have to eat; better still if they can pay
>     their
>     own medical expenses too, and have something left over. I'm not a big
>     mover and shaker, but I would think it would be best to identify one
>     aspect or two of the problem that is REALLY PAINFUL to someone with
>     money, so that you can get them to start transferring capital to
>     you in
>     exchange for addressing their perception of the pain.
>
>     Another way to put it: Patrick, are you viewing this as an
>     "internal" IT
>     problem, or have you considered the problem/solution in terms of a
>     business model?  
>
>
> internal IT problem (I don't like paper, and I don't like current
> EMRs) -- the 'itch'. As to the business model, it's up for grabs, but
> I would tend to follow Thomas' thread on the matter. MedSystemsGnu is
> GPL3.
So, with an Oracle dump, the first path I would consider is setting up a
Linux box with the Oracle 11g database, and upload your dump. See
http://oss.oracle.com/. Then at least you've got SQL and some basic
tools access to the data for a while while you migrate.

I must have missed something in the discussion. Can you tell me more
about MedSystemsGNU?

BTW, I took a look at the shell script. AFAICT, it looks like pretty
good work, and I've done a lot of scripting. (You misspelled category as
catagory.)

>
>      Doubtless there is a market for medical records
>     management for doctor's practices, clinics and hospitals. What
>     about for
>     the client or families? It would have been worth about a hundred bucks
>     to me in the case I outlined above, to get a valid immunization record
>     and avoid the hassle of being poked with a needle. (Perhaps it's
>     about
>     time someone created a medical records "credit union" as it were, and
>     separate the ownership of the records from the institutions.)
>
>
> Where is the barrier? Not w/ you, but w/ the current state of EMRs and
> paper, and the pervasive philosopy of medicine and sharing information
> w/ the patient. 'Let's not make it too easy' might be a silent mantra
> heard amidst hallways of hospitals and clinics. At least the silent
> mantra sheds some light on a fact of medicine; sometimes the client
> knows more than the professional and the man behind the curtain
> is....well...falliable.
Not to mention the rampant falsification of medical coding. I heard this
narrative recently:
Client, waiting for a blood draw: "What does code XYZ mean?"
Jr. Staffer: "Oh, that's a headache."
Client: "A headache? Why is it listed as a headache? I didn't come in
for a headache."
Jr. Staffer: "Um, I don't know... you'll have to talk to your doctor
about that..."
Sr. Staffer, later, to Jr. Staffer: "The insurance company won't pay for
the actual procedure. So they throw in codes that they know will be
allowed. Avoid talking to patients about the codes."
Wink, wink, nudge, nudge.

I don't pretend to have any such experience in the medical field to be
able to prognosticate about it. But long periods of expansion and
technological growth are often punctuated by major upheavals. I would
wonder rhetorically, if a significant part of the effort being expended
now is really being made with the design to shore up barriers which are
constantly (perhaps increasingly) being eroded by the environment. But
I'm beginning to babble.










_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@...
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/

Re: EMR philosopy w/ financials was Re: EMR EBM EBMgmt

by patrick blanchard-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



On 8/14/07, Mitch Amiano <mamiano@...> wrote:
patrick blanchard wrote:
>
>
> On 8/14/07, *Mitch Amiano* <mamiano@...
> <mailto:mamiano@...>> wrote:
>
>     Thomas Lord wrote:
>     > Mitch Amiano wrote:
>     >> There exists a general market <snip/>
>
<snip/>

>
>     They are my records, and while I shouldn't be allowed to falsify
>     someone
>     else's entries, or muck with some other's version of the same
>     records,
>     by the same token I should have complete access to the content as it
>     pertains to me. From that aspect, I think Arch philosophically is
>     appealing.
>
>
> Yes, they are your records. HIPPA, and the guarded release of medical
> information itself is possibly a wolf in sheep's clothing; designed to
> mitigate legal risk to the business of medicine. Unfortunately your
> personal experience of financial loss, and exposing yourself to the
> health risk of repeat immunizations (you did read the potential
> complications of the immunizations didn't you?) is a common occurance;
> the identification of it by the patient is not so common however. Can
> it be traced to the state of medical charting? Not all of it, but it
> certainly adds mud to the murky water.
Yeah. I was due for a booster on one of them anyway, but I felt the
other one was unavoidable.

>     One last comment - where's the money for it going to come from?
>     >
>     > Are you asking me or Patrick?
>     >
>     Definitely posing that question to Patrick. I recognize from listening
>     in on the Arch list that you've been through the wringer financially
>     while working on Arch.
>
>     I'm playing Devil's advocate rather than looking at it as the techie I
>     am at heart.  Regardless of how many neat open source projects that

>     could be leveraged to address one aspect or another of medical
>     records
>     management, it still costs people time, effort, and resources to
>     attempt
>     such an endeavor. People have to eat; better still if they can pay
>     their
>     own medical expenses too, and have something left over. I'm not a big
>     mover and shaker, but I would think it would be best to identify one
>     aspect or two of the problem that is REALLY PAINFUL to someone with
>     money, so that you can get them to start transferring capital to
>     you in
>     exchange for addressing their perception of the pain.
>
>     Another way to put it: Patrick, are you viewing this as an
>     "internal" IT
>     problem, or have you considered the problem/solution in terms of a
>     business model?
>
>
> internal IT problem (I don't like paper, and I don't like current
> EMRs) -- the 'itch'. As to the business model, it's up for grabs, but
> I would tend to follow Thomas' thread on the matter. MedSystemsGnu is
> GPL3.
So, with an Oracle dump, the first path I would consider is setting up a
Linux box with the Oracle 11g database, and upload your dump. See
http://oss.oracle.com/ . Then at least you've got SQL and some basic
tools access to the data for a while while you migrate.

Is it possible to import the .dmp to MySQL?
 

I must have missed something in the discussion. Can you tell me more
about MedSystemsGNU?

I understand there is a GNU / medical initiative already. However, it seems to be missing something important - maybe a 'view from the trenches' perspective. Anyway, it's just a hunch, but I am not convinced it's the proper direction. There appears to be a lot of 'me-too' approach, not real innovation. If I am going to spend my time and effort on something like this, I don't want to reinvent. This project is going to be costly for me in many ways, but it's a labor of love. I also have been thinking about using a free medical clinic that I established 3 years ago as a testbed. for medsystemsgnu (msg).

BTW, I took a look at the shell script. AFAICT, it looks like pretty
good work, and I've done a lot of scripting. (You misspelled category as
catagory.)

thank you.

>

>      Doubtless there is a market for medical records
>     management for doctor's practices, clinics and hospitals. What
>     about for
>     the client or families? It would have been worth about a hundred bucks
>     to me in the case I outlined above, to get a valid immunization record
>     and avoid the hassle of being poked with a needle. (Perhaps it's
>     about
>     time someone created a medical records "credit union" as it were, and
>     separate the ownership of the records from the institutions.)
>
>
> Where is the barrier? Not w/ you, but w/ the current state of EMRs and
> paper, and the pervasive philosopy of medicine and sharing information
> w/ the patient. 'Let's not make it too easy' might be a silent mantra
> heard amidst hallways of hospitals and clinics. At least the silent
> mantra sheds some light on a fact of medicine; sometimes the client
> knows more than the professional and the man behind the curtain
> is....well...falliable.
Not to mention the rampant falsification of medical coding. I heard this
narrative recently:
Client, waiting for a blood draw: "What does code XYZ mean?"
Jr. Staffer: "Oh, that's a headache."
Client: "A headache? Why is it listed as a headache? I didn't come in
for a headache."
Jr. Staffer: "Um, I don't know... you'll have to talk to your doctor
about that..."
Sr. Staffer, later, to Jr. Staffer: "The insurance company won't pay for
the actual procedure. So they throw in codes that they know will be
allowed. Avoid talking to patients about the codes."
Wink, wink, nudge, nudge.

I don't pretend to have any such experience in the medical field to be
able to prognosticate about it. But long periods of expansion and
technological growth are often punctuated by major upheavals. I would
wonder rhetorically, if a significant part of the effort being expended
now is really being made with the design to shore up barriers which are
constantly (perhaps increasingly) being eroded by the environment. But
I'm beginning to babble.

No, you are  just starting to vocalize something important. I hope you recognize your 'babble' is really thinking, and don't degrade yourself anymore.

Unfortunately, my wife fell ill last year. Not from her cancer, but from a medical mistake. She beat the cancer, but not the mistake; and it's not a subtle one. She required 2 open chest surgeries, chest tubes, and almost died twice. As a physician, I expected openness and honesty from my collegues. Instead I recieved 'we have never seen this before'. It was degrading for me as a professional. It was worrisome for me as the husband of the patient. For example, she was in recovery for open chest surgery and despite seven urgent faxes and phone calls to the specialists, they didn't send her records. It seems unethical now not to try and do the best I can to improve the system. I've learned to trust a 'hunch', even when 'the expert' is degrading it.

As to an upheaval, part of heaving upwards is empowering the masses. I don't know XML, but it sounds like something that could work as a front end. I can't get XML to work and have a hunch the XML initiative may have a hidden agenda somewhere. I can wrap my head around version control, and mesh it with the trench work I've already done w/ sane and Hylafax, and also have a clinic ready and willing for a testbed. Who knows where it will lead. But that somewhere is certainly better than were we are now.

patrick

_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@...
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/

Re: EMR philosopy w/ financials was Re: EMR EBM EBMgmt

by Michaeljohn Clement :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

patrick blanchard wrote:
> Is it possible to import the .dmp to MySQL?

No, it's a proprietary format, close to a raw dump of the internal
storage of the tables in Oracle.  Your best approach is to install
Oracle, import the .dmp, export the tables to a standard SQL text
format, and import that into your database of choice.  (I would
recommend taking a close look at PostgreSQL.)

Michaeljohn


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@...
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/
LightInTheBox - Buy quality products at wholesale price!