Healthcare-IT outsourcing is different

Offshore outsourcing in Healthcare-IT or eHealth is very different from any other industry vertical. However many IT companies tends to treat it as just any other vertical.

Reasons why Healthcare-IT outsourcing is different:
1. Healthcare and IT knowledge needs to exist in the same brain and needs to be processed together by the same processor. The idea of putting a Domain expert with IT team doesn’t work in Healthcare because Healthcare experts talk Greek and Latin jargon which IT folks don’t understand.
2. Way of thinking is very different between clinical and engineering disciplines. Clinicians think in terms of lists and rule-out one by one to reach a decision. Intuition developed with experience plays a vital role in decision making. Whereas engineering discipline thinks in terms of 2-by-2 tables and makes decisions based upon numbers from hard data. Intuition developed with experience has no place in engineering disciplines.
3. Doctor-Patient relationship is like that of Priest-Disciple relationship completely based upon trust. You remove the trust factor and no patient will ever want to go under the knife of a surgeon no matter what quality standards are applied.
4. Cost of the Healthcare is Bourne by the payer [Employer, Insurance or Govt], whereas the benefits go to the patient. The payers believe that increase in productivity will pay for the cost of healthcare in the long-term; however this has never been proved. In other words, Cost of Healthcare goes in one direction and the benefit goes in opposite direction. This is exact opposite of what happens in any transaction based industry.
5. Management principles like 80-20 rule don’t apply to healthcare. Hospitals earn 80% of their revenue from 20% of the investments. Rest 80% is spent for treating diseases that provide 20% of revenue. Any other industry will optimize on the non-performing investments and save lot of costs, but the hospitals can’t ignore these non-performing investments else morbidity and mortality will shoot up.
6. Healthcare-IT has developed over a period of time where the systems are developed in wide variety of technologies and they don’t talk to each other.
7. Old systems don’t have any documentation and common sense doesn’t work in understanding the logic because the keywords are Greek and Latin.
8. Most of the knowledge is stored in the heads of old employees working on the systems
9. Systems are mission critical and need to be up 99.99% of the time.
10. No one can ever document all the requirements 100% at the beginning because doctors know only small% of the human body and rest is guess work.
11. Processes in a hospital are dynamic and change at the drop of a hat. In emergency doctors need to take over everything outside the system and then the system have to catch-up post-facto
12. Doctors and nurses are ubiquitous in the hospital setting and can be giving orders anywhere in the hospital. The orders are executed almost simultaneously. Therefore little time to switch between order entry system and order fulfillment systems!
13. Learning and absorbing the Healthcare knowledge takes time. Therefore quickly training the IT resources in healthcare domain knowledge and deploying them on Healthcare projects is seldom useful. Also rotation of IT resources is not possible because you need to lock the Healthcare trained IT resources for next similar projects. Healthcare-IT resources continue to increase in value with every cycle.

What is EHR?

EHR is the larger umbrella that covers all Healthcare-IT systems that store or help in storing healthcare records. Examples of systems coming under EHR are Hospital Information Systems (HIS), Electronic Medical Records (EMR), Clinical Information Systems (CIS), Patient Medical Records (PMR), Lab Information System (LIS or LIMS), Radiology Information System (RIS), Picture Archival and Communication System (PACS) etc..

Healthcare Records is a vague term and has many meanings derived out of it. To my mind it means all Health Records of patients from cradle to grave and beyond. If these records are stored in electronic format then its called a EHR. EHR could be created by collecting the primary data at the point of care, Lab, Pharmacy etc. and/Or EHR could be created by scanning old paper based records and keeping them for future reference.

Secondary data derived by analysis of primary health records also keeps getting added to the EHR once created. Examples of such secondary data are disease trend analysis for the chronic diseases such as Diabetes or Hypertension.

Reports generated by Evidence based medicine also get added to the EHR. Also population level epidemiology analysis is an anonymised view of the EHR.

