Some of the most frequent questions I receive these days surround data interoperability and integrating multiple health IT systems. One of the biggest problems in connectivity is matching patient record data and ensuring that the same patient data in different systems is linked properly. Given how many times this topic comes up, I reached out to Cameron Thompson, Acxiom Healthcare Group Managing Director. Acxiom has an interesting method of patient data matching, called persistent links, and when I saw what they were doing for matching consumer records in non-healthcare settings (e.g. marketing) I thought some of you might want to learn about it. Here’s what Cameron had to say about the various techniques for matching patient data:

The promise of secure and seamless exchange of patient healthcare information is powerful. As payers, providers, Health Information Exchanges (HIXs) and Accountable Care Organizations (ACOs) move rapidly toward the full deployment of electronic medical records, healthcare IT professionals are grappling with a fragmented network of systems and data silos. These disparate systems and databases often house redundant copies of patient medical data in multiple formats, which limits the ability to see a true 360-degree view of the patient. The benefits from connected patient data are many, including:

• Reductions in inaccurate coverage determinations.
• Intelligent information sharing for clinical decision making.
• Honoring patient consents and preferences consistently and accurately.
• Minimizing risks of data breach with a unique health identifier that allows the transfer of patient information but NOT personally identifiable information such as name and address.
• Reduction in time and effort in administrative processes including billing or claims inaccuracies.
• Avoiding costly duplication or unnecessary testing.

To reduce these inefficiencies and solve the underlying problem, the new healthcare ecosystem needs an accurate means of identifying and matching patient record data to the correct individual across internal and external healthcare systems, including collaborative care delivery models.

Multiple systems across the healthcare enterprise produce duplicate patient records that are not easily recognizable as matches. Recognizing that Mary Jane Smith at 123 Elm Road in the 2009 clinical laboratory system is also Mary Collins of 78 Oak Street in the 2011 patient registration system is a challenge for any organization. Identifying a solid method for distinguishing patient information across multiple data systems and combining the data accurately will be pivotal to the effective adoption of Electronic Health Records (EHRs) and successful implementation of Health Information Exchange (HIE).

As organizations take on this challenge, several methods have been identified and considered to recognize an individual. Three leading methods can to be explored to achieve your business goals of continuity and cost reduction. These are:

1. Algorithm or String-Based Matching

An organization can develop an algorithm with string-based matching using identifiers in the existing data to uniquely identify individuals. The benefits of string-based matching include:

• Recognizable practice – This is a well-known practice and resources capable of creating these programs are plentiful.
• Options for processing – Algorithms can be created internally and run without sending data outside the organization or an external organization can be identified to conduct the match on the organization’s behalf.

Some of the challenges with this strategy include:

• Inherent challenges in string-based matching – String-based matching relies on consistencies in reported names and addresses, which tend to change often.
• Ensuring the accuracy of the data used in the algorithm – Manually entered names and addresses are often laden with inexactness. This makes string-based matching more difficult.
• Absorbing the costs to develop and enable this identifier across systems – Costs would need to be incurred to develop, maintain and put the identifier into use across systems.

2. State-Issued Number

An organization can use another state-Issued number such as a state of issuance and birth certificate number. Benefits of this method include:

• Development cost savings – using existing assigned identifiers would save costs on development of a new identifier.
• Availability – an organization could select an identifier that is already available in many systems.

Some challenges with this strategy include:

• Inconsistent data fields and record lengths – if state issued numbers are of different lengths this could create difficulty for the programmer creating the data field.
• Protecting personal information from fraudsters – using a state-issued number could raise concern over identity theft with the proliferation of stolen Social Security numbers. Whether real or perceived, this information being made available opens the door for fraudsters to invade an individual’s privacy.

3. Persistent Links

