Privacy Technology Review

Prepared by The EXOCOM Group Inc.
Business Strategy and IT Consulting Division
for the Office of Health and the Information Highway, Health Canada
August 30, 2001

Table of Contents

• Executive Summary
• 1. Electronic Health Records: Characteristics and Use
  • 1.1. The Health Infostructure and Electronic Health Records
  • 1.2. Privacy Issues
  • 1.2. Developing Criteria for Privacy Technology
• 2. Review of Privacy Technologies
  • 2.1. Anonymizing Technology
  • 2.2. Platform for Privacy Preferences (P3P)
  • 2.3. Infomediaries and Identity Management Systems
  • 2.4. Trust Management Systems
  • 2.5. Smart Cards and Personal Computer Cards
  • 2.6. Biometrics and Biometric Encryption
  • 2.7. Public Key Infrastructure and Public Key Certificates
• 3. Applicability of Privacy Enhancing Technologies for Meeting Privacy requirements
  • 3.1. Accountability
  • 3.2. Identifying Purposes
  • 3.3. Consent
  • 3.4. Limiting Collection
  • 3.5. Limiting Use, Disclosure, and Retention
  • 3.6. Accuracy
  • 3.7. Safeguards
  • 3.8. Openness
  • 3.9. Individual Access
  • 3.10. Compliance
• 4. Conclusions and Recommendations
  • 4.1. General
  • 4.2. Unsuitable PETs
  • 4.3. Useful PETs
  • 4.4. Promising PETs
  • 4.5. Recommendations
• Annex A

Executive Summary

The EXOCOM Group Inc. assigned two principals to the project. They conducted the study and assessment from June to August 2001 in four phases, which are reflected in the organization of the document into four sections:

Section 1 - Electronic Health Records: Characteristics and Use

The authors summarized privacy requirements in the health sector, based on operational scenarios and the ten fair information practices delineated in the CSA Model Privacy Code. This phase included interviews with OHIH resources, and discussions regarding OHIH's broad concept of an electronic health record. The results are summarized in a table at the end of Section 1, which shows the ten privacy principles, the business rules that each implies, and the requirements that a privacy technology must meet to support the business rules.

Section 2 - Technology Survey

The authors surveyed commercial privacy technology available now or in the near future for supporting privacy agendas. The privacy technologies chosen are those that privacy advocates and technology vendors generally refer to as privacy enhancing technologies, as well as those that the authors determined support some aspects of privacy. The authors divided the privacy technologies into six groups or technology families, described how each is intended to address privacy, and briefly assessed its suitability in an electronic health records context in as determined by its design. At the end of each description, the authors include an abbreviated assessment table using only the ten privacy principles. The authors have noted difficulties in assessing some of the privacy technologies.

Section 3 - Technology Assessment

This section consists primarily of a detailed summary table of all six privacy technology groups, measured against the requirements developed in Section 1, and using the assessments of the technology's suitability from Section 2. This table is considerably more detailed than those in Section 2 in that the authors have added comments on the potential of a technology, when used in combination with applications or other infrastructure, to support a business rule.

Section 4 - Conclusions and Recommendations

The authors summarized the conclusions from the technology and recommend exploration of the most promising technologies, based on Section 3's results. The authors concluded that the most promising technologies are Trust Management Systems and Public Key Infrastructure, most likely in combination, and possibly using tokens. The authors recommend that OHIH undertake four activities: explore the Trust Management/Public Key Infrastructure combination in further detail; explore the use of tokens if stronger safeguards and attribution are required or if the finalized electronic health record concept includes patient control of some or all of their health record; explore the use of infomediaries if multiple identities are permitted; and develop the EHR concept concurrently with the other activities.

Annex A is a partially annotated list of useful web sites.

1. Electronic Health Records: Characteristics and Use

1.1. The Health Infostructure and Electronic Health Records

The health care sector is using technology to improve health care for Canadians wherever they are, as well as to increase the effectiveness of the health care system. Data that meets the information requirements of the health community, including individual citizens, will be part of the vision for the health info structure; data will reside in a variety of health system repositories, some of which will create data that is available to other systems, including those used for administrative support. Canada and other western nations conceive of their Electronic Health Records (EHR) systems as important elements of the health infostructure. EHRs offer the potential to meet a number of goals, and in Canada, these are summarized as follows:

• They promise to facilitate quick access for health care professionals, on a need to know basis, to an individual's health records for delivering better care;
• Individuals could have access to their health records, and will thereby be able to play a greater role in decisions about their own health care, in conjunction with health care providers¹; and
• With appropriate safeguards, health care administrators, policy makers and researchers will be able to use integrated health care information to strengthen the health care system by reducing costs, accommodating future developments, and supporting clinical and health service research.

Some health groups have advanced the concept of the EHR as a single, longitudinal, record of an individual's encounters with health providers. In OHIH's view, an individual's EHR will be a virtual record constructed from data stored at source, or from data that resides in centralized repositories such as the proposed College of Pharmacy's provincial data collections. The patient may also have a portable record of essential personal health information that many health care providers will need, such as blood type, allergies, and adverse reactions to medication.

The health records environment uses a wide range of technology and technological capabilities, a variety of media including paper-based records, and different standards and formats for similar information. These information systems operate in and reflect the legal and regulatory differences of their jurisdictions. In order to develop a useful list of requirements that apply in most, if not all, these different environments, the authors assumed that the ideal health info structure can and will be built, and that it will be interoperable and completely electronic, as privacy enhancing technologies will be most relevant in that context.

1.2. Privacy Issues

Privacy legislation and codes are designed to provide individuals with the means to prevent exploitation of their personal information or its use in ways over which they have no control. Ultimately, privacy legislation acknowledges individual control over use of personal information, that is, over the collection, use, disclosure, retention and disposal of their information by collecting organizations. In the EHR context, the privacy requirements that are defined by the ten standard privacy principles² present a major challenge to the health care sector. The principles provide no guidance in terms of standards. They do provide, however, some guidance regarding business rules. A number of requirements in the ten principles remain difficult to realize in the health sector, particularly ownership of information as opposed to records that contain personal information, and the requirement to notify regarding purposes of collection, obtaining patient consent, and notification regarding changes to uses and sharing with third parties.

1.3. Developing Criteria for Privacy Technology

This report uses the business rules embedded in the ten privacy principles to establish the criteria that will be used for assessing the usefulness of technologies that purport to support privacy in the health care context.
The table below lists technological requirements for supporting the business rules derived from the ten privacy principles. The authors use the requirements listed in the third column of this report to assess whether or not a privacy technology or technologies supports privacy in the context of EHRs.

technological requirements for supporting the business rules derived from the ten privacy principles

Principles	Business Rules	Requirements
1. Accountability An organization is responsible for personal information under its custody or control and shall designate an individual or individuals who are accountable for the organization's compliance with the privacy principles.	Appoint accountable individual Exercise organizational responsibility within the organization Exercise organizational responsibility for personal information disclosed to third party(ies)	Permit organization's accountable person to manage personal information use, disclosure etc. Verify adherence to principles e.g. audit trail Collect/monitor status of controls used to manage other principles Report the status of controls, assists in managing privacy issues
2. Identifying Purposes The purposes for which personal information is collected shall be identified at or before the time the information is collected.	Document purposes Notify individuals of the purpose of the collection Notify individuals of any changes in the purpose of the collection List data items and purposes	Document purposes and track changes to purposes Support accountable person Document when and how individuals are notified of purpose and changes to purposes
3. Consent The knowledge and consent of the individual are required for the collection, use, or disclosure of personal information	Method(s) to obtain express consent for sensitive personal information Keep track of consents - how, when, etc. Keep track of consent withdrawals	Document history of consent given Audit or review consent database
4. Limiting Collection The collection of personal information shall be limited to that which is necessary for the purposes identified. Information shall be collected by fair and lawful means	Describe/ document method(s) used to collect Show source of information Each data item must be related to purpose and substantiated Collection of information is tailored to the stated purpose	Document how each item supports purpose Document how collection made Audit or review collection Capture explanation of why data item being collected Capture explanation of how collection being done Collect information according to defined rules and definitions
5. Limiting Use, Disclosure, and Retention Personal information shall not be used or disclosed for purposes other than those for which it was collected, except with the consent of the individual or as required by law.	Use: Reflect all purposes for each health sector provider, by sector Identify who in health sector will use each piece of information Manage access to the collection by role to avoid purpose "a" to access purpose "b" data, etc.	Use: Document information use(s) Document authorized access to the information; define the roles Manage access based on authorization Audit access and use Capture who can obtain access Permit authorized access and disallow other access Capture /log access requests Report access requests outside of defined authorizations
	Disclosure: Match each access and disclosure to a purpose and document it Manage exclusions -- XXX must not access -- and document them Identify records that need to be kept from disclosure or use by specific groups Some records may need special handling because they have to be treated anonymously (see HIV example)	Disclosure: Deny use/ access/ receipt based on authorizations/ permissions and exclusions Audit access/ receipt Capture exclusions in authorization/ permissions rules Report access/ receipt by excluded roles Track authorized disclosures /receipts
