Healthcare

Yes, I believe so. Earlier patients were not well informed about their conditions, disease progression, medications, their side effects and the onus was entirely on the physicians to extract necessary information from patient and care-givers for treatment related decision-making. Extracting clinically significant information was a challenge in with language/cultural barriers coming into play or a patient who is inarticulate or unobservant about relevant signs and symptoms. With information explosion in the wake of internet wave, now a large number of patients visit physicians with prior research on their signs and symptoms as well as treatment options.

Eighty-five percent of online adults from the United Kingdom, Germany, France, Italy and Spain report using the Internet to find health and prescription drug information, according to a new Manhattan Research survey and 67% of U.S. adults reported having searched for health information online  according to a new Harris Interactive survey.

Physicians have genuine concern regarding the veracity of all the information that their patients are exposed to on internet. They also have to deal with unprecedented queries regarding diagnosis, treatment options, side-effect of medications etc. Discouraging patients to seek information online would be counter-productive to patient enablement. Physicians continue to be the most trusted source of health information for patients. They can support patients in their health education by guiding them towards reliable websites and addressing their queries.

An informed patient actively participates in health care and contributes to better outcomes by:
• Being more aware of signs and symptoms
• Clearer articulation of problem history and current complaints
• Better medication compliance
• Informing physicians about their unique response to a treatment protocol
• Observing side effects and improvements in condition
• Better ongoing health maintenance through diet compliance, exercises and recommended lifestyle changes

Additionally, patients perceive more empathy and have greater satisfaction from physician visit if the physician spends time to explain them about their disease and how to cope with it. Particularly in case of chronic diseases, it is critically important to enable patients and their care givers in disease management. Patients can be true  partners of their physicians in managing chronic diseases if they are well informed about cause of disease, what aggravates it, what to expect from treatment, what are acceptable side effects and when to seek medical attention. Evidence suggests that enabling patients for chronic disease self-management results in improved health outcomes and reduced hospitalization. Informed and experienced patients or care-givers can in turn enable other patients leveraging Health 2.0 platform. About 35% of U.S. adults used social media for health and medical purposes in 2009 according to the Manhattan Research survey. 80 million U.S. adults in 2009 created or consumed health care content on blogs, chat rooms, message boards, online communities, online social networks and patient testimonials.

Posted by Seema Pandey at 09:48 AM | Permalink | Comments (2) | TrackBacks (0)

As the global healthcare industry grapples with tremendous challenges on both cost and quality fronts; the healthcare consumer is simultaneously undergoing an equally dramatic change in behavior, attitude and awareness.  This new-age healthcare consumer will soon demand a significantly more active role in managing his/her own health needs as well as filtering and monitoring the relevant services that would be provided by the health industry.

At the foundation of these simultaneous yet converging  trends of industry moving to patient centric care and the consumer moving towards demanding and receiving personalized and holistic attention; will be the demand for comprehensive, transparent yet secure flow of healthcare data, information and knowledge. 

Currently the entire healthcare industry, globally across all sectors; is in the process of putting into place the basic transactional systems required to capture individual sector specific data needs for serving the healthcare customer through sector specific views.  This process itself has been long, tortuous and has evolved over the last 20 years.  Particularly in the US, this has resulted in an environment of extreme heterogeneity of systems that hold healthcare customer data – even within each individual sector such as payer, provider, pharmaceuticals, government, medical devices industry and retail health.

This rampant proliferation of niche systems has resulted in extraordinary obstacles to free flow of healthcare data; not least because of security and privacy concerns.  HIPAA and related legislation was an important step towards enabling / mandating true interoperability of health systems.

Moving forward there will be a tremendously accelerating demand for the following types of interoperability requirements

a) Interoperability within individual sectors within the industry – as a basic requisite to view and analyze sector specific healthcare customer data
b) Cross sector interoperability will soon begin to demand extraordinary attention as the health industry moves towards true patient centric and personalized / holistic care.

Both these types of interoperability requirements need to be handled very differently even from a technology perspective

As I continue with these blog posts on interoperability, will delve deeply into various aspects of these, including key problems, trends, solutions and market demands in subsequent blog posts.

Suffice to say for now, that in the reality of the current technology landscape of the healthcare industry – interoperability needs and initiatives will form the basis of a significant portion of technology support in the move towards patient centric care. 

Posted by Dr. R Balaji at 09:19 AM | Permalink | Comments (0) | TrackBacks (0)

