When we think of the agile software development method Scrum, we think of a fast-paced process that includes working on multiple phases at the same time with a small team completing a software tool over multiple “sprints.” These sprints last one to four weeks and are dependent on the daily communication between the team members for success. The communication is supposed to be quick and should identify daily accomplishments and tasks ahead. The longer communication occurs at the beginning and end of each sprint, in which the team plans the contents of each sprint and in the end evaluates its performance to implement lessons learned and improvements. While this methodology can be successful within teams working at the same location or working in different locations, there is a limitation to how far apart the teams can be for this to work successfully.

For example, if the development and testing teams are in a different location than the analyst who clarifies and communicates requirements (in the form of user stories), chances are higher that details will be missed over audio and web conferencing. If the time difference between the two locations does not allow team members to work at the same time, answers and issue resolutions can be delayed by a full day. On top of that, if the analyst is working physically apart from the business stakeholders and the development and testing teams, communicating the small intricacies of what makes an online tool very user-friendly versus a complete eye sore can become even more difficult.

Traditionally, agile methodology works best when the team is small, five to six people, and there is one stakeholder representative who is the communication bridge between the IT team and the business stakeholders. If that bridge is missing or does not have the necessary information to translate business requirements into system requirements, almost everything has the potential to get lost in translation. Furthermore, most often teams utilizing agile methodology experience the “too many hands in the pot” syndrome, in which the business stakeholders want to conduct user acceptance testing after each sprint and provide feedback. There are more cons than pros to this approach.

The whole point of having a sprint is to build a piece of the puzzle until we have solved the entire puzzle over a few sprints. Testing piecemeal functionality results in the following:

Stakeholder: “I did not see [particular functionality] in the tool.”

IT Analyst/Lead: “This is not part of this sprint, as you can see in the list in front of you. This was shared with you at the beginning of the sprint.”

Stakeholder: “Oh, right. I forgot. Then what about [another functionality]? I thought that was part of this sprint.”

IT Analyst/Lead: “No, as you can see in the list, this functionality is part of the next sprint.”

A business stakeholder will always look at the entire puzzle instead of a piece by piece snapshot, because business stakeholders manage entire processes, not one piece of a process. Therefore, not understanding this basic piece of human behavior can lead to a large amount of time wasted, yes, wasted, on answering questions that end up being asked at the entirely wrong times.

Health Information Exchange (HIE) is “the development of secure health information exchange between healthcare providers…in order to improve the continuity and quality of care for patients.”[1] According to a recent research study, 71 percent of U.S. hospitals intend to purchase a HIE solution, with 25% intending to purchase it within a 7-to-12 month period.[2] States across the country are setting up HIEs in which providers and ACOs can participate to better integrate their health information.

Idaho, through IHDE (Idaho Health Data Exchange), has helped groups like Primary Health Medical Group (PHMG) access patient information such as admission and discharge summaries, as well as physical and lab test results, better understand its patients’ medical history before diagnosing and implementing treatment. As a result, PHMG is preparing a multi-phase approach to its participation in which the intended end result is the statewide availability of the 200,000 patients it sees annually.[3]

The Kansas Health Information Exchange (KHIE) was intended to be a government HIE but evolved into a public-private share entity with private funding from the Kansas Hospital Association and the Kansas Medical Society. Now its operations are being handed over to the state completely, with leadership citing cost issues. As a private, independent entity, KHIE’s staffing costs were as high as $400,000 a year. As a government entity, however, its staffing costs are expected to fall to $54,000 a year. The board is hoping this will force the government to “have some skin in the game,” thereby giving more attention to the providers whose participation will ultimately benefit the patient.[4]

Michigan Health Connect (MHC), Michigan’s largest health information exchange, recently teamed up with Greenway Medical Technologies to provide Michigan providers and physicians real-time access to clinical data leading to more than 900,000 results per month. The partnership is geared toward ambulatory practices and clinics, and will include 54 member MHC member hospitals and more than 4,000 physicians across the state.[5]

