Readers Write 7/20/12

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!

Note: the views and opinions expressed are those of the authors personally and are not necessarily representative of their current or former employers.

How Obamacare is Driving Healthcare IT Investment
By Stewart Billings

Mandates in the Affordable Care Act and the changes in patient behavior that accompany it, combined with the rising consciousness of the public about the cost of healthcare, are forcing providers to make sustained investments in their IT infrastructure.

Health Information Exchanges

Government action may have been the only thing that could have driven this level of cooperation on sharing data across the entire system. Health information exchanges (HIEs) are possibly the biggest driver of healthcare IT change mandate by the ACA. They also carry high potential for driving change across an entire organization. The efficiencies that can be achieved when clinical data can actually be shared and accessed through HIEs depends largely on how the availability of the data translates into more timely and higher quality continuity of care for patients. Those savings may be years down the road, but the investment in the infrastructure that undergirds HIE needs to happen now and be continued sustainably into the future.

New Payment Paradigms

Electronic funds transfer requirements are pushing an industry standard for processing payments and accessing claims, simplifying the whole payment process and finally giving healthcare IT confidence in the payment frameworks they are building. These new rules also push standardization of claims attachments, unique identifiers for health plans and certifications for HIPAA compliance.

ACOs Will Need Communication Support

Accountable care organizations are likewise going to have to have ways to report, record, and analyze patient care in order to improve the outcome of care. All of that coordination between providers in an ACO will likely go beyond even the necessities of information exchanges. Infrastructure will need to be in place for sharing data about cost, quality, and care plans between providers.

Even Bigger Data Will Drive Efficiency

The big unknown in all of this is what tools IT can provide to help organizations collect and analyze all of the data that these standardized systems will be generating about patients, providers, and even their own operations. That mountain of data is promising in that it can help identify inefficiencies and test policy changes that can improve patient outcomes.

Big data will be a competitive advantage for companies that are able to use it to inform patients about their consumption of services, too. Connecting customers with cogent information about the cost of procedures gives them the ability to make decisions about how they access and pay for care, not to mention making the decisions of their providers more transparent.

All of these changes were probably inevitable, but the Supreme Court decision on the ACA has lit a fire under organizations that were already pushing long-term investment into their information technology resources. The next few years should be very revealing about just how tangible any of these benefits are likely to be for providers, ACOs and patients.

Stewart Billings is marketing manager for ZirMed of Louisville, KY.

Actuarial Informatics: An Emerging Field?
By Digital Bean Counter

I can’t remember the last time I actually enjoyed writing a term paper, let alone writing about a topic I inherently knew nothing about at the time. What kept me going (besides the multiple lattes) was that deep down, I truly believed I was on to something: the emerging field of actuarial informatics. 

You could argue that I simply combined two words so that I would appear intelligent, but Google “actuarial informatics” and you’ll be surprised at what little substantive data and information is readily available. With a deadline looming, and a busy work schedule thanks to Medicare bid season, I did a deep dive into the books hoping that I would learn something.

Fast forward three months: I’m in a new role with a health plan working on something that I’ve only learned and read about as a master’s student. My paper has long since been turned in. I’m thumbing through the day’s meeting minutes, recapping the announcement from CMS that we officially joined the ranks of 153 others in the ACO world today, and I see the header on a report from a leading health plan that we’ve been following: Actuarial Informatics Dept.

Call it what you want, there is much evidence suggesting actuarial informatics is alive and well. In the ACO world, the buzzwords are aplenty: value-based purchasing, risk stratification, bundled payments, and population management, just to name a few. While the rest of the industry continues to debate topics such as the true definition of informatics, I often wonder who or which organization will capitalize on low-hanging fruit such as actuarial informatics.

Now if they would only reopen my favorite coffee shop, my life would be complete.

Single Sign-On: Are Preconceptions Actually Misconceptions?
By Dean Wiech

With single sign-on (SSO), end users log in to accounts once with their credentials and thereafter enjoy immediate access to all of their applications and systems without being asked to log in again. It’s a splendid antidote to the many passwords end users currently have to remember. Typically, that’s not reason enough for organizations to unquestionably implement an SSO solution.

Many IT managers and security officers are skeptical about the implementation of an SSO solution. Their skepticism is the result of a number of preconceptions, which in many cases are misconceptions, about these identity and access management tools. The following is a summary of the most common beliefs held by IT managers and security officers at large and medium-sized companies in a variety of sectors, including enterprise healthcare systems.

Implementing SSO Imposes Greater Pressure on Security

In many instances, IT managers and security officers believe that with one-time logging in to accounts security of information is immediately placed at risk, because if an unauthorized person gets hold of that single log-in credential, that person will have access to all the account’s associated applications.

When using SSO, all the various access entries to applications are replaced by one access point. For example, the software allows users to use just one password for multiple accounts. Once the password is entered, all accounts are accessed. Though this does appear to constitute a risk, the log-in process is actually streamlined for the user. Having to remember just one password essentially does away with the risk that the user will scribble passwords on a piece of paper and place them under their keyboard (as is often the case) like they might if they have to remember 12 password and username combinations (the average number per user) that most users have without SSO.

To protect the critical applications and applications with private and sensitive information, it is possible to add extra security to the primary SSO log-in with a user card and pin code or an extra-strong password. Logging in with a card and pin code is an extremely secure authentication, and users also consider it to be very user-friendly.

An SSO Implementation is a Long, Drawn Out Project

Often, an SSO implementation is part of a broader security policy. Other components might be introducing more complicated passwords, taking more care with authorizations, and complying with standards imposed by the government.

Because SSO affects almost all end users and runs throughout the organization, some see implementation as taking a great deal of time to notify and prepare end users for the change. SSO brings with it a number of questions, like, “How do I deal with people who have multiple log-ins on one application?” or “What do I do if an application offered through SSO gets a new version?” and “What happens if the application itself asks for a password to be reset?”

All these questions often cause SSO implementation to be shifted to the background. However, any potential complexity faced at implementation is no reason to postpone adding a SSO solution because it has long-lasting benefits once up and running. By starting small, say by making the top five applications available through SSO, a considerable time saving on the number of log-in actions can be achieved, justifying buying the solution.

It’s Not Possible to Make Cloud Applications Accessible via SSO

Regarding SSO, one thing is certainly clear: the SSO log-in to cloud applications is possible just as it is with every other application.

An SSO Implementation is Expensive

The nice thing about an SSO solution is that it’s often not necessary to set it up for all the people in an organization. In a hospital, for instance, SSO is only needed for a select group of people. The advice here is to restrict yourself to the most critical applications and the people who have to log in to a variety of different applications. The implementation will then be easy to control in terms of price and complexity. This offers an excellent springboard for any further growth and expansion in accordance with changing future needs.

An SSO Solution is Not Needed Because We Use Extremely Complex Passwords

Insisting on extremely complex passwords is one way to secure the network, but at the same time, it’s also one of the causes of insecure situations. Many end users have difficulty remembering their mandated passwords, certainly when they have to recall more than a dozen username and password combinations. Often, a strict password policy immediately leads to more help desk calls because employees tend to forget their passwords. A highly insecure and undesirable situation arises when end users write their passwords on notes and leave them lying around their computer. Using SSO means employees only have to remember one password for all of their applications, meaning a simple solution to a complex problem, easier access to multiple accounts for all who need access to them, and fewer calls the help desk, ensuring IT staff are able to focus on more important priorities than password resets.

Dean Wiech is managing director at Tools4ever of Baarn, The Netherlands.

Bye, Bye Privacy and Securityl Hello HIPAA, Hello!
By Frank Poggio

Some think there may be a hidden ‘gold nugget’ in the proposed Meaningful Use Stage 2 regulations. ONC is proposing to eliminate the Privacy and Security (P&S) test criteria for EHR Module certification in Stage 2. On the surface, it looks like they want to give niche players and best-of-breed (BoB) vendors a nice break.

If you are not familiar with the P&S criteria required by the Accredited Testing and Certification Bodies (ATCB), here they are along with a short description:

1. Access controls – can you system prevent unauthorized access?
2. Authentication – does you system authenticate each user?
3. Emergency access – can your system allow limited access in emergency situations?
4. Automatic log-off – after no user activity for a specified period of time, does your system clear all PHI and log off all users?
5. System access logs – do you maintain system logs for all inquiries, adds, modifications, and deletions of PHI? Do you generate mandatory reports?
6. General encryption – does your system encrypt PHI at rest using a FIPS 140 compliant algorithm?
7. Integrity – do you use SHA1-compliant tools to maintain file and data integrity?
8. HIE encryption – how does your system ensure integrity and encryption when data is communicated / received to / from outside entities?
9. Account for disclosures – do you track requests for PHI from outside entities?

Most EHR Module vendors that have gone through ONC Certification get certified on 1 through 8. Number 9 is deemed ‘optional’. In my many certification experiences, numbers 6 through 8 can be a hurdle, particularly if you are a SaaS or cloud-deployed system.

Meanwhile on page 125 of the Proposed Stage 2 Rules for Vendor Certification, ONC states:

We propose not to apply the privacy and security certification requirements at §170.550(e) for the certification of EHR Modules to the 2014 Edition EHR certification criteria. Stakeholder feedback, particularly from EHR technology developers, has identified that this regulatory requirement is causing unnecessary burden (both in effort and cost). EHR Module developers have expressed that they have had to redesign their EHR technology in atypical ways to accommodate this regulatory requirement, which sometimes leads to the inclusion of a privacy or security feature that would not normally be found in a certain type of EHR Module. In turn, this has led to EPs, EHs, and CAHs purchasing EHR Modules that have redundant or sometimes conflicting privacy and security capabilities.

And then ONC goes on to state:

In addition, EPs, EHs, and CAHs remain responsible for implementing their EHR technology in ways that meet applicable privacy and security requirements under Federal and applicable State law (e.g., the HIPAA Privacy Rule and Security Rule and 42 CFR Part 2).

But as might be expected in this regulatory maze, when you look at the ONC Stage 2 Draft “Medicare and Medicaid Programs; Electronic Health Record Incentive Program”, which is the basis for provider MU attestation for Stage 2, you will see repeatedly that to meet the Privacy and Security MU requirements, the provider (not the vendor) must:

Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1), including addressing the encryption / security of data at rest in accordance with requirements under 45 CFR 164.312 (a)(2)(iv) and 45 CFR 164.306(d)(3), and implement security updates as necessary and correct identified security deficiencies as part of the provider’s risk management process.

45 CFR 164 is the HIPAA security rules. Just last month, HHS’s Office for Civil Rights published the protocol that it will use to conduct audits of the HIPAA Privacy and Security rules. In that document, they outline the audit procedures the OCR will follow. For example:

164.308 (a) Audit Procedure

Inquire of management as to whether formal or informal policy and procedures exist to review information system activities; such as audit logs, access reports, and security incident tracking reports. Obtain and review formal or informal policy and procedures and evaluate the content in relation to specified performance criteria to determine if an appropriate review process is in place of information system activities. Obtain evidence for a sample of instances showing implementation of covered entity review practices Determine if the covered entity policy and procedures have been approved and updated on a periodic basis.

This audit procedure is repeated frequently throughout 164.308 and applies to all PHI, regardless of whether it is in the primary EHR or resides in a Module(s). In regard to Business Associate agreements under 164.308 (b)(1), OCR further states:

Inquire of management as to whether a process exists to ensure contracts or agreements include security requirements to address confidentiality, integrity, and availability of ePHI. Obtain and review the documentation of the process used to ensure contracts or arrangements include security requirements to address confidentiality, integrity, and availability of ePHI and evaluate the content in relation to the specified criteria. Determine if the contracts or arrangements are reviewed to ensure applicable requirements are addressed.

As you can see, the HIPAA audit does not differentiate between a full EHR and EHR Module. Any and all systems or service contracts that deal with PHI of any type must comply, and the provider must prove it under audit.

Under Stage 1 the ongoing debate was whether a best-of-breed system supplier needed to get ONC certified. Fact is there was never an ONC-mandated requirement that any vendor get certified. But many BoBs underwent certification for competitive reasons and some addressed most of the P&S criteria because they did not want to allow the big EHR vendors a ‘certification edge’.

Now ONC is trying to push the P&S criteria of MU back on the provider and thereby reduce the time and effort for the testing bodies. Their strategy, as they often state in the proposed Stage 2 regulations (see page 119), is to let the market require (demand) it, not mandate it via ONC regulation. Simply put, since the health provider needs to be legally responsible for P&S under HIPAA and MU attestation, ONC expects that providers will demand from their vendors that they meet the HIPAA P&S requirements. HIPAA audits by OCR have started this year, so expect your clients to contact you for help and assistance as OCR asks to see the P&S documentation for all systems that touch PHI. And the best documentation you can show that confirms you the vendor comply with HIPAA P&S will be … ONC certification!

As Stage 2 unfolds, I would expect either one of these scenarios;

• Things stay as they are – EHR Modules must meet the eight P&S criteria, or,
• If the Draft regulations stand, module vendors can request to be tested by the ATCBs for P&S so as to satisfy HIPAA Business Associate requirements and address market / competitive issues.

In summary, BoB and niche vendors could in the past casually sign Business Associate agreements. Under proposed Stage 2 and HIPAA, you’ll have to prove you got real P&S. On closer inspection, that nugget is beginning to look more like fool’s gold.

Frank L. Poggio is president of The Kelzon Group.