Privacy & Security Tiger Team on Patient Matching

Here's the results of yesterday's public hearing on patient matching as summarized for the Tiger team meeting this morning.

Privacy and Security Tiger Team - Patient Matching - 2010-12-10

Patient Linking

This morning I'm testifying at an ONC Privacy and Security Tiger Team hearing on Patient Linking. As Health Information Exchange expands, patient matching becomes ever more important.

U.S. Department of Health and Human Services

Office of the National Coordinator for Health Information Technology

HIT Policy Committee

Privacy & Security Tiger Team

 

Patient Linking Hearing

Thursday, December 9, 2010

Allscripts

Written Public Testimony

Richard Elmore

Vice President, Strategic Initiatives

Introduction

To Deven, Paul and the Privacy & Security Tiger Team members – thank you for the opportunity to participate in in this vitally important hearing. 

Allscripts provides electronic health records and revenue cycle management systems – both inpatient and ambulatory - as well as analytics, ePrescribing, financial and clinical transaction services, clinical trials, care management, ED and home health software and services to over 180,000 physicians, 1,500 hospitals, and many thousands of post-acute care organizations across the country.  In working to best serve our clients and help advance our collective goal of improving health for the nation’s citizens, Allscripts promotes a vision of a connected community of health built on this foundation.  As you can imagine, with a client base this size, we do a lot of matching of individuals across heterogeneous platforms.  Identity management and matching are critical to Allscripts. 

A Clarification on Matching / Linking

The published purpose of this hearing is “to learn about experiences in linking or matching patients to their information”.  In the technical community, there has been a debate when a patient match is established regarding the relative merits of dynamically linking the patient information versus the merging of the patient information.  As a result, in this testimony, the word “matching” has been used to establish when information from two systems are determined to refer to the same person.  The word “linking” is used to refer to links to information for the same person. 

Summary

In preparation for this hearing, we surveyed eleven larger provider organizations (with patient populations as large as 4 million) as well as a similar number of internal and external experts on the topic of patient matching. 

The most important requirement identified by Allscripts clients when it comes to matching is high quality patient demographic information.  Data governance and management, user workflows, provider verification and a clean patient registry are vitally important to patient matching. 

From a technology perspective, electronic health records, master patient indices, and patient identification exchange standards are critical components to ensuring and improving the high accuracy levels reported by our clients.  Based on our survey, electronic health records are serving as a positive safety and privacy mechanism.

General Topics for All Panels

1.   Standards for identifying individuals

Individual identification standards are established by the provider.  Typically these include “out of band” verification of identification through cards such as driver’s licenses and health insurance certificates.  Minimal basic demographics include full name, date of birth, sex, address, zip and preferably the last 4 digits of the social security number.  For pediatrics and other special workflows, additional demographics are required.  Some states and organizations, however, do not collect social security numbers. 

One note is that discipline and completeness of demographics tends to be better in organizations that see patients on a recurring basis, and better in revenue cycle departments than in clinical departments.  With the exception of certain urgent care workflows, identity usually flows from the revenue cycle demographics data capture process to the clinical departments.  

2.   Ensuring accuracy in matching a patient with his/her data

There are no perfectly accurate matching approaches, and there is no one-size-fits-all approach to patient matching.  The best approach for a given healthcare organization depends on a number of factors related to the population characteristics, the way the information is used and managed, data quality and algorithms employed by various systems involved in information exchange, among other factors.

Patient information is matched in two basic ways:

·         Statistical patient matching based on demographic factors, with more advanced systems including rules, demographic weightings and probabilistic algorithms with configurable attributes.

·         Unique invariant non-disclosing patient identifiers

These linkages can be established at any number of points in the workflow, but there are two basic methods: 

·         Dynamic linking, which is real-time linking based on demographics with records kept separate, or

·         Static merge, which means a link is established, with the data potentially combined and maintained at that point in time

There are two types of errors associated with patient matching:

• A false positive – which incorrectly links or merges clinical information to the wrong patient.
• A false negative – which fails to match information to a patient and may result in an additional record for the same patient, with each record missing some information.

Most legacy systems in use in the U.S. today use deterministic matching (the most basic statistical matching looking for exact matches over 4 or 5 demographic variables).  This may have been a workable solution for smaller patient populations that resided in a society where demographic factors like name and address were more stable, and where the collection of unique identifiers like social security number was better tolerated.  All of that has rapidly changed, however, and many of the legacy systems haven’t kept up with the need for advances in patient identity.

As the distance between the settings of care gets smaller, and as there is more interconnectedness, the opportunity for error rises rapidly.  In an interconnected world, the borders get fuzzier.  Patient matching was important in the 90’s as hospitals consolidated and now, with ACO’s, Community Health Teams and other payment reform initiatives rapidly gaining momentum, the pace of consolidation is quickening even more, with the importance of accurate linking growing exponentially alongside. 

Patient matching technologies are employed in a variety of systems.  Reviewing recent strategic decisions by Allscripts clients, we can generalize how these matching approaches are being applied today including:

