Friday, July 10, 2009

 

A Starting Point

If we are going to look at many code repositories for VistA, then I would like to submit the following model as a feature of discussion:

The boxes marked “VistA Package Development” are code repositories, and there are not just four of them, but possibly hundreds. The VistA Authorities are those agencies/companies we allow to say, “This is good” and “This is not so good”. The good is then scrutinized by clinician input and that is our final step of quality control. At this point, the code is either incorporated into VistA, returned to the authority for further review, or returned to the repository for further development.

This is submitted as a “starting point” for discussion, not even as a “draft” solution.. I do not suspect the final model will look anything like this, but wanted to generate some good discussion on the topic.



Monday, July 06, 2009

 

Electronic Medical Records; Boon or Bane?

One of the “newest” technological gadgets to come into vogue this century is the Electronic Medical Record, or EMR. The EMR is being touted as one of “the” ways to achieve significant cost savings in an industry where prices increases are counted on a daily basis. Contrary to popular opinion, the history of the EMR dates back to July 30, 1965 when President Lyndon Johnson signed into law the Medicare Act. The Department of Health, Education and Welfare (HEW) started a concentrated effort launching the Health Care Technology Division of what was soon to be reorganized as the National Center for Health Services Research and Development (HCTD/NCHSR&D). The current Department of Veterans Affairs, Veterans Health Information System and Technology Architecture (VistA) is an offshoot of that effort.[1] The VistA development has several spin-offs including the Department of Defense Composite Health Care System (CHCS), the Indian Health Service with their Resource and Patient Management System (RPMS) and the nation of Finland’s MUSTI system.

When you look at a software release you are much aware of what version you are running, when it was released, and what type of support you can expect. While most commercial software companies will release numerous “security patches”, their target is the same – to achieve a level of excellence where the product can be sold for a profit. Through the years we have come to expect this as the status quo. Of course, sooner or later you lose support for your software and must purchase a new version, usually just about the time you are getting comfortable with the old one. If you are allied with the medical profession or a student of healthcare informatics, you know that we have been bombarded with a literal pantheon of “medical information” software. Normally, these are excellent ways to handle one or two functions in which their developers specialize. There are systems for lab as well as systems for digital imaging and systems for record management, all available as commercial off-the-shelf (COTS) software. Your purchase of the license guarantees you may run the software on a specified number of machines for a specified amount of time. Given the heightened interest in medical technology today, the status quo looks promising.

Before we dive too deeply into the world of open source software, we need to understand the difference between “open source” and “public domain”. When software, or any creative work, is in the public domain, it is free from restriction. You are free to modify, edit, translate, or otherwise mutilate the original work without affecting anyone. Cornell University has a table of when different works pass into the public domain at http://www.copyright.cornell.edu/public_domain/ which is worth looking into. Since some people are adamant about placing disclaimers, if you wish something of yours to be in the public domain Creative Commons is happy to help with their tool at http://creativecommons.org/licenses/publicdomain/.

Open source means that the author is willing to relinquish access to the source code, with restrictions. These restrictions are:

1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

2. Source Code
The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.


3. Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

4. Integrity of The Author's Source Code
The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.


5. No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of persons.


6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

7. Distribution of License
The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.

8. License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.


9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.

10. License Must Be Technology-Neutral
No provision of the license may be predicated on any individual technology or style of interface.[2]


So as you can see, when software is released as “open source” and given away with no cost, it is not “free” of any restrictions or liabilities on your part. Generally open source work will carry with it a GNU General Public License. These licenses ensure the original code remains intact and any changes are returned to the originator of the code for inclusion and distribution. The great possibilities with open source software are realized through distributed development. A case in point: Microsoft has approximately 1500 – 2000 developers at their disposal working on new versions and security patches to supported versions. Linux, by contrast, has millions of developers spread across the globe. When you download Linux you are not charged for the distribution, but you don’t get any support either.


The reason that open source software, especially in EMR technology, is successful is because of the paradigm shift from “status quo” to “status fluxus”. Open source EMR software developers understand they are trying to hit a moving target, and that the path of the movement is not constant. Therefore, software will be released that “isn’t quite right” or “isn’t quite ready” to be released. The goal of early release is two-fold: First, releasing early shortens development time considerably; and second, it puts the product into the hands of the best product testers in the world – the clinicians. Once a product is released, feedback is actively sought along the lines of, “What isn’t right?”, and “What needs to be changed?” This type of feedback is crucial to developers who are targeted on their customers and clients.