Other states, like Montana, Colorado, and Florida, are also contracting with physicians to participate and share patient information with each other. However, which HIE solution is the best at the state level? Further, do we need HIE solutions to be operable only at the state level? Or should we be strategizing toward a solution that will eventually tie all state patient data into a national health information exchange? The Office of the National Coordinator for Health Information Technology is currently working with federal agencies, local and state governments, health information exchange organizations, and other entities to develop standards and policies at the national level. This group is formerly known as the NHIN (National Health Information Network) Cooperative and expected 35 participants in this network by the end of 2011. As of March 2012, it had 27.[6]

A 2008 study on CDS (clinical decision support) tools found that while the benefits of CDS technologies are widely understood and accepted by providers, there is still a lack of proactivity in its adoption. An article summarizing the study stated: “For example, Chang said that while CPOE with CDS is now already widely accepted, it is rarely used appropriately.” Physicians complain that too many inappropriate alerts pop up on the computer screen, and as a result, providers begin to ignore the alerts, negating the reason why they were set up in the first place. Chang also cited a general lack of technology adoption and steep financial investment as high barriers to adoption. “If Facebook is able to predict who an individual might be friends with based on who he/she is already friends with, why shouldn’t CDS be able to determine what diagnosis patients may have based on their health information?” she asked.”[1]

The problem with this analysis is that Facebook cannot be sued if members become friends with the wrong people but physicians can be sued for malpractice if a patient is incorrectly diagnosed and treated, especially if that treatment turns seriously negative for the patient. Medical practice and treatment should not be subjected to as simple a comparison. Even if a CDS tool can be accurately set up to flawlessly diagnose patient symptoms, it cannot replicate the personal touches of a physician who can answer patient’s questions while performing a check-up. For example, a patient can go to a podiatrist for a foot problem and also be able to get a prescription for eczema cream without having to see two doctors at two different times and pay two different co-payments. The patient can speak to the doctor about his/her eczema or other minor ailments while the doctor is checking his/her foot. If the point of new technologies is to ultimately improve healthcare, then how will a CDS tool that diagnoses patients without seeing a doctor help in this commonly occurring situation? If the patient can still see and speak directly with a physician, why should he/she spend time on a CDS tool as well?

Fast forward four years and here is where we are today: “A 2009 Black Book EHR survey found that 88 percent of provider organizations believed their EHR vendor would meet most of their interoperability and foreseeable clinical information needs. However, in 2012, fewer than 10 percent have the same expectation of their EHR system.”[2] Why? The reasons are plenty.

Providers do not feel equipped to hire and train qualified candidates who can become experts in specific CDS tools to make enough improvements in the delivery of care. However, according to the same 2009 survey by Black Book, 69% of larger hospitals feel “technologically equipped” to handle the changing healthcare environment. Also, more and more providers are now focusing on gathering business intelligence on the care they provide before adopting technologies to change its delivery. CDS tools that make generating and presenting this business intelligence easier are needed more than others that can auto-diagnose patients, etc. Business intelligence tools can give providers the information needed to determine whether more sophisticated tools are necessary or the clinical workflow simply needs to change to improve the delivery of care and the revenue stream.

Before we pile on more CDS tools that may not improve delivery of care and the health of patients, proper information is necessary to determine whether such tools are even needed. For example, EHRs as a CDS tool can improve the delivery of care. The next step should be to gather data from EHRs to generate intelligence on diagnoses and treatments, and then decide whether more sophisticated CDS tools are required in these areas. We are only now entering the era of EHR business intelligence.

Some healthcare solutions experts foresee the following five financial benefits of ICD-10:[1]

1. Providers can establish or strengthen CDIs by conducting thorough reviews of clinical documentation and implementing improvements, such as a CDI “Lite” program.
2. Development of patient preferences due to new procedures being performed based on more thorough and detailed ICD codes. Patient preference will result from information available on physicians and hospitals providing the specific procedures and their rating of the results. Physicians and hospitals have a better opportunity to differentiate themselves to improve their financial positions.
3. Providers will be able to receive appropriate and timely payments for procedures performed, because there will be less confusion about the procedure details.
4. Because claims will be processed more efficiently due to the specificity of the procedure codes, there will be fewer rejections and lower administrative costs.
5. Coding timelines will be improved and errors will be minimized due to “logically standardized definitions and more accurate clinical terms.”

