CHI Benefits Evaluation Framework

We usually associate risk with adverse events and negative consequences. Privacy and security breaches, project failure, plague and pestilence dominate our attention. But risk management techniques are also applied to the good things in life.... wealth and prosperity, reward and recognition. Consider your investment portfolio. Nothing in your portfolio is there to be lost. You recognize that there are risks, but you manage them. In fact... more risk, more reward.

But you need indicators to help determine if you're winning or losing. Like your investment portfolio we need to know what we want to achieve with our investments in eHealth, and indicators to mark progress or loss.

Canada Health Infoway has issued a technical report titled Benefits Evaluation Indicators - Technical Report, which provides a benefits evaluation framework and indicators for its primary investment lines which include diagnostic imaging, drug information systems, laboratory information systems, public health systems, telehealth systems and the interoperable electronic health record.

Its an important resource for those of you charged with demonstrating the value of eHealth investments.

eHealth Vulnerability Reporting Program

The eHealth Vulnerability Reporting Program is a venture, founded in May 2006, "to establish approaches and procedures that will help ensure eHealth systems are broadly and rapidly deployed with the highest levels of privacy and security". They have published an executive briefing on some of their findings which include:

• EHR vulnerabilities can be exploited to gain control of application or access to data for modification or retrieval
• EHR applications have vulnerabilities consistent with other complex applications
• Application vulnerabilities have long lives
• EHR vulnerabilities are not disclosed to customers of these systems
• Commercial EHR systems are vulnerable to exploitation given existing industry development and disclosure practices
• Security software effectively reduced time of exposure
• No organization could be identified that has responsibility, charter or mission to address security vulnerabilities in eHealth applications

The report stresses that the "sky is not falling" but EHR vendors, healthcare providers and the healthcare industry need to do much more.

This is a space worth watching for future developments.

For an overview of the report read Nancy Ferris' article titled Hacking into e-health records is too easy, group says.

So Much for Transparency ☹

As I sat yesterday contemplating the contents of the courier package, I thought about Kafka’s Joseph K. and the niggling and growing frustration he felt as he prepared for his trial. These aren’t bad people… these nameless and faceless bureaucrats. But they are a breed, and its in their nature to jealously hoard and guard information.

You may have read the post concerning my Freedom of Information request for the Privacy Impact Assessments for the Ontario Laboratory Information System (OLIS), the Ontario Drug Benefit Drug Program Viewer (ODBDPV), and the Integrated Public Health Information System (iPHIS). My original intention was innocuous enough. Very few PIAs are available on the Internet. I was looking for examples I could use in the Health Privacy Professional Workshop I teach at the Waterloo Institute for Health Informatics Research. I had read two of the three PIAs in question in my former role as Chief Privacy and Security Officer for the Ontario Smart Systems for Health Agency and thought that they would be useful and topical references for workshop participants.

In June the Ontario Ministry of Health and Long Term Care (MOHLTC) denied access to the documents under various exemptions in the Freedom of Information and Protection of Privacy Act. I appealed the decision to the Information and Privacy Commissioner for Ontario.

My appeal has just gone through the mediation process and the courier package contained a new decision to release redacted copies of the OLIS and ODBDPV PIAs. The full iPHIS PIA is still denied. To say the OLIS and ODBDPV PIAs were redacted is an understatement.

Now I would have expected some modest redacting where there was a risk of exposing, for example, security vulnerabilities or trade secrets. However, the redaction in this case went over the top.

The redacted ODBDPV PIA (download a copy here) is an 83-page document. The pages are blank until page 56 where they then released 16 pages of already available public information such as regulations and forms. The last 12 pages are also blank. Not a cover page, table of contents or executive summary… I would not even be able to identify the document as the ODBDPV PIA were it not for the covering decision letter.

The redacted OLIS PIA (download a copy here) is a 153-page document. The first 11 pages containing the cover page, document boilerplate and definitions have been released. This is followed by 110 blank pages, then 2 ½ pages containing a textbook table of very general privacy risks and some legal authorities followed by another 30 blank pages.

Of course the iPHIS PIA was denied in its entirety, which for the sake of the trees involved was probably just as well.

All in all the MOHLTC sent me more than 200 blank pages!

The reasons for the denied access referenced the following exemptions under the Freedom of Information and Protection of Privacy Act.

• Section 12 – Cabinet Records
• Section 14 – Law Enforcement
• Section 17 – Third Parties
• Section 19 – Solicitor-Client Privilege


The sad thing is that these are good projects, and I expect that the PIAs would demonstrate that all known privacy risks have been identified and are being well managed. I personally know and respect the people who wrote these documents. Unfortunately we are subject to those governmental and societal influences so well described by Franz Kafka in his books The Castle and The Trial (I reflect on these issues and my own experience as one of Kafka’s bureaucrats in my essay We’re All Kafka Bureaucrats). If I didn’t know better I could read sinister motives into the Ministry’s denial of my request. What could they be hiding? What terrible risks lurk in these systems that could do serious damage to the good citizens of Ontario?