·         Patient identity management systems (community patient registries and EMPI’s) with robust probabilistic matching are found in health information exchange settings – both public and private.  Health information exchange can rely on dynamic linking of patient records, thus ensuring as demographics are updated, patient record matches resolve to the most currently appropriate individual (recognizing that in some cases, demographic changes can also degrade the accuracy of a match, as in legal name or address changes).

·         Strong statistical matching and fuzzy logic algorithms can be applied to traditional operational interfaces and bulk uploads.   

·         Unique patient identifiers are applied for system-to-system patient matching, in the limited cases where there is strong organizational control of the patient identifier to ensure it is unique, invariant and non-disclosing.

·         Patient communication solutions start with a unique invariant patient identity established in the EHR and result in an email invitation being sent to the patient to participate in a portal / EHR.  The patient email address is established outside of the system in communication between the provider and the patient. 

·         Providers with low tolerance for matching errors have implemented unique, invariant, non-disclosing patient biometric identification techniques like palm vein scanning.

·         Patient identification for devices is typically driven from the EHR to the device using web services. 

3.   Problems with patient-matching, internally and/or for information exchange.  Source of those problems.

Issues that have adversely affected patient matching performance include:

• Source data quality, completeness and consistency – these are by far and away the most often reported sources of patient matching problems. 
• Local population characteristics and social factors that impede good quality data including common names, sharing of identity information (or in the case of drug abuse – the use of multiple identities), and other factors
• State level differences such as opt-in or opt-out consent requirements for health information exchange and varying policies regarding exclusions of sensitive health information (e.g., Psych, HIV, etc.).
• Accuracy of the management of demographics information in source systems
• Acute care environments with numerous ancillary systems and medical devices (key problem is that there are multiple points of demographic data entry with varying degrees of accuracy)
• Pediatric workflows
• Multi-organization sharing where many organizations are sending patient information into a single repository.
• Changes in marital status (with name change)
• Dirty MPI’s resulting historically from less sensitivity to patient identity accuracy

As an example, Steven Anderman, Bronx Lebanon Hospital’s COO has led major advances in care coordination and technology at Bronx Lebanon, as well as health information exchange through the Bronx RHIO. Many of the “externalities” listed above are applicable at Bronx Lebanon and these adversely impact patient registry quality.   Bronx Lebanon Hospital’s patient population is two thirds Medicaid and is subject to frequent moves, often provide bad addresses and phone numbers, and creates a tremendous burden in terms of collecting good demographics.  And patient identity sharing is common.  The process repeats itself at each health care organization in the community.  This places an undue burden on the provider to be the regulator of patient identity.   

3a) Handling patient matching problems (wrong/ambiguous match)

Providers use a variety of tools and processes for handling patient matching problems, including:

• Workflow and reporting solutions to evaluate possible duplicated patients.
• Follow-up user workflow solutions to analyze, identify and resolve potential duplicates. 
• Corrections in source systems.
• Improvements to the rules / weightings based on specific usage, data quality and population characteristics.
• Upstream workflow process improvement to accurately capture demographic information the first time.
• False negatives can be resolved through dynamic linking solutions or merge capabilities.
• Logic to detect common mistakes and alert users of possible match or mismatch.
• When no match is found, user workflows and tools for research and resolution are typically applied.
• Also, "cleansing" techniques can be applied such as removal (from database and/or from searches) of obsolete records (e.g., deceased patients)

Who’s doing this well today? 

One example is North Shore Long Island Jewish.   They identify the potential duplicates centrally and then are able to communicate with various Medical Records Departments electronically to obtain the information necessary to resolve them.  They can also assign the resolution to the respective Medical Records departments.  Currently they have at least 8 systems feeding the Allscripts EMPI and are adding additional participants at a steady pace.

3b) Consequences of a Wrong Match – to Patient Safety, Privacy

We can find a powerful real world example of the dangers of wrong matches in a recent case where a patient had an EKG at her local clinic.  While she was at the clinic, they misplaced her EKG and mistakenly evaluated her based on another person’s EKG.  The wrong EKG, with her name hand-written on top, incorrectly indicated that she was on the verge of a heart attack.  The ensuing clinical response ultimately resulted in coma and then her death.  In this simple case, where the patient match involved data only intended to move from the device to the physical patient in the same clinical setting, during the same encounter, without an EHR and without any health information exchange technology, had deadly consequences. 

This story is very revealing for those of us who are engaged in the policy conversation.  In fact, it’s a bit of a Rorschach test.  As you tell this story, there is a tendency for listeners to jump to their pre-conceived notions of what’s important about patient matching depending on their role in the healthcare ecosystem.    

Providers recognize the risks to safety and privacy, but up until now, among those polled, error rates have been generally extremely low.  Providers also recognize that as they engage with more outside entities, the risk of patient matching errors rises.

Providers are very aware of the potential for patient safety issues in the event of a wrong match.  Typical of the issues include the need to review/change medications, inform pharmacies, manage rework of the records, and communicate with providers, consulting providers and patients. 

The providers did identify privacy concerns, as well, in the event of a wrong patient match.  This includes the risk of privacy exposures when the wrong information is entered into a patient’s chart and the potential need to explain this to a patient. 

There are privacy considerations, as well, in connection with larger data bases, unique patient identifiers (not including VUHID – more on this below) and potentially non-essential information being shared in connection with patient matching.