Other experts foresee the following five financial issues emanating from ICD-10:[2]

1. Everyone who deals with claims in the healthcare industry will need to be trained to properly handle the medical coding and billing. Without proper training, major delays can occur in the timely processing and payment of claims.
2. If claims processing and payment is delayed, by 10 to 20 days according to some experts, providers may experience a cash crunch in which they will have to dig into their cash reserves to pay operational expenses while they wait for accounts receivable reconciliation.
3. For Medicare and Medicaid claims, a sum is due to the government. If that sum is not paid, the provider will be investigated for fraud and abuse. The government will send RACs who have legal authority to request and view data, and get paid based on the number of errors they find. Not implementing ICD-10 properly and training staff adequately can result in large sums paid in fines due to errors made in submitting claims.
4. With the list of procedure codes expanding, providers may find themselves short of medical coders who are adequately trained. Therefore, they will be forced to outsource the work or hire contract coders.
5. If providers decide to outsource the medical coding work, they risk data security that can lead not only to issues that have to be dealt with financially but also loss of personal health information of patients.

With yet another delay of the ICD-10 mandate (the new date is still up in the air), providers and payers have more time to consider the benefits and risks, and to work together to make a smooth and successful transition. What do you think? Do the benefits outweigh the costs of ICD-10?

The Federal Register outlines the following pros from comments received on the adoption of X12 Version 5010 for HIPAA Transactions: 1) reduction in analysis time and minimization of companion guides; 2) improved efficiency through improved eligibility responses and better search options, reducing phone calls to providers and health plans; 3) improved electronic posting, automation of data entry of reimbursement information; 4) reduction in appeals and cost of sending and processing paper remittance advices; 5) improved clinical data and reporting of diagnosis and procedure codes with the implementation of ICD-10-CM and ICD-10-PCS; and 6) better understanding of clinical data and better monitoring of mortality rates, treatments, lengths of stay, and clinical reasons for seeking health care.[1]

Since the release of these statements in 2009, health plans across the nation have made, or have almost made the transition from 4010 to 5010 and are preparing to meet the ICD-10 mandate date of October, 2013. The industry seems to be pretty excited about all the new information that these changes are going to generate. However, are we appropriately prepared to generate, store, and analyze this information for improvements in our nation’s healthcare system?

It seems there is already a ton of information ready to be generated at our hospitals and health plans, but the appropriate tools are not in place to properly generate and present this information for influential decision making. If we are unable to fully understand the information being processed in our healthcare system today, it may be more difficult than we realize to understand new information and identify how the new mandates have helped us better understand healthcare spending and usage.

For example, health plans process authorizations and claims everyday but do they know what percentage of authorizations turn into paid claims? Or denied claims? Today, there are health plans that are unable to distinguish between approval or denial of an authorization or claim and of individual diagnosis and procedure codes included in it. More specifically, when a Medical Director is requested to review a claim or an authorization, he or she can approve some procedure codes and deny others. So if two codes are approved and two codes are denied, the reporting system will display that only one decision was made because only one form or review was completed. However, that is not the case. The Medical Director actually made four individual decisions. This hides the actual information from leadership, like which codes are being repeatedly approved or denied and why?

With the new ICD-10 codes that are much more specific than the existing ICD-9 codes, being able to better understand clinical data will require the implementation of adequate clinical reporting systems as well. Understanding why authorizations for certain codes were requested and then approved or denied may be more difficult than anticipated. The desire and hope to generate the necessary information does not mean that we are actually ready to generate it. The healthcare industry must invest in robust business intelligence tools to generate actual business intelligence that goes beyond basic metrics. Otherwise, we may be setting ourselves to fall into the same trap we are in today: too much data and not enough information.

When documenting business requirements for a multi-application technology-based solution, is it crucial to have proper representation from the impacted systems in each discussion? For example, provider contracts may be stored in one internal application (i.e., SharePoint) but must be exposed to providers via a second application (external portal) after being passed through a third application (internal workflow tool) to manage the contracting process from a workflow perspective while automating the process at the same time. Further complicating the mix is the validation required of a provider’s signature if the option to electronically or digitally sign a contract is provided via the external portal. So right from the beginning, there are four different technologies or systems for which requirements must be gathered and solutions must be developed.

