Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

Practice Fusion Settles FTC Charges Over “Deceptive” Consumer Marketing

Posted on June 20, 2016 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

In what may be a first for the EMR industry, ambulatory EMR vendor Practice Fusion has settled Federal Trade Commission charges that it misled consumers as part of a campaign to gather reviews for its doctors.

Under the terms of the settlement, Practice Fusion agreed to refrain from making deceptive statements about the privacy and confidentiality of the information it collects from consumers. It also promised that if it planned to make any consumer information publicly available, it would offer a clear and conspicuous notice of its plans before it went ahead, and get affirmative consent from those consumers before using their information.

Prior to getting entangled in these issues, Practice Fusion had launched Patient Fusion, a portal allowing patients whose providers used its EMR to download their health information, transmit that information to another provider or send and receive messages from their providers.

The problem targeted by the FTC began in 2012, when Practice Fusion was preparing to expand Patient Fusion to include a public directory allowing enrollees to search for doctors, read reviews and request appointments. To support the rollout, the company began sending emails to patients of providers who used Practice Fusion’s EMR, asking patients to review their provider. In theory, this was probably a clever move, as the reviews would have given Practice Fusion-using practices greater social credibility.

The problem was, however, that the request was marketed deceptively, the FTC found. Rather than admitting that this was an EMR marketing effort, Practice Fusion’s email messages appeared to come from patients’ doctors. And the patients were never informed that the information would be made public. And worse, a pre-checked “Keep this review anonymous” only withheld the patient’s name, leaving information in the text box visible.

So patients, who thought they were communicating privately with their physicians, shared a great deal of private and personal health information. Many entered their full name or phone number in a text box provided as part of the survey. Others shared intimate health information, including on consumer who asked for dosing information for “my Xanax prescription,” and another who asked for help with a suicidally depressed child.

The highly sensitive nature of some patient comments didn’t get much attention until a year later, when EMR and HIPAA broke the story and then Forbes published a follow up article on the subject. After the articles appeared, Practice Fusion put automated procedures in place to block the publication of reviews in which consumers entered personal information.

In the future, Practice Fusion is barred from misrepresenting the extent to which it uses, maintains and protects the privacy or confidentiality of data it collects. Also, it may not publicly display the reviews it collected from consumers during the time period covered by the complaint.

There’s many lessons to be gleaned from this case, but the most obvious seems to be that misleading communications that impact patients are a complete no-no. According to an FTC blog item on the case, they also include that health IT companies should never bury key facts in a dense privacy policy, and that disclosures should use the same eye-catching methods they use for marketing, such as striking graphics, bold colors, big print and prominent placement.

Could Blockchain Tech Tackle Health Data Security Problems?

Posted on March 25, 2016 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

While you might not own any them, you’ve probably heard of bitcoins, a floating currency backed by no government entity. You may also be aware that these coins are backed by blockchain technology, a decentralized system in which all participants track everyone’s holdings on their own individual systems. In this world, buyers and sellers can exchange bitcoins untraceably, making bitcoins perfect for criminal use.

In fact, some readers may have first heard about bitcoins when a Hollywood, CA hospital recently had all its data assets frozen by malware hackers, who demanded a ransom of $3.4 million in bitcoins before the hospital could have its data back. (The hospital ended up talking the ransomware attackers down to paying $17K, and when it paid that sum, IT leaders got back control.)

What’s intriguing, however, is that blockchain technology may also be a solution for some of healthcare’s most vexing health data security problems. That, at least, is the view of Peter Nichol, a veteran healthcare business and technology executive consultant. As he sees it, “blockchain addresses the legitimate previous concerns of security, scalability and privacy of electronic medical records.”