Personal information shall be retained only as long as necessary for the fulfillment of those purposes and as required by law.	Retention: At least some health records will tend to be collected and kept for extended periods of time to reflect life expectancy (100+ years) Retention agreements as per Consent Disposal of records and backups Record of disposal Reliable disposal/ destruction	Retention: Document rules for retention Document information disposal Audit disposal of all information in a collection Audit destruction and verify Capture, hold, manage records for long retention periods Inventory all copies (backups, all subsets, all media) Document/ capture all steps in collection's life cycle
6. Accuracy Personal information shall be accurate and as up-to-date as necessary to fulfill the purposes for which it is collected.	Data validation procedures Integrity maintenance Link to openness. (See also 9. Individual Access to information, and ability to correct information, below)	Defined accuracy and maintenance checks Integrity designed into collection and retention mechanisms, across collections (See also 9 below)
7. Safeguards Security safeguards shall protect personal information against loss or theft, as well as unauthorized access, disclosure, copying, use or modification, through all phases of its life cycle, regardless of the format in which it is held	Define security requirements according to sensitivity of information, impact of loss/compromise/corruption Base needs on an accepted TRA process Validate against a known "Best Practice" standard e.g. ISO17799 Need supporting info showing WHY each safeguard is needed - or not Issues re safeguards for very long term holdings (100+ years) Software and hardware will need to become part of the "record" because they are needed to read the info	Information protection due diligence Accepted security practices (standards) Confidentiality and integrity objectives considered high Right to access very limited Safeguards selection based on requirements Approach can be HAZOP3, ISO17799, Cobit or other recognized standard Specific data protection tools justified to meet objectives For long-lived records, must allow for retrieval across generations of technology: software and hardware can become part of the record so that the record can be read throughout its life
8. Openness Specific information about policies and practices relating to the management of personal information shall be made readily available.	Policy manual becomes a public document Policy changes are public information because of the need to inform Need to manage public versus proprietary components	Mechanism(s) for policy accessibility
An individual shall be informed of the existence, use and disclosure of his or her personal information.	Inform about existence, use, disclosure Need a process for informing individuals about the status of the collection (see 2., 3. and 4.) Need to keep track of who has been or who cannot be informed Need to track use for reporting to individuals. Where has information been used and by who and for what purpose Need to track other disclosures for reporting to individuals Need to track when information has been destroyed	Mechanisms for individual to receive/ access status of information including use, disclosure (includes who has access to the information), disposal Mechanisms to track collection, use, disclosure, consents, disposal
9. Individual Access Upon request, an individual shall be given access to his or her personal information. Exceptions to the right of access must be limited and specific.	Document exceptions Methods for granting access to information owner Methods for verifying identity of individuals	Permit individuals to access their information; block exceptions (identification and authentication) Record who requests, how, when
An individual shall be able to challenge the accuracy and completeness of the information and have it amended as appropriate.	Track reasons for any change with before/after cases Document time limits if applicable Track when individual has been given access and of the results of this access Need for other supporting evidence	Reliable change management process to record requests, action them, track changes and confirm them to the individual making the request Mechanism for propagating the change across all copies of collections that include the individual's information
10. Challenging Compliance An individual shall be able to address a challenge concerning compliance with privacy requirements to a designated individual or individuals.	Document compliance challenge process, including response mechanisms and accountabilities Method to respond to challenge, manage challenges Document the process for amending privacy practices	Audit compliance challenges and responses

2. Review of Privacy Technologies

Privacy Technologies must provide tools that will allow organizations to manage their approach to privacy for both their staffs and for the individuals from whom they collect information. Our approach in this assessment has been to identify the characteristics or functions that automated tools should have in order to support privacy principles and objectives. Section 1 of this report identifies those requirements.

EHR systems are designed to collect health information. By default, most of that information is about individuals and has to be managed and processed according to the well-recognized Privacy Principles. These privacy requirements are distinct from the requirements to be met for the management of the health information in EHRs.

Privacy Technologies, or Privacy Enhancing Technologies (PETs),⁴ as generally defined in WWW searches, have directed themselves primarily to protecting an individual's identity during visits to web sites, web interactions and web transactions. While this type of tool for creating anonymity may have a role in how individuals have access to health information, they may not be appropriate in environments where data about a person must be clearly linked to specific individuals and where access must be limited to authorized parties. This is true of EHRs, where creating, altering, sharing, communicating and destroying data about an individual's health need to be attributed to and limited to authorized individuals.

Other approaches are emerging. Some, such as smart cards, are new ways to use existing security technology to enhance privacy. This section contains descriptions of what is currently understood to be privacy related technologies and their capability or potential to support privacy-related rules. It is also important to note that technology can be used to support policies, processes and procedures, but is not a substitute for them.

This section identifies six major categories of Privacy Technologies. Each group is described below with a summary assessment of how this technology can or cannot support privacy. Annex A is a partially annotated bibliography of PET web sites. The tables in this section accompanying the assessment of each technology address whether or not, at a macro level, the technology design can support privacy business rules. For some technologies, the capacity to address a privacy requirement will depend on EHR design and the role the patient will play in controlling their personal information. Section 3 is a more detailed analysis of the technology's potential to support privacy business rules.

2.1. Anonymizing Technology

Anonymity is defined as lack of identity. Anonymizers replace the identity of Internet users with a temporary identifier that exists only for the duration of the access. By doing so, any personal information the individual provides cannot be traced back to them.

Anonymizers operate on the concept that threats to an individual's privacy on the Internet derive from unauthorized monitoring of on-line actions, unknown logging of on-line actions, preservation of those logs for future access, and disclosure of the collected information to unknown parties. Monitoring and logging across multiple Internet sites can create vast amounts of information that can be aggregated and manipulated for various uses, all unknown to the individual. Individuals thereby lose the ability to choose what they want to disclose about themselves and the destination and use of their information and activities. Anonymity offers an Internet user the ability to visit web sites and conduct transactions without revealing who they really are and what their interests are. In that sense, any information collected about their WWW habits loses most of its meaning.

On the Internet, anonymity can take the form of persistent anonymity, or pseudonymity, where the user has a persistent on-line persona not connected to their real name; and one-time anonymity, where the user has an on-line persona that lasts for one use. In both cases, the information cannot be linked to a user's real name, although in the case of pseudonymity, various on-line actions can be linked to that pseudonym. Simple anonymizing techniques include using a third party that deletes Internet message headers and resends the message content using their identifier, or connecting to a mail server and forging fake headers that are attached to the message body. Anonymous re-mailers combine these two techniques by using a computer to automate the header stripping and resending process. In most cases, there is a location on someone's system that links the pseudonym to the real user, so security controls are needed to protect this link. Re-mailers vary in the strength of protection provided for this pseudonym.

Trusted intermediaries and technologies can minimize the need to collect personal information, or minimize the number of times the information needs to be accessed. New re-mailer technology gives enhanced protection against eavesdropping through techniques such as chaining and encryption of each link of the chain, and constant-length messages. Some can defend against replay attacks and passive correlation attacks, and use continuously generated random traffic to hide real messages. Pseudonymity servers deliver additional anonymity by using pools of re-mailer identities and encryption. Message pools protect users by allowing them to encrypt their message with the recipient's public key and send the message to a mailing list or newsgroup. Re-mailers can also be used for anonymous Web browsing: a web proxy can filter out identifying headers and source addresses from a web browser.

For electronic commerce, privacy and identity protection technology is promising, and anonymous digital cash, such as DigiCash's ecash, uses cryptography to protect a payee's identity and thus accords privacy. It is likely that designing anonymity into various services will move towards infrastructures that support bi-directional anonymity, analogous to a re-mailer network, and sometimes referred to as "Pipenet". To date, Pipenet designs have insufficient protection against the traditional attacks that can be made on re-mailers and that are associated with low-latency, long-lived connections. Some Internet credit card systems, however, allow individuals to make a credit card purchase over the Internet without transferring card numbers directly to the vendor.

Assessment of Anonymizing Technologies:

For virtual EHRs, anonymizing technology has limited potential, particularly given current vulnerability to attacks. Anonymous credit card transaction methodology may help to address authorizations for payment for health services, if that is considered part of an EHR. The underlying assumptions for anonymizing technology are in fact contrary to some EHR requirements: Anonymizers negate identity, but identity is a requirement for EHRs. The table below summarizes how anonymizing technologies fit EHR privacy requirements.

how anonymizing technologies fit EHR privacy requirements

Principles	Applicability
Accountability	No - not within design parameters; anonymizers cannot support audit; cannot monitor controls as controls cannot be implemented if there can be no attribution.
Identifying Purposes	No - not within design parameters
Consent	No - not within design parameters
Limiting Collection	No - not within design parameters
Limiting Use, Disclosure, Retention	No - design is contrary to attribution of action; anonymizers cannot support audit; cannot monitor controls as controls cannot be implemented if there can be no attribution.
Accuracy	No - not within design parameters
Safeguards	No - not within design parameters
Openness	No - not within design parameters
Individual Access	No - not within design parameters
Challenging Compliance	No - not within design parameters

2.2. Platform for Privacy Preferences (P3P)

The Platform for Privacy Preferences (P3P) was developed by the World Wide Web Consortium (WWWC) to define a standard for automating a way for users to exert control on the use of personal information by the web sites that they visit. Participants in P3P development include a variety of vendors and others, including America Online/Netscape, American Express, the Information and Privacy Commissioner of Ontario, Microsoft, Citibank, IBM, NEC, Nokia, and the Privacy Commissioner of Schleswig-Holstein. WWWC expects P3P to be in the form of a standard soon.

P3P is a tool intended to permit e-commerce providers to build services that respect users' privacy rights and preferences, while giving users greater control over their on-line privacy through individualized choices about the relationships they want to have with web-based services. P3P operates in a regulatory and policy context; it does not protect privacy in and of itself. In countries that have privacy laws, such as Canada, P3P can be used to assess privacy statements, allowing them to be collected and analyzed, and then assessed for compliance. P3P has the potential to enhance transparency and accuracy, but P3P does not guarantee that organizations follow their privacy policies.

P3P defines a standard set of practices related to the collection of private information. Web sites define how they intend to handle any data they collect. Individuals define, using multiple-choice questions, how they wish their information to be collected and handled. P3P-enabled browsers can then compare an individual's wishes to the Web-site policy and allow a user to proceed with the link knowing about the differences between their preferences and the site. A P3P Preference Exchange Language (APPEL) is used to encode the user preferences and the site policy and to directly take specific actions.

Users can also use P3P facilities to store data that they frequently exchange with web sites.

New concepts envision P3P as the basis for designing an identity management system, which will allow users to manage their privacy and control their digital identity. This concept is discussed in paragraph 2.4 below.

Assessment of P3P:

P3P was developed to help users to assess how a web site handles their personal information. It can also help organizations develop privacy policies and practices. P3P technology can assist the health sector in developing and managing privacy policies where information is exchanged over the Internet through web portals or sites, including how information is shared among linked services. This approach could ensure consistency.

P3P's major weakness is that it does not provide assurance that an organization complies with its own policies. The technology does not include security features such as access control, identification and authentication. In addition, it is intended for direct interchange between individuals and web sites. P3P offers limited support for the current EHR model, and only if OHIH anticipates that the patient will play a direct role in permitting data to be linked and/or in managing their records. Assessing P3P's ability to support privacy principles is a challenge: P3P addresses policy checking only, and does not include security features. Its usefulness also depends on the patient's role in EHR design. The table below therefore assesses only what a user can know is implemented.

The table below therefore assesses only what a user can know is implemented

Principles	Applicability
Accountability	No - not part of design parameters
Identifying Purposes	Yes - providing that policy is followed
Consent	Possibly - depending on EHR design: Patients have the choice to provide the information being asked if they agree with the policies; there is still no guarantee that policy is followed
Limiting Collection	Possibly - depending on EHR design: only information that patients consent to have collected, is collected, providing policy is followed and no unseen processes have been implemented to collect additional information.
Limiting Use, Disclosure, Retention	No - not part of design parameters
Accuracy	No - not part of design parameters
Safeguards	No - not part of design parameters
Openness	Yes - if policy is followed; policy content is verified using P3P tools
Individual Access	No - not part of design parameters
Challenging Compliance	No - not part of design parameters

2.3 Infomediaries and Identity Management Systems

A few companies have introduced tools and services designed to help users manage their on-line identities. These information intermediaries - infomediaries - offer tools that allow users to store personal information in a secure location. This information can then be used, through automatic form filling, to restrict the information individuals wish to share to those sites that match their privacy preferences. Some vendors are "incubators" for infomediaries, setting up companies that act as infomediaries. Some appear to be primarily oriented to customer relationship management, although their products feature maintenance and respect of customer consent as information is exchanged. Some have integrated biometrics as part of their solution, and offer electronic wallets or other forms of e-cash.

Some infomediary tools are based on P3P. P3P platforms, when coupled with an anonymous communications network, offer identity management systems. These tools allow users who wish to be known by different names in different contexts to manage their various combinations of identity, roles and personal data. Identity management systems allow the user to decide to whom to give which data, when to act anonymously, when to use a pseudonym, and when to identify or authenticate. Some systems provide certified pseudonyms that can be used when a real identity is required, for example, for a business transaction, for voting in an election, to pre-authorize purchases, to register for warranties, etc. Certificates can be transferred or used as vouchers, with on-line verification and expiry dates where required.

In well-structured infomediaries, only the user/ information owner is able to link their pseudonyms. Data, however, is stored centrally and could be logged and analyzed to gain a detailed picture of user behaviour by the infomediaries themselves. Implementations with this type of data aggregation are potentially privacy-invasive.

Assessment of Infomediaries and Identity Management Systems:

This type of technology combines identity management with anonymizers and P3P techniques to help users of the Internet manage different identities. This technology itself needs to adhere to the privacy principles so that users can monitor the way in which they allow their information to be distributed. These tools implement few of the privacy management requirements that are listed in Table 1 either for the systems they allow pseudonym access or for the personal data they contain.

As for basic anonymizing technology, the objectives of infomediaries and identity management systems are to dissociate an individual from their personal information. This appears to defeat the main purpose of the virtual EHR systems, which is to insure all of an individual's information is readily available to authorized parties.

The authors believe that infomediaries could play a role in EHR systems, although they are not designed to do so. These types of identity databases could be used to link an individual's existing records by keeping track of the various identifiers that are used for one person in different EHR source databases. This would allow the custodian/owners of each health database to manage information in the most efficient way possible for them while at the same time provide that information to other health professionals without undue restrictions. If the infomediary could capture use information, this would allow patients some measure of control on information that has been collected about them, if EHR design permits patients a direct role in the EHR.

Table: Principles

Principles	Applicability
Accountability	No - not part of design parameters
Identifying Purposes	Possibly - providing that P3P-like policy is stated and followed
Consent	Possibly - Depending on EHR design: patients have the choice to provide the information being asked under their real identity or using a pseudonym
Limiting Collection	Possibly - providing that P3P-like policy is stated and followed
Limiting Use, Disclosure, Retention	Possibly - depending on EHR design, and if creation of identity databases and multiple identities are permissible; tool needs to capture use information
Accuracy	No - not within design parameters
Safeguards	No - not within design parameters
Openness	Yes - if P3P-like policy followed
Individual Access	Possibly - depending on EHR design and if use information is captured
Challenging Compliance	No - not within design parameters

2.4 Trust Management Systems

A trust-management system helps applications answer questions of the form, "Does this potentially dangerous operation conform to my security policy?" Typically, the correct answer depends on what the operation is, who is requesting that it be performed, the local security policy, the requester's credentials, and other factors. Trust management systems provide applications with a standard interface for getting answers to such questions, and provide users with a standard language for writing the policies and credentials that control what is allowed and what isn't. There are five components to a trust management system:

• A language for describing actions, which are the operations with security consequences that the system controls;
• A mechanism for identifying principals, which are entities that are authorized to perform actions⁵;
• A language for specifying application policies, which govern the actions that principals are authorized to perform;
• A language for specifying credentials, which allow principals to delegate authorization to other principals;
• A compliance checker, which provides a service to applications for determining how an action requested by principals should be handled, given a policy and a set of credentials.

In traditional applications, policies are often "hard-coded" into applications and are difficult to change. In a Trust Management system, policies are written in a standard language that stays the same across different applications, that is defined outside of the application's code and that can be altered by the responsible user whenever needed. An especially powerful concept is the unification of the notion of security policy with that of security credentials. Distributed applications can easily create polices that defer to a remotely managed authority, which can change the policy simply by issuing new credentials (certificates). A policy can become a remotely usable credential simply by being signed.