So during the business requirements phase, should a Technical Architect from each potentially impacted system be present to fully understand the coordination required between all systems to meet the end goals being set by business leadership? Or should their involvement be reserved for the system requirements phase and onward? There are pros and cons to each approach. If the Technical Architects are involved right from the start when business requirements are being documented, the discussions may become too technical and the business goals may not be understood in their entirety before decisions are made to change or sometimes even kill the project as a whole. On the other hand, Technical Architects can help the business understand some fundamental issues concerning the end solution being requested, things that may be more costly than alternatives or just technologically impossible.

The benefit of involving the architects early comes in handy when business requirements start specifying technical requirements for applications that are not fully understood by the business users who are requesting the functionality. For example, the business user may need application 1 to launch inside application 2 to make his or her job easier, and may document such a business requirement in the BRS. However, once the BRS is approved and system requirements are being gathered, it may be revealed that the two applications are technologically incompatible and cannot be integrated in this way. At that point, the process of properly changing requirements takes over and slows down the progress of the project itself. In this case, I have seen projects get postponed over months and even years. Every time the project is picked up, the same arguments over the technologies take place but are never resolved because the business requirements were never re-visited with the Technical Architects who could have provided the necessary insight into the impacted systems.

So a lesson learned is that when it comes to business requirements for technology-based solutions, it is crucial to involve the Technical Architects of the potentially impacted solutions to ensure that the end goal being proposed by business leadership is technologically feasible. When to involve the architects depends on the dynamics of the teams. Some companies have architects in the business requirements sessions to ensure no time is wasted asking for solutions that are too costly or impossible. Other companies involve architects after the business requirements have been documented but not officially approved for the next phase. This allows the business to document their requirements without lengthy technical discussions and also allows the architects to provide their input without causing major delays.

In Part II of this blog series on the Patient Protection and Affordable Care Act (PPACA), I will explore the following statement: “Adults with pre-existing conditions became eligible to join a temporary high-risk pool, which will be superseded by the healthcare exchange in 2014.To qualify for coverage, applicants must have a pre-existing health condition and have been uninsured for at least the past six months. There is no age requirement. The new program sets premiums as if for a standard population and not for a population with a higher health risk. Allows premiums to vary by age (4:1), geographic area, and family composition. Limit out-of-pocket spending to $5,950 for individuals and $11,900 for families, excluding premiums.”

In addition, the premiums (effective September, 2010) for this high-risk pool were set as follows:

• Premium to be set at a standard rate for a standard population
• Premium for older individuals allowed to be up to 4 times the premium for younger individuals
• Premium for tobacco users allowed to be up to 1.5 times the premium for non-tobacco users

What is disturbing about this premium scheme is that individuals who cannot control their age are required to pay much more than individuals who can control their tobacco-related habits. Does this seem disturbing to anyone else?

While there is a limit on out-of-pocket spending, there is no ceiling on premiums (yet) and no floor for benefits. There is a 40% excise tax on premiums greater than $27,500 for families and $10,700 for individuals. However, this tax on health insurance companies does not go into effect until 2018. In addition, the healthcare exchange mentioned in the provision does not take effect until 2014.

The healthcare exchange is a government subsidy that will be provided to families based on size and annual income as a percentage of the federal poverty line. For instance, a family of 4 whose income is 400% above the poverty line (in other words, $88,200) will have a maximum out-of-pocket premium of $8,379 (9.5% of income). However, for another two years there is no premium ceiling, and for another six years there is no penalty for charging high premiums. Further, there is no premium ceiling at all for families whose annual income is above $88,200. What can this mean for a middle-class family in the US?

In the same year as the healthcare exchange takes effect, the government will also begin imposing a $2,000 tax per employee on employers who do not offer health insurance and employ more than 50 individuals. Thus, in two years, a family of four making $90,000 annually can lose its health benefits and be forced to purchase its own insurance for which there will be no subsidy and no premium ceiling.

