Readers Write 8/17/10

Submit your article of up to 500 words in length, subject to editing for clarity and brevity (please note: I run only original articles that have not appeared on any Web site or in any publication and I can’t use anything that looks like a commercial pitch). I’ll use a phony name for you unless you tell me otherwise. Thanks for sharing!

How Would You Define a Secure Database?
By Robert J. Rogers, MD

While driving to work in late June, my phone rang. I saw it was my office manager calling. For those of us who own our practices, an early morning call from the office manager is rarely good news.

“Dr. Rogers, someone broke into the office last night and stole the computers!”

Thus my partners and I began our saga of learning the ins and outs of dealing with a potential breach of protected data. We are the “Texas allergy clinic” referenced by Mr. H in the Monday Morning Update of 8/9/10.

(Let me briefly mention now that our database was purely for our practice management system. We do not use an EMR yet. More on that later).

Selfishly, my first thought was, “I hope our backup is good”. A few years ago, we experienced a server crash and learned that our backup was corrupted, requiring a manual rebuild of our database. Fortunately, we learned the backup was fine when the new computers were installed. I naively thought our biggest challenge was behind us.

We decided to check with the Texas Medical Association regarding our reporting responsibilities. We were directed to the AMA’s summary of the HIPAA Data Breach Notification Rule, which was enacted in September of last year. It was at this point that we learned the very important distinction between password protection and encryption.

As I suspect is true in most offices, we were under the impression that our database was secure since we needed a username / password combination to gain access to it. We use a well-known practice management system supported by a local reseller. Password protection was the only security measure discussed.

However, we learned that the database was considered vulnerable if it was not encrypted, thus triggering our reporting responsibilities (first class letter to each affected party, and notification of local media if more than 500 individuals are affected). I will leave it to your imagination to consider the logistics of sending letters to 25,000 patients.

This was a nightmare until we learned that commercial printers and mailing services can handle everything — stuffing, addressing, stamping, and mailing (for a fee, of course). [Mr. H — I didn’t actually complain about the cost of this process. I just responded to the reporter’s question regarding the cost of the mailing.]

Being victims of this crime has triggered a number of questions that I hope some of you may be able to answer. Now that I have learned the importance of encryption, I wonder why encryption is not automatically provided by all vendors? Is it complicated and/or expensive?

In an informal survey of my physician friends, none of them understood the importance of encryption. None had asked their vendors about encryption. Many of these doctors host their own servers.

Our potential data breach was important mainly due to the potential for identity theft since we don’t use an EMR (fortunately, in this case). That’s bad enough, but I worry even more about the thousands of physicians who use EMRs and may not use data encryption, thus making sensitive medical information potentially accessible.

As a patient, should you ask your doctor about the security measures in place?

The Data Breach Rule requires notification of the local media if more than 500 patients are affected. I wonder about the wisdom of that requirement. Might the thief be unaware of importance of the stolen server until learning about it from media reports?

Because of our experience, we elected to change to an ASP model for our software, using an off-site server accessed through an encrypted virtual private network. We think this is an adequate level of security, but we thought our previous system was secure, too. Is our database now secure?

As we rush to encourage all physicians to use EMRs, how can we make sure that all involved understand these important security issues?

Robert J. Rogers, MD is a physician with Fort Worth Allergy and Asthma Associates of Fort Worth, TX.

The Business Associate “Relationship”
By Stephanie Crabb

We are working with many customers who are looking to implement Data Loss Prevention as part of their information security and compliance programs. The best-practice deployment of these solutions requires collaboration with the HIS application vendors that contribute to the ePHI data life cycle such that the DLP solutions can efficiently and effectively content fingerprint targeted data “at the source” in the applications themselves. To some, this might fall under the rubric of “integration” as we have come to define it in healthcare, a common practice.

One small client of ours, a hospital of just 20 beds with an unwavering commitment to patient privacy and data security, approached its core HIS vendor, Meditech, with a formal request to connect directly with the database (aka “dictionaries” in Meditech-speak) to accomplish the implementation of its DLP solution. The data set was minimal — six fields of basic, and I mean basic, data to start. 

This request, surprisingly to us, was met with a firm “no” from Meditech. Why? They consider this “customization.”

Respecting Meditech’s longstanding position in this area, I personally worked with our customer to develop the business case to present to Meditech as to why they needed Meditech’s re-consideration. We cited areas around breach notification, uses and disclosures, and the like to inspire cooperation from Meditech and to put into clear context that DLP was a technology being adopted specifically to demonstrate compliance with HITECH and MU.  

The Meditech account representative acknowledged that they would need to do better in the future, but until they had a “critical mass of requests” from their clients to work with another vendor (like the client’s selected DLP vendor), their answer was still no. Understanding that our client’s Meditech account rep only has so much authority, my CEO and the client CEO requested a personal meeting with Howard Messing, only to be told that Mr. Messing could not accommodate their request. 

This is about a simple permission that the vendor could absolutely grant and requires little to no effort on its part whatsoever. It is a permission that other HIS vendors have eagerly provided. Oh, the vendor did offer to sell our client a module that would make this “easier” to the tune of $40K, even though what the client needs to access is already present in their its implementation.

DLP is not the only emerging technology that holds tremendous promise for organizations looking to reduce their data loss / data breach risk, enhance the controls around their data and its uses, and protect patient privacy. Unfortunately, covered entities cannot accomplish the implementation of these technologies alone. They need the business associate to collaborate, facilitate, and, sometimes, participate. And let’s face it, the rise of technologies like DLP that offer compensatory controls for privacy and security has resulted, in part, because the HIS vendors have been slow to respond with their own system capabilities.

I really do not mean to single out Meditech here. There are certainly other vendors who subscribe to similar operational models. This is, however, precisely the client service mindset that needs to change and that HITECH is requiring, particularly when technology is not the barrier. If these implementations are technically possible and largely resource-neutral to the vendor "business associate," why delay or deny their clients the opportunity to close the privacy and security gaps that are requisite to achieving meaningful use?

While the content of the NPRM may set about a chain of events whereby business associates become even more conservative in their commitments to privacy and security collaboration with their covered entity partners, there really is no where to hide, regardless of how ambiguous HIPAA and HITECH may be written. If you are in this space and in the business of touching ePHI in any way, you have to be “all in” — technically, operationally, and in the way you serve your clients and the industry at large.

It is simply not acceptable to relegate privacy and security considerations to the back burner, or worse yet, leave leave your client holding the bag. OCR recently clarified that “willful neglect” includes failure to take action when one recognizes a risk. Business associates who fail to respond when requested by covered entities to address a perceived risk could find themselves in an uncomfortable and costly position if a breach occurs and it could have been avoided.

Stephanie Crabb is VP of client services with CynergisTek of Austin, TX.

Why Are Lab Orders from Ambulatory EHRs So Hard?
By Ken Willett

While hospitals with integrated inpatient EHR systems are claiming high adoption rates for CPOE (in some cases 100%), most providers in ambulatory settings are still creating lab orders outside their EHR. What makes it so much harder?

An integrated HIS system, which includes lab and radiology ordering, can present the provider with the correct choices for that hospital’s services. In the ambulatory world, the EHR is much more limited (being less expensive), yet the variety of external service providers is larger. There are generally multiple labs, with ordering rules governed by insurance contracts, and each has its own test catalog, data requirements for the order, HL7 dialect, and requisition formatting requirements.

The provider wants to quickly capture what tests to order and why. Their manual process is to make a few strokes on a preprinted superbill or order slip. It’s very hard for an automated system to compete with that. Ordering facilities in the EHR are often cumbersome, while at the same time too generic to capture the specifics needed by the lab or radiology provider.

The lab, on the other hand, needs an order which is complete, with billing information, the lab’s order codes, appropriate Ask at Order Entry (AOE) questions answered, and the correct requisition and specimen labels printed. To try to assure that orders coming to the lab are accurate and complete, the lab will generally provide an order entry application and workstation to the practice, for use by a phlebotomist or other staff person.

Having a lab-specific ordering application addresses the problem of making sure the order reflects the most current compendium data of that lab (test codes, AOE questions, specimen requirements, and medical necessity rules), at the expense of having a separate ordering application for each lab (and in many cases, due to Stark laws, separate workstations, printers, etc.). Re-entry of order data, together with the need to use multiple ordering applications, significantly increases the likelihood of error.

Improving lab ordering within the ambulatory EHR is difficult because ordering rules need to be configured for each lab and compendium data needs to be constantly updated. This is a significant burden for each practice to
undertake.

Given that we are now in an environment with much more seamless connectivity between applications (with web services and other technologies), I believe a better solution is to move the ambulatory ordering function out of the EHR itself and instead provide orders via a connected SaaS application. This can allow compendium data management to be done in one place for multiple practices and multiple labs while still giving the provider and phlebotomist direct access to a universal ordering interface.

Only some EHRs have the necessary integration capabilities to allow this sort of user interface extension. Still, this seems like a promising direction to improve provider adoption of electronic orders.

Ken Willett is president and CEO/CTO of Ignis Systems of Portland, OR.