But no. They hide everything… good and bad. Its in their nature. So much for transparency.

Needless to say I have applied to the Information and Privacy Commissioner’s office to proceed to the next stage – adjudication. We’ll see what happens next.

Oh.. and I will be using these documents in my privacy workshop, though not in the way I had originally intended.


Supplementary Comment (22/9/07):

I'm not the only one frustrated by Government's response to FOI requests. Check out this article in the Globe and Mail titled Delay, denial and stonwalling still clog FOI system.

EHR and Patient Safety

Canada Health Infoway has published a comprehensive report titled The relationship between Electronic Health Records and Patient Safety. Conducted in collaboration with the Integrated Centre for Care Advancement Through Research and the Canadian Patient Safety Institute, the report provides an honest assessment of what we know and don't know about EHRs and patient safety, and where we need to go.

Worth a read.

Future Directions in Technology-Enabled Crime

The Australian Institute of Criminology has published a comprehensive report titled Future directions in technology-enabled crime: 2007 - 09. This 166 page tome surveys existing and emerging threats to information systems in the e-enabled world. Among the risks areas discussed are:

• Computer-facilitated frauds
• Unauthorized access
• Evolution of malware
• Intellectual property infringement
• Industrial espionage
• Child exploitation and offensive content
• Exploitation of younger people
• Transnational organized crime and terrorism
• Threats to national information infrastructure

Security has always been a cat and mouse game between the bad guys and those who work to thwart them. This report gives a good overview of the game as of today. Lets hope the good guys can stay out in front.

Get Ready to Rumble!

I enjoyed immensely yesterday's post by Blogger Dr. Scott Shreeve in an open letter to Google Health's new director Marissa Mayer. He succinctly sums up the challenges encountered by everyone trying to implement IT in health care.

I especially liked his openning salvo:

Get ready to rumble. The healthcare industry is littered with the carnage of decades of innovators shattering themselves against the iron anvil of the healthcare. While there have certainly been successes, there are 10x defeats.

Take a look. Its an short but interesting read.

Catogorizing eHealth Business Risk

I have been looking for a model for categorizing and evaluating eHealth business risks. The best I've found so far is a standard and guide published by the UK Risk Management Institute titled A Risk Management Standard. This Standard describes four types of business risk:

Strategic Risks - include all of the external and environmental factors associated with an industry. In eHealth this could include political risk, user acceptance (or lack thereof), business model and governance issues.

Compliance Risks - are those risks associated with the need to comply with laws and regulations. In eHealth this would include compliance with privacy and data protection legislation, health and safety regulations, and compliance with legislation governing the operation of health institutions and health professions.

Financial Risks - are those risks associated with the financial structures, transactions and financial processes in place in your organization. In eHealth this could include risks associated with inadequate financial controls, fraud, legal liability and unstable sources of capital and operational funding.

Operational Risks - are those risks associated with operational and administrative procedures. In eHealth this could include business continuity, disaster recovery, procurement issues, and ability to meet required service levels.

All-in-all, a neat and simple way of expressing business risk.

The guide also suggests a basic (though complete) approach to business risk identification and treatment. Another site, UK Business Link, which seems geared to small to medium sized businesses (about the size of our average health care operation), provides a good overview of the process.

How to Eat an Elephant

Its an axiom that we all-too-often forget. The way to eat an elephant is one bite at a time. Big bang projects are rarely successful. I was reminded of this point while reading an article on the CIO website titled How to Justify an IT Project With Uncertain Returns (And Still Make Your CFO Happy). The author, J.Marc. Hopkins, is the CIO for a large US medical practice. He stresses the need to start small, build on successes, and focus on the needs of end users.

A Foolproof Privacy and Security Plan

GovernmentHealthIT published an article today titled Experts offer advice for creating a foolproof privacy and security plan for sharing patient information. Key points:

1. Think nationally, act locally
2. Use available tools
3. Bring the right people to the table
4. Be broad but restrictive
5. Study HIPAA (or whatever privacy legislation applies to you - italics mine) then go beyond it
6. Keep the focus on the patient

Useful advice.

Australian Standard AS/NZS 4360 Risk Management

Anyone looking for a comprehensive standard for risk management should look to Australian Standard AS/NZS 4360 Risk Management. I have looked at just about everything out there in the standards space and find this standard to be the most useful and usable. What I especially like about it is that it takes a broader view of risk, looking at the opportunity side of the equation in addition to the more negative risk-of-adverse-event side.

From the forward to 4360:

Risk management involves managing to achieve an appropriate
balance between realizing opportunities for gains while
minimizing losses. It is an integral part of good management
practice and an essential element of good corporate governance.
It is an iterative process consisting of steps that, when
undertaken in sequence, enable continuous improvement in
decision-making and facilitate continuous improvement in
performance.