What if the primary breadwinner of this family loses his job but has a pre-existing condition that may not be insured for 6 months to 10 years by a new healthcare package, based on the state in which the family resides? Even if he finds a new job right away, will he have to refuse healthcare for six months in order to enter the temporary high-risk pool of individuals, some of whom may have to pay up to four times the standard premium because they are older? Will this individual be able to afford this high premium when combined with insurance costs for his family? How will he insure his family during those six months? I have yet to find answers to these questions in the PPACA. I hope I am missing something.

I plan for this blog to be the first in a series of questions I have regarding different aspects of the Patient Protection and Affordable Care Act (PPACA, in the hope that it will help me not only gather more details that I have yet to uncover through further research but also spark some intelligent conversations that can help us all understand, as American citizens and healthcare consultants, the future of healthcare in this country.

While reading a summary explanation of the PPACA I was confused by the following items: 1) 40% excise tax on health coverage in excess of $10,200/$27,500, to raise $32 billion in funding, and 2) Impose a $2,000 per employee tax penalty on employers with more than 50 employees who do not offer health insurance to their full-time workers.[1] Item #1 will not go into effect until 2018 while item #2 will be in effect by 2014. In other words, by 2014, employers who, in 2009, paid an average of $13,375 on a policy covering an employee’s entire family will have to pay only $2,000 to not insure that same employee and his/her family.[2] When considering the scenario that even self-insured employers will save on healthcare costs by simply paying the penalty, what exactly is this “imposition” incentivizing?

Now, let’s consider item #1. By definition, an excise tax is “an internal tax or duty on certain commodities, as liquor or tobacco, levied on their manufacture, sale, or consumption within the country.”[3] It is more commonly known as a tax on luxury goods. Planned to be in effect by 2018, this 40% excise tax will be imposed on “Cadillac” plans that cost more than $10,200 per individual and $27,500 per family for everyone else while $11,850 per individual and $30,950 per family in annual premiums for retirees and employees in high risk professions. “Cadillac” plans, as they are referred to, are often based on age, gender, health, and for an employer-based plan the pooled risk of employees. These plans usually come with low deductibles and generous benefits, so it is easy to take a guess at the impacts of the excise tax. Payers will want to remain below the thresholds and thus will lower premiums. However, since there is no requirement to provide a certain minimum package of benefits to any insured individual or family, payers will decrease benefits or increase co-pays and deductibles, or both. Again, the same question arises: What is this “imposition” incentivizing? Also, if an expensive healthcare plan is required for professionals like firefighters who risk their lives as part of their jobs, is a “Cadillac” plan a luxury good to be excised or a necessity to be provided?

Combined, these two items created the following dilemma for the healthcare consumer. If your employer no longer offers health insurance and your annual household income is more than $88,200 (disqualifying you for a cost-sharing subsidy) but less than $100,000, can you afford healthcare insurance for you and your family? There are more factors to be considered in answering this question. I hope to address those factors in this series through much research.

I have seen Business and System Analysts (SAs) get involved in various ways throughout the SDLC process. On one hand, Systems Analysts join forces with Business Analysts to gather business requirements and are required to approve the business requirements specification (BRS). The two work as a team with the business to understand the process, develop process flows (as-is and to-be), and document what the end product needs to accomplish. Asking questions on how certain steps of a manual business process are required to fit into an automated process can help address concerns that sometimes end up being raised too late in the game. On the other hand, a Systems Analyst is not involved in the business requirements phase at all but is expected to gather system requirements after the BRS is complete. The Systems Analyst has no control over how the requirements are captured or knowledge of the existing business process. He/she is essentially starting from scratch when it comes to not only understanding the as-is and to-be process but also finding gaps in the information provided to document accurate system requirements. Most often, they are forced to ask questions that later require updates to the BRS and cause delays in the delivery of system requirements documentation.