In his essay posted on LinkedIn Nichol describes a way in which the blockchain can be used in healthcare data management:

  1. Patient: The patient is provided a code (private key or hash) and an address that provides the codes to unlock their patient data.  While the patient data is not stored in the blockchain, the blockchain provides the authentication or required hashes (multi-signatures, also referred to as multi-sigs) to be used to enable access to the data (identification and authentication).
  2. Provider: Contributors to patient’s medical records (e.g. providers) are provided a separate universal signature (codes or hashes or multi-sigs). These hashes when combined with the patient’s hash establishes the required authentication to unlock the patient’s data.
  3. Profile: Then the patient defines in their profile, the access rules required to unlock their medical record.
  4. Access: If the patient defines 2-of-2 codes, then two separate computer machines (the hashes) would have to be compromised to gain unauthorized access to the data. (In this case, establishing unauthorized privileged access becomes very difficult when the machines types differ, operating systems differ and are hosted with different providers.)

As Nichol rightly notes, blockchain strategies offer some big advantages over existing security, particularly given that keys are distributed and that multiple computers but need to be compromised for attackers to gain access to illicit data.

Nichols’ essay also notes that blockchain technology can be used to provide patients with more sophisticated levels of privacy control over their personal health information. As he points out, the patient can use their own blockchain signature, combined with, say, that of a hospital to provide more secure access when seeking treatment. Meanwhile, when they want to limit access to the data it’s easy to do so.

And voila, health data maintenance problems are solved, he suggests. “This model lifts the costly burden of maintaining a patient’s medical histories away from the hospitals,” he argues. “Eventually cost savings will make it full cycle back to the patient receiving care.”

What’s even more interesting is that Nichols is clearly not just a voice in the wilderness. For example, Philips Healthcare recently made an early foray into blockchain technology, partnering with blockchain-based record-keeping startup Tierion.

Ultimately, whether Nichols is entirely on target or not, it seems clear that health IT players have much to gain by exploring use of blockchain technology in some form. In fact, I predict that 2016 will be a breakout year for this type of application.

EHR Hosting Demystified – What to Look For (and Look Out For), on Your Way to the Healthcare Cloud

Posted on March 15, 2016 I Written By

The following is a guest blog post by Joe Cernik from eMedApps.

As I write this post I’m trying to reach the cloud. I’m on my third-in-a-row delayed flight segment on this week’s business trip – ARGH!  Ascending to the cloud these days is mostly easy though. My music is there, as are my photos, bank accounts and even my fitness stats collected on my wrist while I’m jogging or while I’m sleeping. Cloud computing has become ubiquitous and healthcare has embraced the transition. Health IT vendors are rapidly migrating EHR, PM and RCM solutions from client-server formats to on-demand, pay-as-you-go cloud hosted solutions.

According to healthcare analyst IDC, organizations that use on-site data storage spend 32% more on IT support than organizations that use an outside hosting provider. From infrastructure costs of servers and support staff to application deployment and ongoing maintenance costs, on-premises software can be a high-touch, high-cost model. Most EHRs are either in the cloud today, or claim cloud compatibility. The cloud promises scalability, interoperability and business continuity – but where do you start to evaluate solutions and define your own path to the cloud?  Here are a few basics to get you going.

Ready, set, cloud….

Step 1: Understand hosting and cloud approaches and determine which type is right for you.

Insourced Hosting: A model also called managed services, managed client-server, or managed on-site hosting, where the hosting vendor provides end-to-end management of your complete EHR/PM system including the hardware and software systems installed at your facility. In essence, your hosting vendor becomes a member of your team, in-house, and manages the infrastructure that you own – generally in a client-server configuration. You’re not in the cloud yet, but this may be a first step in that direction if you’re ready to get out of the EHR/PM management business.

Outsourced Hosting: Also called remote hosting, hosted off-premise, and cloud hosting, outsourced EHR hosting locates your critical EHR/PM applications in a datacenter facility – outside of your LAN-based practice or clinic. EHR and patient data is stored on remote servers accessed via secure Internet connections. Fully outsourced remote hosting shifts the expense of procuring, managing and maintaining your EHR application and servers from your facility and your IT team to a fully managed datacenter. Servers are owned, managed, and refreshed by the hosting company.  Now, you’re in the cloud.

Hybrid Model Hosting: Also called hosted client/server in the cloud and managed hosting, this model allows your organization to place your servers into a secure datacenter. This hybrid model between insourced hosting and outsourced hosting allows your organization to leverage existing capital investments in servers and investments in EHR application licenses, but moves the ongoing management and maintenance of this infrastructure investment to an internet accessible, secure remote site. Rather than installing and managing your application on a server in your office, the installation is managed on your server(s) in a controlled data center environment. Your users log into your remote server through a web browser.