The effective use of information technology is a key focal point for improving healthcare in terms of patient safety, quality outcomes, and economic efficiency. A series of reports from the U.S. Institute of Medicine (IOM) identifies a crisis of "system" failure and calls for "system" transformation enabled by the use of information technology. Such a change is possible by "an infrastructure that permits fully interconnected, universal, secure network of systems that can deliver information for patient care anytime, anywhere. A critical foundational component for resolving these system and infrastructure issues is the Electronic Health Record System (EHR-S).

The IOM's 1991 report, The Computer-Based Patient Record: An Essential Technology, and updated in 1997 (Dick, R.S, Steen, E.B., & Detmer, D.E. (Editors), National Academy Press: Washington, DC) defined an EHR System as:

• The set of components that form the mechanism by which patient records are created, used, stored, and retrieved.
• A patient record system is usually located within a health care provider setting. It includes people, data, rules and procedures, processing and storage devices (e.g., paper and pen, hardware and software), and communication and support facilities.
  

The 2003 IOM Letter Report, Key Capabilities of an Electronic Health Record System, defined the EHR System as including:

• Longitudinal collection of electronic health information for and about persons, where health information is defined as information pertaining to the health of an individual or health care provided to an individual
• Immediate electronic access to person- and population-level information by authorized, and only authorized, users
• Provision of knowledge and decision-support that enhance the quality, safety, and efficiency of patient care;
• Support of efficient processes for health care delivery
  

The 2003 ISO/TS 18308 references the IOM 1991 definition above as well as CEN 13606, 2000:

• A system for recording, retrieving and manipulating information in electronic health records.

In developing the EHR-S Functional Model, HL7 relied on three well-accepted definitions: two provided by the U.S. Institute of Medicine and one developed by the European Committee for Standardization/ Comité Européen de Normalisation (CEN). This Functional Model leverages these existing EHR-S definitions and does not attempt to create a redundant definition of an EHR-S.

Thick client vs Thin client

HIS/EMR applications have evolved from modular systems existing at departmental levels. Integrated HIS/EMR applications came up when the thought process evolved to entrprise level. Integrated HIS/EMR may have a single database at the backend or extreme modular design where each modulae has a separate database.

Obviously the front-end UI has also evolved in the same way. Mostly its an extreme modular design where each module has a separate UI. Some HIS/EMR offer an integrated UI and others even allow integrating thrid party applications under their portals. We have very few examples of Monolithic design with single database at backend and single front-end UI and shared services in the business layer.

All these systems were designed for client-server environment to work within an enterprise. The need for looking at the healthcare data from outside the enterprise wasnt felt till internet became prevalent and healthcare professionals started using mobile platforms too.
Thick clients do a wonderful job in Client-server environment, Where the front-end is rich in personalisation features and offers extra security in terms of allowing a user to login only from his/her desktop. The response time for data intensive applications is very good since its located within the enterprise and bandwidth isnt an issue unless concurrent users exceed the planned load.

However Thin client concept came with the internet paradigm where people wanted to look at everything through the 'Single Window' browser. Thin client within the enterprise works in the same way as a Thick client. Personalisation, CRM, security feautures etc have been pushed to the middle business layers of the application.

Now due to the eveolution of thought, healthcare professionals started demanding the availability of Thin client over a browser from anywhere outside the enterprise as well. This raises some pertinent issues such as security, turn-around time, data throughput. Large data intensive work slows down the response time e.g. hitting the database often for CPOE or getting the medical images. This is a challenge outside the enterprise, due to limited bandwidth. Some solutions are available, but there isnt a perfect solution yet.

Thin client thought process gets even more difficult to put in reality when you want to put it onto the small screen of mobiles and PDAs. Again there is some success but lot is left to achieve.

An extreme case of Thin client is to host the entire HIS/EMR on a central server and offer it as a service to clinicians and hospitals. However this model requires a lot of bandwidth and good security to be built into the system. Also the clinicians and hospitals have to trust the system for safe keeping of their data. From a business stand point this reduces to capex of the hospital or clinicians and they pay only as per use. The capex burden is shifted to the application service provider.

Revenue Cycle Management - Hype

