Security of Medical Information

eHealthRisk Blog reader Lyndon Dubeau passed on this link to UK Information Security Expert Ross Anderson who is a professor at the University of Cambridge. I've just spent an hour watching his online lecture Searching for Evil, in which he discusses how to find and thwart bad guys on the net.

Anderson's website has a wealth of information and useful links. Its worth a look.

Community Attitudes to Privacy 2007

The Office of the Privacy Commissioner of Australia has issued a report titled Community Attitudes to Privacy 2007. The study aimed "to understand Australians' changing awareness and opinions about privacy laws, how they apply to government and business and how individuals view a range of emerging issues, in particular, identity fraud and theft and the use of closed circuit television."

Also included in the report was an assessment of consumer attitudes towards health services and privacy including inclusion in a National Health Database, health professionals sharing patient information, Doctors discussing personal medical information in an identifiable way, and disclosure of the fact that a patient has a genetic illness - with and without consent. A brief analysis of the report and its implications for health care can be found on Dr. David More's blog Australian Health Information Technology.

What Type of Person Takes Risks?

How do you classify a person who skydives, yet won't stand up to his/her boss? Is he/she a risk-taker? Understanding why we take some risks and yet avoid others is at the heart of risk management. Researchers at the University of Michigan have recently published a paper titled Towards the development of an evolutionary valid domain-specific risk-taking scale - an unwieldy title better explained in an article titled Not all risk is created equal by the University of Michigan News Service.

Thanks to Gila Pyke for passing this link along.

AHRQ National Resource Center for Health IT

The Agency for Healthcare Research and Quality (an agency of the US Department of Health and Human Services) has established a National Resource Center for Health Information Technology. While US focused, it contains many articles, resources and toolkits that can be adapted to many jurisdictions. I particularly like their Privacy and Security Toolkit and "Emerging Lessons" pages for CPOE, EMR/EHR, Health Information Exchange, and Health IT in Small and Rural Communities.

Its an excellent site that appears to present a balanced view of many eHealth opportunities and issues.

eHealth Business Risk

Business risk is associated with the business and political environment in which a health care organization operates. It is perhaps the most challenging area of risk because often the organization doesn’t have control over the measures necessary to reduce the impact or likelihood of such events.

Business risks are often at the heart of the risks identified in other domains. For example, many privacy risks arise because of confused business models that don’t clearly define the roles and responsibilities of each of the stakeholders in an eHealth program. Business risk sometimes transcends the organization for regional, provincial, state and national eHealth programs where government or other supra-organizations are responsible for setting and enforcing standards and policy. The issue of eHealth governance is central to the management of business risk.

There are no defined control standards available to specifically address eHealth business risks at the regional, provincial, state and national levels. Each government jurisdiction has its own unique business and regulatory environment. However, anecdotal evidence suggests several significant control measures that should be put in place for such eHealth programs.

1. An eHealth Governance Framework and Authority – A legitimate body that has the authority to establish and enforce policy and standards in an eHealth environment that includes many healthcare organizations, health care providers and other stakeholders.

2. A Comprehensive Business Model – that defines the roles and responsibilities of each stakeholder in an eHealth program. This includes ensuring that all stakeholders benefit from the initiative in a manner and magnitude consistent with their investment.

3. A Contractual Framework – that accurately represents the business model and agreements between all stakeholders participating in the eHealth program. This would include consent forms and processes for patients.

4. Strategic Business and Technical Architectures –that enable the integration of the eHealth program into the larger health system and ensure that it is interoperable with other eHealth programs and systems.

5. A Stakeholder Engagement Model – to ensure that the interests of all stakeholders, and in particular, patients and end-users, are addressed in all aspects of eHealth program design, deployment and support.

In most jurisdictions around the world, governments have significant involvement in the funding and management of health care. This results in a complex political environment that has a direct impact on business risk. Political influence can be exerted by politicians or by the bureaucracy that supports the government. Political decisions affect priorities and in extreme cases can interfere with normal business protocols.

Business risks associated with eHealth include:

• Regulatory and legal liability
• Financial loss
• Political interference
• Procurement challenges
• Rejection by users
• Business interruption

Guidance on business risk assessment and management can be found in the publication Management of Risk: Guidance for Practitioners that is published by the British government’s Office of Government Commerce. This guide addresses risks at the strategic, program, project and operational levels.

eHealth Insider