Risk management involves establishing an appropriate
infrastructure and culture and applying a logical and systematic
method of establishing the context, identifying, analysing,
evaluating, treating, monitoring and communicating risks
associated with any activity, function or process in a way that
will enable organizations to minimize losses and maximize
gains.

To be most effective, risk management should become part of an
organization's culture. It should be embedded into the
organization's philosophy, practices and business processes
rather than be viewed or practiced as a separate activity. When
this is achieved, everyone in the organization becomes involved
in the management of risk.

Although the concept of risk is often interpreted in terms of
hazards or negative impacts, this Standard is concerned with risk
as exposure to the consequences of uncertainty, or potential
deviations from what is planned or expected. The process
described here applies to the management of both potential gains
and potential losses.

Organizations that manage risk effectively and efficiently are
more likely to achieve their objectives and do so at lower overall
cost.

The Standard is available for purchase alone or with a very useful implementation guide titled HB436 Risk Management Guidelines - Companion to AS/NZS 4360. Both publications are highly recommended.

A Poor Judge of Risks

Continuing the thread from my post What Type of Person Takes Risks, an anonymous commentator suggested that we look at security guru Bruce Schneier's article Why the Human Brain Is a Poor Judge of Risk.

Every human being (yes.. that's each one of us) looks at life through filters. Some are rosy... some are black... and they change depending on our moods, our personal experiences, and how we interpret our present circumstances. We really can't be trusted to assess risk based on our "gut feelings".

Question: How many animals of each type did Moses take on the Ark?

Answer: None... It was Noah

The human brain is too easily tricked into thinking that it knows and understands more than it really does. That is why we need structured and disciplined processes such as Privacy Impact Assessment, Threat and Risk Assessment or Safety Hazard Risk Assessment.

For more also read Don Norman's essay Being Analog.

We need to apply more science and less instinct.

Dealing with Whistleblowers 2

eHealthRisk Blog reader Kim Sanders-Fisher posted a lengthy comment on my previous post Dealing with Whistleblowers concerning her own personal experience as a whistleblower at a prestigious US hospital. Her comment suggests that my assertion, that every health care organization should put a reporting system in place that allows staff to report safety, privacy and other risk issues without fear of retribution, was somewhat simplistic.

In a perfect world we would encourage and thank people who report matters that compromise the safety and wellbeing of patients and health care workers. In reality, the world is much more complex and, often times, nasty. We continue to live in a blame-oriented culture that would much prefer to kill the messengers (i.e. whistleblowers) than to accept that our organizations and the people who run them are less than perfect.

Unfortunately, even whistleblowing programs and protections that are in place in progressive organizations are easily subverted by low, middle and senior managers who have a vested interest in maintaining the status quo, even if the status quo poses risks to patients and others. Its too easy to blackball someone, making their life miserable, in the hope that they will just go away.

Quis custodiet ipsos custodes? (Who guards the guardians?) Its sad that those in positions of authority in many organizations will tend to act in their own self-interest and the interests of the organization, rather than in the interests of patients.

I am coming to the conclusion that we must implement independent mechanisms such as the Aviation Safety Reporting System to address risk issues in health care, including safety, privacy and security issues associated with eHealth such as security deficiencies, software and other technology errors and poor human factors engineering. This would include the many systemic and organizational issues that will arise as health care providers us eHealth tools to deliver health care.

I'm waiting to hear about a positive whistleblower experience. One where the whistleblower was acknowledged and thanked for taking a personal risk to protect the interests of the patients they were caring for.

I'm not holding my breath.

Its the Business Model Stupid!

More and more, it becomes clear that the greatest risk to major eHealth initiatives has nothing to do with privacy, security or other risk issues... Its the business model. Unless there is a clear value proposition for each of the major players in an eHealth program, it will not survive. Scanning the news this morning I came across this post from Modern Healthcare Online titled RHIO experts talk problems, future of movement. Some notable quotes from the article:

It's not yet clear if the incentives exist for healthcare organizations to share information.

One problem with RHIOs as they often are proposed is that they provide the bulk of their benefits to patients and health plans, people and entities that according to our current healthcare payment structure either don't pay at all for RHIO startup and operational costs or pay a disproportionately small share.

It does not make sense for a RHIO to have a consumer-centric model. It's a noble idea to say put the patient first, but what you have to have are business plans within the provider community.

Another common stumbling block to RHIOs is an unwillingness of likely participants to collaborate because of provider and payer rivalry and mistrust.

Too many eHealth initiatives go forward on the assumption that with the right technical architecture and interoperability standards, success is a slam-dunk. While important, what will sink the initiative is one or more stakeholders not believing that it is worth their while to participate.

I was intrigued about the comments concerning the idea of putting the patient first. While it is a noble thought, and while we would do well to structure our architectures based on that premise, eHealth must provide direct, tangible and measurable benefits to those who have to foot the bill or expend the energy effort necessary to ensure success.

Its the business model stupid!