As per me Revenue cycle management is another hype created by general purpose MBA consultants who have no idea about Healthcare. Its another hype just like HIPAA.

Healthcare system is focused on clinical, lab, rad operational issues. The IT and Consulting budget of a hospital cant be more than 10% of the total outlay; this mostly falls short for the core IT issues such as HIS/EMR/EHRS and clinical, lab, rad operational issues. Who has the budget for Revenue cycle management? Besides RCM doesn't make sense in Healthcare at all, because of the nature of the business.

How can you control the number of consumables used by the surgeon? Should he be counting the consumables or counting the minutes he has to get the patient back? Even the most experienced cardiac surgeon can't accurately predict the length of stent required in stent angioplasty. Even the most experienced orthopedic surgeon cant accurately predict the number of holes plate required for surgical reduction of bone fracture. So who pays for the stents or plates that were opened but not used/wasted in the surgery? Till date there is no way to exactly predict Disease outbreaks, then how can you ever predict the required medications? When you cant predict the variables, then how can you strictly monitor the cost and manage the revenue cycle?

How can you make surgeons use the most economical material and not allow him to decide his best way of doing surgery? Innovation in healthcare happens in the doctors office and surgeons theatre, and not in a lab environment like other industries.

I can go on with examples of why RCM doesn't make any sense in healthcare. But I feel its high time the generalist MBA consultants realize that Healthcare is different. Its time for Healthcare professionals to stop listening to generalist MBA consultants who bring ideas from other industries and then blindly try to force it on Healthcare.

Bottom line, you cant control something that you cant predict. Therefore dont apply the revenue cycle management techniques blindly taken from services, FMCG or manufacturing business.

Measure/Analyze what? - Financial or Clinical?

Cost goes in one direction and benefit goes in another direction.

Healthcare is not like a transaction system where you get a service for a consideration. Healthcare is unique because the cost of healthcare is borne by either the Govt in commonwealth healthcare system or the Insurance companies in private healthcare system, whereas the benefits go to the patient.

Someone can say that the benefits to the patient can be measured, but the improvement in patient safety is not really measurable. If you are going on the correct side of the road then you don’t know all the hazardous events that could have happened to you if you were on the wrong side of the road. So if you don’t know something, then you can’t measure it.

Therefore benefits of healthcare cannot be always measured in financial terms. What makes more sense is measuring the parameters in clinical terms e.g. disease trends at population levels, outcomes based on past evidence and disease progression in each patient. Utilization of resources as compared to baseline also helps.

Most business consultants’ don’t understand this simple logic in healthcare. In summary, Healthcare doesn’t have the service for a consideration financial model.

I know most people will not agree to my note above, until lots of projects fail. I will also wait for someone to educate me otherwise.

Federated vs. CDR Integration Approach

What is better system for integrating different Healthcare applications spread across different locations e.g. Regional or Provincial level EHR? -

1. Federated model - where data is pulled on demand
2. Central Data Repository - where all data from source systems is pooled upfront
   

This Q has troubled my mind for a long time and I am unable to find a consensus on the best approach. But after having discussed this matter extensively I felt I should post summary of all views in the blog for a wider audience.

Most Commonwealth countries are adopting the Federated model to build their HIE and EHRS. Standards such as HL7 and DICOM make it relatively simple to implement a more flexible Federated model. However how would you do Evidence based medicine 'closing the loop' and Epidemiology data analytics in Federated model? Isn't Central Data repository required for the data analytics.

Whereas Central repositories tend to be fairly brittle. Converting the source data to standard format to store in CDR is a challenge. Also, relatively small changes on the part of any of your data sources can result in all kinds of difficulties. But it is much easier to get a single, consolidated view of patient information with a CDR method.

Some people feel that we need at least some metadata or a clinical subset to be stored in a CDR fashion. That's the only way to do data analysis for outcomes measurement. A "hybrid" model is most promising i.e. Store key clinical indicators and pull other details as needed.

