The Seven Myths of Healthcare Technology5. One Size Fits All

August is over, and so is, sadly, vacation. So, we came back to the office this week, to a pile of mail (I see that Canadian Tire had some nice sales in August) and a week of "start-up" appointments. One was a discussion with a partner company in Toronto. They are in marketing and were contacted by a potential client about an EMR/management system for small-office providers. As an SME, I was brought in to provide support. It sounded like a well-thought-out product serving a clear need. However, as we talked, I recognized a flaw in the initial assumptions;

Myth #5 "Solutions Are Shippable."

The potential client, a software vendor, was thinking of establishing a client base in Ontario and then expanding through Canada and the US--a reasonable and not uncommon business-development route for most products. Vendors and buyers of look on both sides of the border for new clients and better deals, respectively. This works with auto parts, fruit juice and so many other things--especially after NAFTA. And one would assume it would work with HIT as well--and be wrong.

Healthcare IT is only a device to enable a service process. It does not actually deliver healthcare. It just helps keep track of the healthcare being delivered. And that process is not the same everywhere. In Canada, the first goal of record keeping is accuracy of health data and surety of care. In the US, the first task is bookkeeping--determining payment liability and authority. In the US, there are HIPPA regulations carefully restricting access to patient information. These regulations are much more stringent and litigious than those in Canada, where a "circle of care" is more readily extended to include those brought into a patient's care process. These things change the nature of how electronic-record software should be not only managed and used, but actually structured.

In the US, software has be made to accommodate the tangled web of insurers and pre-authorizations required. Before care other than emergency stabilization can begin, financial responsibility and authorization have to be obtained from any one of a myriad of people and documented. Following that, HIPPA practices (coupled with litigation-risk management practices) require careful and full documentation of patient information and consent. Security functions (ID/password systems and access logging and monitoring) are required to assure HIPPA adherence by providers and facility staff. Then each service, each supply and each provider interaction has to be documented in a way that can later be billed successfully to whichever insurance company, HMO, employer fund or government plan may apply. This is often a complicated mix of incremental payments from a number. There often is still a significant balance to be charged the patient (or their family) which may require financing (and the related software functionality). Healthcare software must handle all of these requirements as core elements. This directs a large part of initial development to service coding, annotation of coding, coding-decision support and back-office interfaces and resources (billing office dataset displays and telecommunications with insurance company databases, for example). And these are core requirements for providers in the US.

In Canada, financial issues are far less complicated; a patient is either Canadian or not (or, in rare cases, not up to date on their Provincial premiums). This immediately clears authorization and billing for the majority of primary care services (more than 90% of all healthcare). For "non-urgent" care; optical and dental, elective services or "extras" like private rooms; billing is to one of the fewer-than-in-the-US insurance companies or to the patient. But the billing process is not a primary function in the electronic record. The "Circle of Care" allows easier involvement of providers and requires less documentation of patient information and consent. While patient privacy and security are highly valued in the Canadian practice, the limitations on provider liability in Canada reduce the urgency for liability-risk mitigation through documentation and security processes. Similarly, coding of diagnoses, treatments and prescriptions are important in the Canadian system, but for different reasons. While the US providers are working to ensure that they get paid, the Canadian providers are more concerned with helping organizations like CIHI in the development of trending data and national care standards (as examples).

Clerks in the US ask "Who's paying?" In Canada, they ask, "What's wrong?"

Software is a device to enable a process. While the goal may be the same everywhere, the process is not. And the software cannot.

Telling Grandma "No."

“...creating a national health insurance to cover everyone will probably increase costs, not decrease them, just as feeding the world's hungry three full meals a day would not reduce our grocery bill. Personally, I think instituting universal health care is the humane thing to do, but let's be honest: Somebody will have to pay for it.”
Dr. Tom Shragg, The Sacramento Bee, Sunday, July 5, 2009