4.   Level of Accuracy for Patient Matching

The fact of the matter is that the industry doesn’t have consistent measurement and performance standards for patient matching accuracy.  The Allscripts providers interviewed on this topic generally reported overall accuracy rates of 99.9+% or 100% after human review and ~97+% on automated match. However, they acknowledge the presence of some errors, and this more consistently aligns with the findings of the RAND study, in which statistical matching generated a false-negative error rate of approximately 8%, meaning that there can be data gaps needed for identification around 8% of the time.

A false positive that results in incorrectly merged patient information is more likely to be a hidden error and therefore more serious for patient safety.  To strictly limit false positives, standards for matching are high.  So generally, in our client base, a false negative is more likely to occur than a false positive. 

Allscripts’ goal is to avoid any false positives, to minimize false negatives, to ensure upfront accuracy and to provide resiliency by putting the tools in place to cost-effectively and timely handle issue resolution and merges. 

Matching accuracy is favorably affected by the presence of more unique demographic attributes. The Rand study found that in a database of 80 million unique patients, false positives could be avoided with a composite key consisting of name, DOB, zip code and the last 4 digits of the social security number.  Conversely, Rand found that removing the unique 4 digits from the SSN reduced accuracy from 1 in 39 million, to 1 in 8.  Allscripts in general provides more demographic fields, options and rules than this to ensure false positives are avoided.  Unique demographic factors are vitally important to patient matching accuracy.   

Note that this also points out that when social security number is shared among patients, or otherwise mis-used, the risk substantially increases of mixed records.

5.   Lessons Learned

Demographic data quality:  Secure technology exists for accurate matching – the key is the data behind the match.  Source data quality, completeness and consistency are by far and away the most often reported sources of patient matching problems.    

Process: Workflows, processes, training and best practices including the individual provider as a last stop-gap are vitally important to accurate source data used for patient matching.

As an example, Scott Whyte at Catholic Healthcare West is very aware of the need to be on top of processes to ensure data quality.  In addition to deploying the technology, Catholic Healthcare West has placed a major emphasis on people, policies, executive sponsorship and monitoring.

Dynamic linking:  Changes in demographics can resolve in different matching.  This can improve accuracy when the changes are corrections in the underlying data and can diminish accuracy when the changes are, for example, changes in name or address.  Holding individual records separately and dynamically linking – effectuated by the HIE strategies of record locator and linking to records offers greater transparency than merging of records. 

Regional differences:  Population and regional differences result in disparate problems.  For example, a community with a large uninsured population, a large immigrant population, or a large transient (e.g., university) population all have slightly different weightings based on their population characteristics. 

Persons:  Guarantors & Subscribers are typically difficult to match with traditional statistical / deterministic techniques.  While the Tiger Team hearing is focusing on the patient, Allscripts would recommend that you consider any individual person matching, whether they’re a patient or fill a financial role in connection with the patient.  

Demographic data management: Data quality management is challenging in enterprises and even more so in collaborating, decentralized organizations.  Data ownership is ambiguous when multiple organizations are seeing the same patient.  The reputation and quality of participating organizations enters into providers’ willingness to accept another’s information.  Best practice involves ensuring that there is zero tolerance for errors at the source, due to the extremely high cost of rework and low level of capability for undoing propagated changes.  The very credibility of the HIEs (or any EMPI service for that matter) rests in large part on ensuring a high quality error free patient registry.   

Priorities for Health Information Exchange using IHE Profiles:  Allscripts is very supportive of the identity-related IHE profiles for Health Information Exchange.  Like MU, where there is a logical progression for the industry, the following progression should be considered:

• PIX for HL7 v2 typical use case involves an HIT system with a registration system communicating with the HIE.  It is a well-established mature profile.  PIX V3, using Web Services, is widely used internationally and is gaining market share in the US.
• PDQ (demographic query) typical use case involves using patient demographic information to communicate with the registry to establish the patient’s identifier.  It is less well established than PIX. 
• Pediatric Profiles typical use case involves a hospital maternity or pediatric department already using PIX communicating with the HIE.  These profiles are undergoing trial implementations. 
• Cross Community Patient Discovery (XCPD) typical use case involves support for snow birds, patient moves, multiple homes, etc., where the provider needs to establish a new patient’s global identifier across the network of HIE’s.   Through gateways, using XDPD, in combination with IHE’s Cross Community Access Gateway (XCA) – a request can be sent out across HIE’s to determine a patient’s id in other exchange networks.  XCPD is promising technology for these “edge cases”, which should be prioritized once core HIE functions are well established.
• With all patient matching, as with any exchange of PHI, there is the need for secure transmissions as well as auditing.    

Support for the small provider:  Patient registries for health information exchange will of necessity be dealing with multiple and various clinical and administrative systems, large and small, that all must be able to participate.  70% of healthcare is provided in small practices, and these providers must have access to the same levels of capability, performance and supporting tools for patient matching as those available to an enterprise. 

Innovation isn’t necessarily government work:  Much of the innovation around patient matching (including EMPI’s and surround workflows and tools) has its roots in advanced healthcare organizations.