In summary, all depends upon what you want to achieve. Federated is the best if you want the patient data to move along with the patient in the healthcare value chain. However you will need CDR if you want to close the loop and do epidemiology analysis, evidence-based medicine or disease progression trend charting for patients.

HCIT plus HC-Mgmt Education Model

With coming of paper-less film-less Digital Hospitals, the Healthcare industry is facing a severe shortage of skills in Healthcare Informatics and on the other side Academia is producing Healthcare Management candidates who need to go to a finishing school to be employable.

Medical education lacks management and IT curriculum. Whereas doctors are increasingly expected to manage digital hospitals, electronic medical records, digital diagnostic images and analyze public health data in electronic form. Isn’t it a paradox?

The shortage is compounded by the HCIT outsourcing from north-America and Europe, where export of services and onsite staff augmentation is growing and needs lot of HCMgmt + HCIT resources.

Govt, Industry and Academia need to come together in building a consortium for enabling a Healthcare-IT R&D university in India. Well developed Healthcare-IT curriculum can be taken from North-American universities and modified for Indian Healthcare. Also IAMI and HIMSS should be involved in accrediting these courses.

Why did RHIOs fail?

RHIOs have failed in the US because all the stakeholders want to hold on to their data. US Healthcare is a privately funded healthcare system where every stakeholder has to protect their business interest. Without any single controlling agency its impossible to bring all stakeholders to share their data.

Whereas in commonwealth countries its a Govt funded, Govt controlled Healthcare system e.g. Canada, UK, Australia, India. Sharing of data is possible because all data belongs directly or indirectly to the Govt. If there is a reliable system to protect and share data then all stakeholders will share data. Therefore the huge investments integrated electronic health record systems (iEHRS) are in the right direction and will surely be a success.

We will soon see next wave of innovation from the countries where healthcare data becomes sharable. Especially closing the loop where data is available for Evidence-Based-Medicine and Epidemiology.

HL7 2.x to XML

For example represent the ORM message in XML format as above:

HL7 2.x was the best thing that could happen to Healthcare in terms of providing a common messaging language between systems. However HL7 2.x did not fit into the bigger picture of web-based applications, especially SOA. Therefore the need was felt for a XML based messaging format. This gave birth to HL7 3.0, where effort was made to define the most granular details. However the flip side is that HL7 3.0 lost the flexibility of accommodating innovation in clinical procedures.

Many new eHealth integration efforts are adopting HL7 3.0, though the old school having implemented HL7 2.x swears by it. Both approaches are right, but where is the meeting ground?

One way of sending HL7 2.x messages in SOA without moving to HL7 3.0 is to convert HL7 2.x fields into XML tags. The name of the tag can be Field# or Field Name. Just put a SOAP header on to the HL7 2.x XML and you are good to go. However the sending and the receiving applications need to share the same xsd. This can become the de facto standard if widely used by all.

Medical Tourism Challenges

I had written this list of challenges for Medical Tourism in 2008 from a US perspective. I am revisiting it: Though Medical Tourism from US never happened but the same challenges still remains valid. I am surprised no one have really filled the gaps in the medical value travels yet.

1. A reliable intermediary is missing in the Medical tourism business. Mostly the patient himself/herself or a relative or a clinician friend acts as the intermediary to negotiate a host of things that need to be done for the patient to go offshore and get a treatment done. Will a intermediary agency ever be able to develop the credibility to deliver on Medical Tourism promise? 

Interpreters or better known as healthcare facilitators are becoming the marketing middle-men to strike deals with the Doctors and ferry the patient around. This is not how Medical Tourism was intended to operate! 

2. A host of service providers are required to come together to offer a reliable Medical Tourism service. Service providers such as Hospitals, Insurance, Telemedicine, HIS/EMR, Call centres, Data processing KPO and Travel agencies are so diverse and different that they have nothing in common; yet they have to come together to deliver on Medical Tourism promise. Will this ever happen? I dont know!

3. All the Medical Tourism is coming from GCC and Afghanistan. Patients from Russian union, Europe, US still remains at large.

4. Most of the funding is out-of-pocket cash. Hawala galore! Where are the Insurance payers?