One of my regular stops on the Internet is eHealth Insider, an online journal published in the United Kingdom. Its focus is on eHealth in Britain, but often its articles are universal in nature. There are lots of lessons to be learned from the UK experience, and this online resource is an excellent source of topical information. They publish eHealth Insider (focusing on the NHS's eHealth initiatives), eHealth Insider Primary Care (what's going on in the physician world), and eHealth Europe (what's going on all over Europe). You can subscribe to their online newsletters so you won't miss a thing!

What caught my eye today is a report on an article published in the British Medical Journal titled Potential of electronic personal health records and EHI's subsequent review and interviews with the authors.

The Un-Health Record

While scanning the Internet my eye caught an article in GovernmentHealthIT titled The un-health record by Nancy Ferris. It discusses a growing trend by Governments to use health claims data instead of clinical data for a "claims-based EHR". This trend is documented in a report by the US Department of Health and Human Services Office of the Inspector General titled State Medicaid Agencies initiatives on HIT and HIE. Similar initiatives exist in other countries, including Canada, where the Ontario provincial government gives emergency department access to drug claims data for the Ontario Drug Benefit Program.

Its understandable that Governments, with their massive stores of health claims data, would want to put that information to use. However, there is always a risk of using information collected for one purpose (claims adjudication and payment) for another (clinical decision making). Data quality is the issue here.

How good is claims data? From the article:

A 2004 study published in the journal Medical Care found that claim forms showed the correct primary diagnosis slightly more than half the time. For secondary diagnoses, doctor’s offices submitted correct information just 27 percent of the time. Other researchers have come up with comparable findings.

What’s more, claims data lacks some important details and nuance because of the universal coding scheme and the way it is used. For example, the scheme does not distinguish between a severe case of diabetes and one that’s under control, and providers don’t always use the diagnostic codes that indicate the spread of cancers. Furthermore, symptoms such as pain or fever usually don’t show up at all.

So long as health care professionals are fully informed about the limitations of the data, the use of claims data probably brings more benefits than risks. Claims data can be used as one input into the clinical decision-making process. However, in the absence of structured processes for evaluating the quality of the data, and safety risks in eHealth, claims data alone cannot be used as the basis for clinical decision-making.

Lessons Learned from Santa Barbara

One of the most celebrated RHIO (Regional Health Information Organization) failures in the United States was the Santa Barbara County Care Data Exchange which ceased operations in December 2006. The California HealthCare Foundation has released an evaluation of the initiative titled The Santa Barbara County Care Data Exchange: Lessons Learned, which documents the issues leading to the failure and lessons learned for similar initiatives. From the Executive Summary:

The Santa Barbara County Care Data Exchange (SBCCDE) was once one of the most ambitious and publicized efforts to develop health information exchange in the United States, and was considered a model for emerging regional health information organizations (RHIOs) elsewhere. Nearly eight years after its inception, and several months after providing some data to clinical end-users, the SBCCDE ceased operations. Although the venture had developed a peer-to-peer technology infrastructure that enabled authorized physicians, health care organizations, and consumers in the region to access some electronic patient information security via the Internet, the once-promising exchange was unable to overcome major hurdles and thrive.

This case study looks at the history of Santa Barbara's RHIO and why it was not successful. It also presents lessons learned from that experience, briefly describes two other exchanges that have been more successful, and discusses the policy implications for nascent RHIOs elsewhere. Reasons why the project did not succeed include the lack of a compelling business case, distorted economic incentives, passive leadership among participants, vendor limitations and software delays, and due to a variety of factors, the venture's poor momentum and credibility.

This case study is required reading for eHealth risk specialists!

Requirements for Enhancing Data Quality in EHR Systems

The US Department of Health and Human Services has published a document titled Recommended Requirements for Enhancing Data Quality in Electronic Health Record Systems (EHR-S). The primary purpose of the project was "to identify requirements for EHR-S that can help enhance data protections, such as increased data validity, accuracy and integrity including appropriate fraud management which would prevend fraud from occuring, as well as detect fraud both prospectively and retrospectively."

The fourteen recommended functional requirements include:

Requirement 1: Audit Functions and Features
Requirement 2: Provider Identification
Requirement 3: User Access Authentication
Requirement 4: Documentation Process Issues
Requirement 5: Evaluation and Management (E&M) Coding
Requirement 6: Proxy Authorship
Requirement 7: Record Modification after Signature
Requirement 8: Auditor Access to Patient Record
Requirement 9: EHR Traceability
Requirement 10: Patient Involvement in Anti-Fraud
Requirement 11: Patient Identify-Proofing
Requirement 12: Structured and Coded Data
Requirement 13: Integrity of EHR Transmission
Requirement 14: Accurate Linkage of Claims to Clinical Records

All of these requirements are integral to managing the risks associated with EHRs. A very useful piece of work!

HIMSS PHR Definition and Position Statement

I give a lot of air time to Personal Health Record (PHR) developments on this blog because I believe they represent the wild card in the high stakes game of eHealth. Think of it as the battle between the controlled economy (EHR) and the marketplace (PHR). For all of the privacy legislation and interoperability standards we put in place, the battle will be won by whoever can capture the attention of the kids who are text messaging and sharing information over their iPhones and Boomers who are increasingly concerned about their deteriorating health and want to take control of their destinies.

The Healthcare Information Management and Systems Society (HIMSS) has published a PHR Definition and Position Statement. They define a PHR as:

a universally accessible, layperson comprehensible, lifelong tool for managing relevant health information, promoting health maintenance and assisting with chronic disease management via an interactive, common data set of electronic health information and e-health tools. The ePHR is owned, managed, and shared by the individual or his or her legal proxy(s) and must be secure to protect the privacy and confidentiality of the health information it contains. It is not a legal record unless so defined and is subject to various legal limitations.

The HIMSS Statement of Position is:

HIMSS supports the development of interoperable ePHRs which are interactive and use a common data set of electronic health information and e-health tools. HIMSS envisions ePHRs that are universally accessible and layperson comprehensible, and that may be used as a lifelong tool for managing relevant health information that is owned, managed and shared by the individual or his or her legal proxy(s). The ideal ePHR would receive data from all constituents that participate in the individual’s healthcare; allow patients or proxies to enter their own data (such as journals and diaries); and designate read-only access to the ePHR (or designated portions thereof).

HIMSS supports ePHR applications with the following characteristics:
• Provide for unique patient identification
• Allow secure access to the information contained in the ePHR
• Permit the receipt of email alerts that do not reveal protected health information (PHI);
• Allow patient proxy(s) to act on behalf of the patient
• Permit the designation of information to be shared electronically;
• Provides technical support to ePHR constituents at all times.

HIMSS champions the development of national standards to ease burdens placed on constituents due to variances in state law and the development of national and uniform state standards to address legal concerns raised by ePHRs such as reliability, reimbursement, ownership, access, transfer, and the limitations, rights and responsibilities of patients and providers for the use of e-health and ePHRs.

Similarly, HIMSS encourages the adoption of incentives by payors, providers, pharmaceutical companies, device manufacturers, and the federal and state governments of the United States to reduce the financial barriers to motivate widespread ePHR adoption.

This is a laudable position that seeks to reign in the wild west world of PHRs. Only time will tell whether the controlled economy or the marketplace prevails.

Project Success and Failure

Information technology projects are well known for the risk of unsuccessful completion. A 2004 report by the Standish Group indicated that only 29% of IT projects succeed. Of the remainder 18% fail outright and 53% fail to meet expectations by exceeding timelines or budgets, or by failing to deliver the required functionality.

The Standish Group has published the top ten criteria for successful projects:

1. User involvement
2. Executive management support
3. Clear statement of requirements
4. Proper planning
5. Realistic expectations
6. Smaller project milestones
7. Competent staff
8. Ownership
9. Clear vision and objectives
10. Hard-working, focused staff

The issue of project management in eHealth is directly linked to yesterday's discussion of program management. Rarely will a project stand on its own. eHealth is implemented into a complex environment that will require a range of interventions to succeed. These other interventions may include business and clinical process re-engineering, changes in job function, new skills development and cultural change. As a result, an eHealth program may involve a number of projects each of which should be considered in the project risk analysis.

Worthy of note is the top reason for project success (or failure if it is missing): user involvement which we know to be a continuing issue in the development of eHealth systems and infrastructure.

A Program View of eHealth

I am a big fan of the book by John Thorp titled The Information Paradox: Realizing the Business Benefits of Information Technology (unfortunately it is out of print, though used copies can be ordered through Amazon.com). One of the main points in his book is the need to take a program view of IT initiatives.

Far too many eHealth initiatives start and end with the development and implementation project. Many project sponsors and managers have a "build it and they will come" attitude. They're convinced of the benefits of eHealth. Surely health care workers will see the light and happily adapt their day-to-day routines to accommodate the new system. Unfortunately, taking a narrow IT project view will more likely end up with interruptions in business and clinical processes, user rejection, and ultimate failure.

Programs are structured groupings of projects designed to produce clearly identified business results or other end benefits. Rarely does an eHealth system stand on its own as a single project. eHealth is invariably implemented into a complex environment requiring a range of interventions to ensure a successful outcome.

For example, eHealth systems often form part of larger business transformation initiatives such as those supporting primary care reform or wait-times management. Even on their own, eHealth systems require re-engineering of business and clinical processes, changes in job function, end-user training, transformation of organizational culture and ongoing management and maintenance in the operational environment in order to be successful.

One cannot realize benefits or manage risk with a narrow project view of an eHealth initiative. The implementation project represents only the first phase in a long term eHealth program designed to benefit patients, health care providers and health care organizations.

Google and Microsoft..... Again

I don't usually publish links to the mass media because they tend to be sketchy in terms of accurate information and rarely contain any meaningful analysis (see my post Critical Reading) . Sometimes they mislead more than they inform.

However, yesterday's New York Times published an article titled Google and Microsoft Look to Change Health Care. Again, the article is really sketchy, but its worth reading to get a sense of where these two software behemoths may be headed with personal health records. It gives some clues as to what Google is putting into its prototype application, and some of the challenges that are likely to slow Google and Microsoft down.

Some of Google's prototype screenshots are showing up in the blog world. Check out the First Google Health Screenshots post from Google Blogoscoped.

Business Continuity Planning

On this, the 4th anniversary of the North American blackout that left more than 50 million people in the dark, I thought it appropriate to discuss business continuity planning. Disasters happen and the health care community must be prepared for them. As health care becomes more dependent on information technology, health informaticians also have to be prepared. A disaster of any kind causes increased demand on the health system. We can't afford to have the technical infrastructure supporting healthcare compromised at the same time.

I had personal experience with two disasters while I was at the Ontario Smart Systems for Health Agency (SSHA). One was the blackout mentioned. At Smart Systems we thought ourselves clever by building two high availability data centers with alternate energy supplies and telecommunications systems that barely felt a blip during the blackout. While our data centers were happily humming along, our administrative offices were shut down, the roads, traffic and public telecommunications networks were gridlocked making it difficult for staff to carry out their duties (though they did manage to get through), and many of our clients were without the power needed to run their local systems.

The other disaster was the SARS outbreak that hit Toronto causing a massive public health crisis. Our own data center staff was quarantined for several days after a data center employee (not an employee of SSHA) in another part of the complex went into the data center while infected (that person later died - thankfully no SSHA staff were infected). Fortunately we were still in the build phase at the time and not running any critical health information systems out of the data center.

These and other disasters such as Hurricane Katrina demonstrate that catastrophic events do happen and that it behooves us to be prepared. See how jumpy public health officials are at the news of a chicken sneezing in a Chinese marketplace.

eHealth has the potential to help the health system cope with a disaster, as was evidenced during Katrina. Electronic health records can aid disaster workers and those who must care for chronically ill patients. But this only works when we have taken adequate precautions to ensure that our information systems are operational at the same time.

I came across a unique public health website the other day. The Peel Public Health Unit (servicing an area just outside of Toronto) is promoting business continuity planning as part of its public health program. They emphasize the need to anticipate disasters, to plan and protect our people, processes, facilities and technologies in the event of a disaster. The threats they suggest need to be addressed are:

• Fire
• Labour interruption
• Communication breakdown
• Pandemic influenza
  
• Communicable disease outbreak
• Supply chain interruption
• Natural/man made disasters
  
• Transportation accident - Rail
• Essential services failure (power, water, sewer, telecom)
• Water contamination
  
• Flooding/drought/water shortage
• Severe weather conditions (extreme heat, extreme cold, freezing rain and severe storms)
• Technology collapse
• Terrorism/Sabotage/Cyberterrorism
• Bio terrorism
• Your worst nightmare

Based on their risk assessment the threats in bold letters represent the 5 most serious threats to the Peel community. This will vary from community to community.

Disasters happen. Our eHealth systems will break down and fail. We need to be ready.

The Point of Vanishing Interest

Have you ever attended a meeting like this one?
(note that this was written in 1957 - 50 years ago)

__________________________________________

Chairman: We come now to Item Nine. Our Treasurer, Mr. McPhail, will report.

Mr. McPhail: The estimate for the Atomic Reactor is before you, sir, set forth in Appendix H of the subcommittee's report. You will see that the general design and layout has been approved by Professor McFission. The total cost will amount to $10,000,000. The contractors, Messrs. MaNab and McHash, consider that the work should be complete by April, 1959. Mr. McFee, the consulting engineer, warns us that we should not count on completion before October, at the earliest. In this view he is supported by Dr. McHeap, the well-know geophysicist, who refers to the probable need for piling at the lower end of the site. The plan of the main building is before you - see Appendix IX - and the blueprint is laid on the table. I shall be glad to give any further information that members of this committee may require.

Chairman: Thank you, Mr. McPhail, for your very lucid explanation of the plan as proposed. I will now invite the members present to give us their views.

It is necessary to pause at this point and consider the various views that the members are likely to have. Let us suppose that they number eleven, including the Chairman but excluding the Secretary. Of these eleven members, four - including the chairman - do not know what a reactor is. Of the remainder, three do not know what it is for. Of those who know its purpose, only two have the least idea of what it should cost. One of these is Mr. Issacson, the other is Mr. Brickworth. Either is in a position to say something. We may suppose that Mr. Issacson is the first to speak.

Mr. Issacson: Well, Mr. Chairman. I could wish that I felt more confidence in our contractors and consultant. Had we gone to Professor Levi in the first instance and had the contract been given to Messrs. David and Goliath, I should have been happier about the whole scheme. Mr. Lyon-Daniels would not have wasted our time with wild guesses about the possible delay in completion, and Dr. Moses Bullrush would have told us definitely whether piling would be wanted or not.

Chairmain: I am sure we all appreciate Mr. Isaacson's anxiety to complete this work in the best possible way. I feel, however, that it is rather late in the day to call in new technical advisers. I admit that the main contract has still to be signed, but we have already spent very large sums. If we reject the advice for which we have paid, we shall have to pay as much again.

(Other members murmer agreement)

Mr. Issacson: I should like my observation to be minuted.

Chairman: Certainly. Perhaps Mr. Brickworth also has something to say about this matter?

Now Mr. Brickworth is almost the only man there who knows what he is talking about. There is a great deal he could say. He distrusts that round figure of $10,000,000. Why should it come out to exactly that? Why need they demolish the old building to make room for the new approach? Why is so large a sum set aside for "contingencies"? And who is McHeap, anyway? Is he the man who was sued last year by the Trickle and Driedup Oil Corporation? But Brickworth does not know where to begin. The other members could not read the blueprint if he referred to it. He would have to begin by explaining what a reactor is and no one there would admit that he did not already know. Better to say nothing.

Mr. Brickwork: I have no comment to make.

Chairman: Does any other member wish to speak? Very well. I may take it then that the plans and estimates are approved? Thank you. May I now sign the main contract on your behalf? (Murmur of agreement) Thank you. We can now move on to Item Ten.

Allowing a few seconds for rustling papers and unrolling diagrams, the time spent on Item Nine will have been two minutes and a half. The meeting is going well. But some members feel uneasy about Item Nine. They wonder inwardly whether they have really been pulling their weight. It is too late to query that reactor scheme, but they would like to demonstrate, before the meeting ends, that they are alive to all that is going on.

Chairman: Item Ten. Bicycle shed for the use of the clerical staff. An estimate has been received from Messrs. Bodger and Woodworm, who undertake to complete the work for the sum of $2350. Plans and specification are before you, gentlemen.

Mr. Softleigh: Surely, Mr. Chairman, this sum is excessive. I note that the roof is to be of aluminum. Would not asbestos be cheaper?

Mr. Holdfast: I agree with Mr. Softleigh about the cost, but the roof should, in my opinion, be of galvanized iron. I incline to think that the shed could be built for $2000, or even less.

Mr. Daring: I would go further, Mr. Chairman. I question whether this shed is really necessary. We do too much for our staff as it is. They are never satisfied, that is the trouble. They will be wanting garages next.

Mr. Holdfast: No, I can't support Mr. Daring on this occasion. I think that the shed is needed. It is a question of material and cost...

The debate is fairly launched. A sum of $2350 is well within everyone's comprehension. Everyone can visualize a bicycle shed. Discussion goes on, therefore, for forty-five minutes, with the possible result of saving some $300. Members at length sit back with a feeling of achievement.

Chairman: Item Eleven. Refreshments supplied at meetings of the Joint Welfare Committee. Monthly, $4.75.

Mr. Softleigh: What type of refreshment is supplied on these occasions?

Chairman: Coffee, I understand.

Mr. Holdfast: And this means an annual charge of - let me see - $57?

Chairman: That is so.

Mr. Daring: Well, really, Mr. Chairman. I question whether this is justified. How long do these meetings last?

Now begins an even more acrimonious debate. There may be members of the committee who might fail to distinguish between asbestos and galvanized iron, but every man there knows about coffee - what it is, how it should be made, where it should be bought - and whether indeed it should be bought at all. This item on the agenda will occupy the members for an hour and quarter, and they will end by asking the Secretary to procure further information, leaving the matter to be decided at the next meeting.

_________________________________________________

Unfortunately I've attended far too many meetings like this.

This excerpt is taken from the essay High Finance or the Point of Vanishing Interest in the book Parkinson's Law by C. Northcote Parkinson. You can read another essay (the one that gave the book its title) Parkinson's Law or the Rising Pyramid at this link. I'm sure you've heard of the law "Work expands so as to fill the time available for its completion". Enjoy!

Truth is Better than Make-Believe

I have just finished reading Henry David Thoreau's classic book Walden... a book chalkfull of famous one-liners and aphorisms. One of the lines in his conclusion is "Any truth is better than make-believe".

The quote struck me because one of the greatest barriers to the successful implementation of eHealth initiatives is a failure to see the truth of our circumstances. Lack of complete and accurate information and understanding is at the root of most eHealth risk.

Why don't we know the truth of our present circumstances? There are many reasons.

• We might not have all the facts.
• The facts that we do have might not be accurate.
• We might not understand the context well enough to be able to interpret the facts that we do have.
• We might fill in any gaps in the facts with our own best guesses, which may be wrong.
• Someone may deliberately withhold the facts, or distort them, or deliberately or unwittingly give us misinformation.
• We might be too busy or not have enough time to gather the facts, and will make decisions based on our gut instincts instead.
• Our biases and prejudices may cause us to misinterpret or disregard the facts.
• Wishful thinking may lead us to fit the facts into a conclusion that we have already reached.
• We might deliberately alter or withhold the facts to avoid blame, or to shield another person or our organization from blame.

Most people don't ignore, alter or withhold information with malicious intent (though that sometimes happens). There are often extenuating circumstances that cause people to interpret the world as they would like it to be. Wishful thinking and avoiding blame are probably the biggest reasons for this.

The first step in any risk management exercise is to understand the environment and context into which your eHealth initiative is to be implemented. This is where science helps. The scientific method is the best approach to analyzing a situation. What are the known facts (i.e. truth)? Where are the gaps? Can we develop reasonable hypotheses to fill in the gaps... and then test those hypotheses multiple times?

We don't know the entire truth about eHealth. We have some early indications of what works and what doesn't. Understanding what we know and don't know, and being honest and truthful about it, and being prepared to take risks, is what is needed to start the journey towards eHealth Nirvana.

Is Privacy a Legal Issue or Management Issue?

There are at least two schools of thought about privacy; one school much larger than the other. The larger school says that privacy is essentially a legal issue... a subject best addressed by lawyers. The smaller school says that privacy is a management issue... those engaged in the management of the business should address privacy issues, consulting legal counsel only when necessary to understand the legal requirements and risks in a particular situation. This matter relates to my recent post Compliance vs. Risk Management.

I am clearly a member of the second school. My experience is that when lawyers get involved in an eHealth initiative, the result is overkill. Solutions are sometimes over-engineered. Complex functionality is created that addresses issues that are very low risk.

I pick on privacy here because privacy (and to a lesser extent - security) is the subject of comprehensive legislation. It seems that legislators and lawyers have little or no interest in the safety or business risks associated with eHealth. Even security issues outside of the privacy domain such as data and system availability and integrity, which can have massive legal and risk implications, are given little attention.

In their proper place legal counsel can be very useful. Privacy legislation is often complex. Health care managers need to understand the legal implications of their decisions. However, legal matters are only one piece of the risk equation that managers must consider.

It comes down to who is calling the shots: the manager or the organization's legal counsel. In my view it must always be the manager.

That said, I found a useful legal resource for Canadians on the web called the Canadian Privacy Law Blog published by Canadian privacy lawyer David Fraser. He has a very comprehensive privacy resource and links section. I'll keep my eyes open for similar resources in other countries.

Listen to your lawyer, then make your decision in the best interests of the patient, health care providers and your organization. Don't let your lawyer make your decision for you.

The Human Factor

Without question the best book I've read about human factors engineering and the issues that arise when we put human beings and technology together is The Human Factor: Revolutionizing the Way We Live With Technology by Kim Vicente. Vicente has written a very readable and fascinating book drawing on real life experiences from the aviation, nuclear, health care and other high risk industries. The book is organized around the "Human-Tech Ladder" which describes a hierarchy of relationships that explains why things sometimes go wrong when humans and technology mix. The ladder looks at the following factors:

Physical - Size, shape, location weight, colour, material
Psychological - Information content/structure, cause/effect relations
Team - Authority, communications patterns, responsibilities
Organizational - Corporate culture, reward structures, staffing levels
Political - Policy agenda, budget allocations, laws, regulations

The book demonstrates that IT failure can rarely be attributed to a simple technology failure or by the failure of a single human being. The extraordinary complexity of the surrounding technological and human systems together with this hierarchy of human-technology relationships is often at the root cause of failure.

I highly recommend this book for anyone building, installing or operating eHealth systems.

Categorizing eHealth Benefits

There seems to be a consensus emerging in the literature about how one would categorize the benefits of eHealth. As we move further with the evaluation of eHealth initiatives, it is important to agree on definitions and categories, and to establish measures for each of these benefits. This will help us to compare projects and help health care managers to develop solid business cases for their eHealth projects.

The categories are:

Improved Productivity: increased efficiency, reduced duplication of tests and procedures, cost reduction/avoidance/containment, support to program reform and health system change management.

Improved Access: easier access to health services in remote or under serviced areas, reduction in wait-times for medical and surgical procedures, improved access to data for research.

Improved Quality: improved patient health outcomes, improved population health outcomes, reduction in preventable adverse events, patient empowerment, improved patient satisfaction, improved privacy and security, enhanced accountability.

We continue to have a challenge coming up with quantifiable measures for eHealth benefits that are comparable across a range of eHealth initiatives. This is a particular problem with the assertion that eHealth can help to improve patient and population health outcomes and improve patient safety. The literature is very sketchy on these subjects and even conflicted on the issue of patient safety. Defining benefits and their measures is an essential task to complete if we are to justify the investments being made in eHealth infrastructure and applications.

eHealth Business Modelling

In my experience one of the most serious risks to any eHealth initiative is the absence of a sustainable business model. While we all get excited about the potential for improving patient care and increasing the efficiency of health care delivery through eHealth, far too many initiatives fail to adequately define the business relationships between the many stakeholder groups, establish a mechanism for information governance or ensure long-term financial sustainability.

I found a really interesting toolkit called the eHI HIE Value and Sustainability Model and Tool Suite prepared by the eHealth Initiative as part of their Connecting Communities Toolkit that provides a lot of guidance on the business aspects of eHealth as it relates to Health Information Exchanges (HIE) and Regional Health Information Organizations (RHIO). The toolkit addresses market readiness, value assessment, risk assessment and provides a pro-forma business plan. This is an excellent site and resource. Check it out.

Commercial Services and Products 1

It is my intention to keep this blog commercial-free. However, some of our blog readers represent companies that are trying to make a meaningful difference in the health care space. Having been a health IT entrepreneur myself, I believe its important to give them a voice too.

So here's my plan. From Monday to Friday all eHealthRisk posts will be commercial-free. On weekends I will post news from companies that have contacted me during the week. You will recognize the posts because they will be titled "Commercial Services and Products #". Inclusion on the blog does NOT represent endorsement of the service or product, though I will review the information in every post to ensure that it is reasonable and not misleading to eHealthRisk readers. Please contact me if you find anything to the contrary.

iMedix

Our first commercial post comes from iMedix, a "community powered health search engine" according to co-founder Iri Amirav. It is a site that enables people with different health conditions to communicate and share experiences with others with the same condition. If for example you have diabetes or asthma, you can post your questions or experiences concerning the disease to a blog or discussion forum. Its essentially an Internet self-health group.

There's obviously a significant opportunity to empower patients with a site like this. There are also a number of risk issues including privacy and safety risks that service providers like iMedix need to address. iMedix is seeking comments and feedback from eHealthRisk readers on the Alpha version of its site.

In order to get into the alpha site you need a user ID and password that can be obtained by sending a blank email to ehealthrisk@imedix.com. They have set up accounts for 50 eHealthRisk readers.

Kroll Fraud Solutions

Our second commercial post this week comes from Kroll Fraud Solutions. Brian Lapidus, Senior Vice President of Kroll has published an FAQ on identity theft titled Identity Theft Protection for Healthcare Companies. This post has been picked up by several health IT blogs. It is a good primer for those who have an interest in identity theft.

Patient Safety and the USVA

One of my favorite sites for the management of patient safety issues is the US Veterans Administration. There are a lot of educational materials and tools that I believe can be adapted to addressing patient safety issues associated with eHealth. I especially like the Patient Safety Assessment Tool, an Excel spreadsheet questionnaire that addresses many of the controls that should be in place when dealing with patient safety and the Healthcare Failure Mode and Effect Analysis (HFMEA) which is a five step process to conduct a prospective patient safety risk analysis. The five steps in the HFMEA are:

• Step 1 - Define the Health Failure Mode and Effect Analysis Topic
• Step 2 - Assemble the Team
• Step 3 - Graphically Describe the Process
• Step 4 - Conduct a Hazard Analysis
• Step 5 - Actions and Outcome Measures
  

An excellent resource worth spending a little time on.

Compliance vs. Risk Management

One of the first realizations I had when I started researching risk management in eHealth is the need for a paradigm shift from what I call a "compliance mindset" to a "risk management mindset".

The compliance mindset says that if you following all of the prescribed laws and standards, everything will be OK. The risk management mindset says that you need to understand the world around you, you need to understand your eHealth program, and you need to understand all of the risks associated with implementing the eHealth program into your environment. The risk management mindset then insists that you do something about those risks.

eHealth has been caught up in the compliance mindset, particularly with respect to privacy and security. Unfortunately, our legislators and standards setters have only tackled part of the risk issue associated with eHealth. While we have privacy legislation in most jurisdictions, and while standards are emerging for eHealth security, we miss many eHealth risks.

The biggest gaps in my mind are around safety risks and the many project and business risks associated with eHealth.

I personally have never seen an eHealth project fail because of a privacy issue (though breaches have caused grief for eHealth managers and the unfortunate victims). I have however seen many eHealth initiatives fail because of project and business risks that were completely predictable, but invisible to those who operated in the compliance paradigm. Poor project management, business models that failed to address the needs of all stakeholders, poor understanding of the end-user environment, inadequate funding and poor procurement practices top my list of factors that have caused eHealth projects to fail.

The safety issue is the sleeper here. The only reason we haven't seen more safety issues is that we have only just begun to implement eHealth into the clinical environment. Early experience around CPOE suggests that implemented well CPOE can reduce medical errors. Implemented poorly, CPOE can kill. As eHealth rolls out I believe we will see more and more serious safety issues. As of yet there is no structured process for assessing safety risk in eHealth (although draft safety standards for health IT software are in development at ISO TC215/WG4). But even these standards will address only part of the safety issue.

Compliance with legislation and standards is a good thing. Legislators and standards setters are to be lauded for their efforts. But it isn't enough. If eHealth is to succeed we need to tackle the full range of risk issues associated with health IT and the human and business systems that surround it.

Journal of Medical Internet Research

The Journal of Medical Internet Research is an excellent resource on all matters associated with eHealth. Based out of the Centre for Global eHealth Innovation in Toronto, Canada, the journal is an international scientific peer-reviewed journal on all aspects of research, information and communication in the healthcare field using Internet and Intranet-related technologies.

I personally was struck by two articles relevant to my eHealth risk and opportunity research: Design and Evaluation in eHealth: Challenges and Implications for an Interdisciplinary Field and Improving Information Technology Adoption and Implementation Through the Identification of Appropriate Benefits: Creating IMPROVE-IT.

All journal articles can be accessed in in HTML format for free. A paid membership fee is required if you want to download PDF files of articles.

This is a page worth bookmarking.