Step 2: Understand Compliance and Regulatory Considerations (HIPAA, PHI, MU) Before You Sign a Contract

Your EHR hosting partner should be an EHR application expert, have demonstrable hosting expertise, and meet all regulatory and security protocols.  While this statement may seem obvious, note that no matter which type of hosting solution you consider or eventually adopt, your hosting provider and their facilities must meet all physical, procedural, operational, and technical readiness criteria established for hosting of protected healthcare data. Make certain to evaluate partners for compliance with all HIPAA/HITECH rules and, for outsourced or hybrid solutions, SOC 2 Type II and SOC 3 centers with certificates including: PCI DSS Level 1 and SSAE 16.

Step 3: Evaluate the Costs

Because there is no upfront cost for the software, and an organization is not required to buy a server, a cloud-based EHR may be less expensive than the onsite client/server setup. If one of your greatest hurdles to adopting an EHR is the initial cost of installation, an outsourced hosting model may be worth considering.

Some practices may also prefer to view their EHR expenses as a recurring operational expense (similar to a utility bill) rather than a capital investment. If your practice or clinic has already invested in on-premises infrastructure but want to consider a move to an outsourced hosting model, a hybrid approach may be a good first step with a full transition to an operational expense model on your next hardware refresh cycle.

Models vary among hosting vendors, and some vendors offer contract terms and conditions that offer hosting packages tailored to your revenue projections or offer low introductory pricing that increases over time. Variable models should be evaluated over a five-year cost-of-ownership timeframe to accurately compare costs across vendor plans.

Clear the fog…move to the cloud.

The way organizations procure and deploy IT infrastructure is undergoing a significant transformation. Don’t be confused by the transition – cut through the fog and get to the facts on a hosting solution that will help you meet your business AND patient care goals.  That solution may include ascending to the cloud – there’s a lot of great music already there. Now, let’s see if my plane will make it into another type of cloud today.

mHealth App-makers Must Develop Privacy, Security Standards

Posted on November 30, 2015 I Written By

The following is a guest blog post by Jon Michaeli, Executive Vice President of Medisafe

In recent times, consumers have developed a rapidly-growing interest in mobile health apps. In fact, more than half of the 1,600 mobile phone users surveyed recently by a New York University research team had downloaded at least one such app. And signs suggest that user uptake of mHealth apps could grow dramatically over the next few years.

But consumers’ adoption of mobile health apps is being held back by concerns that their health data isn’t safe.  Nearly half of consumers surveyed told Healthline that they’re afraid hackers may try to steal their personal health data from a wearable, and one-quarter of respondents said that they don’t believe app or health tracking data is secure.

We believe that it’s time for mHealth app developers and vendors to take a stand on mobile health data privacy and security. Consumers have the right to exchange private health data securely, and to be sure that data is never stolen or shared with unauthorized parties.

But until we develop industry-wide standards for protecting mobile health data, it’s unlikely that we’ll be able to do so. To make that happen, we welcome the creation of a broad industry coalition to create these standards.

Security fears justified

Concerns over the security and privacy of mHealth data are well-founded. Less than one-third of the 600 most commonly-used mHealth apps have privacy policies in place, according to recent research published in the Journal of the American Medical Informatics Association. Another study, by HIMSS, suggests that health IT leaders are just beginning to scope out their mobile health security strategies.

Worse, some practices engaged in by app developers pose a clear risk to users’ health data. For example, some health apps use a Social Security number as a “secure” user method of validating user identity. Unfortunately, Social Security numbers are often stolen during hacking exploits, and they’re fairly easy to buy online. Thieves have a powerful incentive to steal SSNs, as health data now sells for 10 times the prices of credit card numbers.

Once SSNs are obtained by the wrong party, the results can be catastrophic. If I obtain a user’s SSN and download their claims data, I might find out that they, for example, take meds used to treat psychiatric conditions or HIV. Malicious parties could conceivably use this information to blackmail someone, expose them at work or in the community, outflank them during a divorce or worse. There’s a reason that SSNs sell for 10 times the price of a stolen credit card number on the black market.