In addition, some Systems Analysts are heavily involved in the review and finalization of test scenarios to ensure that the proper functionality is being tested without over-testing or wasting time and effort toward testing minor details, like the word “cancelled” being spelled with one “l” or two. Sometimes, Systems Analysts are even required to provide approval to system test cases and work very closely with the UAT (User Acceptance Testing) Manager of the project to ensure the minimum functionality necessary to perform the business process is being demonstrated to the user. Finally, Systems Analysts sometimes also work closely with the Training & Education manager, or sometimes they are the Training managers. This ensures the user is being properly trained to do his/her job and perform the business process that he/she is responsible for, which is the whole reason for that particular project in the first place.

However, on many occasions, Systems Analysts are required to understand everything about the process being built inside an application but are not involved in half the phases of the project. This reality becomes more confusing when we consider that the development team seeks guidance from the SAs when it comes time to develop the solution. Further, the test team seeks guidance from and asks questions of the same SAs when testing the application. The business teams also work on a daily basis with the SAs to make sure the proper system requirements are being captured. Then, why are these same teams and users not required to involve SAs when it comes time to complete their respective work? At the end of the day, the SA becomes a crucial part of the implementation. Why are these essential participants left in the dark?

One thing I have been wondering about recently is to what extent consulting firms are exploring the clinical trial sector of academic medical centers (AMCs). While conducting an assessment of just one (small) department within an AMC in a previous consulting engagement, I learned how weary everyone around me was of the academic bureaucracy and lacked any faith that a change can come about. During our assessment, my teammates and I learned about two types of organizations that can be set up inside an AMC to boost its competitiveness in the clinical trial landscape.

Organization Types

One is a Site Management Organization (SMO) that helps sponsors manage multiple sites for clinical trials, including private sites in the AMC’s own vicinity. An SMO can help an academic medical center not only boost clinical trial revenues with more sites under its belt but also cut costs on research and resources by sharing them with its sites. The only drawback is that a SMO cannot conduct its own Quality Assurance, which would be resolved if the AMC can use its university’s Institutional Review Board (local IRB) to gain approval for all its clinical trial sites. However, the fact that local IRBs can take somewhere from two to six months to approve one study, as they are often underfunded and understaffed, really means that by the time a study gets approved it is over. Other clinical trial sites have picked up patients, reaching the maximum goal set by the sponsor. Thus, an SMO within an AMC has no choice but to contract with an independent IRB (central IRB) or partner with a Contract Research Organization (CRO) to keep up the pace. While the former partnership is necessary to gain fast approval for clinical trials (within one business week), the latter is not in an AMC’s best interest because a CRO is a direct competitor who can manage clinical trial sites, conduct Quality Assurance, and compile the findings to meet sponsors’ requirements. In a partnership with a CRO and a sponsor, the AMC SMO would be just another, bigger, clinical trial site.

AMC Advantages

One very crucial thing that an AMC has going for it, and that a CRO cannot boast, is the research minds and expertise of its world-renowned physicians as well as the research funding and resources that come with being part of a large state university. Sponsors like to see more AMCs in their clinical trials because results from these sites provide the credibility that a CRO cannot provide by simply compiling the results. Further, from our research, my teammates and I found that sponsors WANT to work directly with AMCs instead of going through a CRO. However, CROs have become a major force in the clinical trial landscape as the main “middlemen” between sponsors and sites because they can manage an entire clinical trial for sponsors on one budget from start to finish. This may offer convenience but may be not always provide the best expertise or the best product for the price.

Now, if you combine the competitiveness of a CRO with the resources that come with being an AMC, you can build a very strong clinical trial competitor who can do more just conduct a lot of clinical trials. An AMC CRO can work directly with sponsors on clinical trials and medical research to improve the healthcare that is provided not only in the AMC’s immediate area but also to patients worldwide by backing up the findings with the expertise of world-renowned physicians who are trusted for their opinions and experience. This will benefit the AMC by attracting the best medical talent there is, meaning the best residents who want to train and the best physicians who want to be researchers, and also by improving its outreach in its immediate community.

I wonder why I don’t see more and more consulting firms working with AMCs on reaching these heights by helping them become major sources of clinical research as well as the best medical care that members can get no matter what their healthcare affordability. I am hoping to gain insight from healthcare consulting experts through my blog.