Healthcare organizations should consider the use of highly accurate match technology that delivers knowledge-based persistent linking. This match technology delivers a set of persistent links a company uses to recognize their patients across a fragmented network of systems and data silos. Persistent Link match technology is regarded as the most precise match technology available to accurately resolve patient identity (such as AbiliTec, the linking technology offered by my company, Acxiom). The link provides a consistent, client-specific ID, across data variations, and it can be applied at all touch points and databases within an organization.

The use of persistent links, created from knowledge-based match technology, can provide:

• More accurate patient recognition and identity resolution.
• Greater control and governance around the patient data because each healthcare entity receives a dedicated set of encoded links, specific to their enterprise. This facilitates link transactions, minimizing the amount of personal identifiable information exchanged, aligning with the need for HIPAA compliance. Further, when multiple entities interact (e.g. an Accountable Care Organization between provider and payer) a unique link reconciliation can be processed by the provider in batch or real time.
• A minimized amount of personal information that a healthcare entity needs to store as they use encoded links to integrate data and recognize patients.
• Eliminate an upfront investment to develop and maintain identifiers. The first two options I mentioned – algorithms/string-based matching and state-issued numbers – require healthcare entities to develop and maintain the identifiers.
• · Creation of a refresh cadence based on specific business needs, say monthly or quarterly, reducing non-matching exposure to the cadence latency.

There are also some challenges related to using persistent links:

• Persistent link application and maintenance will be more costly and an organization needs to be willing to look at the investment in higher quality.
• The healthcare organization needs to be willing and able to transmit records with personally identifiable information in a privacy compliant manner, such as encryption.

As healthcare organizations move forward by adopting technology to improve patient experience they will find that the accuracy of the data will drive their success. Organizations should consider each of these methods for recognizing patients, each have their benefits and select the method that best meets specific organizations needs.

The foundation of an effective provider and payer relationship depends on recognizing the patient throughout the continuum of patient care. If the healthcare community can provide accurate patient information, billions of dollars can be captured yearly and patient healthcare would become much more efficient, inevitably leading to improved outcomes.

The Linux Foundation has invited me to speak about how to use Android in Medical Devices on Monday, February 14 at the Android Builders Summit. If you’ll be at the Summit or are in the San Francisco area and would like to meetup at or near the event, please reach out to me via speaking@shahidshah.com.

Here’s the abstract of my talk on Monday:

FDA regulated medical devices are considered safety-critical systems due to their ability to affect patient lives. Given the nature of scrutiny and the requirement to play it safe, most medical device vendors end up choosing proprietary or custom solutions for operating systems, databases, messaging platforms, alarm notification systems, and event logging. This talk will uncover some of the common misconceptions around government regulations and how there are not inherent limitations around using Android or FOSS in safety-critical systems so long as the requisite risk analysis and quality assurance work is conducted. Shahid will present his recent work on modern medical device architectures built on Android and the challenges and opportunities associated with using Android in medical devices. Questions such as these will be answered: Will the FDA accept open source in safety-critical systems? Are Android systems safe enough for medical devices? What kind of assessments are needed for Android software in medical devices?

If you’re in the DC area near NIH please join me tomorrow as I lead a discussion on why MU is insufficient for EBM and CER. Here are the details:

When:  3:30 – 5:00 PM, Thursday, February 9, 2012

Where:  NIH Clinical Center (Building 10 North), Hatfield Room 2-3330

Abstract: Comparative Effectiveness Research (CER), which is being rechristened “Patient-Centered Outcomes Research” (PCOR), is all about using clinical outcomes research comparing different interventions and strategies to prevent, diagnose, treat and monitor health conditions. What’s known is that CER/PCOR is impossible without clinical data interoperability; what’s unclear is how to create simple, practical, solutions to data interoperability without creating or buying mountains of systems. Join me in this talk where I will review an open source architecture that can be implemented in almost any clinical setting to increase and improve the amount of clinical data available to feed CER and PCOR initiatives.

If you’d like directions to the NIH Clinical Center or the Hatfield Room please drop me at note at speaking@shahidshah.com.

This is the next post in my series of Do’s and Don’ts Healthcare IT. As we all know, some of our most important citizens live in rural settings, small cities, the countryside, or remote areas. These areas have smaller populations and less direct access to vital healthcare resources. In the past 15 years or so we’ve made some great strides in remotely accessible healthcare; these offerings, called telemedical tools, provide important clinical care at a distance. Here are some do’s and don’ts of telemedicine:

• Do use commonly available web meeting and online video tools bring expert caregivers anywhere. WebEx, GotoMeeting, Adobe Connect, Skype, and a variety of other “web meeting” tools used mostly in professional office settings and remote sales pitches are wonderful tools to connect caregivers in populated communities to their rural patients. A simple $30 to $50 per month account on the physician side with almost no direct cost for the patient is an excellent way to engage with patients. These kinds of web meetings can happen securely either at the patient’s home or patients can be brought into satellite offices with high-quality telepresence. Then, instead of waiting for days or weeks for a health professional to travel to an area or patients having to take off many hours or entire days traveling to experts in big cities, care can be given almost immediately with less inconvenience. Don’t assume that kinds of web meeting solutions are HIPAA compliant out of the box; however, do realize they can be made HIPAA compliant with appropriate protections.
• Do use medical devices for remote monitoring of in-home care improve clinical observations. While web meetings are great for basic primary care, it’s not perfect for elder care, long-term care, and other types of clinical requirements. There is a new class of devices that can put near-hospital-quality patient monitoring devices into patient homes and “beam” that data to monitoring centers that can watch for important events across many patients in different geographical areas. Toss in a nurse or other caregiver that can visit once a week or once a month to calibrate the devices and you can see how much more convenience patients can have and have their physicians, wherever they may be, have immediate access to their actual vitals and clinical status.
• Don’t assume that medical device connectivity will be fast or easy to do on your own — you’ll need something like Qualcomm’s 2net platform. 2net is a trustable, Class I FDA-listed, standalone gateway with an embedded cellular component that sends clinical data truly “in the cloud” without requiring local internet connectivity. Medical data can be sent from devices in the same way that e-books can be read on Kindle devices – using 3G cellular, from mobile phones, and software APIs.
• Don’t always send patients to labs; instead, take labs to patients with mobile imaging and lab specimen collections that allow remote reading and web-based report distribution. It’s difficult for many rural communities to have their own full diagnosticians but mobile imaging centers and lab specimen “kiosks” can do the X-rays, take pictures, and perform collections and then send the data electronically to large populated centers where they can be “read” and analyzed; the reports can be distributed via secure e-mail or other web-based applications to doctors in the rural areas or physicians remotely available and connected through web meeting or other similar tools.
• Do try and make behavioral health, mental health, and related care made more accessible. Veterans of our foreign wars are coming home with many problems that can be easily diagnosed with proper access and many of the veterans live in rural communities; while primary care and specialty care is difficult to get in smaller population regions, behavioral and mental health is even harder to access. Telemedical assistance through online chat, Skype-like video conversations, and secure online messaging can provide quick relief.
• Don’t leave patients on their own and encourage them to join online communities. Online community building tools allow populated city citizens to meld with their rural counterparts. Patients helping other patients is a terrific approach to extending care; sometimes what a patient needs is not necessarily a health professional but a curated session with fellow patients going through the same problems. Online, electronic, community tools such as PatientsLikeMe.com can connect geographic communities and bring them closer together without increasing costs or requiring anything more than a simple mobile phone or computer.

What do’s and don’ts would you add to a telemedicine strategy? Drop me a comment below.

I recently wrote, in Do’s and Don’ts of hospital health IT, that you shouldn’t make long-term decisions on mobile app platforms like iOS and Android because the mobile world is still quite young and the war between Apple, Microsoft, and Google is nowhere near being resolved. A couple of readers, in the comments section (thanks Anne and DDS), asked me to elaborate mobile and mHealth strategy for healthcare professionals (HCPs) and hospitals.

A couple of the key points were:

• (Anne) how can you avoid making long-term mobile decisions at this point?  After all, hospitals that don’t steer their doctors are going to be managing whatever technology the doctors invest in, aren’t they?
• (DDS) the risk is that people will take this to mean that they shouldn’t move at all on mobile app platforms, and this would be a mistake. This is the perennial issue with health IT; if it’s not perfect, then wait.

The approach I recommend right now for mobile apps, if you’re developing them yourself, is to stay focused on HTML5 browser-based apps and not native apps. So, to answer Anne’s and DDS’s question specifically, no you shouldn’t wait to allow usage of mobile apps by anyone; but, if you’re looking to build your own apps and deploy them widely (not in simple experiments or pilots) then you shouldn’t write to iOS or Android or WP7 but instead use HTML5 frameworks like AppMobi and PhoneGap that give you almost the same functionality but protect you from the underlying platform wars. In the end, HTML5 will likely win and it’s cross-platform and quite functional for most common use cases. If you’re not developing the apps yourself and using third-party apps, then of course you must support the use of iOS native, Android native, and soon Windows native apps on your network.

So, from a general perspective you should embrace mHealth but do so in a strategic, not tactical manner. Here are the most critical questions to answer in a mHealth strategy — it’s not a simple one size fits all approach:

• How will you allow doctors’ or patients’ own devices within your hospitals / organizations — simply by providing connectivity and wireless access on the production network or some other means?
• How will you allow doctors’ own devices to connect to hospital IT systems?
• How will you extend hospital IT systems via hospital-owned mobile devices?
• How will you allow the hospital or organization to “prescribe” the use of apps to patients and track the usage of apps?
• How will you approve or deny the use of certain apps that may not meet FDA regulations if they get close to MDDS or Class 1/2/3 devices?

If there is interest in this topic, I will expand on my list of Do’s and Don’ts — mHealth is a very complex topic and requires a good strategy. Just saying that you allow the use of mobile devices like smartphones in your hospital is not an mHealth strategy.

In case you haven’t seen it, MU attestations data is now available on Data.gov and it includes analyzable vendor statistics.

The data set merges information about the Centers for Medicare and Medicaid Services, Medicare and Medicaid EHR Incentive Programs attestations with the Office of the National Coordinator for Health IT, Certified Health IT Products List. This new dataset enables systematic analysis of the distribution of certified EHR vendors and products among those providers that have attested to meaningful use within the CMS EHR Incentive Programs. The data set can be analyzed by state, provider type, provider specialty, and practice setting.

The data set does not include dollar amounts or the difficulty of attestation (e.g. how many times it took to pass). I’ll try and find out if that data might be available in the future. It’s also unclear whether the provider counts were broken up into each line (meaning one provider per row) or if multiple providers were aggregated into lines (meaning multiple providers were grouped).

The dataset is available now on Data.gov at http://www.data.gov/raw/5486 and is worth checking out. Since the file has been downloaded over 75 times, it’s clear some of you already know about this so if you’ve done some analysis with it; if you’ve done any analysis or posted results please drop me a note below so that everyone can benefit.

Last year I started a series of “Do’s and Dont’s” in hospital tech by focusing on wireless technologies. Folks asked a lot of questions about do’s and dont’s in other tech areas so here’s a list of more tips and tricks:

• Do start implementing cloud-based services. Don’t think, though, that just because you are implementing cloud services that you will have less infrastructure or related work to do. Cloud services, especially in the SaaS realm, are “application-centric” solutions and as such the infrastructure requirements remain pretty substantial – especially the sophistication of the network infrastructure.
• Do consider programmable and app-driven content management and document management systems as a core for their electronic health records instead of special-purpose EHR systems written decades ago. Don’t install new EHRs that don’t have robust document management capabilities. Do consider EHRs that can be easily integrated with document and content management systems like SharePoint or Alfresco.
• Do go after virtualization for almost all apps – as soon as possible, make it so that no applications are sitting in physical servers. Don’t invest more in any apps that cannot easily be virtualized.
• Do start looking at location-based asset tracking and app functionality; your equipment should be aware of where it’s physically sitting and be able to “find itself” and “track itself” using location-based awareness. Don’t invest heavily in systems that can not support location-based awareness (like potentially allow or disallow logins based on where someone is logging in from as well as enable / disable certain features in applications on where logins are occurring).
• Do start implementing single sign on and common identity management with CCOW integration. Don’t invest in any systems that cannot meet common identity or SSO requirements.
• Don’t make long-term decisions on mobile app platforms like iOS and Android because the mobile world is still quite young and the war between Apple, Microsoft, and Google is nowhere near being resolved. A platform that looks strong today may be weak tomorrow and become legacy quickly; however, HTML5 is not going anywhere and will be ultimate winner of the next 15 years just like HTML4 is the winner from 1995 to now. Do start investing in HTML 5 and CSS3 and away from HTML4. Don’t install any more apps that require IE6/7 or older browsers and don’t invest in systems that don’t have HTML5 in their roadmaps.
• Don’t write applications on top of legacy EHR platforms; write applications with proper HL7 connectivity and platform independence. Most EHR platforms are using technologies that are either ancient or need to be replaced; by integrating deeply but remaining independent of their technologies you’ll get the best of both worlds.
• Don’t buy any medical devices from vendors that don’t have a deep and thorough medical device to healthcare IT enterprise connectivity strategy. If a device doesn’t have wired or wireless TCP/IP access, doesn’t have data export or HL7 connectivity is not worth purchasing.
• Don’t buy any thick-client applications that do not have thin-client “remote viewers” available.

One of the most important activities you can undertake before you begin your EHR implementation journey is to standardize and simplify your processes to help prepare for automation. Unlike humans, which can handle diversity, computers hate variations. Before you begin your software selection process, get help from a practice consultant to reduce the number of appointment types you manage, reduce the number of different forms you use, ensure that your charting categories (“Labs”, “Notes”, etc.) don’t look different per patient type or physician, determine how you will manage medication lists and problem lists across the patient population, and deal with how you’ll manage paper in your digital world.

If you spend even just a few hours a week doing the prep-work before you buy any software, you will be better prepared in your selection process. Without some level of standardization your EHR implementation will either fail, be delayed, or have many unhappy users; the more you can standardize and simplify, the more likely you will have a successful outcome. A strong project manager with authority to make decisions will be the difference maker in the simplification process.

To help you with your workflow assessment and standardization efforts, check out the The Agency for Healthcare Research and Quality (AHRQ.gov) Workflow Assessment for Health IT Toolkit. Even if you’ve done workflow assessments before, the toolkit is worth checking out.

As most of my regular readers know, I work as a technology strategy advisor for several different government agencies; in that role I get to spend quality time with folks from NIST (the National Institute of Standards and Technology), what I consider one of the government’s most prominent think tanks. They’re doing yeoman’s work trying to get the massive federal government’s different agencies working in common directions and the technology folks I’ve met seem cognizant of the influence (good and bad) they have; they seem to try to wield that power as carefully as they know how. Since most of you are in the technology industry, albeit specific to healthcare, I recommend that you learn more about NIST and the role it plays – they can make your life easier because of the coordination and consensus building work they do for us all. I, for one, was thrilled when NIST was picked as the governing body for the MU certification criteria. These guys know what they’re doing and I wish they got more involved in driving healthcare standards.

A few years ago NIST came up with the first drafts of the seminal definitions of Cloud Computing; they ended up setting the stage for communicating complex technical concepts and helping making “Cloud” a household name. After 15 drafts, the 16th and final definition was published as The NIST Definition of Cloud Computing (NIST Special Publication 800-145) in September. It’s worth reading because it’s only a few pages and is understandable by the layperson. No computer science degree is required.

Yesterday I was speaking to a senior executive in the EHR space and we had a great discussion on what healthcare providers are doing in terms of cloud computing and how to communicate these ideas to small practices as well as hospitals. It reminded me of the numerous similar conversations I’ve had with other senior executives we serve in the medical devices and other regulated IT sectors. In almost every conversation I can remember about this topic over the past couple of years, I had to remind people that NIST has already done the hard work and that we can, indeed, rely on them. Most of the time the senior executive was unaware of where the definitions came from so I figured I’d put together this quick advisory.

My strong recommendation to all senior healthcare executives is that we not come up with our own definitions for cloud components – instead, when communicating anything about the cloud we should instruct our customers about NIST’s definition and then tie our product offerings to those definitions. The essential characteristics, deployment models, and service models have already been established and we should use them. When we do that, customers know that we’re not trying to confuse them and that they have an independent way of verifying our cloud offerings as real or vapor.

Below I have copied/pasted from NIST 800-145 their key definitions. Imagine how many debates you would avert with technicians at clients when, during conversations with a client, you communicated some of the following information first, showed them how it was a “standard definition” and handed them a copy of the publication, and then mapped your offerings and discussions to the different areas. Your sales teams and the marketing teams would appreciate the clarity, too.

Note that you do not need to map every offering you have to every definition – just start mapping the obvious ones and then figure out how you can communicate the “gaps” as being not applicable to your products / services or if those gaps will be filled in the future as part of your roadmap. Treat these definitions as canonical but not inclusive – meaning that just because your SaaS offering doesn’t fit every essential characteristic doesn’t mean that you’re not “cloud” – it just means partially cloud.

If you’ve got questions about how to map your product offerings, drop me some comments and I’ll assist as best as I can.

Here are the key definitions from NIST 800-145, copied directly from the original source:

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models.

Essential Characteristics:

On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.

Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).

Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth.

Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.

Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability¹ at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

Service Models:

Software as a Service (SaaS). The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure². The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Platform as a Service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider.³ The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.

Infrastructure as a Service (IaaS). The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).

Deployment Models:

Private cloud. The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises.

Community cloud. The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it may exist on or off premises.

Public cloud. The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider.

Hybrid cloud. The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).

Productivity loss and workflow disruptions are commonplace as our industry gets on the Meaningful Use bandwagon and is starting to adopt EHR systems at a slightly more rapid pace than in previous years (things aren’t really as rosy as many think, but the pace is picking up). The reason we have productivity loss is that we focus changing the behaviors of our most expensive resources too early in our automation journeys – we go after doctors first.

My experience, and some basic math, shows that if you want a physician to be more productive you first make sure their supporting staff have the tools they need to reduce the physician’s burdens. Only after you’ve optimized those around a physician do you then go after improving the physician’s productivity.

According to research done by GE, you need (on average) about 5 supporting resources per physician to help manage patient records and a bit more to support patient care. What if we focused on building software and systems for optimizing the work of the 5 resources around the doctor first? What if we offered more capabilities for patients, with proper verification and validation by a professional through simple tools, to self-manage their data directly in EHRs? Not just through portals, but real collaborative care management tools.

Physicians are highly trained, which means they have years of things to “unlearn” if you change their workflows and they are (generally speaking) well paid which means if you any mistakes and disruption in their workflows is far more expensive than for supporting staff. Of course, the opposite is also true: if you get the automation right, the return on the investment is certainly worth it; the problem is, while ROI might be high, the risk of loss is also high.

This advice may seem obvious, but the architecture, design, user experience, and implementation of existing health IT apps don’t always heed it. I’m sure we all see, over and over again, that many apps are being written to increase documentation and data entry requirements by doctors – instead of using system integration, medical device connectivity, and other simple technologies like worklist management to reduce the workload.

As I mentioned above, productivity loss and workflow disruptions are commonplace with EHR implementations – drop me a note below about how you think vendors should change their products to make things better.