Not only that, even among those who post privacy policies, few app developers make it clear how they address privacy issues. Developers often fill their policy write-ups with jargon and deceptive language. And few consumers are informed enough to demand plain, straightforward disclosures in areas that may affect them. For example, they may not be aware that their privacy could be compromised if the app pulls data from outside sources without requiring an additional login and password.

Those opaque privacy policies may also conceal questionable data-sharing practices, such as the sale of personal data. If individually-identifiable data gets shared with the insurance industry, insurers might use this data to reject applications for coverage. Pharmaceutical companies could leverage this data to market meds to such consumers. Employers could even buy such data to screen out sick applicants. The possibilities for harm are great.

Time for mHealth security standards

Fortunately, mHealth vendors that want to boost security and privacy protections don’t have to start from scratch. Practices and standards already in place in healthcare IT departments provide a good foundation for mHealth app developers. Certainly, consumers need to play a role in protecting their own health information, by taking a responsible and smart approach to app use, but we have obligations too.

First, we should assume that any mHealth app must meet HIPAA standards for protecting patient health information (PHI). Requirements include making sure users are who they claim to be (authentication), seeing that PHI isn’t altered prior to reaching its destination, and assuring that data is encrypted at rest, in transit and when stored on independently-managed servers.

Also, if PHI is being exchanged, mHealth developers must be sure that any third-party apps integrated into our health app also meets HIPAA requirements. And we need to verify that compliance. If connected third parties are compromised, the app isn’t secure either.

But above all, our industry needs to establish privacy and security standards that meet the unique needs of mobile health environment, standards which evolve as mHealth changes. I believe it’s high time that the mobile health industry leaders collaborate and create these standards. Otherwise, we may fail in our ethical obligations and do lasting damage to consumer trust. We invite other mHealth app vendors and their partners to join us in collaborating to protect consumers.

