Re: EMR EBM EBMgmt

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.


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



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


> 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