|
| From: | Mitch Amiano |
| Subject: | Re: [Gnu-arch-users] EMR EBM EBMgmt |
| Date: | Tue, 14 Aug 2007 15:16:28 -0400 |
| User-agent: | Thunderbird 2.0.0.6 (Windows/20070728) |
Thomas Lord wrote:
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.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.
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.
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.One last comment - where's the money for it going to come from?Are you asking me or Patrick?
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? 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.)
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
| [Prev in Thread] | Current Thread | [Next in Thread] |