Health institutions with large numbers of records must rely on probability to declare that a given record or set of records matches a set of identifiers (name, gender, date of birth, etc.). The risk of this strategy, of course, is that the matches so recorded may not be accurate. There is some risk of "false negatives"—records that pertain to a patient but are not found. There is a much greater risk, however, from "false positives"—matches with records that do not pertain to the subject patient, but are wrongly returned in a search.
False positive matches carry two forms of risk—privacy risk and clinical risk. The privacy risk is that records pertaining to patients not under the care of a particular clinician will be delivered, exposing personal details to those who have no need for them. The clinical risk is that a clinician will make a decision based on information that is erroneous because it is actually information about a different person, not the subject patient. Although clinicians are trained to make allowances for the fact that there is a significant error rate in clinical information when they make important decisions, the technology for handling such matches still needs to be optimized for a high degree of certainty, and where incorrect matching does occur, the system should err on the side of returning false negatives rather than false positives.
In addition to the technology, however, there also need to be policies spelling out how systems containing patient information should operate. This document outlines a set of policies for matching patient records with patient demographic details, so as to minimize incidental disclosures of personal health information within the nationwide electronic health information exchange. This document was developed by the Markle Connecting for Health Policy Subcommittee.
Part of the Markle Connecting for Health effort is to define and develop the “Common Framework”—the set of technical and policy specifications designed to help sub-network organizations (including regionally based networks and national networks, such as the VA) create data exchanges among their participating members, while creating interoperability between sub-network organizations (SNOs)1 (see P2: Model Privacy Policies and Procedures for Health Information Exchange).
The goal of the Common Framework is to define a minimal set of commonly adhered to standards and policies that allow for the SNO-based implementation of health information networks that are nationally interoperable. One component of this system is the Record Locator Service (RLS), which is a file of the location of patient records, queryable only by authorized participants. The RLS is the “White Pages” of any given sub-network, the coordinating entity that allows institutions within that sub-network to know whether other institutions hold records relevant to a particular patient. The RLS is designed to take a query from authorized users in the form of demographic details and return only the location of one or more matching records.
The RLS must implement a matching algorithm for queries using a sometimes incomplete subset of the possible constellation of demographic details. Authorized queriers present a set of demographic details and receive in return zero or more matching record locations. Probability weighted matching can improve the quality of record matching by taking the specific characteristics of records in particular databases into account.
Issue: the “false positive match” and the RLS
Attempt to match: John Q Public, 1043 W. Easy St., Phoenix, AZ 85535, 5556060, 10-24-1950, 482891822.
Which of the potential matches should be returned in response to this query?
Part of Initiate's Identity Hub Software. This example from their literature:
|101||John Q Public||"1043 W. Easy St, Phoenix, AZ.85535"||5556060||10-24-1950||482891822||20.0|
|102||Jon Public||"1043 W. Easy St, Phoenix, AZ.85535"||5556060||10-24-1950||482891822||18.0|
|104||John Q Long||"552 Green Dr, Phoenix, AZ.85535"||11-15-1962||57265225||5.0|
|106||Kevin Dohert||"1028 W. Easy Ave, Phoenix, AZ .85535"||5554289||48224857||4.0|
Note: The example score on a scale of 1 to 20 is an arbitrary placeholder for different levels of matching for purposes of discussion, but does not represent an absolute scale of probability.
Pursuant to HIPAA privacy regulations, a covered entity is permitted to use or disclose protected health information for treatment, payment, or health care operations.2 An entity is also permitted to use or disclose protected health information incident to an otherwise permitted use or disclosure, provided that it has complied with applicable requirements of the minimum necessary standard and required security safeguards.3
In proposing the addition of the incidental disclosure provision to the Privacy Rule in its 2002 guidance, the United States Department of Health & Human Services (HHS) described an incidental use or disclosure as a secondary use or disclosure that cannot reasonably be prevented, is limited in nature, and that occurs as a by-product of an otherwise permitted use or disclosure. As described in the preamble to the Privacy Rule, an incidental use or disclosure is permissible only to the extent that the covered entity has applied reasonable safeguards and implemented the minimum necessary standard. In addition, covered entities are not required to document permitted incidental disclosures in an accounting of disclosures.4
HIPAA’s minimum necessary standard requires covered entities to limit how much protected health information is used, disclosed, and requested for certain purposes. These minimum necessary policies and procedures also reasonably must limit who within the entity has access to protected health information, and under what conditions, based on job responsibilities and the nature of the business. The minimum necessary standard does not apply to disclosures, including oral disclosures, among health care providers for treatment purposes.5
HIPAA security standards require that a covered entity must have in place appropriate administrative, technical, and physical safeguards that protect against uses and disclosures not permitted by the Privacy Rule and that limit incidental uses and disclosures.6 It is not expected that a covered entity’s safeguards guarantee the privacy of protected health information from any and all potential risks.
An incidental use or disclosure that occurs as a result of a failure to apply reasonable safeguards or the minimum necessary standard, where required, is a violation of the Privacy Rule. Failure to comply with HIPAA regulations can result in general fines of up to $25,000 per incident.7
The Markle Connecting for Health Policy Subcommittee assumes that the RLS false positive match is an incidental disclosure pursuant to HIPAA, with the understanding that such a disclosure is permissible under the law only to the extent that the covered entity or entities involved have applied reasonable safeguards and implemented the minimum necessary standard. The parameters recommended in this document for such matches are believed to require such safeguards.
NB: It has been noted that, as a legal matter, it is unclear whether “false positive match” disclosures are “incidental” according to HIPAA. There may be a legal argument that they can be considered permissible treatment disclosures. In either case, the disclosure would be permissible under HIPAA, so the result would be the same. At the time of this writing, there has been no authoritative guidance on the issue from HHS, although it is possible that an FAQ on the topic could be sought in the future.
The Markle Connecting for Health Policy Subcommittee assumes that the covered entities who could be involved in a request for information from the RLS, including the requester of information, the RLS (which could be defined as a “business associate” pursuant to HIPAA8), and the entity holding information pointed to by the index are in compliance with HIPAA’s minimum necessary standard and required security safeguards. Indeed, if the entities are not in compliance with HIPAA’s requirements and disclosures of protected health information occur, they are in violation of federal law and subject to the penalties described above.9
Beyond the strictures of HIPAA, the false positive match scenario may still produce incidental disclosures, albeit “permissible ones” according to the law. For example, in the sample data presented above, it is possible that J Public is not the person for whom information was requested. If J Public had, perhaps, visited a psychiatric hospital and that information was both recorded in the index, even without any additional clinical information, and returned to the requester, J Public might feel that his privacy had been violated, despite the entities’ compliance with the letter of the law.
Therefore, the Markle Connecting for Health Policy Subcommittee recommends the setting of a minimum level of certainty before the RLS returns information to the requester; and that whenever that level of certainty is not reached, the RLS could request additional demographic fields until either the level of certainty is reached or no record can be returned. This recommendation is based on ethical and public policy reasons, as opposed to the merely legal requirements of the HIPAA “reasonable safeguards” standard. It is also based on the need to reduce errors in record linkage.
For example, if a requester submits information in five demographic fields for a patient to the RLS, but the RLS does not find a match with a certain level of certainty on any one record, the RLS will report back that there is no match.
In the case that the RLS can return no matches with the specified certainty level, the RLS could require additional demographic data in order to determine a match. For example, at this point, the requester could be asked to supply data for additional demographic fields.
These levels could be set in order to minimize to the extent possible incidental disclosures of protected health information in an effort to respect the privacy of patients for ethical and public policy reasons.
Issues considered in formulating these recommendations include:
The Markle Connecting for Health Policy Subcommittee assumes that the covered entities who could be involved in a request for information from the RLS are in compliance with HIPAA’s minimum necessary standard and required security safeguards. The incidental disclosures in this scenario would be permissible according to the law.
However, as discussed above, the false positive match scenario may still produce incidental disclosures, even if the RLS requires a high level of certainty in order to return information from the index. Given the above recommendations of this Subcommittee, if a match meets the criteria for a positive match, they are permissible disclosures and cannot possibly be prevented without making the threshold for a positive match so high that it would create an unacceptable level of false negative matches.
The Markle Connecting for Health Policy Subcommittee adopts the following position: In the case in which a requester of information recognizes that information received from the RLS does not apply to the patient about whom information was requested, the requester should take reasonable steps to immediately destroy that information, including, where applicable, deleting the electronic version of that portion of the RLS response and/or any paper copies thereof.
Yes. If the false positive match scenario is not approached as a Common Framework issue, it is possible that various SNOs could set different standards for certainty and different numbers of required fields of demographic data in order for the RLS involved to return information to the requester.
This variability in what information will be returned from an RLS raises reliability of information questions: How will I, as a provider, be able to rely upon the information returned from the RLS in Idaho as well as the information from the RLS in Maine? Moreover, it is also unclear how sub-network RLS systems could grow and become increasingly interoperable when different threshold standards for information return are set across the systems.
For these reasons, the Markle Connecting for Health Policy Subcommittee adopts the position that the false positive match/incidental disclosure scenario and the recommendations arrived at by this Policy Subcommittee should be considered part of the Common Framework, to allow for increased reliability and scalability of a nationwide electronic health information exchange.
Markle Connecting for Health thanks William Braithwaite, Senior Vice President and Chief Medical Officer, eHealth Initiative, and Clay Shirky, Adjunct Professor, New York University Graduate Interactive Telecommunications Program, for drafting this paper.
©2006-2012, Markle Foundation
These works were originally published as part of the Markle Connecting for Health Common Framework: Resources for Implementing Private and Secure Health Information Exchange. They are made available free of charge, but subject to the terms of a License. You may make copies of these works; however, by copying or exercising any other rights to the works, you accept and agree to be bound by the terms of the License. All copies of these works must reproduce this copyright information and notice.