Using a trust management system for controlling security-critical services frees the application developer from a number of often difficult and subtle design and implementation issues, and allows users to take advantage of a flexible, standard, application-independent language for specifying policy. Before trust management, every application had to provide its own mechanisms for specifying policy, interpreting credentials, and binding user authentication with the authorization to perform "dangerous" operations. Trust management systems, on the other hand, provide an interface that potentially takes care of all of these things. All the application designer has to do is identify the trust management questions in the application and formulate appropriate queries to the trust-management system.

Assessment of Trust Management Systems:

Trust management unifies the notions of security policy, credentials, access control, and authorization. An application that uses a trust-management system can simply ask the compliance checker whether a requested action should be allowed. These could include the access principles required for the management of private information.

Furthermore, policies and credentials are written in standard languages that are shared by all trust-managed applications; the security configuration mechanism for one application carries exactly the same syntactic and semantic structure as that of another, even when the semantics of the applications themselves are quite different. Trust-management policies are also easy to distribute across networks, helping to avoid the need for application-specific distributed policy configuration mechanisms, access control lists, and certificate parsers and interpreters.⁶

This type of technology seems to offer many of the features that would be needed by EHR systems to help manage who can access and use a person's information. Trust Management, however, adds a layer of complexity to managing private information without necessarily providing the controls the ten privacy principles impose on the collection of information.

Table: Principles

Principles	Applicability
Accountability	Yes - Trust rules can be designed to ensure consent, limit use and disclosure, protect other access, and allow individual access. These rules can also be audited, thus providing the accountability defined by privacy. The PKI support for authentication can provide some assurances about the identity of the users and administrators.
Identifying Purposes	Yes - certificates can be created for each purpose
Consent	Yes - can be part of the certificate creation process.
Limiting Collection	Yes - by design (see Identifying Purposes) plus audit
Limiting Use, Disclosure, Retention	Yes - combination of credentials, access management supported by PKI, logging and audit
Accuracy	Yes - Using PKI digital certificates for integrity; collectors cannot modify information unless they are assigned the proper credentials.
Safeguards	Partial - provides access control mechanisms
Openness	No - Only in policy statement; not part of design parameters
Individual Access	Yes - suppliers of information could have the credential to access their information depending on EHR design + users with the appropriate credential can verify accuracy.
Challenging Compliance	No - not part of design parameters

2.5 Smart Cards and Personal Computer Cards

Smart card technology has progressed to the point where the increased capacity for memory and functionality permit the creation of secure solutions for a wide range of situations. Smart cards have been used since the early 1970s for many different types of applications. In their most common form, they contain stored values that are transmitted when the card is inserted into a reader, or for some newer version, when they are in close proximity to devices that receive radio frequencies. Many smart card implementations include complex crypto logic protocols that allow these devices to be used to protect the confidentiality of the stored information.

Smart cards can be used to store credential information, such as academic qualifications, credit rating and permission to access a room; and produce evidence that the individual holds credentials without the individual having to reveal the personal information that is ordinarily required for verifying credentials. In Europe, smart cards are widely used for processing transactions with retail, telephony and information retrieval applications, particularly for electronic "purses". Personal Computer (PC), Personal Computer Memory Card International Association (PCMCIA), Miniature, SmartMedia, MultiMedia and CompactFlash cards offer different memory capacity and vary in size as well as in compatibility with card and socket services.

Smart cards can store information that defines a person's identity: Using a reader, a person can authenticate to a computer system to retrieve or store information. Such an interface to an access control system or to a Permission Management Infrastructure can be used to allow authorized access to information according to pre-set rules. In addition, they can store records of personal information. Anyone needing access to that information needs to have possession of the card and the authority to read the information it contains. Although the authors have not identified any devices that can do so, Smart Cards with appropriate programming could capture usage and access data. This reporting feature would allow Smart Cards to meet many of the privacy reporting requirements described earlier.

Assessment of Smart Cards and Personal Computer Cards:

Although Smart Card technology has the potential to hold medical records and can help users manage who gains access to those records, most current uses of the technology are limited to storing information that is used to confirm the identity of its holder or to store encryption keys used to encrypt information. Much development work, therefore, remains to be done to apply Smart Card technology to the management of personal information.

Table: Principles

Principles	Applicability
Accountability	No - not part of design parameters
Identifying Purposes	No - not part of design parameters
Consent	No - not part of design parameters
Limiting Collection	No - not part of design parameters
Limiting Use, Disclosure, Retention	No - not part of design parameters
Accuracy	Partial - if card contains digital signature
Safeguards	Partial - provides high assurance verification of identity
Openness	No - not part of design parameters
Individual Access	No - not part of design parameters unless EHR design requires token for patient access
Challenging Compliance	No - not part of design parameters

2.6 Biometrics and Biometric Encryption

The progress of biometrics⁷ using fingerprints, voiceprints or retinal scans, promises to deliver a high degree assurance for processes that validate the identity of individuals. A biometric device authenticates an individual and verifies eligibility to access a service or specific information. Biometric verification replaces a password or PIN, and offers the benefit of stronger authentication than a password or a PIN to counter identity fraud. Control of the stored digital biometric representations, and of their encryption keys where cryptography is used, is the weak link in this model, and information from a variety of sources can still be linked to or associated with the biometric template, thereby permitting third parties to have access to detailed, complete personal profiles.

Encryption based on a biometric key can be used to anonymize information in a database by separating an individual's identity from the personal information. The link between the identity and the information is a pointer that is encoded by the individual's fingerprint pattern, for example, or other biometric representation. The individual now controls that personal information.

Some biometric technology is not as stable as required for widespread large-scale use. Fingerprint and retina patterns can change according to conditions or to alterations from accidents and are thus are not reliable. Retinal scans continue to offer the most promising solutions, although most Canadians resist them as invasive. Voice recognition technology is also making significant progress and has been implemented in many smaller scale applications. Biometric technology is relatively expensive.

Assessment of Biometrics and Biometric Encryption

Biometrics and biometric encryption offer possibilities for strong identification and authentication when used in combination with smart card or personal computer cards, and possibly with PKI and/or trust management systems. Biometrics offers the strongest possible identification and authentication for individuals who are authorized to enter or retrieve data from an EHR. In the case of health care organizations, such as hospitals, this level of granularity may not be warranted, unless it is the patient who uses a card to permit data to be entered or retrieved. Many individuals find biometrics to be invasive, and resist using the technology; others assess biometrics as privacy neutral.

Using biometrics as part of an EHR system requires implementers to pay attention to how the biometric record is stored for back-up purposes. In addition, proper registration of individuals is a major challenge, especially if biometrics devices are to be used in large numbers.

Table: Principles

Principles	Applicability
Accountability	No - not part of design parameters
Identifying Purposes	No - not part of design parameters
Consent	No - not part of design parameters
Limiting Collection	No - not part of design parameters
Limiting Use, Disclosure, Retention	No - not part of design parameters
Accuracy	Partial - if card contains digital signature
Safeguards	Partial - provides high assurance authentication of identity
Openness	No - not part of design parameters
Individual Access	No - not part of design parameters unless the patient controls the electronic health record
Challenging Compliance	No - not part of design parameters

2.7 Public Key Infrastructure and Public Key Certificates

Public Key Certificates (certificates) are part of a Public Key Infrastructure (PKI), and normally require that the identity of an individual is validated to varying degrees of rigour, and bound to the digital signature and confidentiality certificates issued by a Certification Authority (CA). The individual's public key is kept in a directory, which is accessible to anyone with a certificate recognized by the directory. PKIs offer a range of security services, including encryption, digital signature, non-repudiation, and identification and authentication. New versions of PKI offer a number of features, including permissions management.

Public key infrastructures support the use of applications that encrypt data and that use digital signatures. Public key infrastructures are based on principles associated with public key cryptography. Public key cryptography encrypts information by using two mathematically related keys: one is kept private; the other is made public. The private key cannot be determined from the public key. An individual who wants, for example, to send a message uses the public key of the recipient to encrypt the message. The recipient uses his or her private key to decrypt the message. The sender therefore knows that only the intended recipient can read the message.

Public key cryptography can also be used to create digital signatures. A digital signature uses a mathematical function to produce a value that depends on the content(s) of a message. This value is then attached to the message and encrypted using the sender's private key. The recipient of the message then decrypts the digital signature using the sender's public key and recreates the value that was attached to the message using the same mathematical function as the sender. If the digital signature can be decrypted and the attached values are identical, then the recipient is assured of both the sender's identity and the integrity of the message. Because the digital signature of a message depends on the private key used to produce it, the sender's ability to repudiate the message is reduced.