The necessity for dual processing with ICD-10 is not just a result of interoperability between entities on disparate code-sets. Even if we assume that all the payers and providers are migrating to ICD-10 (desirable, but hardly a pragmatic situation) on Oct 1st, 2013 (compliance date), dual processing is going to be required for some adjusted claims and inpatient claims.

Assume that a claim with service date prior to the compliance date was rejected by the payer post compliance date, due to incorrect coding. The provider must code the claim correctly and resubmit it to the payer. If the provider’s coding and billing systems can’t support ICD-9 codes anymore, the claim can only be submitted manually. Of course the product vendors are aware of this problem, so their billing systems will continue to support ICD-9 codes beyond the compliance date.

Ideally, product vendors will allow users to capture ICD-10 codes (regardless of the date of service) and internally (within the coding and billing systems) translate to ICD-9 based on the date of service. But the vendors might also provide limited support with two sets of UI’s, one to capture ICD-9 and another for ICD-10 codes, leaving it for the coders to decide which code-set and UI to use. The first option will naturally be desirable - the providers would use some kind of a crosswalk or VOSER software to convert codes in this option.

On the payer side, adjudication programs will need to base their logic on contract term effective dates and the dates of service (DOS). If the DOS or the discharge date (for inpatient claims) is prior to the compliance date, the adjudication programs will pick up the contracted rates that are based on ICD-9 codes (and matching DRG and CPT codes). Otherwise the ICD-10 rules will apply. The codes that are used by the adjudication programs will flow in to the claim output process, so the remittance process will not require major revisions. The remittances will automatically reflect the correct coding.

Finally, when the remittance is received back by the provider, payment posting will take place using the code-set that was originally used to submit the claim.

The following diagram illustrates an arrangement that will work while processing adjusted claims.

Posted by Vijay Kumar B at 12:08 PM | Permalink | Comments (1) | TrackBacks (0)

Few weeks ago, in one of my blogs, I had attempted to set some basic tenets for the tactical option (downgrade-store-and-forward) for complying with the 5010 mandate. They primarily covered,
• A dynamic rules based bidirectional converter
• A comprehensive store-and-forward mechanism for storing and retrieving reduced data
• A clear performance management strategy to manage data reduction (for down conversion) and data addition (for up conversion)
• A robust API to provide access to reduced data for the downstream applications, and
• A comprehensive test bed and associated test strategy
I promised in that blog that I would not ignore the strategic approach (remediating downstream applications to make full use of the mandate) and would tackle that in a future blog. So here we are. Lets see what are the basic tenets for the strategic approach.

Strategic Approach

The strategic approach is the course of action that incorporates remediating all the downstream applications (core, transactional, or peripheral) fully to support all changes associated with shifting from 4010 to 5010. As the focus shifts from the front-end (EDI gateway, mapper software etc) to the back-end (claims adjudication engine, eligibility system etc), it is imperative that the scope of the assessment and remediation grows manifolds. In some cases, I have seen code volume to the extent of 100 Million lines of code (yes, you did not read it wrong, that is 1 followed by 8 zeros). Now that is a heft piece of code base to go through and pin-point, say the 500k lines of code that are actually going to use the attributes that have changed between 4010 and 5010. Needle in a haystack anyone? So few of the basic tenets for a strategic remediation are driven by this singular fact and lead to core necessity of automation. Lets try to put them on paper

• A three step approach covering high level business process impact in step one, application portfolio assessment as step two and low-level code assessment as step 3, is of paramount necessity. Try to do the code assessment directly and you will hit a wall before you can blink or say go through one or two disjointed source systems. On the other hand, ignore deep-dive into the code at your own peril because attempting to remediate without having gone through a comprehensive business process mapping is sure-shot recipe for failure.

• A semi-automated tool to map all the business processes of the organization, to capture all the business requirements at one place in a hierarchical process order, and to generate a rough order of magnitude effort and cost estimation so that you can define your roadmap much more intelligently rather than taking a stab in the dark. The step/activity seems innocuous and invariably I hear that we already have it. After all we run our business every day. Well, I don’t mean this to be demeaning to anybody but precedence tells that 90% of the software/remediation/upgrade/transformation disasters can be directly attributed to lack of clarity upfront with respect to business process definition and its alignment with the application portfolio and system infrastructure. So, it would not hurt to do a quick double-check. There is not much to lose and upside is significant

