VistA EMR - fly into it with open eyes, a crash will be expensive

VistA is being adopted by many due to the seemingly big benefits of open source. Many a people have asked my opinion before flying into it. I write my opinion here so that people can atleast fly into it with open eyes. A crash later will be very expensive.


First of all let me state that there is no free lunch. Open source doesn't have cost of licenses and it reduces the upfront cost of implementation. However you have to be ready for hidden cost of customization and integration with other systems. Also the cost of open source maintenance and upgrades is prohibitively high unless its spread across multiple implementations. The choice is yours.


VA and Indian health services have many proprietary components integrated with VistA as per local needs e.g. the analytics of Cache database, Ensamble integration engine, CNT for clinical notes and the RIS/PACS. Therefore the open source versions e.g. WorlVistA are at best a sub-set of VA VistA. The difference is stark - compare the standardized packaged milk and the milk from a domestic cow in your backyard.  


VistA was built by physicians so they built a UI [CPRS] for themselves. However surgeons, radiologists, pharmacists, lab technicians and many auxiliary staff have to work on character based screens [roll-n-scroll] of VistA; they didnt get a UI! I guess surgeons were too busy in the theatre when VistA CPRS was built by physicians. Supporters of VistA say that the character based screens actually increase productivity as you have to remember only a few commands that you get accustomed to very soon. However detractors argue that using a character based screen in today's world is like traveling on a bullock cart. 


VistA workflow was built as per VA hospital workflow. Many of these workflows dont match with workflows elsewhere in the world. If you want to adopt VistA, you should be ready to change your hospital workflows as per VistA; you cant do the reverse with VistA. Example1 - In the VA phlebotomist goes to different locations to draw samples from the patients i.e. VistA has only one accessioning step. Whereas this workflow is in conflict with multiple collection points feeding the central Lab and the accession number being generated at the central Lab. Example2 - There is no support for Gynac, Neonatology, Pediatrics in VistA, because VA doesnt treat pregnancies and children. There is no way of attaching the bed of a new born to the mother and treating them together in first few days/weeks of the neonate. This comes in direct conflict with some of the workflows prevalent and predominant in India.


VistA can pose challenges in conforming to privacy of data in some cases e.g. PNDT Act, MTP Act, HIV test. Any physician or nurse can over ride the privacy alert and look at any data in the system. VistA doesnt offer any straight solution to this issue. At best you can do some workarounds to conform to the law.


VistA by design offers analytics on parameters such as problems, diagnosis, vitals and orders. However it's a big challenge to analyse any keywords or data stored in notes because VistA stores the clinical notes as text. 


VistA was built on the proprietary version of Mumps database called Cache. The license cost of Cache offsets the open source advantage of VistA. The cheap alternative is the open source Mumps database called GT.M from Fidelity. GT.M lacks relational database [RDBMS] concepts; the data is stored as objects in nodes. Whereas Cache offers both object oriented and relational views. Without the relational view its a technical challenge to extract the data from the Mumps databse to another RDBMS and vice-versa. In short, GT.M is like the 1970s car whereas Cache is like the latest Jaguar.


VistA requires code changes to make it work on GT.M. Integration component of VistA was written for Cache/Esamble. You have to write new routines in VistA to make it work with any other integration engine. Further code changes are required in VistA e.g. Date format, SSN, VA Labels etc. First you have to invest heavily in making these code changes and then invest heavily in maintaining that code because the code changes have forked you out of the open source VistA.


Having said so much about VistA, let me also state that there is no perfect EMR yet. Your EMR product selection should be based on its merits for your situation. Hire an independent consultant to help you select the EMR. Never select an EMR because a product vendor told you its the best EMR in the world. Select an EMR if its positives outweigh the negatives for you. Let it not be a blind choice.

Setting up an IT Dept. in a Hospital

My article 'Setting up an IT Dept. in a Hospital' has been published in Sep2011 issue of Health Biz India magazine in the Industry Trends section . Republishing it here on my blog for my regular audience.  

Setting up of an IT Dept. in any hospital should begin with Selection of the CIO—the responsibility of the board is to find a Physician Executive with IT experience and appoint him/her as the CIO. IT experts have a much steeper learning curve as a Hospital CIO, therefore should be the second best choice. The hospital board can consider appointing an experienced external consultant to setup and hand hold the IT Dept.

IT Roadmap – To setup the hospital the first and the foremost thing is to lay down the IT roadmap to match with the hospital business needs. IT Roadmap will include the software, hardware, networking projections. Need to factor the transaction load in the short term and projected growth of beds and geographical spread in the long-term. If the organisation will be network of geographically spread hospitals then you need to invest heavily in a remote data centre with cloud based network architecture. Also the software should be able to accommodate multiple sites e.g.  site based MRN, multiple Pharmacies, network of Labs and different state based Tax rules. Whereas you can manage with a sleek in-house IT setup if the hospital is going to be a single site monolithic organisation.