Dr. Shragg describes himself as “a specialist in pulmonary and critical-care medicine with 30 years of experience.” In his opinion piece for the Sacramento Bee entitled “The Conversation: Is health care cost debate focused on wrong issues?” Dr. Shragg looks at some of the leading suggestions for healthcare reform in the US--EMRs, shifting of compensation from specialists to primary-care providers and a “single-payer” system---from his own view as an experienced special-care physician in private practice the US. His primary point is these solutions to rising healthcare costs are either inappropriate or plain wrong.
The doctor describes these foci of cost reduction as “the wrong birds.”
Dr. Shragg’s writing is reflective of his practical history. EMRs, he feels, are only a distraction from the healthcare process. Using and EMR, he writes, “slows me down and diverts my attention from the patient to the computer…These computer records may improve accounting, but not health care.” After 30 years in practice, Dr. Shragg (like most physicians) probably does little of his own charting, as nurses, PAs and other staff would be both taking and charting vitals, lab results, etc. He finds increased compensation for primary care over specialized care to be “naïve,” and “somewhat insulting.” As a specialist, he is understandably sensitive to the legitimate need for specialists. But as such, he has limited experience with the current US system’s “only pay for crises” incentive structure (it should be noted that the Doctor’s group practice does accept payment by most major insurance companies). And lastly, national health insurance might be “humane,” but it would not reduce the cost of health insurance (see above). All three are the “wrong birds.”
So, what does Dr. Shragg consider the “right bird?”
Dr. Shragg describes a 92-year old patient suffering a variety of late-stage ailments; renal failure, stroke and mild dementia among others. Her treatment included oxygen, consultation with a nephrology specialist, in-patient intensive care and dialysis. This is Dr. Shragg’s identified “bird.”
“If you wanted to eliminate the costs associated with that patient's treatment, you would have to empower somebody to deny the care she and her family desired. To borrow a popular expression, the elephant in the room that nobody addresses is the ‘R word:’ rationing.”
The US healthcare conversation is still ongoing, and no consensus has been reached, so it cannot be said if Dr. Shragg expresses the mainstream. But the Doctor’s does demonstrate something particular to US healthcare; commodification. Doctor Shragg’s access points to the issue are remuneration and funding--who is getting paid and who is paying them. In this dialectic, healthcare is a consumable--something to be bought and sold.
Every western nation currently has a national approach to healthcare, ranging from the single-payer/single provider (UK) to nationally regulated private-sector insurance with multiple providers (DE).
US focus on healthcare has only recently expanded beyond academia and industry, while many other nations are already at a “Phase 2” stage of revising a chosen healthcare architecture. In none of these nations is finance any longer a barrier to service. Citizens of the UK do not think about “health insurance.” They have “The National Health Service,” and like the Postal Service, it is expected and committed to deliver to everyone.
In none of these other nations is healthcare thought of as a commodity available only to those possessing adequate resources. They have already decided the question “who gets care?” with “Everyone.” Now they are working on the questions of access, of economies of scale and of quality of patient experience.
Canadian healthcare is one of the more mixed-bags of solutions. While healthcare is nationally defined as a basic right of all residents, its management is the responsibility of the Provinces; thus, there is Alberta Health Services, the Ontario Ministry of Health and the Ministry of Health of British Columbia, among others. Each Province has pursued its own solutions to healthcare. In Alberta, there is a single central authority (at present) that directly oversees each discrete facility. Ontario operates with a mix of state and private insurance, with regulated drug prices far below those in the states. The models in Canada, and the changes in these models are many and varied. As Canada successfully delivers on a national commitment to healthcare for all, the ways of managing delivery, access, quality of care, breadth of care and, yes, cost are always evolving.
This example of one nation successfully implementing a variety of solutions could serve as a valuable resource to the US in developing its own solutions. The US has a free-market hodgepodge of healthcare methods; state and local facilities and services; not-for-profit clinics; private practice and public-service doctors, and; insurances of all sorts. The successful mix of many Canadian models could quickly shorten the US learning curve. But to benefit from the Canadian example---or the French or the Swiss or the German--would still require a shift in US thinking. Other nations manage to deliver medicine and care to all of their people because they hold healthcare as a “must,” not a “maybe.”
Dr. Shragg writes of healthcare as something to be bought or “maybe” given as charity. His is not the only voice to lament the cost of late-stage care; but the US is the only nation to consider first and foremost the cost of care. If the US is to make a national effort (and to date the only national efforts have been the regulation of healthcare products--drug and device approval and patents and licensing), a true commitment by the nation must be made---to the nation.

The Seven Myths of Healthcare Technology 3. Technology Can Do It All

In a letter sent Tuesday to Sens. Edward M. Kennedy (D-Mass.) and Max Baucus (D-Mont.), President Barack Obama reiterated his commitment to promoting the use of information technology as a means of reducing healthcare costs.
healthcareITnews, June 4, 2009
A month later, HealthcareIT news reported
"President Obama called for fixing the broken healthcare system by building upon investments made in electronic medical records in a town hall meeting held Wednesday." [July 1, 2009]