• An automated tool set to support code crawling at the least and coverage of process map also in the best case scenario. It does not take a rocket scientist to figure out that having to focus on 5% of the code set to identify and remediate the changes is going to be a lot less effort and cost intensive than to have to do that against the complete code base. So why not have an automated tool provide you with that 5% code base that actually uses one or more of the tokens (attributes that have changed between 4010 and 5010). Afterall if a line of code does not use one of these tokens, how likely is it that that line of code will be impacted by a change in one of these tokens? Not very likely.

• A large set of 5010s to test and a comprehensive test strategy along with associated test cases and test scenarios. There are 968 unique and more than 6500 combinational changes between 4010 and 5010 TR3s, not to mention the changes that are specific to companion guides. If you want to be at peace that you have tested every possible scenario, you better have a comprehensive list of the changes between 4010 and 5010, especially the ones that are specific (and hence configured) to your environment. The vendors may certify your 3rd party applications as 5010 compliant, but one can take them on their word only at one’s own peril. One must have a large number of 5010s to test those compliant applications and what better way to generate those 5010s but to create them from existing 4010s using, yes you guessed it, the same converter that was described in step 1.

• Steer clear of over-dependence on your vendors. Granted that for core pieces of transactional software that you do not have code for, you have to depend upon them but have you thought about what percentage of your total application portfolio falls under that category. I have heard from people that they don’t need to do anything as all their systems belong to one vendor who has promised a miraculous upgrade to take care of their entire problem at a low-low cost of few Million dollars. I am not sure when I face such optimistic sentiments. Inherently I am the ‘glass half full’ kind of a guy but that does not mean I bury my head in the sand in face of the oncoming train either. If one carefully looks at a COTS implementation in their environment, one would realize that 30-40% of the code base is actually custom built for their implementation. We don’t call them COTS (Customizable off the Shelf) products for nothing. Do you remember all those services cost that went into creation of the interfaces specific to your environment etc. So do you seriously think that the vendor’s next upgrade will cover those custom interfaces also by default? And what about those pesky little Access databases that hide better than the ‘Oracle in Matrix’? By a rough estimate, an average payer organization has only around 20% of their total code base that is truly vendor driven. For providers, the number go up a bit but not by much (around 35%). If you can live with supposed coverage of 20 to 35% of your portfolio then yes, may be you can rely completely on your vendors and sleep peacefully but if I were a betting man, I would say I would not take those odds.

So these are a few of my favorite things, when it comes to 4010 to 5010 transition using strategic approach. Maybe I am a bit too close to these things for me to maintain an impartial objectivity but every bone in my body screams that you miss out on one of these, you get ready to get your fingers burned. Maybe a heck of lot more than just the fingers.

Posted by Rajiv Sabharwal at 07:52 AM | Permalink | Comments (0) | TrackBacks (0)

Supply and demand is perhaps one of the most fundamental concepts of economics and it is the backbone of a market economy. Demand refers to how much (quantity) of a product or service is desired by buyers. The quantity demanded is the amount of a product people are willing to buy at a certain price; the relationship between price and quantity demanded is known as the demand relationship. Supply represents how much the market can offer. The quantity supplied refers to the amount of a certain good producers are willing to supply when receiving a certain price. The correlation between price and how much of a good or service is supplied to the market is known as the supply relationship. Price, therefore, is a reflection of supply and demand, according to Investopedia.com, a Forbes company.

Let us consider then the latest proposal in the United States Senate to pay for “Healthcare Reform” in part by taking $500B out of Medicare and also, perhaps, change the eligibility age for Medicare, at the same time, to 55 years of age rather than the current 65 years. So, we are going to add a decade of Americans to the Medicare roles while taking $500B out of Medicare?
If you believe the Supply and demand concept and also understand how care givers are reimbursed by the government then it is easy to see the calamity this can cause in the healthcare market space. You see, the $500B is not being taken away from the patients directly but rather the caregiver’s reimbursement rates. Hospitals, Physicians, and other associated care giving entities in the continuum of care will be squeezed by this lack of funding. Consequently, more of them will literally stop accepting Medicare patients but rather opt for direct pay or other private insurance funded patients out of a need to stay in business. The more “Public Option” centric healthcare becomes the more physicians and clinicians will opt out of the business, leaving a severe shortage of caregivers leading to a severe lack of supply of healthcare.

If that last paragraph is mind boggling so is the reasoning behind the thinking of Government Controlled healthcare. One thing is certain however, the more severe the shortage, the better it will need to be managed minutely giving technology providers even more challenging technologies to develop.

Posted by Gary O. Claytor at 12:37 PM | Permalink | Comments (4) | TrackBacks (0)