Software – CIO needs to plan the software application portfolio consisting of - HIS, EMR, RIS, PACS, LIMS, Pharmacy system, SCM, MMS, ERP etc. The portfolio should be derived from the IT Roadmap that in turn has to be planned as per the business vision of the organisation. Usually some software already exists that had been procured by some powerful stakeholders or lobbyists. The CIO has a difficult decision of how to use the existing but maybe redundant or obsolete investment or completely go for rip-and-replace. If old software is to be retained then the CIO must plan to open the hood and do a technical evaluation to make sure that the system is not bursting at the seams due to uncontrolled historical changes to the source code or implementation.

The best approach is a monolithic system that does everything from registration – medical records – orders – billing – lab – pharmacy – imaging etc. This system should also be able to take care of support functions such as HR, Finance etc.  However India has very few systems available of this scale. Mostly hospitals have to piece it together. Financial constraints and priorities gravitate the decision towards HIS having limited capabilities at the cost of EMR. Anyhow the CIO must keep EMR with CPOE, CDSS and BCMA in the IT Roadmap and plan for it because you can’t achieve a digital hospital dream without a robust EMR. Also CPOE, CDSS and BCMA go a long way in reducing the medical errors that means a significant cost savings on the admin side.

Interoperability Standards – CIO must plan to adopt all softwares  that comply  with interoperability standards such as HL7, DICOM, X12 etc. CIO must force the vendors to comply or else be prepared to face information silos. Even the home-grown software should be made compliant to interoperability standards. I cannot underscore the importance of this. I have seen massive IT transformation projects fail due to low investment in this area.

Hardware – The hardware requirement is governed by the software portfolio and the IT Roadmap. Usually the high end servers are required for Imaging and real-time EMR. Large disc space is required if the hospital decides to keep the past medical records on the hard disc for many years. The best policy is to shift the records older than 1 year to tape drives and allow a time delay for retrieval on demand.

For EMR with CPOE and CDSS capability the load on the server goes up significantly because every click has to be sent back to the server for processing. CIO should factor a very high end server for such an EMR.

Client hardware has to be planned as per the data input and retrieval needs. Stationary staff should be given desktops. Mobile staff should be given laptops or Tablets. Touch screen tablets are a great way to increase adoption of EMR. However it lays additional pressure on the cost of EMR implementation because the clinical templates have to be built with clickable form elements such as check-boxes, radio-buttons and drop-downs.

The latest addition is smart phones to the portfolio. CIO can consider smart phones for consultants on the move. It’s a great tool to enhance productivity but it also has its own security challenges. There are real risks of breach of data privacy due to loss of phone or impersonation.

Network—LAN/WAN Intranet, Internet and cloud etc. must be planned in advance in the IT Roadmap as per the current load and business growth as per vision. External data centre creates special needs, such that the network has to be fail-proof. MPLS private cloud offers a good choice here.

Network should be planned at the hospital planning stage itself. It is expensive to slit open the walls to put network wires and ports that had not been planned earlier. Also Wi-Fi cant be placed everywhere to cover lack of planned wires.

In a brown-field hospital a CIO must keep the network cabinets locked but also must open the network cabinets regularly to monitor the health of the network cables, routers, switches and racks. Housekeeping loves to use any available space as store or garbage dump!

Data Centre—Data centre can be located in-house with heavy capex or it could be outsourced with a combination of capex and opex or completely hosted on a cloud as an opex. The CIO must decide the model based on scalability and security requirements. In many ways the data centre drives the LAN/WAN network decisions. The challenge of the CIO is to get the best out of it without becoming a captive to the model.

Backup and Disaster recovery strategy—CIO must classify the servers into critical and non-critical. Backup and disaster recovery strategy should be based on criticality of the server. I have seen most of the hospitals underplay the importance of back-up and disaster recovery. This is like term insurance policy. It’s said that disaster doesn’t need someone’s permission to strike!

Services and SLA—Centralised services teams for customer complaint Triage, Level 1, 2 and 3 support with very tight SLAs need to be setup. The CIO must build a governance structure to monitor the SLAs on a weekly, monthly and quarterly level. This could be in-house teams or outsourced. Outsourcing has benefits over in-house because the CIO’s hands are freed-up for strategy and growth of the organisation.

Change management—Large Healthcare-IT projects like HIS/EMR implementation should never be treated as an IT project. The implementation starts failing the day it becomes an IT project. The team doing the implementation should have predominantly healthcare skills with some IT experience not vice versa. The leader of the implementation project should be a Physician Executive with seasoning in IT and Management. These are catalysts for change management. The CxO team of the hospital should use this as an opportunity to drive people, process and technology improvements across the enterprise. The critical success factor is adoption of the Healthcare-IT system.