In the US, many of the players--drug makers, provider organizations and insurance companies--have been calling for increased IT investment as the key solution to the problems of healthcare in the US. The advantages of increased IT efficiency are clear. Yet the healthcare business process lags far behind other businesses in the use of electronic automation. Most providers and facilities are just beginning to look at electronic record management, and many are still using only paper records. The most advanced use of IT for healthcare is by the Federal government. The Department of Defense is well along in development of a "lifetime electronic record" and the VA continues to set a high standard for management efficiency. And Medicare/Medicaid manages one of the largest patient bases and payment processes electronically.
But does electronic automation provide ALL the answers?
In Canada, aggressive support of HIT has been a policy of both the Federal and Provincial governments since 2000. A number of hospitals in the greater Toronto area became very active in digitizing patient records and integrating digital patient records into the care process. Record access has been greatly increased. There are years of data recording increased record accuracy and improved efficiency in data entry. Many of the hoped for results have been realized.
Yet, this past year, the Province of Ontario presented a grant pool of millions of dollars to support possible solutions to wait-time reduction. It seems that even after all of the HIT implementations of the last eight years, patients are sometimes experiencing emergency-room waits in excess of five or even 10 hours (these grew even longer in the 2007 flu season). The back-ups waiting for hospital admissions are staggering and seemingly without a solution--even from "fully integrated" HIT systems. According to a 2006 survey by Ipsos Reid, 42% of Canadians surveyed felt that '"a patient wait time guarantee that would reduce wait times for key health services' was the most important to them personally."
So, why has IT not been the solution to the Number One issue for Canadians (lower taxes got only 19%)? Because the solution is not about the technology. According to providers at a number of well-digitized hospitals in Ontario, patient records and patient interaction are great in the ED--patients' records can be created, their histories can be accessed, and intake moves pretty quickly. In-patient care has also been greatly improved; medication conflicts are avoided, patients are correctly identified and prescribed, etc. These providers are quite clear that the breakdown is the connection between in-patient and out.
Because of the differences in workflow and practice, HIT systems are different in the ED than in the rest of a facility. And connecting the data from the one to the information from the other to create usable knowledge that would enable efficiencies is not as easy as just installing a data-mapping agent. It takes people and, more importantly, it takes changes in the ways those people work.
Emergency Department staff do not access bed-management resources. Why would they? Emergency care is just that. And as we have discussed earlier (Myth #1), healthcare providers focus on the immediate task at hand--the here and now. They only look for a clinic/bed assignment when they are done with a patient--and then it can become a rushed, time consuming task for staff both in the ED and on the wards. Perhaps, Upon initial diagnosis of a patient, the search for a clinic/bed assignment were begun (to run in concert with the continued efforts in the ED) in anticipation of an eventual need for admission. Then patients might move more easily and quickly into the inpatient population, and that would reduce the long queues of people waiting in the ED.

A non-technical solution to a problem of technology--Sometimes, Healthcare IT cannot do it all--and should not......

RECs--What, Who and How?

The American Recovery and Reinvestment Act of 2009 (ARRA) has more than just EHR money in it. The act also seeks to encourage the establishment of "regional extension centers" (RECs) to provide support and assistance. Funding is being made available to organizations who meet certain requirements, and this funding is to range from $1-10 Million per year in two-year awards. So far, the government has published some criteria and guidelines for preference. Among other things, they are proposing to give preference to:
• Organizational plans and implementation strategies that include multi-stakeholder collaborations that make use of local resources, such as universities with health-related programs; medical or professional societies; state primary care associations; state or regional hospital organizations; large health centers and networks of rural and/or community health centers; state Area Health Education Centers; HIEs; and government entities such as public health agencies, libraries and information centers with health professional and community outreach programs, and consumer/ patient organizations.
• Applicants identifying viable sources of matching funds, including but not limited to grants from states and not-for-profit foundations, and payment for services from providers.

(as reported by Helen Pfister of Manatt Health Solutions. For her full write up, see ihealthbeat)

Historically, Federal programs have accede to state and local organizations--particularly in matters of geography. And in this instance, as is often seen as sensible, preferred organizations would be those connecting to and working with "local resources, such as universities...and consumer/patient organizations." And while extant organizations may understand their populations, local universities are often restricted in whom they can serve and where they can operate--to the state or locality in question. "State/local organizations" are often funded to serve--and only serve--residents of their state or locality.
In regional community healthcare services, all of this is counterintuitive to success. Providers serving similar populations in similar environmental and economic environments face the same problems and work towards similar solutions. Environments and economies do not stop at the legal boundaries of local or state government. The circumstances and life issues of The Blue Ridge Mountains extend across township, county and even state lines. Providers know this fact that bureaucrats miss. According to a survey of providers and provider organizations released by eHealthinitiative last month (available here), "Nearly half of respondents said that regional extension centers should not be constrained to a specific metropolitan or state boundary." In the eHealth survey, "local government-sponsored entities," are found very poorly suited to manage RECs by 42% of respondents.

The RECs are to provide support, guidance and knowledge-management resources to regional organizations receiving funding. Traditionally, providers have largely depended on publications, conferences and vendors for guidance on industry trends and software support. And vendors certainly meet the
other requirements to;
• Describe proposed levels and approaches of support for providers to be served;
• Address how the applicant would structure its organization and staffing to ensure providers served have ready access to reasonably local health IT "extension agents" and provide training and ongoing support for these critical workers;
• Demonstrate the capacity to facilitate and support cooperation among local providers, health systems, communities and health information exchanges ("HIEs");
• Demonstrate that the applicant is able to meet the needs of providers prioritized for direct assistance; and 
• Propose an efficient and feasible strategy to furnish deep specialized expertise (in such areas as organizational development, legal issues, privacy and security, economic and financing issues, and evaluation) to all providers served, as well as intensive, individualized, "local" presence from an interdisciplinary extension agent to smaller groups of providers assigned to individual agents.

And while vendors are experienced at offering service and support, providers are not that trusting. The absolute last choice by providers and provider groups to manage RECs was vendors--71% of those surveyed find them to be the MOST poorly suited. (Strangely, as to those who DO trust them, only 9% of those surveyed thought they were best suited. Note: Technology vendors made up 11% of the survey).

So who then is to create and manage the RECs?
Associations? HIEs? Not for Profits? Or will new things be formed among vendors, state agencies and inter-jurisdictional NGOs? The comment period for the regulations close at 5pm ET today. It will be interesting to see what people (and vendors, associations and providers) have to day...What do you all think?

The Seven Myths of Healthcare Technology2. Technology Can Do Healthcare

"All involved in the healthcare industry will have to understand the entire healthcare system much more deeply than at present."
Dr. Steven F. Collier, CEO White River Rural Health, Arkansas, US

At the HIMSS GHIT conference this week, Doctor Steven F. Collier presented an overview of his work at White River Rural Health in Arkansas. As CEO, he has overseen the development and implementation of an EMR solution over the past 7 years. With a population spread across 10 counties living in towns (usually) of which the largest is less than 50,000, White River clinics are often the sole providers of healthcare to one of the poorest and most poorly served communities in the US. White River has been lauded as a model of best practices in implementation of EMRs to serve diverse, rural, under-resourced populations. The staff of White River has more than 6 years' experience in driving their technologists to develop and deliver solutions that would serve White River's understanding of their own business; so, when the doctor speaks of "understanding the entire healthcare system," he speaks from great experience and not a little pain.

As discussed in "Myth #1: Healthcare Does Technology," the very dialectics of healthcare are the opposite of those of technology. Healthcare is urgent, responsive and independent where technology development is planned, scalar, and collegial. Healthcare personnel neither understand nor welcome technologists in their environments--and the requirements of technologists do not track to the common expectations of healthcare organizations. Doctor Collier made clear that he is a healthcare provider. He spoke of results in clinical terms, of motivating problems as patient needs, and of success metrics in terms of patient wellness.

Technologists do not share this worldview. They speak of results in processing terms (operations/sec), of motivating problems as "needs for new calculus," and of success metrics in terms of technical performance. And while internal IT personnel may want to deliver solutions that serve the organizations' needs and timelines, external technologists are even less likely to succeed at healthcare. In addition to the cultural gap between technology and healthcare, they have the additional gap of being outsiders to the organization. And they are not just technologists--they are vendors.

Vendors have their own priorities, many of which are counter to both the organizational and the cultural interests of their healthcare clients. "Close-out" delivery of a completed solution is a goal of healthcare. Vendors in HIT have a number of self-serving goals that require more time and less closure. Often, technology solutions involve hastily or imperfectly written pieces of software which require more customization or "shake-down" time than a vendor might care to admit. As the HIT industry is growing so rapidly and as many of the vendor companies are so new, solutions are sold before they are fully developed. This leads vendors to use clients as "beta sites" to extend their development time while garnering revenue. Healthcare organizations are so eager for solutions and are often so averse to technology that they will buy "total solutions" with "full support and maintenance." This puts the IT infrastructure of an organization in the control of the vendor being paid to deliver it--where is the motivation for close-out in that? And vendors are businesses. They sell things; software, services, support, training. While interfacing with clients to deliver one product, they are motivated, even driven to upsell more products. which just pushes out the horizon to "solving the problem," when all healthcare wants is to solve the problem.

In a recent KLAS survey, of all organizations who reported a vendor promising tremendous ROI on an investment, not one was able to report actually realizing it within the original purchase. Not one.

So, if technologist can't do healthcare and if healthcare organizations can't do technology for themselves, what is the solution? Is there a third option?

Myths Will Wait--What's a PHR?

Today's column was supposed to be "The Seven Myths of Healthcare Technology; 2. Technology Can Do Healthcare." However, this evening was the opening reception for the Government Health Information Technology (GHIT) Conference in Washington, DC (June 4, 5 at the Ronald Reagan Center). It was hosted at the Canadian Embassy and there were senior representatives of some of the leading organizations in GHIT. It was a good time; There was talk--and rumour. And news.
The word was that there is an urgent push on the Hill to modify the HIT legislation to include Personal Health Record (PHR) with the Electronic Health Record. This led to an impromptu roundtable of core people from HIMSS and the GHIT conference to consider the question;

"Why a PHR? What Would It Be? How Would It Work?

There were different ideas of "Why." A regulatory thinker felt a PHR to be nothing more than a comfort to paranoid citizens who want to "control" their personal information, but that it could never be used as a trustworthy resource by a provider. A sociological view saw the PHR as an opportunity to gather massive amounts of statistical data to drive cultural, epidemiological and other study data--all identity-scrubbed, of course. Others saw it as a traveler's safety, providing accurate information for use in a critical-care situation.
The group came to see it as having value in each of these ways, but requiring two types of data; Mandatory information written and managed by authorized providers (drug interaction/allergies, for example) and optional data which the patient could modify or erase as they wish (treatment for a wart).
This dichotomy would have specific requirements. Among the many discussed, were;
Data requirements to qualify as a PHA (what information MUST be in the record to qualify as a PHA)
Standards of encoding
Clearly defined, documented and controlled workflows for access, addition, modification and deletion of data.
Security and privacy considerations
Most importantly, a standard storage, transportation and access method
This storage method must have access control; For instance, a method to "sign" for "consent to view" by the patient.
A physically secure method to "sign" for "access to write" by providers.

One method posited for serving these requirements was a smartcard. Specifically, a smart-Social Security-card. As a number is issued at birth (or immigration), data collection can begin shorty after the card is issued, ensuring that even children have a PHA to carry into adulthood.This would, however, have to be a very smart card. It would require two physical sections; one secured against patient access and the other enabled for patient access. These securities would have to be "countersigned" biometrically, perhaps in combination with passcode. There were some high-level workflows discussed as well.
A patient enters a new facility and meets a new provider. They present their smartSScard and swipe a fingerprint reader to authorize read-only access to their data.
Following on treatment, the provider wants to add data to the record. Some may be defined as "mandatory." For example, a new drug allergy is discovered. The provider must also identify biometrically, with crosscheck at a centralized, government record. This data would then be written to the "secured" side of the smartchip.
Some of the data may not be mandatory; Perhaps, notes of elective plastic surgery. These would be written to the "optional" side of the smartchip. All of the data would still be entered into and maintained in the regular medical record.
This is only one workflow. There are still questions; How would a PHR be used when traveling? Would an international standard be developed? How could providers from outside the system add data? If the data is pertinent to critical care, how to access the data when the patient is unresponsive? How could data be added without the specialized equipment needed to access the card, contact external databases and read biometric data? What, if any liabilities could arise from use of PHR data? How would PHR data be validated with the EHR?

Lots of questions. Lots of ideas. The PHR/EHR discussions are picking up, and at GHIT there should be quite a few as they come into play with the panel discussion of remote and rural communities......

Let us know what you think....

Real Time Healthcare?

Warehousing. Storage. Overstocking. These are some of the biggest costs in product-delivery businesses today. BMW and Amazon are just two companies that have each spent millions on technologies to achieve the goal of "Real Time Delivery" (RTD). And in many healthcare models--particularly the revenue-driven US system--patient wait times, materials storage and pharmaceutical overstocking are viewed as "cost-centers" and "productivity negatives." They are leading drivers of some of the largest cascade costs; construction, patient transport, bed allocation and purchasing among them.

There are already solutions being applied to services of healthcare; supply and transport. After all, Real Time Delivery is most obviously about "delivery." Velocity Express, a pharmaceuticals delivery company in Connecticut has customized their services to reduce the management impact on hospital staff and to refine the ability of pharmacies to schedule their deliveries later at night within a 15 minute window. An even more explicit delivery solution is Inform's (of Aachen, DE) SyncroTESS system, software for resource management of ambulances and patient transport resources. But these are solutions developed by vendors for themselves--vendors using their knowledge of their own industries and technologies to streamline their own processes. They then market themselves as working to "take the strain off...care nursing sectors" thus "allowing them to focus on patient care."
In these cases, just as in the cases of outsourced pharmacy management, healthcare is not yet using RTD, but is only paying vendors for the benefits of their own RTD solutions.

So what would RTD of healthcare really be? And can hospitals do it for themselves?

BMW is a leader in RTD, and bumpers at BMW do not mind waiting on the factory shelf. healthcare is different--patients do mind waiting. Wait time reduction is a priority for patients. A 2006 survey found that more Canadians ranked a "patient wait times guarantee" as the Number One priority for the government (42%)--more than twice as many wanting lower taxes (19%) and three times those worried about crime (14%). In response, the government of Canada is now spending millions to reduce wait times in all areas of care ($5 Million at Radiation Oncology in New Brunswick and $38 million to reduce wait times in Ontario regional service clinics are just two examples).
Technology is being applied to this; improved scheduling tools, time-motion studies of "bed-turns," and aggressive support for EMRs. King's Daughters Medical Center in Kentucky US instituted and EMR system in the ED and reduced patient wait times almost by half, from 220 minutes to 118. The EMR, in combination with increased staff to manage workflow, reduced the time spent by staff on paperwork and charting, allowing more time for patient interaction. The goal of RTD is a wait time of zero, and the reduction at King's Daughters is impressive, and ED staff are known as the fastest, most efficient providers in a hospital, so why is there still an average wait time of nearly 2 hours?
A reason that is heard in hospitals everywhere is not about the the ED--it is about the rest of the hospital. The disconnect between inpatient resource management and ED outpatient completion. RTD in the ED needs to address not the real-time delivery of patients TO the ED but the real-time delivery of patients FROM the ED to inpatient systems.
EDs have unique issues and are not as controllable as scheduled outpatient clinics. Yet, average wait times in dialysis clinics and family-care clinics are notoriously long. the average patient wait time in some regional dialysis clinics in Ontario can run to 4 hours. There are no sudden strains on resources as in the ED. But, even with careful time-motion studies and more accurate time-per-treatment metrics, patients are still scheduled for a block of time "Wednesday morning" and required to wait their turn within that period. This drives unnecessary costs in clerical staff time spent managing the on-site patients and accompanying support givers, the costs of these support givers, the need for building and maintaining larger waiting facilities to host both patients waiting for treatment as well as patients waiting for transport after treatment. These wait times could certainly be reduced by automating patient intake with an EMR, as was done in the ED in Kentucky.

But these things requires more than just an EMR. RTD is about an entire system from beginning to end, and a REAL real-time solution requires a systemic approach--an organic, interactive connection of bed management to staff notification to diagnostic scheduling to pharmacy right through to nutrition.
A hospital could choose a solution of a single unified system (like the great promise of EPIC's million miles of modules). Or a facility could opt for a customized automated messaging system (like Commtech of Perth, Australia) in combination with specially trained clerical staff. Either way, the facility is still paying a vendor for a solution. Why? Hospitals do all sorts of things, don't they--from birth to death and everything in between, right? So why can't they do this for themselves?
Well, that's for tomorrow; "The 7 Myths of Healthcare Technology: Healthcare People Can Do Technology......"

BMW and Amazon have each spent millions on technologies to reduce the costs or warehousing, stock and delivery to achieve the goal of "Real Time Delivery" (RTD). At BMW's Spartanburg plant, the goal is to have each batch of new bumpers delivered to the line just as the last one is pulled off the shelf. Amazon is working to order more copies of "Blogging for Dummies" at exactly the right moment to ensure that the new stock arrives at the back of the warehouse just before the last one gets loaded into the Fedex truck out front. Millions have been spent to save billions in storage, excess capacity, shipping and control.
As healthcare has become a business like any other, how to manage the same bottom-line demands? And how to map commercial production solutions to healthcare practices?
There are already solutions being applied to services of healthcare; supply and transport. After all, Real Time Delivery is most obviously about "delivery." Velocity Express, a pharmaceuticals delivery company in Connecticut has customized their services to reduce the management impact on hospital staff and to refine the ability of pharmacies to schedule their deliveries later at night within a 15 minute window. An even more explicit delivery solution is Inform's (of Aachen, DE) SyncroTESS system, software for resource management of ambulances and patient transport resources. But these are solutions developed by vendors for themselves--vendors using their knowledge of their own industries and technologies to streamline their own processes. They then market themselves as working to "take the strain off...care nursing sectors" thus "allowing them to focus on patient care." In these cases, just as in the cases of outsourced pharmacy management, healthcare is not yet using RTD, but is only paying vendors for the benefits of their own RTD solutions.

So what would RTD of healthcare really be? And can hospitals do it for themselves?

BMW is a leader in RTD, and bumpers at BMW do not mind waiting on the factory shelf. Healthcare is different--patients do mind waiting. Wait time reduction is a priority for patients. A 2006 survey found that more Canadians ranked a "patient wait times guarantee" as the Number One priority for the government (42%)--more than twice as many wanting lower taxes (19%) and three times those worried about crime (14%). In response, the government of Canada is now spending millions to reduce wait times in all areas of care ($5 Million at Radiation Oncology in New Brunswick and $38 million to reduce wait times in Ontario regional service clinics are just two examples).
Technology is being applied to this; improved scheduling tools, time-motion studies of "bed-turns," and aggressive support for EMRs. King's Daughters Medical Center in Kentucky instituted an EMR system in the ED and reduced patient wait times almost by half, from 220 minutes to 118. The EMR, in combination with increased staff to manage traffic, reduced the time spent by staff on paperwork and charting, allowing more time for patient interaction. The goal of RTD is a wait time of zero. The reduction at King's Daughters is impressive, and ED staff are known as the fastest, most efficient providers in a hospital, so why is there still an average wait time of nearly 2 hours?
A reason that is heard in hospitals everywhere is not about the the ED--it is about the rest of the hospital. The disconnect between inpatient resource management and ED outpatient completion. RTD in the ED needs to address not the real-time delivery of patients TO the ED but the real-time delivery of patients FROM the ED to inpatient systems.
EDs have unique issues and are not as controllable as scheduled outpatient clinics. Yet, average wait times in dialysis clinics and family-care clinics are notoriously long. the average patient wait time in some regional dialysis clinics in Ontario can run to 4 hours. There are no sudden strains on resources as in the ED. But, even with careful time-motion studies and more accurate time-per-treatment metrics, patients are still scheduled for a block of time "Wednesday morning" and required to wait their turn within that period. This drives unnecessary costs in clerical staff time spent managing the on-site patients and accompanying support givers, the costs of these support givers, the need for building and maintaining larger waiting facilities to host both patients waiting for treatment as well as patients waiting for transport after treatment. These wait times could certainly be reduced by automating patient intake with an EMR, as was done in the ED in Kentucky.
But these things requires more than just an EMR. RTD is about an entire system from beginning to end, and a REAL real-time solution requires a systemic approach--an organic, interactive connection of bed management to staff notification to diagnostic scheduling to pharmacy right through to nutrition.
A hospital could choose a solution of a single unified system (like the great promise of EPIC's million miles of modules). Or a facility could opt for a customized automated messaging system (like Commtech of Perth, Australia) in combination with specially trained clerical staff. Either way, the facility is still paying a vendor for a solution. Why? Hospitals do all sorts of things, don't they--from birth to death and everything in between, right? So why can't they do this for themselves?
Well, that's for tomorrow; "The 7 Myths of Healthcare Technology: Healthcare People Can Do Technology......"