For example, Bill Spooner’s IT team at Sharp Healthcare supports seven hospitals and 2,500 physicians.  A small team of five handles patient matching and duplicates, running a tight ship, where any mismatch is a critical error.  In 2009, on a base of four million patients, they identified and managed 260 manual registration errors.  In the same timeframe, 2,740 duplicates were generated off of enrollment tapes.  As more of healthcare becomes risk bearing, there is clearly a lesson to be learned around Sharp’s experience with enrollment. 

The bottom line is, ONC should look to these experienced healthcare organizations for continuing innovation.  As the rest of this testimony suggests, it isn’t about the match as much as it is about the quality, consistency, resilience and recovery capabilities around the match.  ONC should consider how to provide the platform for innovation and allow the market to develop.      

6.   Cost  Implications of Various Solutions

In all cases cited, the high performance solutions will be cost-effective compared to current operational costs managing errors and rework. 

7.   Recommendations for ONC to address patient matching problems in information exchange

ONC recommendations in support of Meaningful Use Stage 2 & 3 should be made as early as possible to ensure that vendors and providers have time to develop and implement the recommendations.  In the context of patient matching, in support of public and private health exchanges, the extended rules should include, in our opinion:

• Robust probabilistic patient matching capabilities

• “Possible duplicate” identification

• Merge (or link) functionality to correct the MPI and through HL7 ADT-type transactions to communicate the corrections to participating organizations.

• Progressive adoption over several stages of the IHE profiles (in sequence: PIX, PDQ, Pediatric, XCA/XCPD). 

ONC should provide support to the innovators in complex environments that are piloting the new generation of patient registries. 

These are emerging at places like Hartford Healthcare System where Steve O’Neill’s IT team is in pilot with four acute care facilities, several federal qualified health centers, and independent Connecticut physician organizations.  The strategy calls for leveraging the patient registry and health information exchange infrastructure to create a patient throughput platform, providing a variety of services across heterogeneous provider platforms. 

ONC may also want to give due consideration to two excellent published works on this topic: Connecting for Health’s 2005 Linking Health Care Information: Proposed Methods for Improving Care and Protecting Privacy and the HIMSS 2009 Patient Identity Integrity (PII) work group recommendations which included developing demographic data standards, medical device standards for identification and HIT workflow support for analysis and correction of duplicates. 

Universal Patient Identifiers

As we all know, the subject of unique identifiers is one that engenders a strong response from different constituencies, and there is even a law prohibiting simple discussion of a national patient identifier.  However, it is our sense that such limits were applied at a time when health information technology and the ability to securely exchange health information was in a very different place, and it’s time to revisit the conversation

The industry should not give up on further exploration of a unique voluntary patient identifier inasmuch as it has the potential to reduce false positives and false negatives and thus improve safety for those patients who opt in to it.  It’s not, however, the “silver bullet.” With any voluntary approach, like the ASTM-based Voluntary Universal Healthcare Identifier (VUHID) that is being discussed in many circles, there will always be a need for patient matching technologies.  VUHID needs mass adoption seeded by a national catalyst, and well-researched best practices/policy guidance to support its implementation and use. 

Should Congress elect to remove its restrictions on the conversation about patient identifiers, a private / public partnership using organizational techniques similar to the Direct Project could be a productive means of encouraging innovation and practical approaches to the implementation.

Specific Topics for Panel 2

1.   Solutions: 

ONC can and should play a leadership role to:

• Ensure high quality patient demographic information at the source using workflow, training, strong attention to process and EHR/MPI technology. 

• Standardize on data definitions and performance standards for algorithms for patient matching.

• Encourage methods for resilience and recovery to perfect the information system.

• Encourage innovation with biometrics to get five 9s plus accuracy – with opt-in / opt-out to protect the providers and provide privacy options (at various levels of safety) to the patients.  Multi-factor look-up could include biometrics, photos, etc.

• Standardize on health information exchange, using stages/roadmap to foster adoption of Integrating the Healthcare Enterprise (IHE) PIX, PDQ, Pediatric Profiles, XCPD/XCA.

• Encourage patient demographic self-verification methods.

• Establish best practices for governance of data quality in a distributed environment.

• Support implementation of the HIMSS PII workgroup recommendations for standards, interfaces, algorithms for matching, business processes, data accuracy, data quality, training and medical devices.

• Standardize device communication for patient identification.

In addition to these solutions, ONC should seek to ensure similar levels of support for small providers and support innovation that is emerging in private as well as public exchanges.

2 and 3: Status of solutions and gaps for healthcare:

While basic matching technology is well established, there are significant gaps in the solutions outlined above.  These include:

·         Standards for source data quality, completeness and consistency are lacking and vitally important as the healthcare system becomes more connected.

• High performance technology for patient matching exists today.  Allscripts is deploying this technology to providers and health information exchanges nationally.

• Methods for resilience and recovery are inconsistently applied and inconsistently available.   

• Biometrics are well established (and in fact required in Ohio).  Biometrics are not however part of the usual standards for health information exchange. 

• IHE profiles for PIX are well established.  PDQ, Pediatric profiles and XCA/XCDP are emerging.

• Patient demographic self-verification has been implemented in several patient portal solutions.

• Best practices for governance around data quality in a distributed environment are not well established.

• HIMSS PII workgroup recommendations are generally yet to be delivered, with the exception of the strong work on EHR deployment. 

• Device standardization for patient identification is a significant gap. 

In summary, not all Health IT vendors deploy these technologies today.  Standards and best practices aren’t in place.  An improved understanding of best performing algorithms for patient matching is needed.  And of course, ONC should foster the platform for experimentation, innovation and performance improvement around patient identification.

Conclusion

In conclusion, Allscripts believes that accurate patient identification is fundamental to health care quality, efficiency, and safety, especially as EHRs and HIEs become more embedded in the healthcare system. Adoption of appropriate standards, identifiers, technology, and processes must be put in place to minimize the costs and consequences of false positives, false negatives and an ongoing remediation of problems.

Thank You

To the Privacy and Security Tiger Team members – thank you for the terrific progress that you’ve made to date, your ever mindful work to gain and keep the public’s trust, and your continued leadership on key issues in connection with privacy and security in healthcare.  It will take your leadership to make the imperfect “near perfect” for patient matching.  Resilience and recovery will be the key in lieu of a “perfect solution”.

IHE Privacy and Security Primer

By John Moehrke, Healthcare Security / Privacy

Most of the IHE profiles in the security space are all simply pointers to common IT security protocols. The message is that healthcare is not special when it comes to security. That healthcare should just leverage the good work common to all IT. The following is NOT a complete explanation. I assume the reader can use a internet search engine to find resources including the specification themselves using key terms I provide. Clearly official profile text and standard text is the best resource.

ATNA - This is a comprehensive profile that indicates that Access Control, Audit Control, and Network Controls are important

• Access Control
  • There is no standards pointed to by ATNA here. There is simply a statement that a system needs to have access controls that can be shown to a local authority are sufficient to protect the systems resources according to the local policies
  • If this can't be demonstrated, then the system should not be authorized to be used. Specifically it should not be given a network identity (see network controls)
• Audit Controls
  • Specifically Security Audit logging
  • This is a very thin profiling of the commonly used SYSLOG protocols for communicating that an auditable event has occurred
  • There is statements that relax size limits
  • This is a FULL PROFILE of the content of that auditable event into an XML encoded message
  • There is a set of 'auditable events'. That is events that when they happen an audit log should capture what happens
  • The audit log message is fully describing: Who, What, Where, When, How, and Why.
  • This requires that the audit event time be kept consistent. Which is why the CT profile exists. The CT profile says use common NTP protocol to keep clocks synchronized to about 1 second, which is generally good enough for security audit logs
  • See Accountability using ATNA Audit Controls And ATNA and Accounting of Disclosures

• Network Controls
  • There are a set of standards specific to the type of network communications. They all address three aspects of network communications of protected information. Not all network communications are protected, for example DNS is not generally needing to be protected as it is not communicating protected information (mostly)
  • Authentication of both sides of all communications that include protected information
  • This is consistently done using machine/service-end-point identities using public/private keys (certificates)
  • Certificates can be directly trusted. One-by-one
  • Certificates can be trusted because they 'chain' to a known authority (certificate) that is trusted directly
  • Caution: the method used on the internet with SSL certificates is technically the same, but not administratively the same. In the internet browser world the 'known authorities that are trusted' are authorities that your internet browser decides should be trusted.
  • ATNA wants a deliberate decision of trust to be done, not a decision by a vendor.
  • Encryption of the communications that include protected information
  • AES is the protocol of choice. This choice does NOT mean that other protocols can't be used. It only means that at least AES needs to be present. This is to assure interoperability. This is NOT to constrain algorithms
  • Integrity control of the communications that include protected information
  • SHA1 is the protocol of choice. This choice does NOT mean that other protocols can't be used. It only means that at least SHA1 needs to be present. This is to assure interoperability. This is NOT to constrain algorithms
  • Note also that the communications is transitory, not long-term-storage, so the use of SHA1 is acceptable. SHA1 tends to not be acceptable for long term signature (See DSG below)
  • TLS is the general mechanism when no other mechanism is used. TLS is the 'standardized' protocol that is more commonly called SSL. (mostly)
  • IHE profiles that BOTH sides of the communication need to be authenticated
  • Whereas common SSL only authenticates the server. This is not sufficient as it allows any client to connect. In healthcare we want to know where the data is coming from and where it is going. Not just the server
  • S/MIME is used for e-Mail
  • WS-Security mechanisms are allowed for Web-Services that want to use end-to-end security. Note that none of the IHE profiles leverage this as they are all profiles defining endpoints that need access. But this is specified because there may be deployments where someone puts in the middle of an IHE transaction some form of intermediary that needs partial access
  See Designing a Secure HIE

PWP - This is a very thin profile that simply says that for user directory, use LDAP

• LDAP is a protocol for doing queries of a directory. That directory might be a database or may be specifically a directory
• The schema for describing a user is based 99% on the common user
• The little addition to the schema is really not that important
• This profile also describes how to find the directory. Using a special DNS record that points at the LDAP directory
• There are pointers to how LDAP can be secured using TLS.
• There are pointers to how LDAP can be used to authenticate a user, through the LDAP security mechanisms
• LDAP is the standard that Windows ActiveDirectory uses for accessing directory entries
• Healthcare Provider Directories (HPD) is a profile leveraging LDAP as well for external use
  • See Healthcare Provider Directories. And Healthcare Provider Directories -- Lets be Careful

EUA - Very thin profile that simply says to use Kerberos protocol for safely authenticating users

• Kerberos is a pluggable protocol, but really is only used for username/password
• Kerberos is the standard that Windows ActiveDirectory uses for authenticating users.
• Kerberos is the standard that Windows uses at windows login (with minor Microsoft extensions)
• Kerberos is very common in Unix as it was invented at Berkely
• Kerberos is really good for within an organization, but has real problems that prevent it from being useful on the internet
• There are also Kerberos ways to pass authentication 'tickets' between an application and server
• See: Kerberos required in 2011 then forbidden in 2013

XUA - Very thin profile that simply says to use SAML Identity Assertions for authenticating users on Cross-Enterprise transactions

• This is the solution for the space where Kerberos doesn't work well
• SAML is both a standard for an XML way to describe a user and provide trust mechanisms of that data; and also a protocol
• The protocol is not part of the XUA profile. It is ok, but not as important as the assertion
• There are other protocols that are more common, WS-Trust is one.
• There is also good reason for a product that does its own user authentication to simply create SAML assertions w/o protocol
• See - Federated ID is not a universal IDand IHE ITI XUA++ - Trial Implementation

DSG - A profile of XML-Digital Signatures to provide long-term signature across a 'document'

• Can sign any document type. Not limited to XML type documents such as CDA
• Signature document is created that is an XML-Digital Signature blob
  • Original document to be signed is signed by 'reference'.
  • Encapsulation is not a bad thing, but it does make the original document harder to get at. Especially if that original document is not XML based
  • Signature by reference allows the original document to continue to be accessed normally by applications that don't need to validate he signature. While having the signature present for those applications that do need it.
  • The digital signature includes the Date/Time of the signature. Assuming trustable date/time
  • The digital signature includes the certificate of the signer
  • Note that signatures need to be valid for decades. Which brings up interesting certificate management issues not addressed.
  • The digital signature includes the reason for the signature. Why was it signed? What does the signature mean?

• XDS Metadata shows that the signature document is in a 'signs' relationship to the original document
  • This allows for finding the signature from a document, and finding the document from the signature
• Works for XDS, XDM, XDR, XCA
  • Might work for other environments as well. The main thing that must happen is for there to be a way to dereference the document ID number found in the digital signature document to get to the document that is being signed.
• Might be future work to have an encapsulated flavor
• See: Signing CDA Documents

BPPC - A profile of a document that represents a patient agreeing to a privacy policy (e.g. Consent)

• Uses CDA to capture that the patient has agreed to a policy by reference
  • The policy is not actually ever defined. This is because there is not sufficient maturity to any standard for encoding of privacy policies. Therefore BPPC assumes that someone can write the policy in human readable language and give that a unique identifier (OID). This OID is used as a reference.
• Supports the consent being digitally signed with DSG
• Supports encapsulation of a scanned image of something (e.g. an ink on paper signature) using the XDS-SD profile
• Supports time limited consents
• Supports both positive policies (OPT-IN) and negative (e.g. OPT-OUT)
• Recognizes that the absence of an instance of a policy means that some other policy is in place. Commonly called 'implied consent'.
• Defined for XDS, XDM, XDR, XCA - and may work for other environments
• See Stepping stones for Privacy Consent

ENC - new profile being worked on this year - Encryption of documents and/or XDM

• Because this is under development the details are yet to be written
• Document encryption has favor as it would be transport agnostic, but is unclear the usefulness of this for long-term-storage usecases like XDS and XCA.
• XDM encryption would likely leverage the e-Mail option that exists today
  • The e-Mail option uses S/MIME to secure the ZIP of the XDM file-system
  • The modification from existing profile would be to explain how to save the S/MIME message as a file rather than delivering it over SMTP
  • This file would simply be a S/MIME message, thus protected with whatever the S/MIME protections used.

confidentialityCode - this is NOT a profile, but is a security/privacy concept built into almost all of the healthcare standards.

• Statement of the data security/privacy classification
• Would be used by access control decisions
• See: Data Classification - a key vector enabling rich Security and Privacy controls.

De-Identification handbook - this is NOT a profile, but is a document being written this year.

• Will be a procedure document that explains how one would evaluate the requirements for a De-Identification scheme specific to a desired use-case
• Would leverage De-Identification and Pseudonymization
• See De-Identification is highly contextual and Redaction and Clinical Documentation

Other

• Cookbook: Preparing the IHE Profile Security Section - Revised 2008-11-10
• HIE Security and Privacy through IHE- Revised 2008-08-22
• Access Control - Published 2009-09-28

Secure Design

• All this assumes that your system is secure by design. This includes limiting opportunities for bad guys.
• Risk based approach should be used to assure that all risks are managed appropriately
• Unnecessary services are disabled, security patches applied,
• Multiple layers of defense are in place both within and in the network
• Etc.

Provider Authentication Recommendations

Earlier this week, the HIT Policy Committee approved the recommendations of the Privacy and Security Tiger Team for provider authentication. The purpose is to support the exchange of clinical information among providers, especially in connection with meaningful use. The goal is to establish a trust framework for information exchange between the clinical systems of each provider.  This is accomplished through digital credentials at an organization level, not at a person level.

The Tiger Team recommended that all organizations that exchange health information should have digital certificates. This includes: "covered entities, business associates, PHR providers, public health entities, PBMs, retail pharmacies, DME suppliers, labs, imaging centers and non-providers including payers, claims clearinghouses and HIOs". The Tiger Team outlined at a high level the requirements for credentialing and the process which will involve multiple credentialing agencies nationally. It was recommended that the HIT Standards Committee establish standards for digital certificates.

EHR's should be certified based on the ability to "retrieve, validate, use, and revoke digital certificates that comply with standards". Authentication would be required for the exchange of personally identifiable health information and when the sending and/or receiving identities must be verified.

Provider Authentication Recommendations - Privacy and Security Tiger Team - 2010-11-19

HIT Policy Committee approves Tiger Team recommendations

The HIT Policy Committee today approved the privacy and security recommendations related to Stage 1 meaningful use.

Tiger Team presents MU Stage 1 privacy and security recommendations

The privacy and security Tiger Team presented its recommendations today to the Health IT Policy Committee regarding a "set of targeted questions raised by the ONC regarding the exchange of personally identifiable health information required for doctors and hospitals to qualify for incentive payments under Stage I of the Electronic Health Records Incentives Program."  The following is an extract of those recommendations.

Tiger Team Recommendation 1: Policies Regarding the Use of Intermediaries / third-party service organizations:

• Third party service organizations may not collect, use or disclose personally identifiable health information for any purpose other than to provide the services specified in the business associate or service agreement with the data provider, and necessary administrative functions, or as required by law.
• Third party service organizations may retain personally identifiable health information only for as long as reasonably necessary to perform the functions specified in the business associate or service agreement with the data provider, and necessary administrative functions.
• Retention policies for personally identifiable health information must be established, clearly disclosed, and overseen. Such data must be securely returned or destroyed at the end of the specified retention period, according to established NIST standards and conditions set forth in the business associate or service agreement.
• Third party service organizations should be obligated to disclose in their business associate or service agreements with their customers how they use and disclose information, including without limitation their use and disclosure of de-identified data, their retention policies and procedures, and their data security practices.
• Where such third party service organizations have access to personally identifiable health information, they must execute and be bound by business associate agreements under the Health Insurance Portability and Accountability Act regulations (HIPAA).

Tiger Team Recommendation 2.1:  Trust Framework For Exchange Among Providers for Treatment

• The responsibility for maintaining the privacy and security of a patient’s record rests with the patient’s providers, who may delegate functions such as issuing digital credentials or verifying provider identity, as long as such delegation maintains this trust.
• To provide physicians, hospitals, and the public with an acceptable level of accuracy and assurance that this credentialing responsibility is being delegated to a “trustworthy” organization, the federal government (ONC) has a role in establishing and enforcing clear requirements about the credentialing process, which must include a requirement to validate the identity of the organization or individual requesting a credential.
• State governments can, at their option, also provide additional rules for credentialing service providers so long as they meet minimum federal requirements.

Tiger Team Recommendation 2.2:  Trust Framework For Exchange Among Providers for Treatment

• The requesting provider, at a minimum, should provide attestation of his or her treatment relationship with the individual who is subject of the health information exchange.
• Providers who exchange personally identifiable health information should be required to comply with applicable state and federal privacy and security rules. If a provider is not a HIPAA-covered entity or business associate, mechanisms to secure enforcement and accountability may include:
• Meaningful user criteria that require agreement to comply with the HIPAA Privacy and Security Rules;
• NHIN conditions of participation;
• Federal funding conditions for other ONC programs
• Contracts/Business Associate agreements that hold all participants to HIPAA, state laws, and any other policy requirements (such as those that might be established as the terms of participation).
• Requesting providers who are not covered by HIPAA should disclose this to the disclosing provider before patient information is exchanged.

Tiger Team Recommendation 3.1: Consent and Directed Exchange

• Assuming FIPs are followed, directed exchange for treatment does not require additional patient consent beyond what is required in current law or what has been customary practice.

Tiger Team Recommendation 3.2: Triggers for Additional Patient Consent

• If the following circumstances are present, patients should be able to exercise meaningful consent to their participation. ONC should promote this policy through all of its levers.
• When the decision to disclose or exchange the patient’s identifiable health information from the provider’s record is not in the control of the provider or that provider’s organized health care arrangement (“OHCA”). Examples of this include:
• A health information organization operates as a centralized model, which retains identifiable patient data and makes that information available to providers.
• A health information organization operates as a federated model and exercises control over the ability to access individual patient data.
• Information is aggregated outside the auspices of the provider or OHCA and comingled with information about the patient from other, external medical records.

Tiger Team Recommendation 3.3: Meaningful Consent Guidance
A patient’s consent must be meaningful in that it:

• Allows the individual advanced knowledge/time to make a decision. (E.g., outside of the urgent need for care.) 
• Is not compelled or used for discriminatory purposes. (E.g., consent is not a condition of receiving medical services or benefits.)
• Provides full transparency and education. (I.e., the individual gets a clear explanation of the choice and its consequences, in consumer-friendly language that is conspicuous at the decision-making moment.)
• Is proportional to the circumstances. (I.e., the more sensitive, personally exposing, or inscrutable the activity, the more specific the consent mechanism. Activities that depart significantly from patient reasonable expectations require greater degree of education, time to make decision, etc.
• Must be consistent with reasonable patient expectations for privacy, health, and safety; and
• Must be revocable. (I.e., patients should have the ability to change their consent preferences at any time. It should be clearly explained whether such changes can apply retroactively to data copies already exchanged, or whether they apply only "going forward.")

Tiger Team Recommendation 3.4 : Consent Implementation Guidance

• The policies described above should not be construed to override laws that permit or compel providers to share patient data including, but not limited to HIPAA and legal requirements to participate in disease registries or research databases. We hope, however, they will be considered more fully in the future.

Further considerations for implementation includes the following guidance:

• Based on our core values, the person who has the direct, treating relationship with the individual, in most cases the patient’s provider, holds the trust relationship and is responsible for educating the patients about how information is shared and with whom.
• Such education should include the elements required for meaningful choice, as well as understanding of the “trigger” for consent (i.e., how information is being accessed, used and disclosed).
• The federal government has a significant role to play and a responsibility to educate providers and the public (exercised through policy levers).
• ONC, regional extension centers, and health information organizations should provide resources to providers, model consent language, and educational materials to demonstrate and implement meaningful choice. HIOs should also be transparent about their functions/operations to both providers and  patients.
• The provider/provider entity is responsible for obtaining and keeping track of patient consent (with respect to contribution of information from their records.) However, the provider may delegate the management/administrative functions to a third party (such as an HIO).

Tiger Team Recommendation 3.5: Provider Consent to Participate in Exchange
Based on the context of Stage I Meaningful Use, which is a voluntary program, ONC is not requiring providers to participate in any particular health information exchange. Whether a doctor’s employer requires such participation is not a matter for government policy.

Tiger Team Recommendation 4 : Granular Consent

• The technology for supporting more granular patient consent is promising but is still in the early stages of development and adoption. Furthering experience and stimulating innovation for granular consent is needed.
• This is an area that should be a priority for ONC to explore further, with a wide vision for possible approaches to providing patients more granular control over the exchange and use of their information
• The goal in any related endeavor that ONC undertakes should not be a search for possible or theoretical solutions but rather to find evidence for models that have been implemented successfully and in ways that can be demonstrated to be used by patients and fulfill their expectations. ONC and its policy advising bodies should be tracking this issue in an ongoing way and seeking lessons learned from the field as health information exchange matures.
• In the interim, and in situations where these technical capabilities are being developed and not uniformly applied, patient education is paramount: Patients must understand the extent to which their requests can be honored and we encourage setting realistic expectations. This education has implications for providers but also for HIOs and government.

Tiger Team Recommendation 5: Exchange for Stage 1 of Meaningful Use – Treatment, Quality reporting, Public health reporting

• The exchange of individually identifiable health information (IIHI) for “treatment” should be limited to treatment of the individual who is the subject of the information, unless the provider has the consent of the subject individual to access, use, exchange or disclose his or her information to treat others. (We note that this recommendation may need to be further refined to ensure the appropriate care of infants or children when a parent’s or other family members information is needed to provide treatment and it is not possible or practical to obtain even a general oral assent to use a parent’s information.)
• Public health reporting by providers (or HIOs acting on their behalf) should take place using the least amount of identifiable data necessary to fulfill the lawful public health purpose for which the information is being sought. Providers should account for disclosure per existing law. More sensitive identifiable data should be subject to higher levels of protection.
• In cases where the law requires the reporting of identifiable data (or where identifiable data is needed to accomplish the lawful public health purpose for which the information is sought), identifiable data may be sent. Techniques that avoid identification, including pseudonymization, should be considered, as appropriate.
• Quality data reporting by providers (or HIOs acting on their behalf) should take place using the least amount of identifiable data necessary to fulfill the purpose for which the information is being sought. Providers should account for disclosure. More sensitive identifiable data should be subject to higher levels of protection.
• The provider is responsible for disclosures from his or her records, but may delegate lawful quality or public health reporting to an HIO (pursuant to a business associate agreement) to perform on his or her behalf; such delegation may be on a "per request" basis or may be a more general delegation to respond to all lawful requests.

These recommendations are based on Fair Information Practices including individual access, correction, openness/transparency, individual choice, collection/use/disclosure limitation, data quality/integrity, safeguards, and accountability.  They are also based on the following core values:

• "The relationship between the patient and his or her health care provider is the foundation for trust in health information exchange.
• As key agents of trust for patients, providers are responsible for maintaining the privacy and security of their patients’ records.
• We must consider patient needs and reasonable expectations. Patients should not be surprised about or harmed by collections, uses, or disclosures of their data.
• Ultimately, to be successful in the use of health information exchange to improve health and health care, we need to earn the trust of both consumers and physicians."

Privacy and Security Tiger Team - August 19 2010

TigerTeamRecommendationLetter8-17_2-1