Jon Michaeli is Executive Vice President of Medisafe (, a cloud-synched platform which helps consumers manage their medications.

A Lawyer’s Perspective on EHR Vendors Holding EHR Data Hostage

Posted on October 23, 2015 I Written By

The following is a guest blog post by Bill O’Toole is the founder of O’Toole Law Group.
William O'Toole - Healthcare IT and EHR Contracts
The recent post, EHR Data Hostage Wouldn’t Exist if EHR Were Truly Interoperable, on EMR & HIPAA got me thinking, and I wanted to offer a few observations from my experience as an HIT lawyer.

The goal is wonderful. However, it would take years and years to achieve such a goal. Data extraction and subsequent import take time, sometimes lots of it. What if there were a standardized specification to which vendors could design extraction tools and programs? Follow that with contractual commitment that the vendor adheres to those specifications. We did it with HL-7, why not data transport?

Thankfully I have not yet represented a vendor that withheld data solely due to the departure of a customer. I have however been involved in very tough situations where the vendor treads a fine line in not releasing data until customers fulfill their obligations (such as paying for use of the software). I like to believe that there is more to the story in the vast majority of data hostage disputes, and in my experience, this has always been the case.

The emergence of the hosted subscription model has resulted in a control shift to the vendor, as opposed to the on premises model where the customer is in control and a vendor can be shut out. That said, vendor assistance is usually required to extract data.

“HIPAA vs. vendor rights” is a very hot topic for me. Providers must provide patient data on request. Vendors have a right to be paid. The contractual right of a vendor to suspend customer access to a hosted EHR butts head-on against HIPAA. I have discussed this with ONC and while the problem is recognized, there is no solution at the present time.

Bill O’Toole is the founder of O’Toole Law Group of Duxbury, MA. You may contact him at

OpenUMA: New Privacy Tools for Health Care Data

Posted on August 10, 2015 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site ( and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

The health care field, becoming more computer-savvy, is starting to take advantage of conveniences and flexibilities that were developed over the past decade for the Web and mobile platforms. A couple weeks ago, a new open source project was announced to increase options for offering data over the Internet with proper controls–options with particular relevance for patient control over health data.

The User-Managed Access (UMA) standard supports privacy through a combination of encryption and network protocols that have a thirty-year history. UMA reached a stable release, 1.0 in April of this year. A number of implementations are being developed, some of them open source.

Before I try to navigate the complexities of privacy protocols and standards, let’s look at a few use cases (currently still hypothetical) for UMA:

  • A parent wants to show the child’s school records from the doctor’s office just long enough for the school nurse to verify that the child has received the necessary vaccinations.

  • A traveler taking a temporary job in a foreign city wants to grant a local clinic access to the health records stored by her primary care physician for the six months during which the job lasts.

The open source implementation I’ll highlight in this article is OpenUMA from a company named ForgeRock. ForgeRock specializes in identity management online and creates a number of open source projects that can be found on their web page. They are also a leading participant in the non-profit Kantara Initiative, where they helped develop UMA as part of the UMA Developer Resources Work Group.

The advantage of open source libraries and tools for UMA is that the standard involves many different pieces of software run by different parts of the system: anyone with data to share, and anyone who wants access to it. The technology is not aimed at any one field, but health IT experts are among its greatest enthusiasts.

The fundamental technology behind UMA is OAuth, a well-tested means of authorizing people on web sites. When you want to leave a comment on a news article and see a button that says, “Log in using Facebook” or some other popular site, OAuth is in use.

OAuth is an enabling technology, by which I mean that it opens up huge possibilities for more complex and feature-rich tools to be built on top. It provides hooks for such tools through its notion of profiles–new standards that anyone can create to work with it. UMA is one such profile.

What UMA contributes over and above OAuth was described to me by Eve Maler, a leading member of the UMA working group who wrote their work up in the specification I cited earlier, and who currently works for ForgeRock. OAuth lets you manage different services for yourself. When you run an app that posts to Twitter on your behalf, or log in to a new site through your Facebook account, OAuth lets your account on one service do something for your account on another service.

UMA, in contrast, lets you grant access to other people. It’s not your account at a doctor’s office that is accessing data, but the doctor himself.

UMA can take on some nitty-gritty real-life situations that are hard to handle with OAuth alone. OAuth provides a single yes/no decision: is a person authorized or not? It’s UMA that can handle the wide variety of conditions that affect whether you want information released. These vary from field to field, but the conditions of time and credentials mentioned earlier are important examples in health care. I covered one project using UMA in an earlier article.

With OAuth, you can grant access to an account and then revoke it later (with some technical dexterity). But UMA allows you to build a time limit into the original access. Of course, the recipient does not lose the data to which you granted access, but when the time expires he cannot return to get new data.

UMA also allows you to define resource sets to segment data. You could put vaccinations in a resource set that you share with others, withholding other kinds of data.

OpenUMA contains two crucial elements of a UMA implementation:

The authorization server

This server accepts a list of restrictions from the site holding the data and the credentials submitted by the person requesting access to the data. The server is a very generic function: any UMA request can use any authorization server, and the server can run anywhere. Theoretically, you could run your own. But it would be more practical for a site that hosts data–Microsoft HealthVault, for instance, or some general cloud provider–to run an authorization server. In any case, the site publicizes a URL where it can be contacted by people with data or people requesting data.

The resource server

These submit requests to the authorization server from applications and servers that hold people’s data. The resource server handles the complex interactions with the authorization server so that application developers can focus on their core business.

Instead of the OpenUMA resource server, apps can link in libraries that provide the same functions. These libraries are being developed by the Kantara Initiative.

So before we can safely share and withhold data, what’s missing?

The UMA standard doesn’t offer any way to specify a condition, such as “Release my data only this week.” This gap is filled by policy languages, which standards groups will have to develop and code up in a compatible manner. A few exist already.

Maler points out that developers could also benefit from tools for editing and testing code, along with other supporting software that projects build up over time. The UMA resource working group is still at the beginning of their efforts, but we can look forward to a time when fine-grained patient control over access to data becomes as simple as using any of the other RESTful APIs that have filled the programmer’s toolbox.

Live Hack of an Infusion Pump Medical Device

Posted on August 6, 2015 I Written By

John Lynn is the Founder of the blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of and John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

UPDATE: Looks like the video was taken down. I can imagine the legal issues that went on with such an incredible demonstration.

At the BlackBerry Security Summit, BlackBerry Chief Security Officer David Kleidermacher and Security Expert Graham Murphy showed how easy it is for hackers to take control of a medical device that’s not properly secured. Check out the video below to see the medical device hack:

What a compelling and scary demonstration!

I think most healthcare organizations assume that medical device manufacturers are taking care of securing the medical devices. Or that HIPAA will protect them from all of this. Many take the stance that “ignorance is bliss.” This demo should illustrate to everyone that you can’t leave security of your medical devices to the manufacturer or HIPAA. It takes both the medical device manufacturer and the healthcare organization to make sure a medical device is properly secured.

What Are You Doing To Protect Your Organization Against Your Biggest Security Threat? People

Posted on July 28, 2015 I Written By

John Lynn is the Founder of the blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of and John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

This was a great tweet coming out of the HIM Summit that’s run by HealthPort. I agree with the comment 100%. Sure, we see lots of large HIPAA breaches that make all the news. However, I bet if we looked at the total number of breaches (as opposed to patient records breached), the top problem would likely be due to the people in an organization. Plus, they’re the breaches that are often hardest to track.

What’s the key to solving the people risk when it comes to privacy and security in your organization? I’d start with making security a priority in your organization. Many healthcare organizations I’ve seen only pay lip service to privacy and security. I call it the “just enough” approach to HIPAA compliance. The antithesis of that is a healthcare organization that’s create a culture of compliance and security.

Once you have this desire for security and privacy in your organization, you then need to promote that culture across every member of your organization. It’s not enough to put that on your chief security officer, chief privacy officer, or HIPAA compliance officer. Certainly those people should be advocating for strong security and privacy policies and procedures, but one voice can’t be a culture of compliance and security. Everyone needs to participate in making sure that healthcare data is protected. You’re only as strong as your weakest link.

One of the attendees at the session commented that she’d emailed her chief security officer about some possible security and compliance issues and the chief security officer replied with a polite request about why this HIM manager cared and that the HIM manager should just let her do her job. Obviously I’m summarizing, but this response is not a surprise. People are often protective of their job and afraid of comments that might be considered as a black mark on the work they’re doing. While understandable, this illustrates an organization that hasn’t created a culture of security and compliance across their organization.

The better response to these questions would be for the chief security officer to reply with what they’ve done and to outline ways that they could do better or the reasons that their organization doesn’t have the ability to do more. The HIM manager should be thanked for taking an interest in security and compliance as opposed to being shot down when the questions are raised. It takes everyone on board to ensure compliance and security in a healthcare organization. Burning bridges with people who take an interest in the topic is a great way to poison the culture.

Those are a few suggestions about where to start. It’s not easy work. Changing a culture never is, but it’s a worthwhile endeavor. Plus, this work is a lot better than dealing with the damaged reputation after a security breach.

Industry Tries To Steamroll Physician Complaints About EMR Impact On Patient Face Time

Posted on June 9, 2015 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

Some doctors — and a goodly number of consumers, too — argue that the use of EMRs inevitably impairs the relationship between doctors and patients. After all, it’s just common sense that forcing a doctor to glue herself to the keyboard during an encounter undercuts that doctor’s ability to assess the patient, critics say.

Of course, EMR vendors don’t necessarily agree. And some researchers don’t share that view either. But having reviewed some comments by a firm studying physician EMR use, and the argument an EMR vendor made that screen-itis doesn’t worry docs, it seems to me that the “lack of face time” complaint remains an important one.

Consider how some analysts are approaching the issue. While admitting that one-third to one-half of the time doctors spend with patients is spent using an EMR, and that physicians have been complaining about this extensively over the past several years, doctors are at least using these systems more efficiently, reports James Avallone, Director of Physician Research, who spoke with

What’s important is that doctors are getting adjusted to using EMRs, Avallone suggests:

Whether [time spent with EMRs] is too much or too little, it’s difficult for us to say from our perspective…It’s certainly something that physicians are getting used to as it becomes more ingrained in their day-to-day behaviors. They’ve had more time to streamline workflow and that’s something that we’re seeing in terms of how these devices are being used at the point of care.

Another attempt to minimize the impact of EMRs on patient encounters comes from ambulatory EMR vendor NueMD. In a recent blog post, the editor quoted a study suggesting that other issues were far more important to doctors:

According to a 2013 study published in Health Affairs, only 25.8 percent of physicians reported that EHRs were threatening the doctor-patient relationship. Administrative burdens like the ICD-10 transition and HIPAA compliance regulations, on the other hand, were noted by more than 41 percent of those surveyed.

It’s certainly true that doctors worry about HIPAA and ICD-10 compliance, and that they could threaten the patient relationship, but only to the extent that they affect the practice overall. Meanwhile, if one in four respondents to the Health Affairs study said that EMRs were a threat to patient relationships, that should be taken quite seriously.

Of course, both of the entities quoted in this story are entitled to their perspective. And yes, there are clearly benefits to physician use of EMRs, especially once they become adjusted to the interface and workflow.

But if this quick sample of opinions is any indication, the healthcare industry as a whole seems to be blowing past physicians’ (and patients’) well-grounded concerns about the role EMR documentation plays in patient visits.

Someday, a new form factor for EMRs will arise — maybe augmented or virtual reality encounters, for example — which will alleviate the eyes-on-the-screen problem. Until then, I’d submit, it’s best to tackle the issue head on, not brush it off.

Epic Belatedly Accepts Reality And Drops Interoperability Fees

Posted on April 21, 2015 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

Unbeknownst to me, and perhaps some of you as well, Epic has been charging customers data usage fees for quite some time.  The EMR giant has been quietly dunning users 20 cents for each clinical message sent to a health information exchange and $2.35 for inbound messages from non-Epic users, fees which could surely mount up into the millions if across a substantial health system.  (The messages were delivered through an EMR module known as Care Everywhere.)

And now, Epic chose #HIMSS15 to announce grandly that it was no longer charging users any fees to share clinical data with organizations that don’t use its technology, at least until 2020, according to CEO Judy Faulkner.  In doing so, it has glossed over the fact that these questionable charges existed in the first place, apparently with some success. For an organization which has historically ducked the press routinely, Epic seems to have its eye on the PR ball.

To me, this announcement is troubling in several ways, including the following:

  • Charging fees of this kind smacks of a shakedown.  If a hospital or health system buys Epic, they can’t exactly back out of their hundreds-of-millions-of-dollars investment to ensure they can share data with outside organizations.
  • Forcing providers to pay fees to share data with non-Epic customers penalizes the customers for interoperability problems for which Epic itself is responsible. It may be legal but it sure ain’t kosher.
  • In a world where even existing Epic customers can’t share freely with other Epic customers, the vendor ought to be reinvesting these interoperability fees in making that happen. I see no signs that this is happening.
  • If Epic consciously makes it costly for health systems to share data, it can impact patient care both within and outside, arguably raising costs and increasing the odds of care mistakes. Doing so consciously seems less than ethical. After all, Epic has a 15% to 20% market share in both the hospital and ambulatory enterprise EMR sector, and any move it makes affects millions of patients.

But Epic’s leadership is unrepentant. In fact, it seems that Epic feels it’s being tremendously generous in letting the fees go.  Here’s Eric Helsher, Epic’s vice president of client success, as told to Becker’s Hospital Review: “We felt the fee was small and, in our opinion, fair and one of the least expensive…but it was confusing to our customers.”

Mr. Helsher, I submit that your customers understood the fees just fine, but balked at paying them — and for good reason. At this point in the history of clinical data networking, pay-as-you-go models make no sense, as they impose a large fluctuating expense on organizations already struggling to manage development and implementation costs.

But those of us, like myself, who stand amazed at the degree to which Epic blithely powers through criticism, may see the giant challenged someday. Members of Congress are beginning to “get it” about interoperability, and Epic is in their sights.