There used to be a saying within the VA that went, “If you have been in one VA hospital, you have been in one VA hospital.” VistA was developed as a “distributed” system, which means each hospital came up with literally hundreds of local modifications to tailor the software into what they needed. Each site’s local modifications were reviewed for incorporation into the national code base. When they were found to have merit they were incorporated.


One of the leaders in open source EMR’s is K. S. Bhaskar, Senior Vice President, Fidelity National Information Services, Inc. Mr. Bhaskar has been a moving force in the development of open source VistA and is currently the Director, President of WorldVistA (http://www.worldvista.org/). In an email interview with Mr. Bhaskar he responded to the following questions:[3]


(RHK) – How do you see GT.M’s replication features enhancing EMR security and recovery from catastrophic failure?


[KSB] – Logical multi-site configurations of VistA allow continuity of business for VistA in the face of not only [un]planned events (such as crashes and catastrophic failures) but also planned events, such as platform and software upgrades. It allows commodity hardware to deliver extreme levels of business continuity.



From a security perspective, look at http://secure.wikileaks.org/wiki/Over_8M_Virginian_records_held_to_ransom%2C_30_Apr_2009 for example. We don’t know how the cracker did it, but I can speculate that he broke in and deleted/encrypted the database and online backups. Presumably they have to either pay him or restore from off-line backups. If they had created a logical multi-site configuration, he would have had to break into multiple boxes to do his deed, and presumably they would be set up differently, with different admin userids, passwords, etc.


(RHK) Do you think VistA will only be commercially viable outside of the open-source arena?


[KSB] That’s a good question. At least with GT.M, our issue in the open source arena has been that it is so robust that many organizations, from clinics to hospitals, use it without support, so our revenues are vary sparse. I think it is different with VistA because you need resources to configure it and manage it. I think the open source business models for VistA (and GT.M and Linux) are still evolving, and it’s too soon to draw conclusions.


Normal software that follows the status quo development model will never be robust enough to keep pace with a medical profession that changes on an hourly basis. Open source technology, such as VistA has the possibility, with its status fluxus development model to get us where we need to go. However, the big stumbling block with VistA is the marketing of open source technology and overcoming the “You get what you pay for” mentality prevalent today. Some companies have been successful with VistA mainly by charging more than was necessary, but enough to give them credibility.


The benefits of open source EMR software and the pitfalls of open source EMR software run very parallel courses. A benefit can be seen in the status fluxus development model that allows software that is “not quite good enough” to be released, and then actively involves all levels of clinical staff in the troubleshooting, upgrading, and patching of the software. One of the biggest pitfalls is that a lot of clinicians don’t want to be actively involved in the software life-cycle process. They want to have what they need when they need it and be free to practice medicine. This attitude is entirely understandable. After all, the reason they spent thousands of dollars and multiple years was to practice medicine, not develop software.


So where do we go to get what we need from either status quo or status fluxus software? The answer is not going to be found in either camp, but rather in a blending of camps and attitudes that will be unique to the medical profession. Just as VistA was developed by the VA (and others) is an excellent example of a comprehensive electronic medical response system, so the VA has managed to bridge the gap between status quo and status fluxus with a new type of medical professional – the Clinical Application Coordinator (CAC). The CAC is that blend of clinician and programmer who stands in the gap between the purest clinician and the purest programmer. They understand the needs of the medical profession and the limitations of the IT profession. While a clinician may need a new application “now”, the CAC understands that software is not produced in one marathon overnight session. Depending on the scope and complexity of the code, the number of disparate systems that must be integrated into the number of queries, reads, and writes, the development process can takes months or years. The biggest benefit this writer has seen to the open source variety of EMRS is the speed in which “parts” of the desired software can be released to the CAC’s for testing and evaluation. This allows the programmers to change course in mid-stream if necessary and more adequately ensures the clinician has the information they need to perform quality medicine.


Where the progress of electronic medical response systems will go in the near future is anyone’s guess, but the impetus is clear – the US health care system is in need of a major overhaul. Major debates throughout the country and throughout all medically associated professions (hospitals, pharmaceuticals, insurance companies and ancillary testing facilities) are heating up just as the Congress is trying to decide what to do. Does open source EMRS software offer a glimpse of the future? Quite possibly. Will some type of technological advance be advocated to help in this situation? Most probably. Does something have to be done? Absolutely definitely.


[1] "History." Welcome to the WorldVistA homepage. N.p., n.d. Web. 19 June 2009. .

[2] Coar, Ken. "The Open Source Definition Open Source Initiative." Home Open Source Initiative. 07 July 2006. 19 June 2009 .

[3] Bhaskar, K. S. "Open VistA on GT.M." Email interview.

This page is powered by Blogger. Isn't yours?