As an experienced healthcare IT professional I am very happy to see that people are looking towards EMRs and automation to improve healthcare staff productivity. However, I'd like to urge a bit of caution and be sure that buyers don't jump into the market for the wrong reason. My rule about automation and insertion of software in any workflow process is simple: if you can't repeat it, don't bother automating it.
How to choose the right software and technology
For most potential users of EMRs, EHRs, and other "complex" workflow automation tools you should ease into the technology. What that means is that before you install any new technology, ensure that first and foremost it does no harm. All technology takes time to implement and get significant improvements; what's important is that while you're working towards improvement you don't harm your business in the process. Technology should first and foremost not make a practice, department, or hospital worse off than it was before the technology was introduced. Then, it should start improving or "healing".
Second, focus on interoperability and best of breed. Our desired tendency is to go for "all inclusive" or "complete solutions" but healthcare is too complex for any single vendor or package to do everything. By focusing on best of breed and interoperability you can grow at your pace and choose solutions that you really need versus those that the vendors think you need.
Third, Ask the right questions of your vendors and staff when they're selecting any new technology. Don't worry about features, functions, and technology. Worry more about your business (which is healthcare and patient happiness) by asking questions like this:
Fourth, make sure the technology fits with your desired outcomes (not tasks). Almost any software will improve some aspects of your business -- but, the question is will the software improve the aspects you care the most about? When asking technical questions, start with some of these:
Fifth, be sure it can handle all the different kinds of data you have. Most vendors or technology providers focus you on what kinds of data they can manage. But, any reasonable office deals with all the following kinds of data and you need to make sure your selection can manage it:
Most software systems handle structured data quite well. In fact, EMRs are an excellent way to capture structured data but in my experience structured data makes up only a small fraction of healthcare data. Semi-structured data and completely unstructured data along with faxes make up a big portion of data and medical images make up an even larger portion of the healthcare data pie. Video and email, chat, and other upcoming technologies will be taking up larger portions of database space as well.
When you're choosing a technology, be sure to look at the kind of data you're capturing regularly and ensure that the vendor you choose and the deployment model you pick are geared towards the data you create rather than the kind of data the vendor can store. Again, almost all vendors are great at structured data but there are very few that are good a non-structured data, faxes, images, and similar information. When looking at "cloud providers" (online software) make sure that the larger data you capture can be fit through your network pipes.
An EMR isn't necessarily the first way to automate
While most people who are new to healthcare IT or looking to jump in quickly always point to EMRs as the most important application, there are actually many different healthcare IT applications that make up the "industry" as a whole. When you're dealing with healthcare IT, EMRs might be a good entry point for some folks but it's actually more likely that EMRs aren't your first place to start your automation journey. These are some other techniques I've used to kick off automation before jumping into full-fledged EMRs:
If you're a physician or responsible for managing an office or an enterprise the government and vendors of technology solutions will be pressuring you to "jump on the bandwagon". Tell them that Shahid said you shouldn't don't drink the Kool-Aid and that it's ok to be afraid of bloated EMRs and ease into medical technology. :-)
I am a frequent reader of your blog. I find your writing very pertinent to my own business. I run a development shop that creates EMR software and our company is currently in a debate about the future of our application architecture. We are a client/server based application. We sell to small clinics, multi-specialty and large hospital settings. We usually play along side the GE Centricity, NextGen, Meditech and AllScripts EMRs - interfacing primarily via HL7. We encounter the same issues as any other client/server based application. There are high deployment costs. Implementations and upgrades are very costly.Recently I have been pushing the strategy (internally in my company) of moving to an ASP model. I have been evangelizing on the merits of this architecture as a way to cut costs and support a more dynamic delivery model. There are obviously many gains to be had.
What I was wondering is in your experience how much of the healthcare application space is already using or is moving towards an ASP model? Is the healthcare world comfortable with this paradigm? We have always written off this model as risky due to HIPAA concerns. Why aren't the major EMRs going this way? Will they? Won't they have to? I just see it as the inevitable evolution.
First, let me thank the reader for the question. Now, let's talk about the state of the applications architecture world in healthcare IT. Lots of healthcare applications are still (yes!) running on mainframes and mid-range computer systems connected to "dumb terminals" running text only user interfaces (using in many cases very old but still quite functional MUMPs software). This is the "big iron".
Most healthcare applications today run on the client/server paradigm with "fat client" applications running either UNIX or Windows on the server and Windows user interfaces on client PCs. This means that the database server is usually on its own computing hardware and the user interfaces (data entry, reports, etc) run on the user's PCs. Very traditional, tried & true, and things work (but have plenty of deployment issues).
There are only a few pure web-based applications out there in the EMR/EHR world. Of course, the PHR world has tons of web based software (almost exclusively). There are many hybrid solutions out there where legacy EMR vendors have put "web portals" in front of their legacy client/server solutions. These portals are often useful but not as useful as complete web-based systems.
There are many companies that have client/server software but also run in an ASP (application service provider) model by using either Terminal Services or Citrix to provide remote and multi-user access from a single deployment architecture.
To answer the reader's specific questions:
In your experience how much of the healthcare application space is already using or is moving towards an ASP model?
Yes, many healthcare IT providers are using the ASP model. It's generally safe and if architected properly it works well. Of course the ASP model using client/server architectures is much harder than the web model but it's certainly achievable using Microsoft and Citrix desktop sharing technologies.
Is the healthcare world comfortable with this paradigm? We have always written off this model as risky due to HIPAA concerns.
Hospitals and large organizations are not necessarily comfortable with external ASP but the small to mid-size market (physicians, small healthcare groups, etc) are comfortable with the model (in fact, they prefer it over on-premise models). However, even the large hospitals and organizations that are uncomfortable using external ASPs would love to use ASP models in their own data centers (in fact, many are requiring it these days).
HIPAA concerns are almost all mitigated these days by using VPNs, leased lines, or other encryption mechanims so it's really no worry.
Why aren't the major EMRs going this way? Will they?
Many are already going this way and those that aren't will whither away quietly.
Won't they have to?
Yes, they will. If EMRs can't be hosted on premises, in an externally managed ASP, in an internally managed ASP, and "in the cloud" simultaneously they won't have a long shelf life. All successful EMR vendors will allow multiple deployment models if they really want to grow big. If you want to stay small you can choose one model; if you want to grow big, you will choose a flexible model.
Last words of advice for all software vendors: don't think that "the cloud" or "ASP" or any specific deployment model will fit all needs. Create a flexible approach using modern web techniques that lets your users tell you how they want things deployed. No single model will work for very long or for a large number of customers.
]]>We all know that blogging, social networking, micro-blogging, content sharing, widgets, and other new media techniques can vastly improve the effectiveness of existing marketing strategies. This keynote presentation that I gave last week was supposed to set the stage for the remainder of the conference by unfolding the landscape of what new media truly means and how it can be effectively utilized to help healthcare systems connect with patients.
I presented almost 20 case studies demonstrating first-rate strategies, a discussion of metrics and how to prove what works and what doesn't which ended up providing a solid overview of new media in the healthcare industry.
The presentation is attached below.
]]>Healthcare Industry Fallacies
Selling to the healthcare community is very hard but not for the reasons they might think. I mentioned that:
Conducting Market Research
Lots of startups don't do basic market research so I suggested the following approach:
How Tech can help Healthcare today (what areas are good to get into)
What types of Business Models to Consider
Some Success Criteria
My feeling is that SOA as a way of defining reusable and portable services for creating composite application as opposed to siloed code components and applications acting independently is still very meaningful and applicable. Whether we want WOA, ROA, SOA, mashups, SaaS, Cloud Computing, etc we still need the basic governance, enterprise architecture, and data-orientation that SOA espouses.
There is a good deal of disillusionment related to SOA but that's because SOA was touted to be the savior of IT. There will be no single savior of IT just like there's no single savior for any complex business or social problem. However, moving to data-oriented and service-oriented architecture in healthcare remain laudable aspirations and design patterns.
Ken Rubin, Chairman of the Object Management Group's (OMG) SOA in Healthcare Conference, invited me to participate in a panel at the Chicago event in early June. He and I chatted about the need for service-orientation in healthcare and both of us concurred that the need is stronger than ever, especially in the light of the stimulus bill's HITECH act and the money that's being pumped into healthcare IT over the next 5 years. If we take that money and stuff it into EMRs and applications alone we'll have squandered a great opportunity.
I wanted to thank Ken for his invitation and think that anyone that's serious about healthcare services and IT should consider attending the conference. The program is outstanding because it's bringing together people who know what they're doing and those who have actually made service orientation in healthcare a reality. Here's a sample of the kinds of sessions you'll be able to attend:
His question is prudent and timely but his comparisons may not have really hit the mark. Let's look at the examples he gave and try to explain why healthcare IT is in the shape that it's in and why money and technology alone are not going to solve the problems.
In Banking, he said "consumers do loads of Internet banking". This is true -- however, the complexity of a banking transaction dwarfs in comparison to an average healthcare transaction (a bank transaction probably has only 5% the complexity of a healthcare transaction). And, if most banks were 1 or 2 person small businesses (like most healthcare businesses are -- over 70% of healthcare is conducted in and most doctors work in less than a 5 to 10 person office) then dealing with them would be difficult, too. For example, small community banks don't have nearly the same technology and super duper online presences as large national banks do; this is similar in healthcare (large players have decent, if not stellar, technology in place.
In finance he said "Transactions, accounting and all aspects of strategy and operations are all digital and computerized." Again, true -- but the majority of financial firms are not 1 to 5 person operations: most stock exchanges, credit card companies, and financial instrument producing firms aren't small businesses. As a better example, look at accounting and tax preparation offices -- there are very few small offices that are technologically savvy; there are no standard rules by which they run and you can't go from one CPA to another and reuse your data unless you manage your own data. If you're comparing the majority of small office doctors to large financial firms that's not a good comparison. If you compare large healthcare businesses with finance firms that's a fair comparison -- and you'll find there's plenty of use of technology to deal with healthcare financial transactions just like normal financial transactions; however, dealing with complex clinical data is a whole 'nother story.
Nari rightly went on to talk about Insurance, manufacturing, resource planning, and other industries. But, the same issue applies -- comparing apples (small "mom and pop" businesses like doctors offices) with oranges (larger firms). Small/tiny firms in all industries are technologically behind because it's tough to work without IT departments.
Nari stepped up and said "there is absolutely no reason for the accounting part of healthcare to be in the 19th Century with scribbles on paper!". However, he's not correct about the fact that the accounting of healthcare is done on paper; in fact, most healthcare financial transactions are conducted electronically through clearinghouses. The clinical parts, however, are almost all paper.
Towards the end Nari said "healthcare advocates are quickly running out of credible excuses on why 30% or all healthcare costs are wasted on repetitive, useless, clerical labor ...on why the same information needs to be entered manually into 30 different forms!" Most of us in healthcare IT couldn't agree more -- that you shouldn't have to fill out the same forms over and over again.
However, thinking that technology will solve this problem is the first mistake. Imagine saying that we'll fix the issues of legal tort reform by adding technology; imagine saying that we'll fix our political process with technology; imagine saying that we're going to tell all CPAs, accountants, and engineers to do business the same way. It just won't work.
For us techies and engineers, imagine that someone told you that as a software engineer you weren't producing good code but by giving you a new IDE and forcing you to use it that it would solve our problems. Even as technologists, look at how much paper we deal with everyday: if we can't get rid of paper, how can non-technologists?
The issues around healthcare will first be solved by incentives, second by consolidation, and third by political and financial healthcare reform. Here's how:
Improving incentives
Today, doctors are paid to see us in the office. Yes, that's right -- your doctor doesn't get paid unless you come to the office to see him. Imagine if your bank couldn't make any interest or fees off your money unless you came to the branch office. What incentive would there be for a bank to allow you to use an ATM?
As long as we don't pay doctors for e-mails, phone calls, virtual visits, telemedicine, and other things it won't matter how much high technology we have. Once we start paying them for taking care of us and not for seeing us and not prescribing medications no amount of technology can be developed that will help reduce time and improve productivity.
Let's look at other industries -- if you spend 15 minutes with your lawyer on an email, he gets paid for it. Your doctor could spend all day with you on email and not get compensated. Same goes for your CPA. It's more valuable for a hospital to keep you another day if the insurance company will pay for it than it is for them to let you out earlier. Hospitals make more money if you get an infection rather than if you don't.
If you dig deeper into healthcare, the majority of the problems are around incentives and the fact that they are setup to do the opposite of what we want. Efficiency in healthcare is not rewarded -- that's why there is inefficiency. It's not a surprise to anyone in healthcare who pays attention to root causes rather than the surface.
Most doctors offices today have the capability to run labs in their office, hospitals have very high tech MRI machines, we have tons of great technology in healthcare for doing healthcare. Because doctors get paid for doing tests, they do more of them than we ever need (30% of all tests are unnecessary). Hospitals get paid more for an MRI than for a simple x-ray so we have more MRIs done than we need to. This is simple capitalism and economics: we humans do the things that we're incented to do. Doctors and hospitals admins are human after all.
Consolidating the market
There are too many small offices to improve technological effectiveness; name a single industry with tons of mom and pop shops that is "paperless" or "technologically advanced". We probably can't -- take a look at small mom and pop jewelry stores, restaurants, convenience stores, etc: can you go from one restaurant to another and they remember your preferences? I doubt it. Ask a CPA what happens when a small business or solo entrepreneur comes to them with information about their business at tax time: boxes of receipts comes to mind, not a "paperless system". But, come tax time for medium to large businesses CPAs have a little eaiser time because systems are in place (efficiencies are rewarded). Same goes for hospitals -- small ones do a inefficient job, larger ones are better in some cases
While I don't advocate it, getting rid of the small physician practices (although that's happening already because they lose so much money given our broken health insurance system), unless we can consolidate mom and pop small cottage healthcare businesses into larger healthcare enterprises that can effectively implement technology we'll stay in pretty bad shape.
Take away
As someone who's seen the ups and downs of the healthcare IT spectrum in the trenches at small and large healthcare settings, I'm afraid that we're going to put too much reliance on technology and forget that simple capitalist rules: the market creates the kinds of businesses we have and the market can fix it if the incentives are properly aligned.
I would be the first to say that we need to improve the usage of healthcare IT; but, first, we need to create the environment in which such technology may actually be useful and could flourish.
This is not an excuse from a healthcare IT guy -- i spend half my time on non-healthcare clients and know exactly what technology we need in healthcare. I wrote this posting because if we try to dumb down the problems in healthcare we'll think that technology can solve the issues without more fundamental change and we'll be back to this same place in 10 years.
]]>Large-scale object-oriented applications development, which is fairly new to healthcare, has not improved our ability to manage data using sound data management principles. This is because in the world of objects, data is simply considered part of the state of an object. For example, a person object's demographics are considered the state of the person object. An encounter's data is considered state of a transaction object. Most modern object-relational mapping (ORM) tools try to hide SQL and the underlying relationships of the database. This is great if the data model is designed from the ground up by a relational modeler and then the ORM is applied on top of it. More often than not, though, the ORM is used to generate the schema - which means that an application programmer is determining the data model, not a data modeler. What's wrong with that? Simple: if the application were the most important thing, that's fine but if we want the data to live forever we need to define the data, its usage, how it's structured, etc before we design the application and not the other way around.
Our friends in the health IT applications development community need to be taught that data modeling is not just a technical exercise. You can't define a data model with a bunch of engineers and other "geeks" sitting around a table. Data modeling is about understanding all the uses of the data, the relationships and attributes involved in the data, and most importantly how the data management approach will grow and change in the future. It's the last part (extensibility of the database) that is often forgotten in most systems. All this involves direct communication with end users, stakeholders, and other non-technical personnel. This seems pretty obvious but in my 15 years of experience I've learned that databases are treated as a file cabinet - just let your application toss whatever is necessary in there and then we'll deal with organizing it later. When you do that, it's a recipe for disaster.
When you're building your own systems, you should attempt to use tried and true data models from existing sources. If you don't have hotshot data modelers, look at Len Silverson's two-volume work The Data Model Resource Book: A Library of Universal Data Models for All Enterprises. Buy the two books, try to comprehend what an extensible data model looks and works like, and then hold your developers and database administrators accountable for it. If you're building a healthcare meta model, there are even books available that cover universal meta models. Unlike a few years ago, there are books which provide de facto, well designed, data models so you're not on your own. If a developer comes to you with a data model but can't provide references and patterns for how he arrived at his model, tell him to use one of the ones described in a book. There's no time to keep reinventing the wheel.
When you're buying new systems, spend more time evaluating the database design than the application's user interface (UI). The UI can easily be changed in the future but the data model is not a trivial change (and when the vendor changes the data model you'll be in a world of hurt). If a vendor does not let you analyze or study their data model, don't buy from them. That's like a car deal selling you a car without you being able to check the engine. When you're evaluating a data management system (and in health IT almost all systems are data management systems) then focus on the data, not the applications. You could even use the Silverston type books referenced above to make your vendor compare their data models against other well known designs.
With all the talk around "patient-centric" architecture you'd think that the vendors have a data model to support it. Of course, we all know that they don't and we need to hold them accountable for it. And, with all the new integration needs being identified by RHIOs, NHIN, PHRs, and EHRs, data models are even more crucial. Applications will continue to be chopped up in a service oriented architecture, making the central database even more powerful.
The lesson here is simple: because applications come and go but data lives on forever, don't ignore the data model.
]]>However, that couldn't be farther from the truth. Most IT systems like EMRs, EHRs, and other medical record capture and retrieval products are purportedly designed for physicians but they really are created to improve the hospital administrators' lives, get data to government agencies looking for comparative medicine, push paperwork through to insurance companies so that they can deny claims faster, and many other "features" that don't really do anything for the doctor.
The problem is not that doctors don't like IT, it's that they don't get the same value out it that other participants in the system do.
EMRs today are like CASE tools were back in the early 90's. Think back to the early- to late-90's and all the talk surround CASE (computer aided software engineering) and how, by automating requirements gathering and coding tasks we would "improve the engineer" and perhaps even get rid of programmers. Pretty soon we realized that programming is a cognitive process not easily modeled or automated -- we realized that the training and tasks performed by programmers and engineers can't easily be improved. Once we gave up on CASE tools (and how to improve programmers' thought processes) we learned that we could improve significant tasks like editing, compiling, testing, etc and the actual application lifecycle.
The same way CASE tools failed to improve programmers and thus failed as an industry, EMRs that strive to improve physicians' thought processes or try to change how they treat patients will fail as well. That's because physicians are trained in a combined scientific and socratic method -- based on case studies backed by science. Physicians using EMRs will be no better doctors than lawyers would be better lawyers because they use a case management system.
So, how do we get physicians to change their behavior and adopt healthcare IT systems? Easy. You can't in the short term. In the long term, once we figure out that the edges of healthcare (as opposed to the direct patient care) can be easily improved through better operations and automation of routine tasks we'll end up creating useful systems.
And therein lies the rub: physicians will not adopt systems that do not provide clear and easily understandable value to them (not just their employers). Because most EMRs today have more value to hospitals, government, and insurance firms and little or no innate value across the board to doctors there won't be huge adoption like we're hoping. Here are some simple questions that doctors will want answered before they adopt anything:
These are usually the kinds of questions going through physicians' heads when you're showing them a system. If you're not ready to answer them your solution probably has little value to them and they're not about to change their behavior to adopt it.
]]>My simple advice to most CEOs and CIOs about project management starts with a question: can you methodically and manually repeat the thing you are trying to automate? If the answer to that question is "no" then no PMO, no project management technique, not even the smartest most talented people in the world can help automate something that can't at least be repeated consistenly manually.
This advice of asking a simple question about repeatability might sound so obvious as to not even bother asking it but it becomes perilous not to do so. At the heart of most failed software automation attempts is a failure to understand the workflow and gather the right requirements. That's pretty easy to figure out. What's not so easy to figure out is: why is the workflow so hard to gather requirements for? It's probably because the workflow, while it seems consistent at the high level, isn't repeatable enough consistently to describe in software. Perhaps parts of it are, but maybe the entire workflow isn't.
So, as a senior executive that may not be leading the project, but may be green lighting it, what you need to do before making a decision is have your project managers describe that they can clearly repeat (manually and consistently) what they are trying to automate. If not, get the process engineering guys in there to work on the process before the geeks get in there to work on the technology. The rule is simple: if you can't repeat it manually, don't bother automating it.
]]>Many of us will be trying to use the new stimulus funds over the coming years to buy new systems so I wanted to give a little advice. Be careful with your selection because it's much easier to get into a system than to get out of one. The initial exuberance of getting into a new IT system always make you feel that things will continue to go well into the future. Of course, that's rarely the case.
We've all seen it: we spend weeks or months in the "sales and demo cycle" for our applications. If we're lucky we consider all workflows, if we're even luckier we test drive the UI and make sure training goes smoothly, if we're smart we also try to ensure that deployment will be easy. However, what we all seem to forget is to figure out how to get out of an application or system after it's been installed for a while.
Why is getting out important? Because every application becomes "legacy" sooner or later. Every system will be replaced or augmented at some point in time. The cost of acquisition ("barrier to entry") is well understood now as something we need to calculate. How about the barrier to exit or switching cost? Do we calculate that when we decide what systems to purchase? Why not?
If you can't answer the "how, in 24 months, will I be able to move on to the next-better technology or system?" question then you've not completed your due diligence in the sales cycle.
When preparing an RFI or RFP or when you're looking to purchase any new system, ask vendors specific questions about how easy it is to get out of their technology (rather than just how easy to it is to deploy and interoperate). Put in specific test cases and have your folks consider this fact when they are looking at all new purchases. Here are some specific factors to consider: