•

» Risk Management

A “Reasonable” Approach to HIPAA Risk Analysis

Posted on March 17, 2011 by Dan Berger in Main | Leave a comment

The Office of Civil Rights (OCR) is responsible for issuing annual guidance on the provisions in the HIPAA Security Rule (45 C.F.R. §§ 164.302 – 318.). But with so much recent interest in IT security driven by the “meaningful use” incentive program, we want to share some our observations and perspectives from recent Redspin client engagements in the healthcare industry.

All electronic protected health information (ePHI) created, received, maintained or transmitted by an organization is subject to the Security Rule. The importance of safeguarding ePHI cannot be understated. Sure, publicized breach notifications and million dollar penalties damage a healthcare organization’s reputation and bottom line. But more than that, such incidents undermine professional and public trust of electronic health records (EHR). And make no mistake about it – the widespread adoption of EHR is fundamental to future improvements in efficiency, communications and patient care.

So if security is the cornerstone to health IT transformation, what can your organization do to not only comply with the regulations but also contribute to this important mission? First, all heathcare organizations are required to evaluate risks and vulnerabilities in their environments. Then they must “implement reasonable and appropriate security measures to protect against reasonably anticipated threats or hazards to the security or integrity of e-PHI.” While “reasonability” is a quintessential element of modern judicial systems, it doesn’t provide a lot of guidance. At Redspin, we suspect there will be little sympathy for major ePHI security breaches no matter what any standard of reasonability might dictate. More simply put, it’s better to be safe than sorry.

Conducting a risk analysis that maps to the HIPAA Security Rule is the first step in protecting ePHI. Note, the Department of Health and Human Services (HHS) does not endorse or recommend any particular risk analysis or risk management model. At Redspin, we think this is wise. From our direct experience, no template or “one-size-fits-all” approach can meet the diverse needs of the healthcare industry. We treat each client individually and conduct a thorough review of their environment even before drafting a scope of work, including:

- size and complexity of the IT environment

- number of physical and logical locations where ePHI is stored

- number of IT staff; their knowledge and experience level

- types of EHR, CPOE and other new applications

- functional responsibilities of team members

- progress-to-date toward EHR completion

- company culture and information security awareness

While a HIPAA Risk Analysis is often project-based, we also consider it the start of a process that will lead to ongoing and durable improvements in information security. The Security Rule itself requires an entity to update and document its security measures “as needed” and specifically recommends conducting continuous risk analysis to identify when such updates are warranted. While the rule does not specify how frequently to do this, it’s a moot point for Redspin’s enterprise security assurance clients. By providing our services on a monthly or quarterly subscription basis, regularly-scheduled assessments, validation and re-testing simply become part of an overall operating environment. Our enterprise solution also tracks and documents all historical findings and remediation via our secure, online web portal. The portal’s dashboard view displays summary information via a compelling graphical user interface, making complex data easier to understand and better enabling you to communicate improvements in your overall security posture to all stakeholders.

In summary, Redspin empowers healthcare organizations to truly integrate their risk analysis and management process. This helps them to accommodate: (1) new technologies (2) evolving business operations, (3) new regulations and (4) personnel changes. And by addressing security risks in a proactive, timely manner rather than fixing problems after implementation, healthcare organizations gain greater value from their investment in IT. Sound reasonable?

Lessons Learned From The BP Well Blowout For Your Industry

Posted on January 7, 2011 by perlbot in Main | Leave a comment

In advance of the much anticipated full report due on January 11th from the National Commission on the BP Deepwater Horizon Oil Spill and Offshore Drilling, a chapter was recently released outlining some key findings that are relevant not only to the oil industry but also every other enterprise.

Low + Low = High

“The well blew out because a number of separate risk factors, oversights, and outright mistakes combined to overwhelm the safeguards meant to prevent just such an event from happening.”

This was not a black swan. Every organization involved had a developed Risk Management Program for the sole purpose to prevent this exact, known event. Perhaps the likelihood was miscalculated, but the impact was surely known.

What adjustments can be made to be better prepared in the future? 1) Ensure layers of controls are implemented and tested for known risks. 2) Do not underestimate or ignore the low risk vulnerabilities. It does not take many in aggregate to result in catastrophe.

Risk Management Starts with Objective Accountability

“… most of the mistakes and oversights at Macondo can be traced back to a single overarching failure—a failure of management.”

While the management of risks requires awareness and execution at all levels of your organization, it starts at the top with accountability. Until accountability has been assigned to an individual who is not also incentivized to bypass safeguards for the bottom line, unnecessary risk will exist. This is why every regulated industry, including Healthcare, Finance, Energy, Retail, etc has standards (HIPAA, FFIEC, NERC CIP, PCI, etc) requiring formal management responsibility of the organization’s Security Program. Who is accountable in your organization?

Regulatory Oversight and Technical Expertise

“… the Macondo blowout was the product of several individual missteps and oversights by BP, Halliburton, and Transocean, which government regulators lacked the authority, the necessary resources, and the technical expertise to prevent.”

There is a need for regulatory oversight. But the regulators are not leading technical innovation within your industry; they are just trying to keep up with it. Regulators are relying on companies within each industry to provide them with the capabilities and information to prevent another Gulf oil spill or healthcare data breach. What are you doing to help your regulators ensure you are in control of your risk?

Perspectives on application security and risk management

Posted on September 16, 2010 by John Reno in Main | Leave a comment

In my last blog post I discussed information security risk management and why the financial services sector aggressively adopted the practice. My recommendation was that the healthcare industry segment needs to follow suit to increase the effectiveness and efficiency of their information security programs. It is refreshing to see evidence that this is taking place. Last week at OWASP’s AppSec USA conference some leaders from the healthcare sector shared their perspectives on information security risk management.

The panel session, entitled “Characterizing Software Security as a Mainstream Business Risk,” represented application security and risk management experts and executives from both the commercial and public sectors, including: Tom Brennan, CEO for Proactive Risk and OWASP Board Member; Ed Pagett, CISO for Lender Processing Services; Richard Greenberg, ISO for the Los Angeles County Department of Public Health; and John Sapp, Director of Security, Risk and Compliance for McKesson.

Rather than focusing on technical issues associated with application security, which you might expect at an OWASP conference, the panel focused on the discussion of risk and the build out of risk management programs. Much of the discussion centered on how the key drivers for risk management needed to be expressed in business terms such as patient care outcomes, customer satisfaction as well as revenue and profit.
Greenburg, from the public healthcare sector, said that for the Los Angeles County Department of Public Health, “It’s all about getting straight to patient care. The department doesn’t really care about IT nor understand what application security is. They can, however, understand risk in the context of their business; how an application security program can help or hinder them from providing the best care possible.”

Sapp from McKesson continued, “When working through the development of our risk management program, we looked at how our application security programs are helping us to achieve our business objectives. Of course, this doesn’t mean we turn a blind eye to technology and security such that we put the business in harm’s way; we certainly don’t want to facilitate a breach. But, a deep dive into the technology isn’t the discussion we were having during our risk management program planning; we left that discussion for the security operations team to engage in outside of the risk management program discussions.”

The panel offered some guidelines to help other organizations build their own application security and risk management programs:

* Speak in terms of the business. For example, focus on how to ensure secure banking transactions, how to guarantee private and highly resilient patient care, and how to deliver trusted services to employees, partners, and customers.

* The answer is never simply ‘buy a tool.’ Avoid blindly buying products in the hopes that they will solve your application security and risk management problems. It is important to first understand the objective of the risk management program and then select the right tool (s) for the job. As Sapp put it, “a fool with a tool is still a fool.”

* Gain a wide range of allies, both deep and wide — focus first on those that have revenue-generating responsibility, followed by those that have audit and compliance responsibility.

* Find in-field leaders and champions to establish some grassroots efforts. Leverage your project management team to achieve a quick win or two and then use them as case studies to progress the program further.

* Leverage frameworks such as ISO 27002 to establish a baseline level of guidance of how to build out your risk management program and your supporting application security program.

In terms of some guidance for those in the healthcare industry, Sapp from McKesson noted the some highlights from their risk management program.

The top four goals McKesson focused on were:

• Harmonizing processes and investments surrounding risk management

• Improving the overall risk management process

• Establishing application governance

• Delivering transparency and visibility through the risk management program

To achieve these goals, McKesson defined a complete set of risk management categories designed to help define, implement and measure progress. Some sample risk management categories include security, quality, privacy, legal and third-party components. Each of these categories play a role in managing risk, and by defining them up front, McKesson was able to establish a comprehensive, formalized risk management program for the entire enterprise. McKesson’s program is designed to encompass its own business risk as well as the risk associated with the products, services and solutions it offers to its clients.

Within each category, McKesson would look beyond the security risk and the business risk; it would do a deep dive into the risk/reward analysis and focus on how to gain the most reward while mitigating or avoiding the most risk. One example of this analysis would include how to lower the total cost of ownership of a system/application versus mitigating the risk to avoid increased operational cost. Another example would include how it could achieve high levels of application quality and resiliency as a reward while mitigating the risk associated with application failures and other critical errors. One final example would be how McKesson could increase the likelihood and close rate of its own sales efforts while reducing the cost of customer acquisition versus mitigating the risk of having competitive disadvantages (such as poor security or poor application quality).
With its program framework in place, leveraging the OCEG (Open Compliance & Ethics Group) framework as a baseline, McKesson began to focus on implementing an integrated application security program. The order with which the company performed the application security analysis was:

1. Applications that were seeking certification on HITECH (Health Information Technology for Economic and Clinical Health).

2. New applications that were in development or on the roadmap for development.

3. Legacy applications that possess the high revenue value for the company.

This analysis and prioritization enables McKesson to make clear, calculated decisions on how to proceed with IT security and application security in relation to its overall risk management program. One such decision revolves around which applications to update or end of life. Without this analysis, McKesson could be making decisions based on poor or limited data, investing potentially millions in systems and applications that should have otherwise been rebuilt or replaced.

With the program in place and the prioritized analysis performed, McKesson was able to select a set of application security products, code analysis tools and consulting services to perform routine risk assessments, prescribe risk mitigation tasks, implement secure application development best practices within its software development life cycle and provide management visibility into the status of an effective risk management program that is application security enabled.

Why information security risk management makes sense in the healthcare industry

Posted on September 11, 2010 by John Reno in Main | 1 Comment

Lately I have been thinking about risk in the context of information security and the healthcare industry. I have written an article that you can find here about using risk management to help healthcare organizations manage their information security, privacy and compliance programs more effectively and efficiently. For the most part using risk to manage information security is new territory for the healthcare industry. Yet it has been common practice in the financial services sector for more than ten years. Why it that the case?

In the late 90’s financial services companies in New York, London and Tokyo went through a dramatic change in the way they managed their information security programs. Risk management took over as (and remains today) the dominant paradigm for running an information security program and enabling business in the financial services sector.

Why did that happen? Well, the financial services world is about transactions. By the late 90’s the infrastructure of the internet had evolved to the point where financial transactions were realistic and could done reliably on a scalable basis. The requirements for enabling electronic transactions were (are) as follows:

• Non-reputable communications between two parties, each of whom can verify the time, value and content integrity of the message.

• Confidentiality

• Authorization

• Counterparty authenticity

• High availability

All of these requirements are information security issues. So information security became a competitive differentiator. A major element of winning in the financial service market was managing information security in the most effective and efficient manner. Risk management is the way to do that.

The financial services sector was a natural place for adoption. First, financial institutions are risk-intermediation businesses; as the most sophisticated of them came to realize, the ability to describe, price, and manage risk should be among their core competencies. Second, this sector is rich in data, and thus the raw fuel for risk analysis already exists. Third, and perhaps most important, they are typically highly leveraged and are monitored by regulators who, concerned about the potential impact of failures, pushed for improved risk management. So risk management was and is at the core of the business and the extension of processes and methods to information security was evolutionary rather than revolutionary.

I don’t think the same severe pressures on information security that exist in the financial services industry are present in healthcare. However, by making poor decisions around information security, privacy and compliance organizations can destroy patient trust, increase costs, damage brand and create major liability. I think healthcare IT leaders need to borrow the financial services information security playbook and aggressively adopt risk management.

The final rule on meaningful use – an opportunity for healthcare process improvement and security program development

Posted on July 17, 2010 by John Reno in Main | Leave a comment

Earlier this week the CMS and ONC released the final Standards Rule for meaningful of electronic health records. This culminates a process in which the ONC received thousands of comments and struggled to reach a balance between specificity (presumed to make certification and implementation a simpler task) and generalization (which can enable more rapid innovation).

An analysis of the requirements can be daunting. For those who choose to go through the details of the requirements, key resources can be found at the Federal Register. Specifically, the Federal Register publication of the Meaningful Use regulation and the Federal Register publication of the Standards regulation. I have found the most useful summary in a recent article in the New England Journal of Medicine by David Blumenthal and Marilyn Tavenner. This reference includes a table with a summary overview of meaningful use objectives and their respective measures. This is a concise and useful description of the 15 core requirements for Eligible Professionals and the corresponding 14 core requirements for hospital organizations as well as the 10 discretionary requirements (of which 5 must be chosen). I have also put together a presentation regarding meaningful use that you may find helpful. Feel free to download it here.

From a security, privacy and compliance standpoint the implications of the final Standards Rule are quite significant. One of the core requirements sets a specific goal: implement systems to protect the security and privacy of patient data in the EHR. The corresponding measure calls for organizations to conduct a security risk analysis, implement security updates and correct identified security deficiencies.

A closer look at the security and privacy rules shows that the most prescriptive requirements involve transport layer security, message integrity and auditing/logging. Key highlights from the regulations are outlined below:

Encryption and decryption requirements for use of electronic health information

Usage guidelines – Any encryption algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2.

Record actions related to electronic health information

The date, time, patient identification, and user identification must be recorded when electronic health information is created, modified, accessed, or deleted; and an indication of which action(s) occurred and by whom must also be recorded.

Verification that electronic health information has not been altered in transit

Standard – A hashing algorithm with a security strength equal to or greater than SHA-1 (Secure Hash Algorithm (SHA-1) as specified by the National Institute of Standards and Technology (NIST) in FIPS PUB 180-3 (October, 2008)) must be used to verify that electronic health information has not been altered.

Record treatment, payment, and health care operations disclosures

The date, time, patient identification, user identification, and a description of the disclosure must be recorded for treatment, payment, and health care operations, as these terms are defined at 45 CFR 164.501.

Now, let’s look at what this will mean in the healthcare community with a focus primarily on security, privacy and compliance programs. By now, I think most vendors and providers in the healthcare industry segment realize that the transition to widespread adoption and meaningful use of electronic health records is an opportunity for a major overhaul and upgrade of their workflow processes and the IT systems that support those processes. Many people in the healthcare community that I have talked with view this as similar to the challenges faced in the 80’s and 90’s when businesses transitioned to ERP systems. The transition can be a source of major disruption and pain, but ultimately a source of competitive advantage and business agility.

The transition should also be viewed as an opportunity for major enhancements to security, privacy and compliance programs. Information security stakeholders at healthcare organizations need to look at the transition to meaningful use of electronic health records not simply as a set of requirements that call for risk analysis, encryption and auditing/logging, but an opportunity to modernize their information security programs, revitalize governance mechanisms and institute risk management as a core, ongoing process. Pragmatically, healthcare organizations must also realize that for the next 12 to 18 months EMR vendors will be focusing on certification as their number one priority. Certification is a necessity for meeting the requirements of the meaningful use rule and a business driver for the EMR vendor community. Realistically, this means that security will not be the priority that it should be. As a result, more of the burden of systems and application security will fall on the shoulders of deploying organizations.

In summary, the transition to meaningful use of electronic health records is a very ambitious program. The most successful organizations will look to set their own goals and invigorate their security, privacy and compliance programs.

State HIE deployments – Some thoughts from the field

Posted on June 16, 2010 by John Reno in Main | Leave a comment

Health and Human Services Secretary Kathleen Sebelius is one busy government employee. From announcements regarding Regional Extension Center Awards and Job Training Grants to the State Health Information Exchange Cooperative Agreement Program, it’s a daunting task to keep up with the acronyms and initiatives.

For the healthcare provider on the front lines, these announcements are just part of several waves of carrot and stick techniques that will ideally drive the U.S. healthcare system toward competitiveness. The carrots have already started coming in terms of grants and incentive payments. State grants (through governor appointed State Designated Entities (SDEs) and state Medicaid agencies) help states improve the exchange of healthcare information which will in turn have many benefits ranging from quality of care to cost reduction.

This sweeping effort reminds me of a huge product development effort on the level of a complex computer system or microprocessor. Given that I have been through more than my fair share of these development efforts, I dug out some notes that I have seen put to very effective use when teams at Intel, IBM and Microsoft and others faced complex endeavors. You might think of these like Stephen Covey’s Seven Habits of Highly Effective People, but for geeks.

1. Focus on tactics, not strategy – Andy Grove, Intel
2. Learn from others – Steve Jobs, Apple
3. Plan to throw one away – Frederick Brooks, IBM
4. Pilot as quickly as possible – Bill Gates, Microsoft
5. Implement in the lab rather that the conference room – Andy Bechtolsheim, Sun
6. Let the most important use cases lead, others will follow – Bill Harris, Intuit
7. Focus on information and users, gain critical mass as quickly as possible – Jeff Bezos, Amazon

But rather than go on and write a book about complex system development process, I thought I would stick to information security and offer a few insights to those that must secure these healthcare information exchanges.

Here are a few things to keep in mind with respect to information security and healthcare information exchange.

• Things will go wrong eventually – have an incident response plan; practice it.
• Make sure you have a CISO. I haven’t met very many in this sector (unfortunately).
• Invest in an information security assessment (yes, I realize it is self-serving).
• Derive policy from security goals and make sure it’s enforceable.
• Develop and maintain a risk management program (the only way to make stakeholders happy).
• Practice business continuity like elementary school fire drills.
• Take a similar approach to security awareness training.
• Review and act on your logs – enough said.
• Develop a threat model – your adversaries are bad, bad.
• Maintain adequate business associate oversight – trust no one.
• Harden your systems, run a patch management program under change control, etc. – this is basic stuff.

There is so much more, but hopefully I have given you a few things to think about.

Attack Surface Reduction – An often overlooked element of web application security

Posted on May 30, 2010 by John Reno in Main | Leave a comment

In industry surveys ranging from the Symantec Threat Report to Gartner analyst reports, application security is constantly cited as the most significant area of risk for enterprises and the most prevalent threat vector for cyber crime. It certainly makes sense, why bother to spend time on reconnaissance when the front door is wide open?

Many organizations have begun to spend a great deal of energy and money to secure applications. Popular approaches include code review, threat modeling, source code analysis and black box testing. Often overlooked is the rather fundamental practice of reducing the attack surface of the application.

During development and configuration of a system and the associated application the software must typically expose both customer and business assets through network ports, database access, APIs, web services and the user interface. The entire collection of entry points in a product is called its Attack Surface. These form the ways in which an adversary can attack a system. A big attack surface generally means big security issues, or often more time and budget dollars dedicated to protecting the system. It’s also important to remember that channels to local resources are not the only vectors for attack, remote resources must also be kept in mind.

Generally, when a software system is architected, implemented and configured, the top of mind issue is about providing useful functionality that meets business goals. From a security point of view, however, the design and deployment teams must also think about turning things off as well as on. From a design standpoint this involves reducing the amount of code that is executing by default, running with user privileges rather system, reducing functionality and data accessible to unauthenticated users and limiting the damage if access points are exploited. From a system configuration point of view this involves turning off unnecessary services, providing access only to required authorized users on specific subnets, and using strong ACLs to control access to resources.

The security community has done a relatively good job with respect to understanding which attack vectors are more likely targeted by adversaries.  Given that perspective, keep the following in mind:

• Minimize the use of scripting engines and controls such as ActiveX, JavaScript or VBScript.
• Avoid symbolic links as these are likely targets.
• Restrict file permissions to the fullest extent possible.
• Minimize the number of services that must run as root.
• Keep up with vulnerability research and build an effective patch process.

A useful practice is to put together a design guideline for developers suitable to your design environment and the business and security requirements associated with your system. Further, at deployment time, a security configuration guide and checklist of security best practices is recommended. Interestingly, some in the industry such as SAP have invested even more heavily in this area. SAP Labs has developed and begun pilot deployment of an Eclipse extension that uses a more formal process to measure attack surfaces. Their method involves summing the damage and potential-effort ratios (DER) of relevant resources. The relevant resources of an application include its channels, such as TCP ports; methods, such as API calls; and data, whether persistent, in memory, or in transit. The DER of a resource is the ratio of potential damage to the effort required to breach the resource. The SAP tool discovers application resources and combines that data with DER numbers to generate attack surface metrics for software components. While the discovery of resources is fully automated, the tool requires context specific configuration based on experience, judgment, and a threat modeling process.

Given the complex nature of deploying SAP software securely it’s not surprising that they have invested in this area. However, all systems can benefit immediately from simply measuring the potential avenues of attack and understanding the impact. This practice can be particularly beneficial for complex systems with many configuration decisions. In the healthcare sector, where Redspin has done many information security assessment projects, a good example is healthcare information exchange systems. A further example with broad deployment across many sectors is CRM systems.

Whether through design reviews, deployment guides or development tools, the practice of reducing the attack surface associated with an application has the potential to quickly yield a high return on investment.

IT Network Securty – How much security is enough?

Posted on May 22, 2010 by John Reno in Main | Leave a comment

In discussions with customers over the past few weeks the question of how much security is enough for a given organization has been raised repeatedly. Contrary to the opinion of some in the industry, this really is not a mysterious issue. To understand what is enough security requires understanding an acceptable risk level for a company. Building that understanding is the heart of a risk management process. At a high level, an enterprise must understand business drivers, business requirements, regulatory requirements and analyze risks and threats on an ongoing basis.  The diagram below illustrates this concept.

There are many different standards and guidelines for risk management ranging from ISO 31000 to NIST guidelines but the general process involves:

• identifying corporate assets
• assign a value to each asset
• identifying each asset’s vulnerabilities and threats
• determine the risk for the identified assets

Upon completion of this process the risk analysis team can determine what’s necessary to mitigate the risks, analyze the benefits of security countermeasures and work with management to make a decision appropriate for the business.

Mitigating risk through security countermeasures such as additional controls is just one option. The organization can decide to accept the risk, avoid the risk (perhaps by exiting a particular business) or transfer the risk by purchasing insurance.

An important element of this process is to understand the relationship between security threats, business goals, legal requirements and regulatory requirements. The risk management team must ask the question – how can security threats negatively affect business goals? They must also ask what impact does legal and regulatory requirements have upon business goals? Synthesizing the answer helps define the acceptable risk level for the business. Understanding the acceptable risk level is the key to answering the question of how much security is enough.

Cloud Security – New Worries or the Same Old Stuff?

Posted on May 12, 2010 by John Reno in Main | Leave a comment

Cloud service based deployments have become commonplace in industry segments ranging from financial services to healthcare. I have discussed in earlier posts how the cloud services model will come to dominate important areas such as healthcare information exchanges. The economic model is highly attractive across a broad range of business problems. Several years ago as the business models and technical foundations for cloud computing were taking shape I helped form the cloud security alliance. One area of frequent debate was whether the cloud services paradigm called for new approaches to security. Then as now, I think the debate is still valid. My personal opinion is that the security and risk fundamentals remain the same, but the pressure points are different.