Keys are managed by a Certification Authority, which may be a third party trusted to associate a public and private key pair with a specific individual or entity, called a subscriber. It manages the issuance and revocation of certificates, and maintains lists of certificates that have been revoked. Digital certificates, which are digitally signed by the Certification Authority, contain the public key and serves as evidence that the individual identified in the certificate holds the corresponding private key. Two or more Certification Authorities can be linked together by cross-certification to provide mutual recognition of the certificates issued by different organizations.

There are a number of privacy-invasive features in PKI, most notably the posting of public keys on a directory accessible to all those holding keys issued by a Certification Authority or by Certification Authorities that are cross certified. This technology can potentially be designed to support privacy by using pseudonyms or some other method to disguise the identity of the certificate holder. Registration procedures still bind the real identity of the certificate holder to the certificate.

Assessment of Public Key Infrastructure

PKI is a relatively mature technology that, when used in combination with other technologies, offers considerable promise for EHRs. Although PKIs require a major effort to implement, including considerable attention to governance, policy and practices, they offer a number of features that will help EHRs support privacy principles: identification and authentication, non-repudiation, policy management and standards, and confidentiality. A permissions management infrastructure can be used in conjunction with PKI.

Successful implementation of a PKI requires strong policy management within an organization, the Certification Authority and across cross-certified organizations. PKIs have built-in audit requirements, and standards. PKI also requires that subscribers agree to protect their keys by signing a formal agreement that could also serve as the formal consent for collection and use of at least some personal information. PKI also offers the possibility of deploying an infrastructure that permits devices rather than individuals to access, enter or change data.

The close association between the certificate issued by a PKI and the identity of its recipient, the subscriber, is usually viewed as in conflict with privacy principles. If patients are subscribers, then directories pose a potential privacy violation unless an identifier or other method is used. Treasury Board Secretariat is exploring ways to address this problem. Seamless ways to register subscribers and issue certificates are also required to make this model scalable.

In spite of its maturity, PKIs are tools for verifying the identity of individuals before they are allowed to access specific in formation or processing resources. By itself, this technology does not provide for the privacy principles and requirements outlined above. PKI, however, identifies subscribers with high level of assurance. Application interfaces that link these identities with EHR records are needed to ensure that personal data does not end up in unauthorized hands.

Assessing PKI's ability to meet privacy requirements is difficult, as PKI relies heavily on policy and policy management as well as safeguards. Policy and audit, along with policy management, are intended as checks and balances; policy must be designed as privacy-compliant, and audits must be public. The policy burden that accompanies PKI is further complicated if a permissions management infrastructure is used, although permissions management can help PKI meet privacy requirements. The assessment below indicates where policy can be audited for compliance to meet policy requirements; where EHR design and the patient's role in EHR could determine whether PKI meets requirements; and where a permissions management infrastructure will help PKI to support privacy requirements.

Table: Principles

Principles	Applicability
Accountability	Yes - audit and policy management
Identifying Purposes	Yes - Certificate Policies and Certificate Practice Statement can state purposes and set standards for adherence to stated purposes; audit
Consent	Possibly - if patients issued certificates and subscriber agreement includes consent to what is stated in Certificate Policies
Limiting Collection	Possibly - if permissions management infrastructure used
Limiting Use, Disclosure, Retention	Possibly - if permissions management infrastructure used, and Certificate Policies state use, disclosure, retention, and audit can track Directory problem must be addressed (see text above)
Accuracy	Partly - through preservation of digitally signed records
Safeguards	Yes - provides verification of identity, encryption for confidentiality and digital signatures for accountability (non-repudiation)
Openness	Yes - Certificate Policies, which need to be subject to audit and audit results must be published
Individual Access	Possibly - if patients have access permissions in a permissions management infrastructure
Challenging Compliance	No - not part of design parameters

3. Applicability of Privacy Enhancing Technologies for Meeting Privacy Requirements

Summary of Findings

This section summarizes privacy requirements as developed in Section 1, listed according to the ten privacy principles, and indicates the technologies that potentially satisfy each requirement. This table includes methods, other than design, that could or do satisfy requirements. Where a PET's design satisfies a requirement the authors have noted this in bold font.

Table: Requirements

Requirements	Applicable PETs8
3.1 Accountability
1. Permit organization's accountable person to manage personal information use, disclosure etc.	P3P - If policy is followed and audit possible, can have policy management across jurisdictions and systems PKI - audit and policy management Trust Management Systems - Design with PKI support for identification and authentication; rules can be audited
2. Verify adherence to principles e.g. audit trail	PKI - digital signatures (non-repudiation) within permissions management infrastructure; and audit Trust Management Systems - Design: Audit
3. Collect/monitor status of controls used to manage other principles	PKI - Certificate Policy audit requirements and audit of permissions management infrastructure TRUST MANAGEMENT SYSTEMS - DESIGN: AUDIT
4. Report the status of controls and assist in managing privacy issues	PKI - audit and policy management TRUST MANAGEMENT SYSTEMS - DESIGN: AUDIT
3.2 Identifying Purposes
1. Document purposes and track changes to purposes	P3P if policy followed Informediaries - if P3P-like policy followed PKI - Certificate Policy and policy management; audit TRUST MANAGEMENT SYSTEMS - DESIGN: CREATE DIFFERENT CERTIFICATES FOR EACH IDENTIFYING PURPOSE
2. SUPPORT ACCOUNTABLE PERSON	PKI - CREATION OF POLICY MANAGEMENT AUTHORITY AND PUBLICATION OF CERTIFICATE POLICY; AUDIT Trust Management - Design: audit certificate use
3. DOCUMENT WHEN AND HOW INFORMATION OWNER NOTIFIED OF PURPOSE AND CHANGES TO PURPOSES	P3P AND INFOMEDIARIES - IF POLICY FOLLOWED PKI - CERTIFICATE POLICY; POSSIBLY THROUGH SUBSCRIBER AGREEMENT IF PATIENT IS A SUBSCRIBER; AUDIT
3.3 Consent
1. Document history of consent given	P3P - depends on EHR design and whether policy is followed; Infomediaries - depends on EHR design PKI - possibly through subscriber agreement if patient is subscriber Trust Management - part of certificate creation Biometrics/Biometric Encryption - Individual's use of biometric may be tacit consent; use could be logged Smart Card -as for biometrics
2. Audit or review consent database	PKI - maintaining subscriber agreements where patients are subscribers (manual) Trust Management -Verification of credentials database
3.4 Limiting Collection
1. Document how each item supports purpose	P3P and Infomediaries - if policy implemented PKI - Possibly - Certificate Policy, Subscriber agreements where patient is subscriber, permissions management infrastructure Trust Management - See Identifying Purposes (3.2)
2. Document how collection made	P3P and Infomediaries - if policy implemented PKI - Possibly - Certificate Policy, Registration model, Subscriber agreement where patient is subscriber; audit Trust management - See Identifying Purposes
3. Audit or review collection	PKI - Certificate Policy audit requirements Trust Management - See Identifying Purposes
4. Capture explanation of why data item being collected	PKI - Possibly through Certificate Policy and subscriber agreements where patient is subscriber Trust Management - See Identifying Purposes
5. Capture explanation of how collection being done	PKI - Certificate Policy and subscriber agreements where patient is subscriber Trust Management - See Identifying Purposes
6. Collect information according to defined rules and definitions	P3P and Infomediaries - if policy implemented PKI - Certificate Policy, registration model, subscriber agreements where patient is subscriber Trust Management - See Identifying Purposes Biometric - if patient has control over HER
3.5 Limiting Use, Disclosure, and Retention
Use
1. Document information use(s)	P3P and Infomediaries - if policy implemented PKI - possibly through permissions management, Certificate Policy Trust Management - through credentials
2. Document authorized access to the information; define the roles	P3P and Infomediaries - if policy implemented PKI - possibly through permissions management Trust Management - through credentials
3. Manage access based on authorization	P3P and Infomediaries - if policy implemented PKI - possibly through permissions management infrastructure Trust Management - through credentials
4. Audit access and use	PKI: possibly through permissions management, Certificate Policy audit requirement, log intrusions Trust Management: through credentials, audit compliance checker
5. Capture who can obtain access	P3P and Infomediaries - if policy implemented PKI - possibly through permissions management infrastructure Trust Management - through credentials
6. Permit authorized access and disallow other access	PKI - Identification and Authentication; possibly through permissions management infrastructure Trust Management - through credentials + PKI for access controls and audit
7. Capture / log access requests	PKI - database access logs or intrusion logs Trust Management - PKI database access logs or intrusion logs
8. Report access requests outside of defined authorizations	PKI - Certificate Policy, Certificate Practice Statement, safeguards, intrusion alarms and logs Trust Management - PKI database access logs
Disclosure
1. Deny use/ access/ receipt based on authorizations/ permissions and exclusions	P3P and Infomediaries - if policy implemented PKI - Possibly through built-in Identification and Authentication combined with permissions management infrastructure Trust Management - through credentials and PKI identification and authorization controls Biometric Encryption - credentials for those authorized or patient control through biometrics Smart Card if patient controls HER
2. Audit access/receipt	PKI - identification and authorization controls Trust Management - PKI identification and authorization controls
3. Capture exclusions in authorization/ permissions rules	P3P and Infomediaries - if policy implemented PKI - through permissions management and identification and authorization controls Trust Management - through credentials and PKI identification and authorization controls
4. Report access/ receipt by excluded roles	PKI - through permissions management and identification and authorization controls; and log database access Trust Management - through credentials and PKI identification and authorization controls; and log database access
5. Track authorized disclosures/receipts	PKI and Trust Management - log database access
Retention
1. Document rules for retention	P3P and Infomediaries - if policy implemented PKI - possibly through Certificate Policy, Certificate Practice Statement Trust Management - policy
2. Document how information is to be disposed of	P3P and Infomediaries - if policy implemented PKI - possibly through Certificate Policy, Certificate Practice Statement Trust Management - policy
3. Audit disposal of all information in a collection	PKI - Certificate Policy audit requirements Trust Management - audit requirements
4. Audit destruction and verify	PKI - Certificate Policy, Certificate Practice Statement Trust Management - through PKI as above
5. Capture, hold, manage records for long retention periods	PKI - Certificate Policy, Certificate Practice Statement, notary services Trust Management - through PKI as above
6. Inventory all copies (backups, all subsets, all media)	PKI - Certificate Policy, Certificate Practice Statement Trust Management - through PKI as above
7. Document/ capture all steps in collection's life cycle	PKI - Certificate Policy, Certificate Practice Statement Trust Management - through PKI as above
3.6 Accuracy
Defined accuracy and maintenance checks	Smart Cards and Biometrics: if digital signature used, and uses logged PKI - partly through digitally signed records Trust Management - collectors cannot modify information unless they are assigned the proper credentials + digital signature for integrity
Integrity designed into collection and retention mechanisms, across collections	Smart cards and Biometrics: if digital signature used PKI - partly through digital signature Trust Management - collectors cannot modify information unless they are assigned the proper credentials + digital signature for integrity
See Individual Access (3.9) and ability to correct information
3.7 Safeguards
1. Information protection due diligence	Smart Cards and Biometrics - if cards can encrypt, digitally sign; use identification and authentication PKI - encryption, digital signature - appropriate assurance level Trust Management - through PKI
2. Accepted security practices (standards)	Smart Cards and Biometrics - if cards can encrypt, digitally sign; use identification and authentication PKI - Certificate Practice Statement for encryption, digital signature, physical security, subscriber agreements,; cross-certification agreements; technical, physical and personnel security Trust Management - provides access control mechanisms
3. Confidentiality and integrity objectives considered high	Smart Cards and Biometrics - if cards can encrypt, digitally sign; use identification and authentication PKI - Design: encryption, digital signature, non-repudiation, back-up Trust Management - use PKI for safeguards
4. Right to access very limited	Smart Cards and Biometrics -use identification and authentication PKI - identification and authentication, registration model; possibly through permissions management Trust Management - credentials Biometrics, Biometric Encryption for stronger access control where required
5. Safeguards selection based on requirements	Smart Cards and Biometrics - if cards can encrypt, digitally sign; use identification and authentication - can augment other safeguards PKI - Safeguards, based on selection of appropriate assurance level Trust Management - through PKI
6. Approach can be HAZOP, ISO17799, Cobit or other recognized standard	As above
7. Specific data protection tools justified to meet objectives	PKI - selection of appropriate assurance level Trust Management - through PKI
8. For long-lived records, must allow for retrieval across generations of technology: software and hardware can become part of the record so that the record can be read throughout its life	PKI - notary services can help maintain document integrity Trust Management - possibly through notary services
3.8 Openness
1. Mechanism(s) for policy accessibility	P3P and Infomediaries - publication of policy; accessible for policy matching across organizations sharing information PKI - Publication of Certificate Policy with published audits
2. Mechanisms for individual to receive/ access status of information including use, disclosure (includes who has access to the information), disposal	P3P and Infomediaries - policy checking only Trust Management and PKI - See Individual Access (3.9)
3. Mechanisms to track collection, use, disclosure, consents, disposal	PKI - audit of permissions management, intrusion logs, log access requests to database
3.9 Individual Access
1. Permit information owner access; block exceptions (identification and authentication)	Infomediaries - depending on EHR design and if use information is captured Tokens: Biometrics, Biometric Encryption - patient Smart Card/ PC Card for patient access where patient controls EHR (see Trust Management below) PKI - partially through identification and authentication where patient is a subscriber; possible requirement for token Trust Management - suppliers of information could have credential to access their information depending on EHR design.
2. Record who requests, how, when	PKI - log intrusions; log database access requests Trust Management - as for PKI
3. Reliable change management process to record requests, action them, track changes and confirm them to information owner	PKI - allow for policy changes through policy management authority and public posting of Certificate Policy Trust Management - as for PKI
4. Mechanism for propagating the change across all copies of collections that include the individual's information	PKI - changes to permissions management, potential to re-issue certificates Trust Management - Design
3.10 Compliance
1. Audit compliance challenges and responses

4. Conclusions and Recommendations

4.1 General

The design of current privacy technologies does not meet the functional requirements that are implied by privacy codes and legislation. None of the technologies surveyed provides appropriate tools that allow privacy managers to answer the basic questions about the private information they keep: What is it used for, Who has access, When was the last access, Is the collection safe and sound, and so on. Not surprisingly, no PET addresses all requirements, and no tools specifically address compliance challenges, partly because administering challenges will come outside of the EHR. As noted in the introduction, the authors acknowledge that technology alone is capable of addressing few requirements. For some, however, such as anonymizing technologies and Platform for Privacy Preferences, there is no built-in technology to support policy. Smart Cards and Biometrics can address few requirements by themselves, but are capable of augmenting promising PETs.

Many of the tools identified limit their functionality to hiding the identity of their users or to permitting the creation and management of several pseudo-identities that serve to hide the real individual. The authors believe this is incompatible with the requirement that EHR records be clearly linked to an individual for purposes of integrity and accountability, and therefore conclude that anonymizers, Platform for Privacy Preferences and Infomediaries are unsuitable for EHRs.

Other technologies, such as PKI, meet privacy requirements primarily through the application of policy and subscriber agreements. This technology will require attention to policy, procedure and processes, and will have to include governance, policy management, and compliance auditing at a minimum. Interoperability will also be a technology and budget issue. Technology that relies on voluntary adherence to privacy policy also needs some form of substantiation that policies are being followed. The tools surveyed provide neither the policies nor the assurance that they cannot be circumvented. For trust management systems, policy is propagated across applications, and technology, such as PKI, is available to enforce permissions management and other policy requirements. Those entrusted with designing EHRs and EHR systems must therefore get the policy right.

The authors thus conclude that although many tools claim to support privacy, this support is usually limited to a very narrow objective that in many creates a governance conflict within EHRs. None of the tools provide the support that a privacy administrator will require to monitor adequately whether or not an organization's application adheres to the privacy principles.

Using the privacy principles, the authors identified a number of requirements that applications need to add to their traditional business specifications. Many of the requirements are reflected in the table in Section 3. Only those applications that factor in privacy during their development have the potential to satisfy all privacy needs. The six categories of privacy technologies from Section 2 are further grouped below, according to the authors' assessment of their potential for supporting privacy requirements.

4.2. Unsuitable PETs

Some PETs are not suitable for EHRs. Our recommendation is to not use these tools in the health context now.

Anonymizers:

Anonymizing technology, by design, does not permit attribution of actions, such as entering or retrieving data. Policy-compliant EHRs will require that at least some actions will need to be attributed to an individual or organization, that is, it is not possible to impose accountability. In addition, anonymizers provide no other protection for safeguarding the availability, confidentiality and integrity of records, transactions and other aspects of EHRs. While safeguards could be added, the inability to impose accountability is considered serious enough to assess this technology as having no potential for use in EHRs, either now or in the future.

Platform for Privacy Preferences (P3P)

While P3P assists organizations to develop privacy-compliant policy and practices, it provides no assurance to the community of EHR users and patients regarding compliance. As with anonymizers, P3P does not safeguard information through access control, encryption and other standard security safeguards. These features could be added, but the uncertainty of policy application is a serious limitation on true openness, accountability, and limitations on use, disclosure and retention. P3P, therefore, offers little or no promise for EHRs.

Infomediaries and Identity Management Systems

The combination of identity management and infomediaries does not permit an EHR system based on this technology to impose accountability. In addition, those that are P3P-based, the majority, will not be able to provide compliance assurance. Infomediaries and Identity Management Systems have some limited potential for use in EHRs, depending on design, and could be used to manage multiple identities where these are permitted.

4.3. Useful PETs

Some PETs have useful features that could be incorporated with other technology in an EHR framework:

Smart Cards and Personal Computer Cards

These technologies are capable of strengthening access control through strong identification and authentication, and could be used to support permissions management. This technology, similar in use to credit and debit cards, should be examined for its potential, given its wider acceptance among less sophisticated users.

Biometrics

This technology, when coupled with smart cards, could provide additional access controls and permissions management. Storage of biometric information will have to be handled very carefully, and registration of individuals in large-scale deployments poses a major challenge. This technology could be effective if EHRs need to incorporate some degree of direct patient access to patient information. Some forms of biometrics are, at present, less acceptable than others.

4.4. Promising PETs

Two types of technologies merit detailed examination: Trust Management Systems and Public Key Infrastructures.

Trust Management Systems

Trust Management Systems offer a number of attractive features, including permissions management and policy compliance enforcement. This technology also permits development of an EHR system that is tailored to meet the unique requirements of the health community through use of application-independent language and simple interfaces. The unification of policy and credentials permits accountability, access control and permission management. One of the most attractive features of Trust Management is that IT security and privacy policy compliance is application-independent, unlike PKI (see below). This technology should be explored in more detail to further identify its potential for EHRs, and to identify potential weaknesses.

Public Key Infrastructures (PKIs)

Public Key Infrastructures are primarily a tool to validate the identity of individuals who require access to specific resources: files, e-mails, authorizations, etc. A valid identity then provides for an application to verify accountability for actions taken during the collection and processing of private information. This technology offers the advantage of being fairly well understood, and it is being implemented in a number of jurisdictions, including the federal government and a number of provinces. The information about individuals held in a PKI directory is itself a privacy concern, especially given the trend to provide more and more data about certificates and their holders.

PKIs require careful attention to governance and policy management, and rely on subscribers to maintain the confidentiality of their private keys. A number of new tools make registration and certificate issuance more straightforward. The number of applications that support PKI is growing, but it is probable that applications will need to be coded to accept encryption and digital signatures as well as permissions management and other tools. This technology merits further exploration to identify its potential for EHRs, and to determine whether certain privacy-unfriendly features can be neutralized or re-engineered.

Combined Solution

The most promising technology combination for EHRs appears to be a combination of Trust Management and PKI, possibly enhanced with smart cards and biometrics. PKI can supply many of the required safeguards such as strong encryption for confidentiality and digital signatures, and Trust Management design can propagate the certificates that are used by the access control components to enforce privacy-supporting practices. Some of the internal management tools that have been built into these types of systems can actually provide information about the privacy practices implemented as part of an application.

4.5. Recommendations

Detailed recommendations are not possible at this stage in the assessment of privacy technologies. The following recommendations in general are to follow those technologies that promise to address privacy requirements that can support the correct policy, and to reject those that cannot:

Recommendation 1: OHIH should explore Trust Management Systems and Public Key Infrastructure in some detail.
Recommendation 2: OHIH should consider the use of smart cards and possibly biometrics to enhance privacy where stronger limitations on access and other actions are required.
Recommendation 3: Where multiple identities are permitted, OHIH should consider the potential of using infomediaries.
Recommendation 4: The activities above should proceed in parallel with the development of the EHR concept so that technology and requirements can be developed together.

¹ Most organizations envision limits to patient access, such as requiring a health provider's guidance for access to specific information.

² The OECD adopted eight privacy principles. The Canadian Standards Association and Canadian legislation (the Personal Information Protection and Electronic Documents Act) identify ten. The U.K., the EU, New Zealand, Australian and Hong Kong legislation are similar. There is no national privacy legislation in the U.S.A. The American Health Insurance Portability and Accountability Act addresses privacy more as a function of confidentiality.

³ Used by the petrochemical industry to meet environmental guidelines: identifies potential hazards for each component in a process and identifies how to manage each hazard.

⁴ Privacy technologies are commonly referred to as Privacy Enhancing Technologies (PETs), and the authors use this more common term from vendor literature and privacy web sites.

⁵ A principal can be a physical entity, a process in an operating system, a public key, or any other convenient abstraction.

⁶ Further information is available at http://www.cis.upenn.edu/~keynote/Papers/rfc2704.txt.

⁷ Authentication can be one, two or three factor: something a person knows, something they have or something they are. Biometrics addresses the something that they are, e.g. a fingerprint, voice pattern, retinal scan. The standard biometric model matches a physiological or behavioural characteristic of a person to an established record of that characteristic. More sophisticated biometric technology uses a mathematical representation of a physical characteristic, such as a person's retina, and matches it by taking a digital sample of the biometric credential, the retina. Replay attacks are almost impossible, as the digital sampling should not be the same two successive times; a system can be programmed to reject the second or third consecutive identical reading.

⁸ For each applicable PET, the table notes the relevant feature, whether by design or other method such as policy, audit, use of another infrastructure, or other method that satisfies the requirement. Please note that where non-design methods have potential or partially satisfy a requirement the table may appear to contradict the tables in Section 2, where only design was normally commented on.

Annex A: Bibliography

General

The following web sites have good general information about privacy, and links to sites with more specific information. They are primarily U.S. sites that were established for privacy advocacy:

http://www.infosyssec.com/infosyssec/anon1.htm
http://www.epic.org/
http://www.privacyinternational.org/
http://www.privacyrights.org/

A Canadian site primarily for access to Canadian law: http://www.acjnet.org/security.cfm.
Industry Canada's e-commerce web site: http://e-com.ic.gc.ca/english/index.html.

The OECD site: http://www.oecd.org/dsti/sti/it/secur/

Anonymizing Technology

See the FAQ at www.w3.org/Security/Faq/wwwsf7.html.

A good general site is www.anonymizer.com.

Roger Clarke's site has interesting articles and references regarding privacy enhancing technologies and "privacy sympathetic technologies" at www.anu.edu.au/people/Roger.Clarke/DV/PEPST.html.

A list of members of the Information Technology Industry Council, and a good paper about Anonymyzing Technology is available at the ITIC web site: http://www.itic.org. The article is copied at Annex B.

http://www.wired.com/wired/archive/4.05/anonymizing_pr.html
http://www.cs.du.edu/~dm/login.html
http://www.zdnet.com/zdnn/stories/news/0,4586,2682476,00.html
http://www.usenix.com/publications/login/1998-5/martin.html
http://www.research.att.com/~lorrie/pubs/networker-privacy.html
http://www.webveil.com/
http://www.wired.com/wired/archive/4.05/anonymizing.html
http://www.hicss.org/HICSS_35/hcmini.htm
http://www.securityoutpost.com/
http://www.ihtml.com/tech/internet.htm
http://mixtersecurity.tripod.com/protecting.html
http://www.sciam.com/2000/1000issue/1000techbus2.html
http://www.ntk.net/
http://www.witsa.org/news/00aug.htm
http://www-swiss.ai.mit.edu/~bianca/swiss_html/users/pmitros/privacy-proto.html
http://anon.efga.org/WebProxies
http://grc.com/downloaders.htm
http://www.lucent.com/press/0697/970610.bla.html
http://www.softouch.on.ca/rc/cookies.htm
http://www.blj8.com/Privacy/index.html
http://www.it.kth.se/~aep
http://www.eros-os.org/~majordomo/e-lang/0363.html
http://www5.zdnet.com/pcmag/stories/opinions/

Platform for Privacy Preferences

The most complete site is the official site for P3P at http://www.w3.org/P3P/.

http://www.cpsr.org/program/privacy/p3p-faq.html
http://www.kcoyle.net/p3p.html
http://www.w3c.org/P3P
http://www.epic.org/reports/prettypoorprivacy.html
http://www.cdt.org/privacy/pet/p3pprivacy.shtml
http://www.research.att.com/projects/p3p/
http://p3ptestbed-1.w3.org/
http://www.wired.com/news/news/story/13242.html
http://www.zdnet.com/zdnn/stories/news/0,4586,2598004,00.html
http://cobra.law.miami.edu/~jb0437/paper.html
http://www.wired.com/news/news/story/12425.html
http://www.wired.com/news/news/technology/story/13242.html
http://www.builder.com/Authoring/P3P/?tag=st.bl.3884.dir1.7584
http://www.uni-siegen.de/security/datenschutz/p3p.html
http://www.anu.edu.au/people/Roger.Clarke/DV/P3POview.html
http://www.itrain.org/itinfo/2000/it000711a.html
http://www.zdnet.com/zdnn/stories/news/0,4586,2591856,00.html
http://www.w3.org/P3P/nutshell.html

Infomediaries and Identity Management Systems

The one page article, "Infomediaries and negotiated privacy techniques," by Dr. Alexander Dix, Commissioner for Data Protection and Access to Information for the state of Brandenburg, Germany at www.cfp2000.org/papers/dix.pdf, is a quick overview of infomediaries and P3P and privacy issues, with recommended links for further reading. It is copied to Annex D.

http://www.consciousbuyer.com/
http://www.epsltd.com/Infomediariesmain.htm
http://www.wired.com/news/news/story/18678.html
http://www.eff.org/bayff/20010319_bayff_announce.html
http://sunsite.icm.edu.pl/sunworldonline/swol-07-1999/swol-07-bookshelf.html
http://www.wired.com/news/news/story/18217.html
http://www.thestandard.net/article/display/0,1151,17328,00.html
http://simap.eu.int/EN/pub/docs/ernst/tsld022.htm
http://www.e-commercebc.net/ic_cap_1k.html
http://www.mikealix.com/tb000913.htm
http://www.canada-ecommerce.com/ic_cap_1k.html
http://www.cyberspaceattorney.com/ezine/privacy.htm
http://www.politechbot.com/p-01079.html
http://www.gladwell.com/1999_10_04_a_sleeper.htm
http://www.cfp2000.org/news/student_reports/infomed-muller.html
http://www.junkbusters.com/ht/en/cfp.html
http://simap.eu.int/EN/pub/docs/ernst/sld022.htm

Trust Management Systems

A complete description of the KeyNote Trust Management System: M. Blaze et al, "The KeyNote Trust-Management System Version 2, September 1999, at crypto.com/trustmgt/kn.html.

http://www.thethirdpower.com/index.html
http://citeseer.nj.nec.com/context/313424/23045
http://citeseer.nj.nec.com/chu-referee.html
http://www.senate.gov/~scia/hearings/730cobel.htm
http://www.cs.caltech.edu/~adam/papers/www/trust-management.html
http://www.w3.org/TR/REC-DSig-label/
http://link.springer.de/link/service/series/0558/bibs/1740/17400001.htm
http://firstmonday.dk/issues/issue3_6/khare/index.html
http://www.star-lab.com/new.html

Smart Card Technology

A good general explanation of smart card technology is available at smartex.com/smartcards_guide.html. For PC cards, see Bill Lempesis, "The Future of Smart Card Technology, March 1997, at http://www.smartcardcentral.com.

http://www.scia.org
http://www.smartcard.co.uk/
http://www.mac-gray.com/
http://www.smartex.com/
http://www3.goto.com/d/sr/
http://www.fusioncard.com/
http://www.microsoft.com/windowsce/smartcard/
http://www.securenet.com.au/
http://www.tricomcard.com/
http://smart.gov/
http://www.gemplus.com/
http://www.smartcardlaundry.com/smart_cards.htm
http://www.cyberis.fr
http://members.aol.com/pjsmart
http://www.publicard.com
http://www.roaster.com/news/jul97/0728/119.html
http://www.divdyn.com/
http://www.intellect.com.au/
http://www.smartcardforum.asn.au/smartcard.htm
http://www.smartcardhelp.co.uk/
http://www.inlucid.com
http://www.smartcardcentral.com/
http://www.globalplatform.org/
http://www.lifestreamtech.com/
http://www.precis-scs.com/
http://www.tatungtel.com/main1.html
http://www.magcard.com
http://www.sfgate.com/
http://www.macgray.com/
http://www.smartdev.demon.co.uk
http://www.cs.franklin.edu/Faculty/Giuliani/mba682/~mwalter
http://smartcard.a-card.com/index.html
http://www.labcal.com/smartsign.php3
http://www.smartcardclub.co.uk/

Biometrics

Tomko, Dr. George, "Biometrics as a Privacy-Enhancing Technology: Friend or Foe of Privacy? Privacy Laws & Business, 9^th Privacy Commissioners' Data Protection Authorities Workshop, 15 September 1998; See http://www.aliconferences.com/conferences/biometrics.htm.

For a list of biometric developers and integrators, see biodigest.com.
The U.S. Government site for biometrics is biometrics.org.

The Biometric Consortium
www.biometrics.org
U.S. government group focusing on biometric research. Site includes a useful introduction to biometric technologies, uses, and standards.

Biometric Encryption
www.emory.edu/BUSINESS/et/biometric/
Encyclopedia-like discussions of processes, purposes, and implementations of biometric technology.

1998 Glossary of Biometric Terms
www.afb.org.uk/glossuk1.html
Extensive list of terms commonly used in biometrics.

The Biometric Digest
webusers.anet-stl.com/~wrogers/biometrics/
Monthly publication providing biometric product news. Excellent page of hyperlinks to many biometric vendors.

The International Biometric Society

www.tibs.org
Academic society dedicated to exploring the mathematical and statistical aspects of biology.

The BioAPI Consortium
www.bioapi.org
Group formed to develop a standard API for biometric implementation. Discusses biometrics' market penetration and attempts to expand it.

Connecticut's Biometric Imaging Project
The state's Department of Social Services is implementing biometrics into its service-providing processes--a possible model for future large-scale implementations.

http://biometrics.cse.msu.edu
http://www.precisebiometrics.com/
http://www.biom.cornell.edu/
http://homepage.ntlworld.com/avanti/
http://stat.tamu.edu/Biometrics/
http://www.zdnet.com/complife/buz/9803/biometricid-6.html
http://www.infosyssec.net/infosyssec/biomet1.htm
http://www.afb.org.uk/
http://www.biometrics.co.za/
http://www.DataCaptureBiz.com/index.asp?page=SRhome.asp&OldDate=2/01/2001
http://www.banking.com/aba/cover_0197.htm
http://www.biometrics-scan.com/
http://www.iosoftware.com/about/employment.htm
http://mason.gmu.edu/~kwong/cs103/index.htm
http://www3.goto.com/d/sr/
http://www.digitalbiometrics.com/
http://www.appliedbiometrics.net/
http://www.biometricgroup.com/a_bio1/technology/research_a_technology.htm
http://www.livegrip.com/
http://www.egroups.com/group/biometrics/
http://www.biometricpartners.com/
http://www.iris-scan.com/
http://www.tibs.org/
http://www.biometricgroup.com/

Public Key Infrastructure

For information about Public Key Infrastructure in the Government of Canada, visit the Treasury Board Secretariat's PKI web site at http://www.cio-dpi.gc.ca/pki-icp/index_e.asp. The site includes FAQs, an overview of PKI, PKI policies and guidelines, and cross-certification information. For federal institutions, this site is the authoritative site about PKI. See also Annex H, Examples of Public Key Infrastructure, and the information from the PKI page (www.pki-page.org/). The IETF page includes information about international standards for PKI (www.ietf.org/).

http://www.ietf.org/html.charters/pkix-charter.html
http://verisign.netscape.com/security/pki/
http://www.itsi.disa.mil/pki/
http://oscar.dstc.qut.edu.au/
http://www.cert.dfn.de/eng/team/ske/pem-dok.html
http://www.certicom.com/
http://www.cse.dnd.ca/cse/english/gov.html
http://www.phaos.com/
http://www.pki-page.org/
http://www.counterpane.com/pki-risks.html
http://www.shym.com
http://www.rsasecurity.com/rsalabs/pkcs/index.html
http://www.authentic8.com/
http://www.infosyssec.com/infosyssec/secpki1.htm
http://www.certco.com/
http://www.usertrust.com/
http://www.dstc.qut.edu.au/MSU/projects/pki
http://www.dvnet.com/
http://www.infoseceng.com/corppki.htm
http://www.unicert.com/library/index.html
http://www.baltimore.co.uk/
http://www.entrust.com