The technology mismatch is striking. About 61% of Americans looked online for health information in 2009, but only 4% of American office-based physicians used fully functional EHRs in 2007 even though evidence exists that using EHRs improves care.
The CMS just released the first of about three rounds of meaningful uses. As these reimbursement requirements roll out over the coming years, the NHIN should eventually support about 100 meaningful uses. One is listing patient allergies and medications at the time and place of service. If I present unconscious at a California emergency room, the NHIN would allow attending physicians to reference my Pennsylvania information. Naive solution: Give patients smart cards containing relevant information, but smart cards alone cannot satisfy all uses (e.g. a lab sending timely results to the requesting provider). So, the NHIN should provide sufficient utility to support the full spectrum of meaningful uses.
Technical bliss also requires the NHIN keep patient information confidential. Privacy is essential to doctor-patient trust allowing patients to freely communicate intimate behaviors and details to physicians and physicians to freely store related facts and notes. A significant loss of privacy in the NHIN will render it useless and can cause serious personal harm as patients opt out and doctors find unforeseen ways to hide sensitive patient information. The ARRA specifies numerous requirements for patient privacy protection, yet the CMS list of meaningful uses for 2011 includes no privacy incentives.
EHRs and the NHIN enable quick and easy sharing of patient information widely and in bulk for many worthy purposes beyond direct patient care. As data-sharing increases, risk of personal harm tends to increase thereby intensifying the tension between limiting data sharing to direct patient care (more privacy) and sharing data widely (more utility).
The techno-policy infrastructure that enables data-sharing, the NHIN, controls this tension, and the NHIN design can itself introduce additional adverse consequences and worthy uses. There is a false belief one must be traded against the other—i.e., to reap benefits of the NHIN, Americans must give up privacy. Unfortunately, the current NHIN approach is worse, making it unlikely Americans will have privacy or utility.
The ARRA charges the ONC within HHS with promoting EHR adoption and NHIN development.
Tasks involve identifying meaningful uses, aligning economic incentives, establishing information exchange standards, and promoting privacy protection mechanisms. ONC's job rivals the Twelve Labors of Hercules, as I have witnessed many of ONC's heroic accomplishments from the vantage point of the privacy and security seat of the HIT Policy Committee, a federal advisory committee established by Congress to advise the ONC. I was appointed through a national search and am the only professional computer scientist.
With only months remaining before early adopters start using new and retooled EHRs to qualify for compensation in 2011, the time seems ripe to examine privacy and the NHIN and seek corrective action.
The current approach to NHIN design is “let a thousand flowers bloom.” Regional and state groups receive financial support from the ONC but are left alone to navigate the immature technical terrain and make isolated decisions. The lack of overall architectural coordination promises autonomous local NHINs that are not likely to interoperate and can expose patient information to different hazards.
The ONC's website describes the NHIN Limited Production Exchange as today's NHIN. Federal entities (e.g., the Social Security Administration, the Veteran's Administration and the Centers for Disease Control) lead the effort with participation from private parties (e.g., Kaiser Permanente).
Technical operations are: (1) patient lookup; (2) document query; (3) document retrieval; (4) audit log query; (5) authorized case follow-up; and, (6) event messaging. These functions allow participants to locate patient information, identify available documents, retrieve patient documents, etc. The last operation, event messaging, stores criteria and automatically forwards matching patient information when it appears. Overall, this is not a bad set of operations, but there are problems with the overall design. Here are a few.
Given explicit identifiers of a patient (e.g., name and Social Security number), patient lookup returns institution-specific identifiers for that patient using patient registries.
Each register is a master patient index containing patient name, telephone, gender, date of birth, Social Security number, the patient's unique identifier at each organization, and optionally, deceased information, marital status, religious affiliation, race, ethnicity and address. There are concerns with this approach. For example, insiders (anyone at any participating facility who can access patient information) can do malicious surveys to locate patients and patient records at other facilities. For example, a domestic violence stalker can use the system to locate victims.
In one version, event messaging allows third-party notification of patient information without the patient's knowledge. This function may help public health agencies receive reportable information, but as designed, enables unsupervised surveillance. For example, an insider could receive notifications of all abortions performed at other organizations.
Participating institutions maintain patient information portals. If deployed widely, these portals would be in environments (e.g. provider groups) having no professional staff to follow the latest computer security practices.
Security additions may help but don't seem forthcoming and other concerns would still remain because of the overall design of NHIN Exchange. These problems are not inevitable as other possible designs don't have them. It is therefore prudent for local communities to understand how different technical designs for the NHIN have an impact on patient privacy.
The ONC's website also describes NHIN Direct. Microsoft and Cerner Corp. representatives mentioned replacing fax with e-mail over secure channels to combat eavesdropping.
A crowd-sourced effort emerged. Unpaid volunteers jointly construct technology for fax-based scenarios (e.g., provider-provider and provider-lab). One concern with this approach is an inability to achieve all meaningful uses due to over-fitting fax scenarios.
For example, an emergency room doctor cannot reasonably retrieve allergies and medications for an unconscious out-of-state patient using e-mail. How does the emergency room doctor know which provider to e-mail? Will responses be timely? How does the recipient know the e-mail is legitimate? The NHIN requires more machinery, but is NHIN Direct a stepping-stone or a distraction? No roadmap shows how the effort eventually achieves all meaningful uses. Common problems to e-mail (e.g. spam, fraud, privacy) and free public labor (e.g. legal responsibility, software fusion) remain unaddressed. For these reasons, the utility of NHIN Direct is gravely uncertain.
It doesn't take a doctorate in computer science to know the prognosis for the NHIN is not good, and it doesn't require political sensitivity to know what public reaction will be.
With few months remaining and a desire that EHR adoption be successful and long-lasting, I propose an intervention. Develop a “flowerpot,” a single conceptual NHIN defined by trust invariants based on stakeholder barriers (e.g. patient privacy and provider liability). A local NHIN participates in the flowerpot only if a risk assessment proves its implementation satisfies constraints. Then, no matter the services or technical architecture deployed by local NHINs, the overall flowerpot of NHINs gives universal responsible guarantees to patients, providers and other stakeholders. So, “let a thousand flowers bloom” … in a single flowerpot!
Latanya Sweeney, Ph.D.
Distinguished Career Professor of Computer Science, Technology and PolicySchool of Computer Science Carnegie Mellon UniversityPittsburgh