Perhaps an example would be useful to consider. Application security is a critical consideration whether you ship a CD (you know some really cool software still ships on a CD these days) or ship bits to Amazon AWS. Often the top of mind issue for developers tasked with the problem of application security is confidentiality – basically protecting sensitive data from cybercriminals and malicious business partners or insiders. Sometimes overlooked are application security issues (that are amplified in cloud services deployments) related to integrity. Consider an attack in which a virtual machine instance is injected into a cloud system such as Google App Engine or Microsoft Azure. Such cloud malware could serve many purposes for the attacker ranging from eavesdropping to data modification. Given that the attacker has done sufficient reconnaissance and is able to convince the cloud system to treat the new instance as a valid VM associated with the particular service, the cloud system redirects user requests to the malicious service implementation and the adversary’s code is executed.

The countermeasure to this threat falls back on the usual security principles. Perform an integrity check prior to using a VM instance for incoming requests. This can be done by storing a hash value of the original VM image and comparing this value with all new service instance images. The attacker can presumably still crack the hash value comparison, but the risk is dramatically reduced.

Perhaps in a later post I will discuss cloud service flooding attacks. An unpleasant thought for those who are paying the bill.

Economics, HIE’s, and Information Security

Posted on May 5, 2010 by John Reno in Main | Leave a comment

Do economics, HIE’s and information security seem like a strange set of words to find together? I’ve been spending a lot of time recently talking with folks at healthcare providers and healthcare IT vendors, and they have found the relationships among these words fascinating. What I have encountered is a quite different set of viewpoints, that form an interesting contrast with the stories related to ARRA funding, state HIE initiatives and breach notification penalties that have been filling the mainstream healthcare IT trade press.

My primary line of discussion with providers (mainly hospitals and integrated delivery networks or IDNs) and HIE vendors has been around the topic of what are the economic drivers associated with HIE deployment and use. It was interesting to find that while hospitals and IDNs see significant benefit in participating in state funded and operated HIE’s over the medium to long term, they are launching their own HIE programs to take advantage of economic benefits in several areas. Several organizations outlined the following elements of near term focus:

• Decrease costs through elimination of redundant tests, fewer lab orders and imaging procedures.

• Improve productivity through workflow optimization in areas such as finding patient records and overall throughput.

• Increase quality in areas such as e-prescribing and more accurate diagnosis.

Over the medium to long term, expected benefits included additional areas such as meeting meaningful use requirements, increased physician referrals and improved patient satisfaction.

Another significant development that has lowered the barriers to taking on an HIE initiative is the growing popularity of software-as-a-service (SaaS) based solutions from the HIE vendor community. These services from vendors such as Axolotl, eClinicalWorks, Initiate, Medicity and RelayHealth mean that the funding organization does not have a capital outlay.  The hospital or IDN needs to focus simply on the operating model to make the economics work.

So where does information security factor into the equation? Well for one, from the vendors and providers that I have talked with, the prospect of managing the security, compliance and privacy of all the sensitive data that an HIE program drives causes a great deal of lost sleep. But security must also be viewed as an economic enabler – if the patients, physicians and hospital staff can use the system effectively, with the assurance that sensitive data is protected and accessed properly, the benefits described earlier can generate the necessary top-line and bottom-line results. Often a common pitfall encountered in structuring security programs is a reliance on simply meeting compliance requirements. While necessary, such an approach by no means is a formula for ensuring security or reducing risk.

In working with both vendors and providers on security, privacy and compliance in the HIE space, we have found the most productive approach is to start with an assessment, break the problem down in to manageable areas, staff appropriately and manage risk on an ongoing basis. The table below outlines how we structure a security assessment for both vendors that are operating a SaaS-based HIE solution or healthcare providers that are using the system.

The information security program is fundamental to the success of an HIE initiative. Making the economic model work effectively requires a focus beyond obvious areas such as compliance and technical controls with careful attention to governance, risk management, and operational process. Draw on expert experience and the business benefits of an HIE program will yield near term and long term results.

1 2 3   Next »