sharing accountability for personal health information

Sharing Accountability for Personal Health Information A Privacy Toolkit to Support PHI Sharing

ii © Erie St. Clair Local Health Integration Network

Sharing Accountability for Personal Health Information: A Privacy Toolkit to support PHI Sharing

Acknowledgements

Consultants

This Toolkit was written and produced for the Erie St. Clair Local Health Integration Network by the following team from MD+A Health Solutions:

Edward McDonnell, Project Lead

Pat Jeselon, Senior Privacy Consultant

Blair Witzel, Privacy Consultant

Anita Fineberg, Privacy Consultant – Legal

Jeff Ibsen, Privacy Consultant – Technical

Trevor Grace, Project Coordinator

Steering Committee/Privacy Toolkit Working Group

We wish to acknowledge and thank the members of the Steering Committee and Privacy Toolkit Working Group who contributed to the development of this toolkit:

Steering Committee

Rodney Burns, Chief Information Officer and eHealth Lead, North Simcoe Muskoka LHIN

Gary Hurd, Senior Project Manager, PMO & eHealth, North Simcoe Muskoka LHIN

Dale Maw, Senior Manager eHealth Team, Waterloo Wellington LHIN

Paul Audet, Executive Lead, Consolidated Health Information Services, Erie St. Clair LHIN

Jody Wellings, eHealth Co-ordinator, Central West LHIN

Karen Waite, Chief Privacy & Security Officer, eHealth Ontario

Patrick Lo, Director of Privacy, eHealth Ontario

Neil Smith, Senior Project Manager, eHealth Ontario

Privacy Toolkit Working Group

Judy Farell, Integrated Director Health Information and Privacy, London Health Sciences Centre

Hilary Halliday, Regional Manager, Business Intelligence and Controller, South West Community Care Access Centre

Lesley Hoffman, Senior Director Client Services, Canadian Mental Health Association, Chatham-Ken Branch

Eric Hong, Director of Corporate Development, Yee Hong Centre for Geriatric Care

Karen Waymouth, Director of Health Records, Chatham-Kent Health Alliance

iii © Erie St. Clair Local Health Integration Network


Management

Toolkit development was managed by Paul Audet and Zoja Holman from Consolidated Health Information Systems on behalf of Erie St. Clair LHIN.

eHealth Ontario

We also wish to extend our appreciation to the input of eHealth Ontario for their time and efforts in reviewing the Toolkit:

Cindy Myers, Adoption Manager, Implementation & Adoption, eHealth Ontario

Neil Smith, Senior Project Manager, eHealth Ontario

Funding

The Ontario LHIN Privacy Project has been funded by eHealth Ontario for Ontario’s Local Health Integration Networks.

© 2011 Erie St. Clair Local Health Integration Network

iv © Erie St. Clair Local Health Integration Network


Disclaimer

• The resource materials provided in this Toolkit are for general information purposes only. They should be adapted to the circumstances of each Health Information Custodian using the Toolkit.

• The Toolkit is not intended, and should not be construed, as legal advice or professional advice and opinion.

• The description of the Personal Health Information Protection Act, 2004, in this Toolkit is based on the current information at the time of writing.

• The Toolkit should not be relied upon as a substitute for the Personal Health Information Protection Act, 2004, or its regulations. Provisions of the legislation were simplified for the purpose of identifying issues for consideration.

• The Toolkit refers to information available from other organizations and their websites.

• HICs/organizations concerned about the applicability of privacy legislation to their activities or the interpretation of the legislation are advised to seek legal or professional advice based on their particular circumstances.

v © Erie St. Clair Local Health Integration Network


Table of Contents

Section 1: Preface..................................................................................................................... 1

1 Introduction ...................................................................................................................... 2

Section 2: Introduction to Personal Health Information Privacy in Ontario ........................ 8

2 Introduction to Personal Health Information Privacy in Ontario ................................... 9

3 Understanding Your Role ................................................................................................ 21

Section 3: Health Information Management ....................................................................... 30

4 A Primer on Health Information ..................................................................................... 31

5 How You Share Information Now .................................................................................. 39

6 New Models for Sharing Client Information .................................................................. 40

Section 4: New Initiatives ..................................................................................................... 44

7 Integrating Privacy into Your Initiative ......................................................................... 45

Section 5: First Steps ............................................................................................................ 59

8 Governance and Accountability ..................................................................................... 60

9 Establishing Consent ...................................................................................................... 73

Section 6: Ongoing Privacy ................................................................................................... 85

10 Collecting, Using, and Disclosing PHI ........................................................................ 86

11 Managing Privacy Incidents and Complaints ................................................................ 95

12 Monitoring Compliance ............................................................................................ 104

13 Safeguarding PHI ....................................................................................................... 112

Section 7: Appendices .......................................................................................................... 125

Toolkit Tools and Templates ................................................................................................. 126

Glossary of Terms and Acronyms ......................................................................................... 129

1 © Erie St. Clair Local Health Integration Network


Section 1: Preface

In this section you will learn about:

• Intended audience for the Toolkit

• Goals of the Toolkit

• General terms used in the context of this Toolkit

• How to use the Toolkit



1 Introduction This Privacy Toolkit was prepared by the Ontario LHINs Privacy Project (OLPP) as a general guide to support Local Health Integration Networks (LHIN)-based health service providers in meeting their obligation to protect health information privacy, while effectively participating in eHealth projects or initiatives involving the exchange of personal health information (PHI).

With the introduction of the Personal Health Information Protection Act in 2004, health service providers were required to develop or update existing privacy initiatives to meet new standards for the handling and exchange of PHI. New concepts such as a health information custodian (HIC) and a health information network provider (HINP) were introduced. Through the support of other toolkits, for example the Ontario Hospital Association’s Hospital Privacy Toolkit and Community Care Information Management (CCIM) Privacy Toolkit, health care providers developed internal privacy programs to govern information handling and protect the privacy of clients and other individuals.

Since 2004, there has been a dramatic increase in the use of shared health information systems and eHealth solutions that involve multiple organizations. The concept of a client record that resides solely within a single organization or health care practice is evolving. There is increasingly shared accountability for PHI used in the course of treatment and care. Research by OLPP indicates that there is often significant confusion among health care providers about privacy roles and responsibilities in this new environment.

At the same time, the effective implementation and adoption of eHealth solutions are critical to supporting Ontario’s health system agenda and ensuring LHINs meet their strategic objectives as part of Integrated Health Service Plans.

Therefore, it is important that health service providers understand how to use new eHealth solutions to share or exchange PHI, and participate effectively in related initiatives while meeting privacy protection obligations in an inter-organizational environment.

This Toolkit and its resources can help you and your organization build upon your existing privacy program and feel more confident in participating in provincial, regional, and local eHealth initiatives.



1.1 Background to the Ontario LHINs Privacy Project

A joint eHealth Ontario-LHIN needs assessment process in fall 2009 identified a number of privacy management issues and needs common to numerous LHINs.

• Variation in privacy approaches slowing implementation of eHealth initiatives

• Lack of clarity on privacy roles: HIC, Agent, HINP, and other important roles

• Knowledge and capacity gaps creating “privacy fatigue” among HSPs

• Need for a common privacy vocabulary, practices, tools, and templates

• Lack of understanding of implications of cross-sectorial legislation (e.g., FIPPA)

• Challenges in dealing with other sectors such as support housing, education, and justice

Such gaps and needs were reinforced by research undertaken by OLPP prior to the development of this Toolkit. The research included an online survey of health service providers in all 14 LHINs, as well as direct consultation with major Ontario health service associations and eHealth delivery organizations.1 Among the key findings:

• Privacy has often been perceived as a barrier to PHI sharing among health service provider organizations

• Confusion exists about privacy roles and responsibilities in relation to eHealth

• Certain tools would be helpful, but having a “recommended” set of tools of resources would be especially beneficial

• Resources need to be “user-friendly” and meet the needs of a diverse audience with widely varying privacy and eHealth knowledge

• Certain sectors such as Mental Health and Addiction have different privacy concerns and sensitivities

• Resources need to serve a variety of PHI sharing patterns

To respond to these issues and needs, the Ontario LHINs Privacy Project was established and included the objective of creating a common set of privacy tools and resources that would be useful and available to health service providers in all major LHIN sectors:

• Hospitals

• Long-Term Care

1 Response rate and other relevant background to be added as footnote



• Community Care Access Centres

• Community Support Services

• Mental Health and Addiction

• Community Health Centres

These findings and other important insights gained through the survey and direct discussion with provincial and regional health service representatives and eHealth delivery organizations were critical to the design and development of this Toolkit.

1.2 Focus on PHIPA

This Toolkit is focused on helping health service providers meet their obligations under Ontario’s Personal Health Information Protection Act (PHIPA).

PHIPA and the associated regulation define the fundamental requirements that all health service providers must meet. These legislative requirements are further interpreted through Orders of the Information and Privacy Commissioner of Ontario (IPC), which has a mandate that includes responsibility for privacy protection and other obligations under PHIPA. Privacy requirements in specific situations are also informed by best practices and standards such as those proposed by IPC, the CSA Model Code for the Protection of Personal Information, COACH’s Guidelines for the Protection of Health Information, and Canada Health Infoway’s EHR Privacy and Security Requirements.

It is recognized that the LHIN health and community support service providers are potentially subject to a variety of privacy and other legislation which include the following:

• New Regulation under the Health Insurance Act, 1990: The Ministry of Health and Long-Term Care (MOHLTC) is proposing a new regulation under the Health Insurance Act, 1990 (HIA). The proposed regulation would give the MOHLTC the authority to disclose PI about physicians to eHealth Ontario for the purposes of providing electronic health services.

• Regulated Health Professions Statute Law Amendment Act, 2009: The Ontario government introduced legislation that, if passed, would improve access to health care for Ontarians by enabling a number of health care professions to provide more services and improve client safety.

• Health Protection and Promotion Act, Section 22.1: Section 22.1 of the Health Protection and Promotion Act (formerly “Bill 105”) requires the taking of blood samples to protect victims of crime, emergency service workers, Good Samaritans, and other persons.

PHIPA is of primary concern to most health service providers and health information custodians. It may be viewed as a “gold standard” in privacy legislation. If a health



organization or service provider meets its requirements—for example, in relation to consent—they generally will meet the requirements of other privacy legislation.

Therefore, this Toolkit and related reference material is centered on obligations under PHIPA while referencing how such obligations are affected when dealing with organizations that are not HICs and/or potentially subject to other privacy legislation.

1.3 Goals of the Toolkit

This Privacy Toolkit was developed to assist HICs and their agents effectively participate in programs that share PHI through electronic means with other HICs and non-HICs. It helps them to practice better privacy management through collaboration among the parties and securely safeguard PHI in their trust. The toolkit is also intended to reduce costs of the development and implementation of privacy solutions by using common tools and templates across all initiatives.

The Toolkit is not intended to replace your current programs, but to act as a resource to enhance your current programs as you begin to use health information technology or eHealth solutions to collect and share PHI.

After reading information in the Toolkit, each organization should conduct a review of how PI and PHI are collected, used, and disclosed within its organization. They should also consider whether policies and practices need to be modified to conform to current privacy principles and best practices.

This Toolkit provides guidance on how to begin meeting your privacy requirements for sharing information.

1.4 Who Should Use this Toolkit

Anyone responsible for overseeing information privacy and security within a health service provider or supporting organization should use this Toolkit. Anyone who is accountable for keeping information confidential and who manages privacy and security risks across multiple organizations would also benefit from this toolkit.

1.4.1 What the Toolkit Should do for You

Through use of the Toolkit and related tools, templates, and other resources you should be able to achieve the following:

• Reach agreement on data sharing and privacy obligations

• Understand your obligations under PHIPA as a HIC, Agent, or other role

• Maintain the privacy and security of health information



• Simplify the process of developing privacy documentation for eHealth initiatives

• Understand how to modify your existing privacy program to participate in eHealth initiatives

• Use a tool, template, or other resource to address specific privacy requirements

• Understand both mandatory requirements and best practices for inter-organizational privacy

• Identify your role in different PHI sharing or exchange situations

• Gain additional knowledge about the type of roles within an eHealth environment

• Supplement but not replace internal organizational tools and resources

• Recognize and reduce inter-organizational privacy and security risks

• Provide a secure environment for future health care applications

1.4.2 What the Toolkit Will Not do for You

• Replace the need for your existing privacy program and processes

• Provide legal advice on your obligations under PHIPA or other legislation

• Provide guidance on sharing PHI with organizations outside Ontario or Canada



1.5 How to Use this Toolkit

The Toolkit is divided into a number of main sections.

Section 1: Preface

Section 1 is a short discussion of the background and the purpose of the toolkit. It also provides some additional information and instruction on the use of the toolkit.

Section 2: Introduction to Personal Health Information Privacy in Ontario

Section 2 provides an introduction to health information privacy in Ontario, including a discussion of other provincial and privacy legislation that may apply. It also provides information to assist in understanding what role organizations are responsible for under PHIPA.

Section 3: Health Information Management

Section 3 is a primer on health information and discusses how shared information systems impact how health service providers share PHI amongst one another.

Section 4: New Initiatives

Section 4 describes how and when to integrate privacy into new health information sharing initiatives.

Section 5: First Steps

Section 5 outlines how to establish a strong foundation for the initiative by creating an appropriate governance and accountability model as well as an effective consent model.

Section 6: Ongoing Privacy

Section 6 discusses how to maintain privacy throughout the initiative from collection, use, and disclosure of PHI to managing privacy incidents and complaints and safeguarding PHI.

Section 7: Appendices

Section 7 provides the reference documents mentioned throughout the toolkit.

The templates/tools within this Toolkit should be adopted as a standard solution by health service providers in meeting their obligation to protect health information privacy, while effectively participating in eHealth projects or initiatives involving the exchange of PHI. Each section provides a link to where you can find the appropriate templates.



Section 2: Introduction to Personal Health Information Privacy in Ontario

In this section you will learn about personal health information privacy in Ontario, including:

• An overview of PHIPA and its supporting regulation

• Other provincial legislation that has privacy requirements

• Other privacy legislation that may apply to PHI

• Information about how health privacy legislation in Ontario is enforced

• Your organization’s roles and obligations under PHIPA



2 Introduction to Personal Health Information Privacy in Ontario Requirements and guidance for health information privacy in Ontario are defined through legislation, orders issued by the Information and Privacy Commissioner of Ontario (IPC), and best practice standards.

The Personal Health Information Protection Act, 2004 is the primary health privacy legislation that addresses issues of PHI in the province. PHIPA sets out minimum requirements for protecting the privacy of individuals and the confidentiality and security of their PHI within Ontario’s health system. PHIPA and its regulation also define specific roles and responsibilities in relation to the appropriate handling and management of PI. Other legislation, professional codes of practice, and regulatory guidelines are also relevant to certain health service providers in specific circumstances.

The Office of the IPC is the oversight body for PHIPA—ensuring that those subject to the Act comply with its provisions. As part of its mandate, the IPC receives complaints about PHI privacy breaches, and access and correction requests, as well as other matters related to the collection, use, or disclosure of PHI. The Commissioner can also investigate and make formal Orders related to PHIPA compliance and privacy breaches involving HICs and/or government agencies.

The Canadian Standards Association Model Code for Protection of Personal Information contains 10 privacy principles—often referred to as the Fair Information Principles. These principles are incorporated into PHIPA and other Canadian privacy legislation. They provide important guidance on addressing various aspects of privacy protection and PHI management. COACH’s Guidelines for the Protection of Health Information and Canada Health Infoway’s EHR Privacy and Security Requirements are also useful in that they provide best practices for privacy protection and PHI management.



2.1 Personal Health Information and Protection Act (PHIPA)

Since November 1, 2004, PHIPA has been the primary authority for PHI protection in Ontario. The Act defines how PHI should be collected, used, accessed, retained, transferred, disclosed, and disposed. The Act also defines how an individual should be provided with access to his or her own PHI, as well as gives an individual the right to correct this information.

The Act has a number of key purposes:

• To establish rules for the collection, use, and disclosure of personal health information about individuals, to protect the confidentiality of that information and the privacy of individuals with respect to that information, while facilitating the effective provision of health care

• To provide individuals with a right to access their own personal health information, and the right to correct or amend such information, except in limited and specific situations

• To provide for independent review and resolution of complaints related to personal health information

• To provide “effective remedies” for contraventions of the Act

PHIPA establishes several roles and responsibilities that an individual or organization can assume under the Act.

• Health Information Custodian – A person or organization that has custody or control of PHI as a result of their duties. HICs listed under PHIPA include health care practitioners, public hospitals, long-term care facilities, laboratories, pharmacies, Community Care Access Centres, Medical Officers of Health, and the Ontario Ministry of Health and Long-Term Care.

• Agent – A person or organization that has been authorized to act on behalf of a HIC in relation to PHI. Agents are often, but not always, employees and their responsibilities are the same whether or not they are being compensated.

• Service Provider2— A person or organization that supplies services to assist a HIC in using electronic means to “to collect, use, modify,

2O. Reg. 329/04 s6(1).



disclose, retain or dispose of personal health information, and who is not an agent of the custodian.”3

• Health Information Network Provider4—A person or organization that provides services to two or more health information custodians, where the services are provided primarily for HICs to use electronic means to disclose personal health information to one another.

As mentioned above, health care practitioners are included in the list of HICs in PHIPA. The legislation defines a health practitioner as:

(a) a person who is a member within the meaning of the Regulated Health Professions Act, 1991 and who provides health care,

(b) a person who is registered as a drugless practitioner under the Drugless Practitioners Act and who provides health care,

(c) a person who is a member of the Ontario College of Social Workers and Social Service Workers and who provides health care, or

(d) any other person whose primary function is to provide health care for payment

These roles and how to identify roles within your health information initiative is discussed in further detail in Section 3.

2.2 Ontario Regulation 329/04

A regulation was established under PHIPA to further define and extend key concepts contained in the Act. For example, the regulation:

• Extends the definition of health care to include blood donor activities

• Adds additional named HICs to the prescribed group

• Canadian Blood Services

• Minister of Health Promotion and Ministry of Health Promotion

• Municipalities operating ambulance communication services

3 The distinction between service provider and agent is sometimes unclear. However, a service provider is typically an entity that offers a generic service to clients to fill a very particular service need for a client (e.g., HIC). An example could be an Internet service provider. 4O. Reg. 329/04 s6(2).



• Excludes persons providing weight loss or fitness services from the definition of “health care practitioner”

• Defines which confidentiality requirements of other legislation would take precedence over PHIPA – including:

• Child and Family Services Act

• Regulated Health Professionals Act, 1991

• Remedies for Organizational Crime and Unlawful Activities Act, 2001

• Social Work and Social Service Work Act, 1998

• Workplace Safety and Insurance Act, 1972

• Defines the concept of a HINP and identifies related responsibilities

• Identifies requirements for eHealth Ontario to have various safeguards in place in relation to services that it provides and that involve PHI

• Establishes requirements for archiving medical records

• Elaborates further requirements related to research using PHI

As with the Act, the regulation is subject to change from time to time.



2.3 Other Provincial Legislation

There is other legislation in Ontario that, although not specifically focused on privacy, contains requirements related to the handling of PHI and maintaining client privacy. You should also be aware of other legislation that applies to your organization:

Legislation (and regulations) Applies to

Quality of Care Information Protection Act, 2004

Health care facilities in Ontario

Distinguishes “quality of care” information from PHI contained in a client’s record

Mental Health Act, 1990

• R.R.O. 1990, Regulation 741

Mental health facilities

Clients determined incapable of consenting to the collection, use, or disclosure of PHI under PHIPA must be provided a “rights advisor”

Public Hospitals Act, 1990

• R.R.O. 1990, Regulation 965

Publicly-funded hospitals

Requires the establishment of a system for the maintenance of client records of PHI

Long-Term Care Homes Act, 2007

• O. Reg. 79/10

Facility licensed by Ontario as a long-term care home

Prior to their posting or publication, certain inspection reports of the facility must be edited to exclude any PHI in order to protect the privacy of clients

Independent Health Facilities Act, 1990

• O. Reg. 57/92

Community-based health care facilities that are licensed by Ontario

A client cannot prohibit the licensee of the facility from including in the client’s record of PHI a written record of an order for an examination, test, consultation or treatment – i.e., a client may not place limit on his or her consent in these circumstances



2.4 Other Privacy Legislation

Other Canadian privacy legislation exists that may affect organizations and individuals involved in providing health care and related services. In some cases the legislation would relate to support service providers involved in community care delivery. In other instances it might affect vendors or commercial service providers of health service organizations.

The chart below identifies key federal and provincial privacy legislation. At a high level, it describes the type of information involved and who may be affected in the context of health service delivery.

Legislation Applies to May affect

Provincial privacy legislation

Freedom of Information and Protection of Privacy Act (FIPPA)

• PI collected, used, or disclosed by the Government of Ontario or its agencies

• Community support service providers

• Government agencies (e.g., eHealth Ontario)

Municipal FIPPA (MFIPPA)

• PI collected, used, or disclosed in the municipal public sector

• Municipal community or other support service providers

Federal privacy legislation

Personal Information Protection and Electronic Documents Act (PIPEDA)

• PI used for commercial activities

• Exchange of PHI between provinces or transfers out of Canada

• Private sector health and related service providers such as hospital catering services

Privacy Act • PI (including PHI) collected, used, or disclosed by the federal government or its agencies

• Department of Health (Canada)

• Public Health Agency of Canada



A number of principles and requirements are common across privacy legislation. Both the federal privacy legislation and Ontario provincial health privacy legislation rely heavily on the CSA Model Code and its 10 Information Fairness Principles.

As shown below, almost all major principles and requirements—such as consent, limits on use, right of access and correction, and oversight of privacy rights—are common to all three privacy laws that may affect health service providers in Ontario.

Principle/Requirement

PHIP

A

FIPP

A/M

FIPP

A

PIPE

DA

Based on CSA Model Code Y N Y

Consent for Collection, Use or Disclosure* Y Y Y

Limit Use to Original Purpose of Collection* Y Y Y

Right of Individual to Access and Correct Own Personal Information*

Y Y Y

Right of Individual to Make a Complaint Y Y Y

Oversight Body to Protect Individual Privacy Rights Y Y Y

Notification in Event of Privacy Breach Y N N

*Except in a few and limited circumstances.

As already noted, PHIPA can be considered the “gold standard” of privacy legislation. There are certainly differences between PHIPA, FIPPA/MFIPPA, and federal privacy legislation; however, if HSPs comply with PHIPA, they can generally assume that they have satisfied many of the requirements of other applicable privacy legislation.



2.5 Privacy Principles

PHIPA like most other privacy legislation is based on privacy principles that were originally developed internationally by the Organization for Economic Cooperation and Development (OECD). These principles were then used by the Canadian Standards Association to develop its Model Code for the Protection of Personal Information which outlines 10 privacy principles. It is important to note that the ten principles guide PHIPA, as well as the related requirements.

Privacy Principle5 Related Requirement(s)

Accountability Designate a contact person to assist you in meeting your privacy obligations, and to deal with any access requests, privacy related inquiries and complaints, and Commissioner investigations

Identifying Purposes Inform clients of the purposes for which their PHI is collected, used, and disclosed unless otherwise exempted by the Act

Consent Rely on implied consent, where appropriate, or obtain express consent from your clients when collecting, using, or disclosing their PHI unless otherwise exempted by the Act

Limiting Collection Limit your collection of PHI to that which is necessary for the identified purposes, or for purposes that the Act permits or requires

Limiting Use and

Disclosure

Limit your use and disclosure of PHI to the identified purposes, unless you obtain further consent, or your use or disclosure is permitted or required by law

Accuracy Take reasonable steps to ensure that your clients’ PHI is as accurate, complete, and up-to-date as is necessary for the purposes for which you use or disclose it

Tell the person to whom you disclose information of any limitations on the accuracy, completeness, or up-to-date character of the information

5 Chart adopted from the OHA Hospital Privacy Toolkit, Guide to the Ontario Personal Health Information Protection Act.



Privacy Principle5 Related Requirement(s)

Safeguards Implement appropriate technical, administrative, and physical safeguards to protect your clients’ privacy and the confidentiality of their PHI

Ensure staff and other parties are informed of privacy and confidentiality requirements

Openness Develop and make available a written statement of your information practices (e.g., your collection, use, and disclosure of PHI)

Access Give your clients access to and the ability to correct their personal health records in a timely manner

Challenging Compliance Develop simple complaint procedures to allow clients to challenge your privacy practices



2.6 Information and Privacy Commissioner of Ontario

The Office of the Information and Privacy Commissioner (IPC) of Ontario is the oversight entity of PHIPA and its application.

The IPC mandate includes:

• Review of the decision and practices of HICs in relation to PHI

• Review of the PHI policies and practices of other organizations

• Research and creation of health information privacy reference resources

• Public education on PHI laws and issues

The Commissioner has a number of key roles to fulfill its mandate, including investigating complaints related to PHI and reviewing policies and procedures to ensure compliance with PHIPA. As result of either the complaint process or reviews, the Commissioner may make Orders that direct a HIC to take specific actions to address PHIPA compliance requirements. The Commissioner’s Orders also provide useful general guidance to HSPs and HICs on how specific PHIPA requirements can be met and what best practice standards exist.

The IPC has issued a number of formal Orders in response to privacy complaints or incidents. These Orders provide interpretation and guidance on how PHIPA should be applied and implemented. While they have risen out of a particular incident involving a HIC, the Commissioner’s commentary or message frequently indicates the expectation that the order applies to all entities subject to PHIPA.

The IPC website (www.ipc.on.ca) contains helpful information and resources for HSPs and HICs seeking t0:

• Understand their role and responsibilities

• Manage specific privacy issues or concerns

• Research special topics or concerns

Anyone interested in health information privacy is encouraged to take advantage of this important set of reference material and resources.



Role and Mandate of the IPC Office

Ontario’s Freedom of Information and Protection of Privacy Act (FIPPA), which came into effect on January 1, 1988, establishes an Information and Privacy Commissioner (IPC) as an officer of the Legislature. The Commissioner is appointed by and reports to the Legislative Assembly of Ontario and is independent of the government of the day.

The term “freedom of information” refers to public access to general records relating to the activities of government, ranging from administration and operations to legislation and policy. It is an important aspect of open and accountable government. Privacy protection is the other side of that equation, and refers to the safeguarding of personal information held by government.

FIPPA applies to all provincial ministries and most provincial agencies, boards and commissions, as well as to universities and colleges of applied arts and technology. The Municipal Freedom of Information and Protection of Privacy Act (MFIPPA), which came into effect January 1, 1991, broadened the number of public institutions covered by Ontario’s freedom of information and privacy legislation. It covers local government organizations, such as municipalities, police, library, health and school boards, and transit commissions.

The Personal Health Information Protection Act, 2004 (PHIPA), came into force on November 1, 2004, and governs the collection, use and disclosure of personal health information within the health-care system. It is the third of the three provincial laws that the IPC oversees.

Together, these three Acts establish rules about how government organizations and health information custodians may collect, use, and disclose personal data. They also establish a right of access that enables individuals to request their own personal information and have it corrected if necessary.

The Commissioner plays a crucial role under each of the three Acts. In general terms, the Commissioner’s mandate is to:

• independently review the decisions and practices of government organizations concerning access and privacy;

• independently review the decisions and practices of health information custodians in regard to personal health information;

• conduct research on access and privacy issues;

• provide comment and advice on proposed government legislation and programs;

*



• review the personal health information policies and practices of certain entities under PHIPA; and

• help educate the public about Ontario’s access, privacy and personal health information laws and related issues.

The Commissioner delivers on this mandate by fulfilling seven key roles:

• resolving appeals when government organizations refuse to grant access to information;

• investigating privacy complaints related to government-held information;

• ensuring that government organizations comply with the Acts;

• conducting research on access and privacy issues and providing advice on proposed government legislation and programs;

• educating the public about Ontario’s access, privacy and personal health information laws and access and privacy issues;

• investigating complaints related to personal health information; and

• reviewing policies and procedures, and ensuring compliance with PHIPA.

In accordance with the Acts, the Commissioner has delegated some decision-making powers to her staff. Thus, the Assistant Commissioner (Privacy), Assistant Commissioner (Access) and other designated staff may issue orders, resolve appeals, and investigate privacy complaints.



3 Understanding Your Role PHIPA defines specific roles and responsibilities in regards to the handling and management of PHI. These roles and responsibilities distinguish the important differences between you and the various actors involved in your initiative. It also establishes what PHIPA requires of you, your organization and project partners. This section provides additional details about those roles and responsibilities and how you can identify your role as well as that of any partners.

PHIPA defines the following four roles:

• Health Information Custodian (HIC)

• Agent

• Service Provider

• Health Information Network Provider

The chart below provides an overview of the scope of these roles and their primary responsibilities. It also provides examples of related organizations and individuals.

PHIPA Definition of Health Care

PHIPA defines health care as any observation, examination, assessment, care, service or procedure that is done for a health-related purpose and that is carried out or provided:

• to diagnose, treat or maintain an individual’s physical or mental condition,

• to prevent disease or injury or to promote health, or

• as part of palliative care.

Health care also includes:

• making, selling or dispensing drugs, devices and equipment or other items by prescription, or

• providing a community service as described in the Home Care and Community Services Act, 1994.

This definition of health care may be important to determining whether a not a person or organization can be considered a custodian of PHI.

*



3.1 Health Information Custodians

PHIPA names specific “persons” as HICs including the following types of organizations and programs:

• Public hospitals and psychiatric facilities

• Mental Health and Addition Centres, Programs or Services

• A Centre, Program or Service for Community Health

• A Centre, Program or Service for Mental Health and Addiction


• Long-Term Care Facilities, Homes for the Aged, and Nursing Homes

• Pharmacies and Laboratories

• Independent health facilities

Where a HIC is an organization, then formally speaking its Board of Directors has ultimate responsibility as custodian of any PHI collected, used, or disclosed within the organization. In practice, organizations must name an individual within the organization as accountable for PHI and related activities. If the organization is also participating in an initiative related to PHI-sharing, the organization should also name a Privacy Lead who may or may not be the same person names as responsible for organizational privacy duties.

PHIPA defines health care practitioners as custodians. Such practitioners may be regulated health professionals as in the case of physicians, nurses, social workers, chiropractors, occupational therapists, and related positions. They may also be unregulated professionals such as mental health counselors and disabilities counselors as long as they are receiving payment for providing health care related services.

What may be different in the context of health information initiatives involving use of shared eHealth solution or health information system?

• More than one HIC could be accountable for PHI contained in the information solution or repository.

• A HIC may not be aware of the specific HICs or Agents that may have access to PHI as part of the initiative.

• Consent management features may be included as part of the information solution functionality.

• Many PHIPA requirements can be supported through technical controls



A few other points to note:

• Persons providing fitness or weight-management services are specifically excluded from the definition of “health care practitioner” for the purposes of PHIPA

• To be a HIC, an organization or individual must be providing health care as defined by PHIPA

• Health care has a specific meaning in the context of PHIPA

Where a HIC is an individual they would have individual and professional responsibility as custodian for any PHI collected, used, or disclosed in the course of their practice.

Specific responsibilities of custodians are outlined in the chart below:

PHIPA Role: Health Information Custodian

General Role and Responsibilities Related Organizations and Individuals

Person or organization with custody or control of PHI

• Ensuring consent is obtained for collection, use or disclosure of PHI

• Takes reasonable steps to safeguard any PHI

• Notification of individuals where PHI has been stolen, lost or accessed without authorization

• Ensuring PHI is accurate, complete and up-to-date as required

• Institutional or individual responsibility for privacy compliance

• Oblige Agents and Health Information Network Providers to meet PHIPA’s requirements

• Health care practitioners

• Hospitals and independent health facilities

• Homes for the aged and nursing homes

• Pharmacies

• Laboratories

• Home for special care



• Centres, programs or services for community or mental health



3.2 Agents

Agents are a very important part of handling and management of PHI. To the extent that they have been authorized by the HIC, an agent may collect, use, access, disclose, retain, or dispose of PHI on behalf of the custodian.

Common examples of agents that may be acting on behalf of a HIC are employees, health care practitioners (not acting on their own behalf), and third-party consultants or other service providers. An agent does not need to be compensated for the PHI handling or management activities that they perform on behalf of the HIC – for example, volunteers could be agents.

It should be emphasized that while an agent may act on behalf of a custodian, the agent should only do so to the extent that they have been authorized by the custodian and should only collect, use, access, disclose, retain, or dispose of PHI to the minimum extent necessary to perform their duties.

PHIPA also include other specific responsibilities of agents as outlined in the chart below.

PHIPA Role: Agent


Acts for or on behalf of a HIC

• Only collect, use, disclose, retain or dispose of PHI as authorized by the relevant HIC

• Only act within the course of the agent’s duties and not contrary to any limits imposed by the HIC

• Follow the privacy-related policies of the HIC

• Notify the HIC at the first possible opportunity if PHI is stolen, lost or accessed by an unauthorized person

• Hospital-based physicians

• Professional and administrative staff in:

o Hospitals

o CCACs

o LTC facilities

o Community support service agencies

o Community-based physician offices

o Certain provincial health and eHealth organizations



Custodians are responsible to ensure that their agents are aware of their responsibilities. A number of methods may be used to do so:

• Providing privacy and PHIPA education

• Establishing a privacy culture within their practice or other work environment

• Including a privacy component to performance review or management programs

• Ensure that staff and vendor contracts include provisions related to safeguarding of PHI and appropriate adherence to other privacy policies and practices6

Further discussion of methods for helping to ensure effective privacy management and appropriate handling of PHI can be found in section(s) 8 to 13.

3.3 Service Providers

Service providers as defined in PHIPA are individuals or organizations that provide services to assist a single HIC in using electronic means to manage PHI. The distinction between an agent and a service provider may not always be immediately clear. In general, service providers:

• Provide a specific dedicated service that supports use of electronic means for PHI

• Do not collect, use, or disclose PHI on behalf of the custodian

• Only use PHI for the purposes necessary to provide the relevant service

PHIPA has defined specific requirements for service providers as outlined in the chart below.

6 List adapted from CMHA Privacy Toolkit (2005)



The IPC has also provided some useful guidelines in relation to the use of service providers for the secure destruction of PHI. These guidelines can only be informative for the ways in which HICs contract generally with service providers – including looking for accredited or bonded vendors, and use of service level or other agreements.

PHIPA Role: Service Provider


Supply services to assist a HIC to use electronic means to manage PHI

• Only use PHI as required to provide services to the HIC

• Shall not disclose any PHI to which is has access as the result of providing services

• Shall ensure that employees or any other person acting on is behalf agree to comply with same restrictions

• Clinical information system vendor (e.g., hospital information system)

• External IT support services provider

• Regional shared services providers



3.4 Health Information Network Providers

HINPs are particularly relevant to eHealth and health information initiatives. HINP are similar to Service Providers except that they provide services to support two or more HICs to disclose PHI to one another using electronic means.

A number of provincial HINPs exist including eHealth Ontario and Cancer Care Ontario. A hospital, CCAC or other HSP may also be a HINP where it is hosting or managing an eHealth or health information solution being used by multiple other HSPs. Regional health data centres or digital imaging repositories are also typically HINPs. Finally, third-party vendors of health or clinical information solutions may also be HINPs where their solutions are being shared or used by multiple HINPs.

There are specific requirements of HINPs as outlined in the chart below.

PHIPA Role: Health Information Network Provider


Provide services to two or more HICs to enable use of electronic means to disclose PHI to one another

• Provide all relevant HICs with a plain language description of HINP services and relevant safeguards

• Provide all relevant HICs with descriptions and the results of privacy and security assessments undertaken and the results

• Make available to the public:

• HINP service and safeguard descriptions

• directives, guidelines, and policies related to its services to the HICs7

• general description of safeguards implemented to ensure security and confidentiality of information

• Upon the request of the HIC, and as reasonably practical in relation to information associated with

• eHealth Ontario

• Cancer Care Ontario

• Electronic Health Record solution providers

• Regional data centre or eHealth solution providers

7 Public information regarding directives, guidelines and/or policies related to its services to HICs can be restricted to those that “do not reveal a trade secret or confidential scientific, technical, commercial or labour relations information” PHIPA Regulation, s6(3)3



that HIC:

• All access to all or part of information

• All transfers of all or part of the information

• Notify every applicable HIC at the first possible opportunity if the HINP inappropriately accesses, uses, discloses or disposes of PHI

• Notify every applicable HIC if PHI is accessed by an unauthorized person

• Enter into agreement with each HIC that:

• Describes the services to be provided

• Describes related safeguards to protect confidentiality and security of information

• Requires the HINP to comply with PHIPA and its regulations



3.5 Who Are You?

Questions Role

• Are you a regulated health professional or unregulated health professional?

• Are you providing health care services as defined in PHIPA for compensation?

• Are you providing such services independently (not on behalf of another health care practitioner or health service provider such as a hospital)?

• Are you collecting, using or disclosing PHI as part of those services?

If you answered yes to all of these questions, you are likely a HIC.

The following LHIN organizations are all HICs:

• Hospitals

• Long-Term Care facilities



• MH&A programs, services and centres

• Do you work for or provide services to any of the previously identified LHIN organizations?

OR

• Are you a health care practitioner as defined in PHIPA providing services on behalf of another HSP?

• Do you collect, use or disclose PHI as part of your employment, volunteer activities, or the services that you provide?

You are likely an Agent.

• Do you provide services to assist a single health care practitioner or HSP manage PHI electronically?

• Is this a specific dedicated service such as Internet service provision, a clinical information system or IT support services?

You are likely a Service Provider.

• Do you provide services to assist multiple health care practitioners or HSPs to disclose PHI electronically?

• Is this a specific dedicated service such as data hosting, provision of a shared clinical information system, or IT support services?

You are likely a Heath Information Network Provider.



Section 3: Health Information Management

In this section you will learn the basics of personal health information, including what personal health information is and how to determine who is responsible for managing PHI throughout the information lifecycle.

You will also review the impact that electronic PHI-sharing initiatives has:

• Implications for your privacy program

• The concept of common records

• How to determine who is responsible for securing and managing common records

By the end of this section, you will be able to define your organization’s new model for sharing information.



4 A Primer on Health Information

4.1 What is Personal Health Information?

The actual scope of what constitutes PHI may not always be entirely clear. PHIPA applies specifically to PHI so it is important to understand what type of information is PHI and what is not. In Ontario, PHI is “identifying information about an individual” that relates to:8

• their physical or mental health including their related family history

• providing of health care including the identification of a provider of health care

• a service plan as defined by the Home Care and Community Services Act, 1994

• payment or eligibility for healthcare or healthcare coverage of the individual

• the donation of any body part or bodily substance or the result of the testing or examination of any such body part or bodily substance

In addition, an individual’s health number and information that identifies the individual’s substitute decision-maker are both PHI. Forms of PHI PHI can take many forms and can be:

• identifying information about an individual whether in written, oral, or spoken form.

• recorded in any medium including written, printed, photographic, electronic form, or otherwise.

Health records containing PHI may be found in the form of x-rays and digital images, computer media such as hard disk drives, and many other formats. Again the format is not as important – it’s the type and use of the information that defines whether it is considered PHI under PHIPA.

8 PHIPA, s.4(1)



About a Person PHIPA states that information must be about an individual person – as opposed to a corporation or some other legal entity – in order to be considered PHI. Living or Deceased

Information does need to be about a person who is living in order to be PHI. However, PHIPA no longer applies to PHI upon the earlier of: 9

• 120 years after the record containing the information was created; and

• 50 years after the death of the individual.

In other words, there will generally be a significant period after a person is deceased before all or part of their health records is no longer considered PHI subject to PHIPA. Identifying Information

As above, PHIPA requires that PHI must be “identifying information about an individual.” But what is identifying information?

Information such as name, certain photographic images, and address are easy to understand as identifying information. However, PHIPA takes a broader view and states that identifying information also means information– either alone or in combination with other information –that one could reasonably foresee being used to identify an individual.

HSPs must use judgment in assessing what information could be reasonably used either alone or with other information to identify an individual. Others have described various types of information as having different probability of allowing an individual to be identified:10

• Geographic location (e.g., location of residence, location of health event, especially where the location is not heavily populated);

• Names of health care facilities and providers;

• DNA and genetic samples;

• Rare characteristics of patients (e.g., unusual health condition); or

• Highly visible characteristics of the patient (e.g., ethnicity in certain locales).

9 PHIPA, s. 9(1) 10 See Guide to the Ontario PHIPA, page 76, 77 which references CIHR Guidelines for Protecting Privacy and Confidentiality in the Design, Conduct and Evaluation of Health Research: Best Practices Consultation Draft



As there is no “hard and fast” rule, HSPs should apply PHIPA principles and concepts against the specific circumstances to determine whether the information involved can be considered identifying.

De-identifying Information

De-identified PHI involves aggregate or collections of information used for health system reporting, practice surveillance, quality assurance, and supporting research efforts. LHIN HSP organizations are currently involved in related activities to track wait times; health outcomes in areas such as chronic disease management, and mental health and addiction; and, system performance and efficiency.

Canadian Institute for Health Information: De-identification processes11

Such processes include but are not limited to:

• Removal of name and address, if present; and

• Removal or encryption of identifying numbers such as personal health number and chart number;

and may also involve:

• Truncating postal code to the first three digits (forward sortation area);

• Converting date of birth to month and year of birth, age or age group; or

• Converting date of admission and date of discharge to month and year only; and then:

• Reviewing the remaining data elements to ensure that they do not permit identification of the individual by a reasonably foreseeable method.

• Methodologies, standards and best practices, in addition to those listed above, may evolve and be developed from time to time and followed, as appropriate, to de-identify personal health information.

11 Canadian Institute for Health Information, Privacy Policy on the Collection, Use, Disclosure and Retention of Personal Health Information and De-Identified Data, 2010, p. 6

*



De-identifying PHI is not as simple as removing individual names or addresses. To be properly de-identified HICs must assure themselves that they have removed any information that can be reasonably anticipated – either alone or in combination with other information – to identify the individual.12

Most information that is referred to as “anonymized” is simply de-identified to some degree. The strength of the de-identification algorithms is often poor. For secondary use (i.e., research) purposes, stronger algorithms are required to prevent re-identification attacks on pseudonymized or de-identified data sets. Any algorithms or processes should be carefully reviewed by individuals with appropriate expertise in re-identification of PI/PHI because the algorithms can sometimes be reversed to re-identify the information.

Truly anonymized information is usually of little use for testing purposes, except for some types of performance and scalability testing. Pseudonymization preserves the uniqueness of client records, but removes or obfuscates the information that allows an individual to be positively identified. Pseudonymization is usually reversible and the client may be re-identified if necessary (e.g. for communicable disease notification purposes).

Mixed Records PHIPA states that identifying information that is not normally considered PHI becomes PHI when it is contained in a record that includes PHI.13 For example, patient financial information or demographic information such as ethnicity, nationality or religious affiliation may be collected for purposes not directly related to providing healthcare. As long as such identifying information is contained in the same record, it must be considered as PHI and managed accordingly.

Remember! All information recorded in the patient chart is PHI even if it

isn’t health-related (e.g., religion)!

12 PHIPA s. 47(1) 13 PHIPA s. 25(3)



Employee or Agent Information

One final area worth highlighting is identifying information related to employees or other agents of a HIC. As an employer, a custodian may keep records of health-related information such as disability accommodation needs, workplace safety claims, or occupational illness.14 Where such information and the related records are primarily maintained for purposes other than provision of health care to the employee or other agents then it would not be considered PHI. Therefore, it would not be subject to PHIPA.

4.2 Who owns PHI and the health record?

It has been well-established that an individual has a fundamental right of access to information contained in medical or health records. In 1992, the Supreme Court of Canada ruled that in the absence of legislation to the contrary, a patient may request to examine and copy all information in their medical record.15 The court clarified that ownership of the “physical medical record” belonged to the physician.

Supreme Court of Canada Ruling

In the absence of legislation, a patient is entitled, upon request, to examine and copy all information in her [or his] medical records which the physician considered in administering advice or treatment, including records prepared by other doctors that the physician may have received. Access does not extend to information arising outside the doctor-patient relationship. The patient is not entitled to the records themselves. The physical medical records of the patient belong to the physician.

The court also stated that access may only be restricted where the physician has “reasonable grounds” for doing so. Among the circumstances the court identified were where records might be harmful to the patient or a third-party, where records might be misinterpreted, or where records might be meaningless. These circumstances were not intended to be comprehensive and any restriction on providing access would need to be justified based on reasonable grounds. PHIPA has clarified the principles identified in the Supreme Court ruling. As further discussed in Section 10, PHIPA states that an individual must be provided access to

14 Guide to the Ontario PHIPA, p. 85 15 McInerney v. MacDonald, [1992] 2 S.C.R. 138

*



PHI about themselves except in specific circumstances. Such circumstances include where the record or information:16

• Could result in a risk of serious harm to the treatment or recovery of the individual, or a risk of serious bodily harm to the individual or another person

• Is subject to legal privilege or prohibited from being released under Ontario’s FIPPA or MFIPPA legislation or other Canadian law

• Could lead to the identification of an individual who was required by law to provide information in the record or who provided the information in confidence and the custodian considers it appropriate that the identity of the individual be kept confidential

Where an individual is not prohibited from accessing all of the information contained in a record, the HIC must provide access to other parts of the record that “can be reasonably severed.”17

4.3 Custody or Control versus Possession in an eHealth Environment

Does accountability and rights of use change in our current Ontario healthcare environment where records are increasingly not “physical” in the traditional sense and an individual’s health record may be contained in an EHR or eHealth repository that combines PHI from a wide variety of custodians?

The answer relates to the difference between “custody or control” and “possession”. A HINP may have physical possession of multiple health records from multiple HICs; however, the custodian retains custody or control of such records and the PHI that they contain. Therefore, the records continue to be controlled by the custodian or HCP that collected the PHI originally and that HIC is responsible for managing requests from individuals for access to PHI about themselves.

16 PHIPA s.52(1) 17 PHIPA s.51(2)



The HINP and other parties involved in the maintenance of EHR or other eHealth solutions should have established practices or protocols as part of their service arrangements with HICs. Such arrangements including those related to access should be documented in an SLA or other similar agreement.

Factors for Determining Custody and Control

In Order PO-1725, the Assistant Commissioner wrote18:

Consideration of the following factors will assist in determining whether an institution has “custody” and/or “control” of particular records:

• Was the record created by an officer or employee of the institution?

• What use did the creator intend to make of the record?

• Does the institution have possession of the record, either because it has been voluntarily provided by the creator or pursuant to a mandatory statutory or employment requirement?

• If the institution does not have possession of the record, is it being held by an officer or employee of the institution for the purposes of his or her duties as an officer or employee?

• Does the institution have a right to possession of the record?

• Does the content of the record relate to the institution's mandate and functions?

• Does the institution have the authority to regulate the record's use?

• To what extent has the record been relied upon by the institution?

• How closely is the record integrated with other records held by the institution?

• Does the institution have the authority to dispose of the record?

Two broad principles emerge from the Commissioner's orders dealing with the issue of custody:

18 Information and Privacy Commissioner of Ontario. Order PO-1725, Cabinet Office. Appeals PA-9901177-1, PA-990118-1, PA-990076-1. 4 November 1999. Available online at http://www.ipc.on.ca/images/Findings/Attached_PDF/po-1725.pdf

*



• The first is that bare possession does not amount to custody, absent some right to deal with the records and some responsibility for their care and protection (Order P-239).

• The second principle is that "... physical possession of a record is the best evidence of custody, and only in rare cases could it successfully be argued that an institution did not have custody of a record in its actual possession" (Order 41)….”



5 How You Share Information Now PHI-sharing has typically occurred in the past between two health service providers or organizations which have released PHI to one another. One organization actively provides PHI on a particular client to another organization. One organization discloses PHI and one organization collects it. This may be repeated with multiple clients or with multiple organizations but is essentially a one-to-one relationship. These PHI-sharing scenarios are repeated regularly within the healthcare system – for example, in such instances where hospitals discharge patients and send them back to their family physicians with a discharge summary, where CHCs send their patients to allied health professionals for supporting services, and similar scenarios.

The defining characteristic of this relationship is that whether the sharing occurs on paper, verbally, or electronically, each organization maintains its own copy of the patient record and is therefore accountable for it. Each organization has custody and control over its own copy of the patient record and each is accountable for its own copy. Neither organization is accountable to one another in terms of how they manage patient information; each is accountable for its own compliance with PHIPA and privacy best practices.

In terms of privacy, this scenario means that each organization will have its own enterprise privacy program which includes policies, procedures, and so forth. The programs would be entirely separate from one another and there would be no meaningful collaboration between the two.

Figure 1 –Traditional PHI Sharing Model Examples



6 New Models for Sharing Client Information Newer information technologies and paradigms have begun to change the way that information is stored and disseminated. Information is often aggregated into central databases because it makes it easier to support and can facilitate sharing the information among many parties. Healthcare is no different. Ontario’s eHealth agenda is focused on establishing shared information services that enable multiple healthcare organizations to have access to clients’ records. The shared information services allow the HICs to more easily share and disseminate information with one another.

A key difference between this new model and the previous model of sharing information is that multiple HICs may share accountability for information in a single repository. Multiple HICs may have collected the PHI and have custody of it. One cannot identify a single HIC as the custodian over all of the PHI. Consider an electronic health record which aggregates PHI from multiple providers. The client’s record may include PHI from the local hospital, a specialist, a family physician, and allied health professionals. Who is the custodian of this record? They all are. They are all custodian for the PHI that they collected in the first place.

6.1 Implications for Your Privacy Program

New models of PHI sharing impact how information is stored and accessed because PHI may now be stored in a shared information repository to which multiple HICs have access. This presents challenges for an organizational privacy program because the organization must now work with several other HICs to ensure that PHI and privacy is protected equally by all parties. No longer is just one organization accountable for the PHI, but all are practically accountable for ensuring that PHI and client privacy are protected. They share accountability for privacy. Therefore, the organizational privacy program can no longer act as silos with no relationship to one another. The programs need to integrate and interact with one another to ensure protection of PHI and client privacy across the initiative.

You will need to supplement your current privacy program to adequately address how it works with others in protecting PHI and privacy. How will your organization handle an access request to a shared information repository that contains PHI collected by another HIC? You can provide an individual with access to the PHI that your organization collected, but can you provide the individual with access to PHI collected by other HICs? How about providing access to your staff? You may feel that your administrative personnel need access to PHI, but other organizations might restrict access only to regulated health professionals. Any initiative involving shared PHI repositories requires a common approach to privacy across all of the organizations. The organizations can either establish common policies and procedures with respect to the shared PHI or they can all agree to establish a minimum privacy benchmark that all organizations must meet. Either way, your organization will



likely have to modify its privacy program to participate in initiatives with shared PHI repositories.

Below you will find some examples of shared information services initiatives to which you may belong.

6.2 Multiple Organizations Contributing to a Common Record

Description

Multiple HICs and potentially non-HICs sharing PHI in a repository managed by a third-party technology vendor (i.e., HINP)

Implications for Privacy

• Shared accountability for PHI in record

• Requires governance model to establish minimum privacy standards and approach including:

• Data Sharing Agreements

• Shared policies and procedures

• Privacy decision making

• Relationship with HINP

• Requires collaboration among HICs to address complaints and breaches in particular

• Individual HICs required to have agreements with the HINP



6.3 Two Organizations Contributing to a Common Record

Description

Two HICs sharing PHI in a repository managed by a third-party technology vendor (i.e., HINP)


• Reflects privacy implications of above scenario



• Data Sharing Agreements



• Relationship with HINP

• Requires collaboration between HICs to address complaints and breaches in particular

• Individual HICs required to have agreements with the HINP



6.4 Multiple Organizations Contributing to a Common Record Hosted by a HIC

Description

Multiple HICs sharing PHI in a repository managed by another HIC on behalf of the group. The HIC providing the shared information services has physical custody of the information but the PHI was collected and is controlled by all of the HICs.


• HIC providing the shared information services also acts as a HINP (most likely)



• Data Sharing Agreements (including clauses specific to the HIC operating as a HINP)



• Requires collaboration between HICs to address complaints and breaches in particular



Section 4: New Initiatives

In this section you will learn how and when to build privacy into your initiatives. This section will discuss:

• The relationship between privacy and the project lifecycle

• Conducting privacy impact assessments for the initiative

• Creating privacy requirements like you would any other business or user requirements

• Conducting a readiness assessment for new organizations interested in participating in the initiative

By the end of this section, you will understand the key tools required to design privacy into your initiative and where to put those in your project plan.



7 Integrating Privacy into Your Initiative When designing a new initiative, organizations generally follow a basic process—define the need, design a product or service to address that need, then create and deploy the product or service and manage its operations going forward. This process is followed whether you are creating a new software application or developing a new out-patient care initiative. Privacy needs to be considered at the conceptual stage of the initiative and carried forward through design to implementation and operations.

You should be designing your systems with respect for client privacy as a core foundational requirement. Privacy must persist throughout the lifecycle of your initiative—whether it is a program, service, or information system—to ensure that PHI is appropriately collected, used and disclosed by authorized persons, and securely retained and then securely destroyed at the end of its life. Conducting a Privacy Impact Assessment (PIA) early on in your initiative identifies privacy risks that need resolution and makes recommendations that mitigate those risks. PIAs ensure privacy is embedded into the entirety of the initiative from its beginning.

Ontario’s Information and Privacy Commissioner stresses the importance of addressing privacy interests and concerns from the very beginning of an initiative. The Privacy Commissioner developed the concept of Privacy by Design (PbD) to address the growing and systemic effects of information technology and large-scale networked infrastructure.19 Privacy by Design advances the view that the future of privacy cannot be assured solely by compliance with legislation and regulatory frameworks. Rather, privacy assurance must ideally become an organization’s default mode of operation.

Privacy by Design refers to the concept and methodology of embedding privacy into business practices, technology, and physical design and infrastructure such that privacy is a default across the entire business and information lifecycle. The seven foundational principles of Privacy by Design set out how to proactively make privacy the default mode of operation, while maintaining full security and technical functionality. Embedding privacy into the design and architecture of your information technology systems is particularly important for large, complex systems that involve multiple organizations sharing accountability for a client record.

Remember! Build privacy into the beginning of your initiative by

developing privacy requirements!

19 See www.privacybydesign.ca



A privacy program helps to ensure appropriate information handling practices and protection of PHI. This section describes how developing a privacy program for your initiative matches the process steps of a standard project lifecycle—not requiring much additional effort on your part, but simply being part of the usual activities that you would conduct to establish a new initiative.

This section also looks at PIAs and when they should be conducted during the project lifecycle. At the end of the section, you will find a link to a PIA template to help you when conducting PIAs for PHI-sharing initiatives.



7.1 Terms You Need to Know

Term Definition

Privacy by Design A concept to address the ever-growing and systemic effects of Information and Communication Technologies, and of large-scale networked data systems.

Source: Privacy by Design, the 7 Foundational Principles (www.privacybydesign.ca)

COACH Canada's Health Informatics Association. COACH was formed in 1975 by several health professionals and vendors in the medical industry, to share ideas and efforts to enable Canadian health institutions to effectively use information technology and systems. The focus has since expanded to include the effective use of health information for decision-making.

Source: www.coachorg.com

Canada Health Infoway Infoway is an independent not-for-profit corporation created by Canada’s First Ministers in 2001 to foster and accelerate the development and adoption of electronic health record (EHR) systems with compatible standards and communications technologies. Funded by the Government of Canada, Infoway works with the country’s ten provinces and three territories to implement private, secure EHR systems, and enable best practices and successful projects in one region to be shared or replicated in other regions.

Source: www.infoway-inforoute.ca

Privacy Impact Assessment (PIA)

A PIA is a formal risk management tool used to identify the actual or potential effects that a proposed or existing information system or initiative may have on individuals’ privacy. A PIA also identifies ways in which privacy risks can be mitigated.

Source: Privacy Impact Assessment Guidelines for the Ontario Personal Health Information Protection Act, IPC, Ontario



Term Definition

Threat and Risk Assessment

(TRA)

Generally defined as a formal assessment of the security posture of a health application. A TRA follows specific methodology. The amount of detail required for a TRA depends on the stage of development of the health application. Refer to eHealth Ontario’s Guide to Information Security for the Health Sector for detailed information on security and risk management.

Source: eHealth Ontario Guide to Information Security for the Health Care Sector - Information and Resources for Complex Organizations

7.2 What PHIPA Requires

PHIPA ss10, 12, and 13 discuss requirements related to information handling and the protection and security of PHI. In summary, HICs are required to establish information practices that comply with PHIPA, and HICs must comply with their own information practices. PHIPA also requires that HICs take reasonable steps to secure the records. Further, Agents, HINPs, and Service Providers are to follow same. Ontario Reg. 329/04 s6 (3) 5. further requires that health information network providers make available to the HIC a copy of privacy and security assessments conducted on their services.

PHIPA sets out the information management practices that a HIC must have in place. It does not speak to privacy by design - this is a methodology that addresses risks identified by a PIA and ensures recommendations are practical and specific for business practices, technology systems, and physical space and infrastructure. PbD helps ensure compliance with PHIPA, but goes further than just policies and procedures.

7.3 What You Should Do

To integrate privacy into your project lifecycle, you must make privacy a core role in the design and architecture of your technology systems and business practices. Privacy protection must be built into your project’s basic work plan. Building privacy into your work plan from the outset of any initiative does not negatively impact your workload. In fact, if it is done at the outset, expensive retro-fits may be avoided. Privacy experts should be included in the project team to provide input, monitor the project compliance with PHIPA, and identify any privacy risks at an early stage.

PHIPA Sections

ss10, 12, 13



The following privacy fundamentals should be considered when designing your information sharing projects.

• Ensure clients rights are respected by building privacy into your project at inception

• Establish privacy policies that are simple, clear, and concise

• Build trust with clients by providing transparency with your information systems, and communicating openly about privacy matters—provide public written statements, descriptive brochures, and simple to use forms

• Provide privacy training on a regular basis to ensure staff is knowledgeable about privacy matters and respects the privacy of clients’ PHI.

The table below illustrates how privacy protection can be incorporated logically into your project’s natural process steps.

Key Project Activities Example Privacy Activities

Pre-Project

• Developing the business case

• Developing the concept

• Developing the Conceptual Privacy Impact Assessment

Project Initiation

• Creating the Project Charter

• Establishing the project team

• Identifying privacy subject matter experts for team

• Identifying privacy-related deliverables

Discovery and Design

• Defining the business, functional, and technical requirements

• Designing the products or services

• Establishing privacy requirements

• Designing privacy operations

• Conducting design-level PIA

Development

• Creating and testing the products and services

• Developing policies

• Creating operational plans

• Establishing governance structures to oversee operations

• Developing privacy-related policies and processes



Key Project Activities Example Privacy Activities

Deployment

• Piloting the initiative

• Training people

• Deploying the products and services

• Privacy awareness training • Establishing agreements • Communicating with patients

Operations

• Transitioning to ongoing operations

• Operating the initiative

• Obtaining consent • Managing complaints • Monitoring compliance • Evaluating privacy compliance and

effectiveness

7.3.1 Conducting Privacy Impact Assessments

A PIA is a risk analysis tool that is used to identify risks that an initiative poses to client privacy and the confidentiality of PHI. The PIA provides recommendations designed to reduce or eliminate these privacy risks based on PHIPA obligations or best practices. It focuses issues such as project governance, policies and other accountability mechanisms, PHI handling, and privacy operations among other issues related to the processes or technology.

PIAs have traditionally been written from the perspective of a single organization—examining how a single organization collects, uses, discloses, retains, and disposes of information. With more focus on sharing PHI between organizations, PIAs need to take a broader view of information flows and accountability structures. The PIA now must include assessing internal processes of participating organizations that share in the accountability and responsibility for protecting the privacy and confidentiality of PHI.

A PIA should be executed at four points during your project process. The difference in these PIAs is the level of detail available at the different stages of the project.

As your project starts When you start your project lifecycle, you should conduct a Conceptual PIA to examine the high-level design of the initiative within the lens of privacy legislation and policy, and to identify possible risks to privacy associated with the initiative. The initiative’s design should consider the recommendations of the conceptual PIA. The PIA provides high-level mitigation strategies to reduce or eliminate the privacy risks and can be used to formulate technical and functional requirements for procurement, or design of



information systems, and the design of programs and services, inclusive of policies and procedures and agreements.

While developing the initiative

After the governance model (policies and procedures and agreements), operational business model, and the technical solution for the project are designed, you should conduct a Design-Level PIA (also known as a Logical or Physical PIA) to review the work from the perspective of the Conceptual PIA. A Design PIA ensures the previous risks were mitigated in the design, and that no new risks were created. If risks still exist, recommendations are made in the Design PIA to resolve the risks or gaps.

After the initiative goes into operation

Once the initiative goes into operation and is functioning, you should conduct an Operational PIA (also known as an Implementation PIA), which looks at how the initiative is actually implemented, and identifies privacy risks associated with the initiative.

When significant changes occur

If there are significant changes to the business processes or technology used to support your initiative, privacy may be impacted. Conducting a Delta PIA identifies any new privacy risks or mitigation strategies that may be required due to the changes in your initiative.

7.3.2 Defining Privacy Requirements

Many people think that designing privacy into their projects means just conducting the PIA. However, privacy should also be considered when developing the business, functional, and technical requirements for the initiative. You should consult with a privacy expert during the requirements definition phase like you would any other subject matter expert. This person can help you define the privacy requirements that your initiative must meet after it has been delivered.

Sources for Privacy Requirements

• Privacy legislation (e.g., PHIPA, O. Reg. 329/04)

• IPC/Ontario’s interpretation of privacy legislation

• Your organization’s privacy-related policies

• Other best practices (e.g., PbD, CSA Model Code for the Protection of Personal Information)

• Canada Health Infoway’s Electronic Health Record (EHR)Privacy and Security Requirements



7.3.3 Establishing Measurable Benchmarks

It is also important to establish benchmarks to evaluate the effectiveness and efficiency of your privacy program. Some benchmarks are clear. For example, a marker of a good privacy program is not that few clients had their PHI inappropriately disclosed. A good marker is that no clients had their PHI inappropriately disclosed. Establishing an achievable target is important, and for some organizations this may be somewhat iterative in nature.

Other benchmarks related to initiating privacy into your operations are often harder to quantify and you will need to be more creative in how you measure success. Define benchmarks that make sense for your initiative and establish mechanisms to measure them.

7.3.4 Developing Privacy Business and Technical Solutions

After you establish the privacy requirements for your initiative, you need to develop the privacy business and technical solutions that will fulfill the requirements. This should occur concurrently with the development of the system functionality. The privacy business and technical solutions could be assigned to a working group of the project committee or to a team in the Privacy Office.

Privacy business and technical solutions fall into the broad categories listed below. Each of these is explained in greater detail within this Toolkit and many have associated tools/templates to help guide you with their development.

Governance and Accountability

• The governance model used to resolve problems and decisions about the privacy issues and practices associated with an initiative.

• Agreements that you must have in place among the HICs and with the other parties, for example, HINPs, agents, and service providers. (e.g., data sharing agreement, service level agreement).

• Policies and procedures that govern how PHI is collected, used, disclosed, and handled.

Potential privacy benchmarks include:

• Number of privacy complaints received

• Average length of time to complaint resolution

• Percentage of end-users trained on the system prior to being given access

• Number of questions received related to the privacy program

• Score of end-users on a quiz related to privacy awareness and practices



• Process for monitoring that staff complies with privacy program.

• Protocols for managing privacy and security incidents and public complaints about your information management practices.

Consent Management

• Consent model for the project (e.g., implied versus express).

• Process for informing clients on how you are using and disclosing their information, for example, written public notices.

• Process related to managing consent in the initiative, for example, how is consent recorded?

• Process related to managing consent directives, for example, what happens if clients want to withdraw their consent for using or disclosing their information?

• Communications plan and materials addressing disclosures.

• Technology to support managing consent and consent directives.

Privacy Operations

• Harmonized procedures for protecting PHI between HICs; between HICs and HINPs or Service Providers.

• Harmonized procedures for managing privacy and security incident handling and complaints management; and individual requests for access and correction.

• Training materials to provide end-users with privacy and security awareness in relation to their responsibilities to protect PHI, and how to use the privacy functionality of the system, e.g., creating a consent directive, including signing of a confidentiality agreement and/or acceptable use statement.

• Communications strategies and materials to inform clients about the initiative and of the purposes for collection, use, and disclosure of PHI (as it relates to the specific initiative); how to withdraw consent; how to file a complaint, how to request access to and correct information; and, the contact information of the privacy contact person (i.e., privacy lead).

• Policies and procedures for retention and destruction of PHI.

Technical Safeguards

• Technical safeguards built into the system to support PHI sharing.

• Security policies to guide PHI protection.

• Access management controls, e.g., password management, user authentication, and user permissions and privileges.



• Logs and reports to help inform monitoring compliance.

• Encryption of PHI at rest and in motion.

• Secure users’ workstations.

Monitoring and Compliance

• Privacy metrics/benchmarks that must be met by the organization.

• Progress toward achievement of metrics and report outcomes reported to executive, board of directors, and to staff.

• Procedures for the regular review of audit log reports by accountable persons.

• Regular review of third party agreements.

• Requirements for ongoing mandatory privacy and security awareness and training for all staff/agents and the signing of confidentiality agreements and/or acceptable use statements.

• Regular self-administered readiness assessments completed by all parties to an agreement.

7.3.5 Conducting a Readiness Assessment

A Readiness Assessment (also known as a gap assessment) is a tool used to assess the gap between what is required for a particular initiative (e.g., legislation compliance, standard policies and procedures), and what your organization is currently practicing. It is typically conducted when two or more HICs are routinely sharing PHI with one another. The disclosing (or originating) HIC(s) uses this tool to establish the state of privacy practices of the receiving HIC prior to entering into a DSA with the HIC. A readiness assessment should be refreshed from time to time.20

The contents of the Readiness Assessment vary depending on the initiative, but it is typically a list of questions that summarize the key privacy policies and procedures that the organizations must have in place prior to being given access to PHI. The assessment establishes the minimum criteria for the organization’s privacy program.

20 A HIC can also conduct a Readiness Assessment on a HINP, Agent, or Service Provider to ensure that they have a strong privacy framework in place prior to sharing PHI with them.



Case Study

A group of six hospitals (the group) are working together to develop and implement a digital Diagnostic Imaging Repository (DIR) that will allow them to share their clients’ diagnostic images. This will improve the quality of care and reduce the cost of repeat images as clients are transferred among hospitals.

The group establishes a project team to develop the business and user requirements for the DIR as well as to develop and deploy the system to the six hospitals. The project team is aware that they need to consider the privacy requirements for the DIR in addition to other functional or technical requirements. They are also aware that the policies, procedures, and training they create on how to use DIR must include privacy. They will need to create policies related to handling incidents, training to users on how to create a consent directive, and so forth. They need to ensure privacy is integrated into their project at every step.

Here are the steps they take to integrate privacy into the project:

• Before gathering the requirements, the team conducts a Conceptual PIA to identify the key privacy issues in the project. The Conceptual PIA identifies consent as a significant concern for this initiative because PHI will be shared among hospitals.

• While defining the detailed business requirements and designing the system, the team gathers requirements on other privacy issues like consent and consent directives management. The privacy requirements inform the design of the technical system in addition to the policies and procedures guiding the initiative.

• The team ensures the design for the technical requirements supports the consent management process.

• Once the policies, procedures, communications materials, training, and technology are designed, the team conducts a Design-Level PIA to identify any privacy issues and risks associated with their plans, and to identify potential mitigation strategies.

• After the initiative goes live, the team conducts an Operational PIA to ensure that any changes made between design and go-live did not affect the privacy stance of the initiative. They find a few issues with healthcare providers not providing adequate information to clients about the sharing of their information, and about their right to withhold consent.

• The team recommends changes to communications materials and information-sharing processes to ensure that clients are made aware that

*



their images could be shared with other hospitals and that they have the right to withdraw or withhold consent.

• The individual hospitals’ respective departments make the necessary changes to their communications materials, policies and procedures, and information technology to reflect the recommended changes.

• When a new hospital applies to participate in the DIR, the new hospital must complete a Readiness Assessment. This assessment identifies any gaps in the new hospital’s policies or procedures prior to being given access to PHI. If gaps are found, the new hospital is required to address any of the key gaps prior to joining the initiative and being given access to PHI.



7.4 Checklist for Integrating Privacy into Your Project

Have you?

Designed your systems with respect for client privacy as a core foundational requirement

Defined your privacy requirements related to your technology and operational procedures

Integrated privacy into each step of your project lifecycle

Included privacy subject matter experts as part of the project team

Conducted PIAs as your project progresses

Conducted Readiness Assessments for organizations wanting to participate in the initiative



7.5 Tools and Templates

Tool / Template Description

Privacy Impact Assessment

Template for conducting a PIA in shared environment

Readiness Assessment Template checklist to determine privacy readiness for an initiative

Risk Response Matrix Template to record and monitor status of recommendations identified during review (i.e., PIA, Readiness Assessment) process



Section 5: First Steps

In this section you will learn some of the foundational elements that any initiative requires prior to collecting PHI. These include:

• Establishing a governance model for the initiative

• Establishing accountability for privacy across the organizations

• Defining the consent model

By the end of this section, you should be able to define a governance and accountability model for your initiative as well to document the consent model.



8 Governance and Accountability A key element of accountability is a privacy governance framework that includes strong information management policies and procedures, and privacy-enhancing protections integrated into your organization’s information technology systems and client health care services. Accountability and responsibility cannot be outsourced—each HIC must do its share to ensure the protection of PHI is continuous. An effective information governance and accountability program:

• Is supported by agreements among the parties which establish the roles and responsibilities of all parties in protecting PHI and privacy

• Establishes the roles and responsibilities of individuals within the organization with regards to protecting privacy

• Promotes harmonization of privacy and security policies and procedures across all of the participating organizations to ensure a common approach to handling PHI and client privacy

• Provides a means by which organizations can be assured that they are compliant with PHIPA as well as with the policies and requirements associated with the initiative

• Proactively identifies and mitigates privacy risks, thereby reducing risks of non-compliance

• Reduces costs related to litigation, fines, and adverse publicity resulting from non-compliance

• Provides documented proof of compliance

• Delivers privacy and security awareness training to staff and contractors with access to PHI

• Is open and transparent with the public about how it uses and protects PHI

The information in this section discusses setting up an appropriate governance and accountability model under PHIPA that addresses privacy issues related to the sharing of PHI between HICs, and the disclosure of PHI to non-HICs. It describes the key activities and roles in establishing a governance and accountability structure, and in defining your information practices and security safeguards.




Term Definition

Accountability A key aspect of information governance that is based on organizations taking responsibility for protecting privacy and information security appropriately and protecting individuals from the negative outcomes associated with privacy-protection failures. Under the first principle of the CSA Model Code for the Protection of Personal Information (Fair Information Principles), accountability requires custodians who collect, use or disclose PI to clearly identify individual(s) responsible for ensuring compliance with applicable data protection legislation and institutional privacy policies.

Source: Privacy by Design: Essentials for Organizational Accountability and Strong Business Practice, November 2009, Ontario Information and Privacy Commissioner.

Compliance Comprises the observance of statutory and company regulations on lawful and responsible conduct by the custodian and its agents and its management and supervisory bodies.

Governance Deals with the mechanisms (policies and procedures) that are used to guide, steer or regulate the course of an organization or system—the authoritative direction or control over an entity or entities that encompasses roles, relationships, powers, and accountabilities.

Information Practices In relation to a HIC, means the policy of the custodian for actions in relation to PHI, including:

(a) when, how and the purposes for which the custodian routinely collects, uses, modifies, discloses, retains or disposes of PHI, and

(b) the administrative, technical and physical safeguards and practices that the custodian maintains with respect to the information.

Source: PHIPA, 2004



Term Definition

Risk Management A component of governance that could be defined as being the process of identifying, assessing, and reducing the risk to an acceptable level and implementing the right mechanisms to maintain that level of risk.

Source: Harris, 2005

Stewardship (or Data Stewardship)

Denotes an approach to the management of data, particularly data that can identify individuals. Data stewardship can be thought of as a collection of data management methods covering collection, storage, aggregation, and de-identification, and procedures for data release and use.

Service Provider A HIC who uses electronic means to collect, use, modify, disclose, retain, or dispose of personal health information and the person who provides the goods or services (service provider) must comply with the requirements that are set out in the Act’s regulations (O. Reg. 329/04) (the Regulation)

A service provider is a non-agent person who supplies custodians with services that enables the custodians to collect, use, modify, disclose, retain, or dispose of PHI. The service provider is not permitted to use or disclose, or access any PHI it may come in contact with, except where it is required to provide the service.

Source: O. Reg. 329/04, s6(1)


PHIPA is specific in its provisions for HICs (and their agents) in respect of accountabilities for the protection of PHI in their custody or control,21and includes that they implement mechanisms to ensure their obligations are met and upheld when collecting, using, disclosing, retaining, and disposing of PHI.

21PHIPA 2004: An Overview for Health Information Custodians, MOHLTC August, 2004

PHIPA Sections

ss10 to 17



To comply with PHIPA, you must:22 • Designate a contact person for the purposes of the Act;

• Establish and maintain appropriate information practices;

• Develop procedures related to use and disclosure of PHI, including noting details in clients’ personal health records;

• Train your staff, volunteers and others acting on your behalf to follow your information practices and your procedures, and have them sign a Confidentiality Agreement and renew it on a regular basis; and

• Establish contracts with Health Information Network Providers


You should review policies and procedures to ensure accountabilities and responsibilities related to the sharing and disclosure of PHI are properly established and that appropriate agreements are in place to ensure that the chain of accountability is maintained as PHI flows from HIC to HIC. As organizations come together to share information, dissimilar policies and procedures must be harmonized.

Best practices should be taken into consideration when you are developing a privacy governance program and include the following:

• Use the 10 Fair Information Principles of the CSA (Canadian Standards Association)23 for the Protection of Personal Information as a guideline for the contents of the privacy policy and any other related privacy policies (e.g., client access and correction, complaints management, privacy incident management).

• Establish regular review and “as needed” revision of privacy policies and procedures related to the collection, use, disclosure, consent, retention, and destruction of PHI within your organization.

• Ensure that contractual agreements (e.g., Data Sharing Agreement (DSA) and Service Level Agreement (SLA) with appropriate privacy provisions are in place with all service providers, including HINPs.

22 CIPP Compliance Toolkit, February 2004 23The 10 Fair Information Principles (FIPs) come from a national standard called the CSA Model Code for the Protection of Personal Information and are the foundation for most privacy legislation.



• Establish compliance monitoring policies and procedures for agents and third-parties. Ensure these requirements are included in the terms and conditions of third party agreements.

• Establish privacy and security training and awareness programs for agents, and require mandatory completion and regular updating.

In situations where PHI is disclosed to another HIC, it is important that you ensure certain structures are in place to provide governance and establish accountabilities.

8.3.1 Establishing a Governance Structure

To get started, your organization should have a governance structure in place that establishes which individuals and bodies are “responsible and accountable” for privacy. Those who are responsible for privacy usually would execute and implement the initiative. Alternatively, those who are accountable for privacy would oversee and make decisions for the initiative, but are held to account for the activities and actions of others.

Key supporting individuals and committees for privacy and information security on your initiative should include the following:

Group / Individual Roles and Responsibilities

Steering Committee The steering committee is the decision-making body that acts as a representative of all parties. Your organization’s steering committee should define its information management practices and ensure they are consistent with the privacy requirements and principles in applicable legislation.

Other responsibilities to consider are:

1. Tabling and resolving privacy issues related to the sharing of PHI

2. Establishing policies and procedures to manage and protect shared PHI

3. Establishing working groups to address and resolve privacy issues that arise

4. Managing and reviewing DSAs

5. Establishing due diligence assessments of “connecting” parties (e.g., Readiness Assessment, PIAs and TRAs)



Group / Individual Roles and Responsibilities

Privacy Sub-Committee The privacy sub-committee should be a sub-committee of the initiative’s steering committee. The Privacy Sub-Committee makes decisions or provides recommendations to the Steering Committee on the privacy-related policies and procedures for the initiative, as well as ensures that the participating organizations are compliant. The Privacy Sub-Committee essentially establishes the model for how all of the organizations work together to maintain privacy.

Privacy Lead The Privacy Lead is an individual at the organizational-level who is accountable for ensuring that his or her organization is compliant with the initiative’s privacy-related policies and procedures. Essentially, the privacy lead ensures that his or her organization is doing its part to protect PHI and client privacy associated with the initiative. It is expected that privacy leads have some representation on the Privacy Committee of a multi-organizational initiative, but may not all be represented. The privacy lead may be the person who is accountable for his or her organization’s broader privacy posture under PHIPA.

It is important to note that the roles identified above are in addition to the organization-level roles that every HIC has to oversee and manage privacy in its organization. For example, most organizations have a board of directors, or other governance body, that is ultimately accountable for all of that organization’s activities, including privacy. All organizations are additionally required to have an individual accountable for privacy at the organization. The organizational roles are distinct from those which are associated with the initiative. That is, the Privacy Lead for the initiative may not be the Privacy Officer for the organization.

8.3.2 Establishing Agreements

Agreements are an important tool in supporting any governance and accountability structure. These are particularly important in a PHI-sharing initiative to ensure that the rights and obligations of all parties are clearly outlined, thereby, ensuring PHI and privacy protection across all organizations. The following agreements should be included in privacy governance and accountability:



Agreement Description

Data Sharing Agreements (DSAs)

DSAs establish the information management and protection roles and responsibilities of each party to the agreement related to the collection, use, disclosure, consent, and retention of PHI.

Service Level Agreements (SLAs)

SLAs establish the service provider security safeguards that will be in place, as well as the reporting and notification requirements of the custodian receiving the service(s).

Confidentiality Acknowledgements or Agreements

Confidentiality Acknowledgements or Agreements establish the privacy and security responsibilities of all agents as they pertain to both PI and PHI policies.

Acceptable Use Statement

Acceptable Use Statement is a set of rules that restrict the ways in which an organization’s technology and infrastructure may be used by all those who have access to these assets.

8.3.3 Establishing Common Privacy-Related Policies and Procedures

Where regular sharing of PHI among custodians occurs, you should develop and adopt a common set of privacy policies to establish common privacy practices across the organizations. The common policies and procedures help to ensure that all of the organizations are following the same procedures when dealing with privacy issues and ensure that client privacy is adequately protected across the organizations.

The policies and procedures address issues such as what type of consent the organizations will obtain from clients, how to address a privacy incident that involves multiple HICs, who should be responsible for providing a client to his or her health record if it is created by multiple HICs, and similar issues.

Typical privacy policies:

• Training

• Consent

• Privacy Incident and Security Incident Management

• Client Access and Correction

• Inquiries/Complaints Management

• Use and Disclosure



8.3.4 Establishing Information Management Practices

Related to the privacy policies and procedures are information management practices that govern how PHI is handled among the organizations. You need to establish common information management practices across the organizations to ensure that client PHI is managed in a standardized manner and to ensure a consistent level of PHI protection.

Before you collect, use, or disclose PHI to another HIC, or a third party, you must establish clear objectives and standards for the collection, accuracy, security, use, disclosure, transmission, access, retention, and disposal of PI, ensure formal agreements are in place, and all parties’ roles and responsibilities related to the protection of PHI are established.

At a minimum, the initiative should develop and implement policies and procedures that set out the following:

• When, how, and the purposes for which you routinely collect, use, modify, disclose, retain, and dispose of PHI;

• How the organizations are working together to address key privacy operations processes, such as consent management or incident, and complaints management;

• What administrative, technical, and physical safeguards and practices that you maintain with respect to PHI; and

• How you inform clients of the use and disclosure of their PHI; and how you make note of the uses and disclosure, and keep the note of the uses and disclosures in a form linked to the individual’s record.



8.3.5 Ensuring Accountability of Agents

HICs are also accountable for the actions of its agents. Agents could be staff members of the HIC, or might be third party vendors who collect, use, or disclose PHI on behalf of the HIC. The HIC needs to ensure that its agents are handling PHI appropriately (i.e., in compliance with PHIPA and for the purposes which PHI was collected). This issue is increasingly important as HICs use third-parties to provide them with IT solutions and support.

The following are standard methods to limit collection, use, and disclosure of PHI by your agents:

Method Description

Agreements Establish agreements that state the purpose of the collection, use, and disclosure of PHI, and provide sanctions against inappropriate collection, use, and disclosure.

Policies and Procedures Establish and implement clear policies and procedures to guide handling of PHI.

Education/Training Build a culture of privacy awareness and provide privacy training to everyone in your organization, including your agents.

Technical Safeguards Deploy technical safeguards to help maintain the confidentiality of PHI and that help monitor collection, use, and disclosure of PHI.

8.3.6 Training

Participating HICs should provide standardized training to all end-users regarding their individual responsibilities as established in the DSA, and on all privacy policies related to the sharing of PHI. This training would be in addition to the regular in-house privacy and security training the HIC provides.

The scope of training should include at a minimum:

• Reporting possible and actual privacy incidents and/or security incidents;

• Addressing requests made by clients for access to, and correction of, their PHI; and

• Responding to requests for withdrawal of consent (lock box).



8.3.7 Establishing Security Safeguards

With the increased use of information technology in health care, your organization must continue to find ways to maintain the security of its clients’ PHI. You must take reasonable precautions to ensure that the PHI is protected against theft, loss, unauthorized use, or unintended disclosure, and unauthorized copying, modification or disposal.

If PHI in your custody or control is stolen, lost, or accessed by unauthorized persons, you must inform the client of this occurrence, with some exceptions24. Your agents are required to notify you at the “first reasonable opportunity” if PHI handled by the agent is stolen, lost or accessed by unauthorized persons.

• See section 13, Safeguarding PHI for more information.

Remember! You should, on a regular basis, evaluate and update your

privacy framework and related policies on accountability,

information management, and privacy.

24See PHIPA s12(3) Exception.



Case Study

A group of community agencies are establishing a new Patient Referral Program (PRP) which uses an electronic system to enable participating community service agencies to match clients with health service providers. The community agencies decide to establish a Steering Committee that will make decisions about the initiative on behalf of all of the organizations, and comprises one member from each of the participating community service agencies. The PRP Steering Committee decides that the new technology will be operated and maintained by a third-party technology provider who will act as a health information network provider.

Each agency is required to sign a joint Data Sharing Agreement (DSA) that establishes how the agencies will work together to ensure privacy is protected among all of the agencies participating in the initiative. The DSA ensures that each agency is able to trust that the others are following the same privacy and confidentiality standards across the board. Each Agency is also required to sign a Service Level Agreement (SLA) with the health information network provider. The SLA describes the services and privacy safeguards that the technology vendor will deliver.

The Steering Committee is also responsible to ensure that privacy policies and procedures have been developed and being observed on an ongoing basis. It does this by appointing a privacy sub-committee who will have the responsibility for drafting recommended policies and procedures for privacy on the initiative. The policies and procedures will be adopted by the Steering Committee and guide how they work together to ensure client privacy and confidentiality is being respected across the initiative. The privacy sub-committee will also be responsible for ensuring that the agencies and their end-users understand and comply with their privacy obligations.

*



8.4 Checklist for Governance and Accountability

Have you?

Integrated privacy governance into the governance model for your initiative?

Develop a clear accountability structure for privacy?

Identified a privacy lead from all HICs in the initiative?

Established agreements among all of the parties?

Established privacy-related policies and procedures to guide the interaction among all the HICs involved in the initiative?

Implemented appropriate information handling procedures?

Provided privacy and security awareness training to all end-users and system users with access to PHI?





Data Sharing Agreement

Agreement to govern data disclosures among HICs

Service Level Agreement

Agreement between HIC(s) and HINP(s)

Confidentiality Agreement

Agreement that agents would sign to guide confidentiality of PHI

Acceptable Use Agreement

Click-through agreement that end-users would review prior to being given access to the system

Privacy Sub-Committee ToR

Terms of Reference for the Privacy Committee, a sub-committee of the Steering Committee for the initiative

Privacy Lead Roles and Responsibilities

List of roles and responsibilities for the privacy lead, the organizational representative for privacy issues with respect to the initiative

Training Policy and Procedures

Policies requiring an organization to provide privacy-awareness training to its end-users prior to being given access to the system

Incident Report Report to be completed in the event of a privacy-related incident

Policies and Procedures

Sample of a common set of privacy policies and procedures for healthcare organizations that electronically share PHI

Retention Schedule Template to record the repositories of PHI and the length of the time that they should be held prior to destruction

User Roles Matrix Template of a matrix that the initiative can use to identify user roles and their PHI access rights



9 Establishing Consent Consent is considered to be an important component of all aspects of health care. At the core of privacy legislation is the concept of clients’ knowledge of and consent to collection of their PI.

The terms “knowledgeable” and “informed” are often used to describe the level of understanding a person must have for consent to be considered valid. Consent is considered knowledgeable if the client (or the client’s substitute decision maker (SDM)) is provided with the information that a reasonable person in the same circumstances would require to make a decision about the collection, use or disclosure of PHI. The standard for obtaining clients’ knowledgeable consent should become even higher when a client’s PHI is shared with HICs outside of the originating organization.25

Once clients appear to understand these essentials, you can assume implied consent for collecting, using and disclosing their information. You cannot assume implied consent if the client expressly states otherwise.

Express consent is always required where the collection, use or disclosure of PHI goes beyond the initially stated purposes and when it is disclosed to a non-HIC. The exception to this requirement is where collection, use or disclosure is permitted by law such as in the instance of reportable communicable diseases.

This section explains consent. You should also read the next section on Collection, Use and Disclosure to ensure that you have comprehensive information on the topic of consent.

25 When PHI is disclosed to a non-HIC or where the information is disclosed for a purpose other than that for which it was collected (i.e., the provision of or support for the provision of health care services), the individual’s express consent is required.




Term Definition

Circle of Care While not defined in PHIPA, the term is used to describe the ability of certain HICs to collect, use, or disclose PHI for the purpose of providing health care.

Source: Sharing PHI for Health-Care Purposes, Office of the information and Privacy Commissioner.

Consent Voluntary agreement by an individual, or their legally authorized representative, to allow the collection, use, or disclosure of the individual’s personal health information. A custodian may conclude that it has the consent of the client if 1) it has fulfilled all of the elements of consent (s.1891)), and, 2) the client is knowledgeable about the purposes for the collection, use, or disclosure of their PHI (s. 18(5)).

Source: COACH Guidelines for the Protection of Health Information, 2009.

Consent, Express or Expressed

Voluntary agreement with what is being done, or proposed, that is unequivocal and does not require any inference on the part of the organization seeking consent. Express consent may be verbal or written.

Source: COACH Guidelines for the Protection of Health Information, 2009.

Consent, Implied

If the client is knowledgeable about the purpose for collection and does not withdraw his or her consent for collection, use, or disclosure, the custodian may assume it has the client’s implied consent for collection, use, or disclosure of his or her PHI.

Source: PHIPA, 2004

Consent Directive

A consent directive is an express instruction of a client to restrict further use or disclosure of their personal health information (lock-box).

Consent, Knowledgeable

A client’s consent is considered to be knowledgeable if the client understands 1) the purposes for the collection, use, or disclosure of his or her PHI; and 2) that he/she may give or withhold consent (s. 18(5)). Without the presence of knowledgeable consent, custodians may not assume they have clients’ implied consent for collection, use or disclosure of their PHI.

Source: PHIPA, 2004



Term Definition

Lock-Box A colloquial term specific to Ontario, refers to clients’ request to “lock away” their PHI from access by other custodians and authorized health care providers.

Source: IPC/Ontario

Mask Refers to the result of the application of a consent directive (lock-box) in that the client’s PHI may no longer be accessed by health care providers who might otherwise have the authority to access the client’s PHI (e.g., as per the permissions and privileges of their assigned role).

Source: Canada Health Infoway

Notice Refers to the written public statement (PHIPA s16(1)) that describes how a HIC will protect PHI in its custody or control and what rights the client has under the Act in terms of access, correction, complaint, and withdrawal of consent.

Source: PHIPA, 2004

Override (with and without consent)

Refers to the temporary removal of a mask, with or without the consent of the client, to enable a health care provider to access and use the client’s PHI that was masked by a consent directive.


PHIPA is a consent-based legislation and is very explicit in its consent requirements for HICs. The requirements for consent discussed in this Toolkit are taken from section 18, 19, and 20 of PHIPA. PHIPA sections 21 through 28 address determination of capacity to consent and are not dealt with in this discussion as they are a standard component of organizational privacy programs that are not affected by PHI-sharing initiatives.


Best practices dictate that you inform clients or their SDMs about the specific information sharing initiative as it relates to disclosing their PHI and about the resulting access and use by another HIC before you collect their information.

Shared information repositories may result in loss of anonymity because PHI is automatically and immediately shared as soon as it is entered into the repository. It is important that clients are informed of and understand the purposes for the disclosure of

PHIPA Sections

ss18 to 28



their PHI to other HICs and be provided an opportunity to withdraw their consent for this disclosure prior to collecting their PHI or at any time following collection.

You should consider the following activities to ensure that your initiative is compliant with PHIPA and effectively protecting your clients’ rights related to consent.

• Define consent requirements: legal, ethical, and best practice.

• Establish notification and consent policies and procedures that can be applied consistently throughout your organization. Policies and procedures should address when and how implied/express consent will be employed and how to record whether consent is obtained, withdrawn or overridden (with and without consent).

• Audit the consent practices of health care professionals. Policy will not change behaviour without regular monitoring and feedback. Review all forms, literature, documents, and statements concerning consent to ensure that they are consistent with the organization’s consent policy.

• Understand clearly where consent is not required for collection, use or disclosure.

• Understand and document where consent is required, e.g., in instances of secondary uses such as research or disclosure to third-parties including non-HICs.

• Do not ask for consent for collection of information that is not required for a specific purpose “just to be on the safe side.” This practice confuses staff and clients as to when and how consent actually is required.

• Ensure any disclosure of PHI to a third party is done in accordance with requirements for express consent from the person to whom the information relates.

A number of the above activities relate to your governance and accountability responsibilities (section 8) and to Collecting, Using, and Disclosing (section 10).



9.3.1 Communicating with Clients

Clients generally understand that providers need to record information into their paper charts for the purpose of maintaining long-term records and providing care. Their knowledge is further supported by public notices that are required by PHIPA. However, shared PHI repositories increasingly lead to an unclear boundary of how PHI will be used and with whom it will be shared. It was reasonable to assume with paper-based charts that PHI shared with a healthcare provider was generally only accessible by providers in that organization, unless the client was specifically referred to another institution. With PHI-sharing initiatives that assumption is no longer reasonable because it is possible that providers in other organizations have access to the client’s PHI – all of it. This scenario makes it much more important to ensure that HICs are communicating with their clients about how and why PHI is collected and with whom it will be shared.

Remember! The patient must know how the information is being collected,

how it will be used, and to whom it will be disclosed for

consent to be valid!

9.3.1.1 Public Notices

All HICs are currently required to have a written public notice related to the PHI they collect and use. The notice typically addresses how the HIC will use the information for treatment and care. The public notice for an information-sharing initiative needs to relate specifically to how the PHI will be shared among organizations. The PHI no longer stays at your organization. It is shared with other providers in other HICs.

PHIPA is specific in its requirements for a written notice. The notice for your initiative should include:

• A general description of the information handling practices (i.e., why PHI is collected, how it will be used, who has access to it, to whom it will be disclosed)

• A statement indicating that the individual has a right to withdraw or withhold consent

• How to contact the Privacy Lead

• How to request access and correct PHI of the client

• How to make a complaint to the HIC and the IPC/Ontario



You should also consider including a brief discussion of any legal requirements that oblige you to disclose PHI without the client’s consent (e.g., reportable communicable disease, spousal or child abuse, MOHLTC reports).

9.3.1.2 Speaking with the Client

You should ensure that your healthcare providers are communicating with clients when collecting PHI. They should be discussing how the information will be used and who will have access to it, particularly if it is shared outside of the organization. Your initiative should have a standard script that providers can follow when discussing the initiative with clients. That script should have the same information as the public notice.

9.3.2 Obtaining Consent

If a client appears to understand the purposes for collection, use and disclosure of his or her PHI (because someone asks the client if he or she understands), then you may assume you have the client’s implied consent to collect and share his or her PHI with other custodians inside and outside of the organization/practice.

The intent of implied consent is to enable a healthcare provider to use or disclose PHI for a purpose consistent with the purpose for which it was originally collected, without having to explicitly ask them whether they provide consent. The healthcare provider must be of the opinion that the client would consent to the further use or disclosure if he/she was asked. Where there is doubt, express consent should be obtained.26Health care providers in your organization may assume they have the client’s valid implied consent to collect and use their PHI, unless they become aware that the client withdrew his or her consent to share this information.

For implied consent to be valid, you must first ensure that a number of conditions are met. The consent of the client to the collection, use or disclosure of PHI about the client by an organization may be implied only if:

• The purpose of the collection, use or disclosure is reasonably obvious to the client (e.g., a family physician asking a client about his or her health to provide ongoing care to the client);

• It is reasonable to expect that the client would consent to the collection, use or disclosure;

• The organization is not aware that the client withdrew consent; and

26COACH Guidelines for the Protection of Health Information, 2009.



• The organization uses or discloses the information for no purpose other than the purpose for which it was collected.

Express consent is required when PHI is disclosed to non-HICs or where the PHI is to be used for a purpose that is not consistent with the purposes for which it was collected (e.g., sharing it for research when it was collected for care). The exception to this requirement is where collection, use or disclosure is permitted by law (i.e. for reportable communicable diseases).

PHIPA does not require that receipt of consent be recorded. However, it is a best practice to record consent since it may prove valuable (e.g. evidence) in the instance of a privacy incident or complaint.

9.3.3 Withholding and Withdrawing Consent

Clients must be made aware that they can withhold or withdraw their consent for the collection, use and disclosure of their PHI (mask/lock-box are the colloquial terms). They must also be advised of the potential implications of withdrawing their consent for disclosing their PHI.

Note! Consent withdrawals are not retrospective. If the PHI was

collected and disclosed prior to a withdrawal of consent

request, the disclosure cannot be recalled. A consent

withdrawal applies to future uses or disclosures.

Your process for Withdrawal of Consent to Disclose should include a notification to other custodians with whom the client’s PHI was shared. The notification informs them that the client withdrew consent to disclose and not all information about the client may be available. The notice should also request that the custodian to whom the PHI was already shared further restrict use or disclosure of the PHI if they have recorded it. The shared information repository should be developed to perform this function for the user as soon as they create the consent directive.

The initiative must have processes in place to effectively respond to clients’ requests to withdraw consent for disclosure. The key consideration is who will actually create the consent directive (i.e., the provider or a central help desk provided by the HINP) and whether a HIC would be able to create a consent directive on PHI collected by another HIC27.

27 Note that even though a HIC may create a consent directive on PHI that originated with another HIC. The information must always be available to the originating HIC.



Where new systems are being designed, many are developing functionality that supports the business process and enables the electronic “masking”28 of PHI in response to a consent directive (withdrawal of consent request).

9.3.4 Implementing Technical Functionality for Consent Directives

Legacy information systems often do not have the ability to support a Consent Directive request. In these instances, you will need to develop rigorous administrative processes to ensure consent directives can be respected. However, when procuring or designing a new eHealth solution you should build consent directive functionality into the system.

The functionality should focus primarily on two actions: 1) creating the consent directive, and 2) overriding a consent directive.

9.3.4.1 Types of Consent Directives

The initiative must make a policy decision regarding the granularity of consent directives that will be supported. Examples of the level of masking PHI that could be included in a consent directive are:

• Mask all PHI (the entire record)

• Mask PHI so that a specific HIC or end-user cannot access the data

• Mask a domain of data (e.g., all lab tests and results), or specific pieces of data within the domain (e.g., all narcotics)

• Mask PHI to all HICs with specific exceptions (e.g., my family physician, my pharmacist, my diabetes nurse)

9.3.4.2 Administrative Processes Associated with Consent Directives

Technology must be supported by business processes to act on the consent directive. The HICs should record:

• Who provided the consent directive (i.e., the client or the SDM)

• If the SDM, their relationship to the client

• The time and date that the directive was provided

• The consent directive itself

28 Masking refers to the outcome of an electronic response to a withdrawal of consent request. While the PHI is not removed from the database, the affected PHI is made “invisible’ to system users who would normally have access to it.



It is also important to have processes to confirm the identity of the person requesting the consent directive. If the individual arrives in person, appropriate staff can check their identification as well as documents asserting their authority to act on behalf of the client if they are the SDM. Procedures would differ if the individual calls or writes a letter.

Finally, the initiative should consider whether receipts will be provided to clients requesting consent directives. The receipt would indicate when the consent directive was requested and when it was acted upon.

9.3.5 Overriding Consent Directives

When a health care provider requires access to a client's health information stored in an electronic system, the health care provider must first ascertain whether there are any existing Consent Directives for that client. There are cases when the health care provider may have to override an existing Consent Directive to access the PHI that is masked.

When a provider temporarily overrides a consent directive to see masked information, the system should challenge the user regarding the authority that the consent directive was overridden. That is, who provided consent to the user to override the consent directive? The individual or the SDM? The information should be temporarily available to the user and then re-masked.

The user must be compelled to respect the fact that the client had placed a consent directive on his or her information. Therefore, the masked information cannot be shared or disclosed any further than for the reason consent was overridden in the first place.

According to the College of Physicians and Surgeons in Ontario, information used in a diagnosis must be recorded into the client’s file. The previously masked information that the client allowed the HIC to temporarily override would now be recorded in the HIC’s local file for the client. This information in the HIC’s local file must continue to be considered as “masked” and cannot be shared with other health care providers.



Case Study

A group of six hospitals (the group) are working together to develop and implement a digital Diagnostic Imaging Repository (DIR) that will allow them to share their clients’ diagnostic images. This will improve the quality of care and reduce the cost of repeat images as clients are transferred among hospitals.

The group wants to establish a common consent model that each hospital will follow when obtaining consent from its patients. In the past, each individual hospital would store the image in its local DI-PACS solution and the image would only be accessible by the hospital that created the image. Now, every hospital will have access to each other’s patient images. The group realizes that the bar for informed consent has been raised because the patients need to be made aware that their PHI will be stored in a centralized repository accessible to all the HICs.

The group develops a communications strategy for the initiative that includes putting posters about the initiative in the waiting rooms of each diagnostic imaging clinic. The group also develops a basic script explaining the initiative that the imaging technicians will read to the patient prior to conducting the investigation. The script tells the patient that their image will be stored in a centralized repository and that they can place a consent directive on the image to prevent it being shared further. The script also indicates that certain users within the hospitals (e.g., emergency room providers) will be able to override the consent directive without the patient’s consent.

The group also develops protocols for obtaining consent directives when a patient wishes to withdraw or withhold their consent as well as for when an override occurs. Privacy officers in each of the hospitals will be trained on how to read the privacy audit reports that identify among other things when a user has overridden consent directives. The privacy officer can then investigate the consent directive override and determine a privacy incident occurred.

*



9.4 Checklist for Consent

Have you:

Established an appropriate consent and consent directives model that is documented in a policy?

Established procedures to obtain consent and act on consent directives?

Developed a robust communications strategy to ensure that clients are well informed about the initiative and their privacy rights?

Educated staff about consent and consent directives?

Designed technical functionality to act on consent directives?

Created an appropriate alerting or reporting system if consent directives are overridden?

Ensured that consent is being obtained when PHI is being collected?

Ensured that consent directives are being respected?





Consent Policy and Procedures

Policies to guide consent and consent directive management

Consent Form To be completed by the user obtaining consent

Consent Withdrawal To be completed by the client or SDM to withdraw consent for use and disclosure of some or all of his or her record

Consent Reinstatement Form

To be completed by the client or SDM to reinstate consent for use and disclosure of his or her record

Public Notice Sample notice informing clients of the purpose of PHI collection and their right to complain and withdraw consent

Consent Script Sample script to be read by the person obtaining consent about the purpose of PHI collection and the client’s right to complain and withdraw consent

Notification to the User Performing a Consent Override

Notification that a shared information repository should present to the end-user when overriding a consent directive

Consent Override Letter

Template to inform patient of (temporary) consent directive override, and timeframe of override



Section 6: Ongoing Privacy In this section, you will learn about what privacy requirements to implement on an ongoing basis to protect client privacy, including:

• Collection, use and disclosure

• Managing privacy incidents and complaints

• Monitoring program compliance on an ongoing basis

• Safeguarding PHI throughout the information lifecycle

By the end of this section, you should be ready to manage the privacy of PHI



10 Collecting, Using, and Disclosing PHI Collecting and using PHI are central to your clinical processes. A healthcare provider cannot provide appropriate and safe care without collecting and subsequently using information about the client seeking health care services. Clients are often seen by multiple providers and PHI disclosure is required to provide appropriate services to the client across the continuum of care.

Much of this sharing of information is conducted through information technology (IT) systems. The PHI may be sent directly to another HIC or it may be submitted to a centralized secure repository where other HICs can access and use the PHI. It is exciting to imagine the possibilities for treatment and care that are borne from the increased adoption of IT systems in healthcare.

There is also much opportunity for privacy abuse with respect to clients’ information on these systems.

This section discusses some of the privacy challenges when sharing PHI with custodians on IT systems and also reviews ways that these systems can enhance both privacy rights and client care.




Term Definition

Collect Collect is a defined term under PHIPA that refers to obtaining PHI.

“Collect,” in relation to personal health information, means to gather, acquire, receive or obtain the information by any means from any source. “Collection” has a corresponding meaning.

Source: PHIPA s2

Use Use is a defined term under PHIPA that refers to applying PHI (does not include disclosing PHI).

“Use, in relation to personal health information in the custody or under the control of a health information custodian or a person, means to handle or deal with the information, subject to subsection 6 (1), but does not include to disclose the information. “Use”, as a noun, has a corresponding meaning.

Source: PHIPA s2

Disclose Disclose is a defined term under PHIPA that refers to making PHI available to another HIC or person.

“Disclose,” in relation to personal health information in the custody or under the control of a health information custodian or a person, means to make the information available or to release it to another health information custodian or to another person, but does not include to use the information. “Disclosure” has a corresponding meaning

Source: PHIPA s2

Need to Know A privacy principle where access is restricted to authorized individuals whose duties require such access. Individuals are not entitled to access merely because of status, rank or office.

Least Privilege A security principle requiring that each subject in a system be granted the most restrictive set of privileges (or lowest clearance) needed for the performance of authorized tasks. The application of this principle limits the damage that can result from accident, error or unauthorized use.




PHIPA generally requires that a HIC obtains consent before collecting, using or disclosing PHI (although there are some exceptions identified within the legislation). You must only collect, use or disclose your clients’ PHI if you have your clients’ consent to do so, or if the Act allows you to do so without consent.

Only collect, use or disclose your clients’ PHI if no other information would serve your purpose. As well, only collect, use or disclose that amount of information necessary to serve your purpose and follow reasonable information practices to protect your clients’ PHI.

Before any PHI is disclosed to another custodian or third party you must:

• Ensure you have the knowledgeable consent of the person to whom the PHI relates before the information is disclosed. Consent must be express where disclosure is to a non-custodian.

• Ensure receipt of express consent is recorded as required on the client’s record (person obtaining consent, date and time, purpose of the consent) or via a signed consent form which is attached to the client’s record [See Chapter 9 on Consent]

PHIPA also requires that you obtain clients’ consent if you plan to use or disclose their PHI for purposes other than that for which you originally collected the information.


The client’s consent is required when you collect, use or disclose PHI. HICs must ensure clients are knowledgeable about the purposes for the collection, use and disclosure of their PHI. One way to accomplish this is by making sure purposes are documented and available to the public (e.g., public notices, direct interaction with staff).

A client’s PHI may be shared by a HIC with other HICs (i.e., circle of care) as long as the purpose for the disclosure is the same as that for which the PHI was originally collected; and, the PHI was collected directly from the client or their SDM; and there is no knowledge of a withdrawal of consent for disclosure. The receiving custodian may assume that the client provided his or her consent for the disclosure and subsequent use of his or her PHI.

HICs should always ensure any disclosure of PHI is limited to the minimal amount of information required to meet the purpose for the disclosure.

The following information explains what you must do when you collect, use or disclose your clients PHI and discusses unauthorized access to information by agents. It also looks at clients’ right to request access to their records and to correct information and HICs responsibility in ensuring PHI is accurate and up-to-date.

PHIPA Sections

ss29 to 55



10.3.1 Communicating when Collecting

An important principle when collecting PHI is ensuring that you are communicating with the clients about why their PHI is collected and more specifically how it will be used. This communication establishes the basis for knowledgeable consent discussed in Section 9.

Communicating with the client is particularly important when using shared information repositories that are accessed by other HICs or when PHI will be shared with other HICs. Both of these scenarios constitute a disclosure and you need to ensure that the client is knowledgeable about the disclosure.

• See Section 9 for a broader discussion of communicating with the client.

10.3.2 Preventing Unauthorized Access by Agents

Preventing unauthorized access becomes particularly important in a shared environment when multiple people access the same information repository and view information on clients. The repositories provide an excellent opportunity for improving treatment and care. Although, they can exponentially increase the risk of privacy incidents when more people have greater access to a client’s PHI. It is critical to limit access to information to only those people who have a “need to know” such as health care providers who are part of the team caring for the client (circle of care) and those persons who support the delivery of health care services.

Limiting access to information can be controlled through a number of methods such as passwords and encryption (see section 13: Safeguarding PHI, for more discussion on appropriate technical controls). Limiting access to information is also controlled by enabling only appropriate access. That is, only giving authorized users access to the information and functionality they need in order to carry out their assigned duties and obligations.

Role-based access control is one model by which users’ access to PHI can be limited. Best practices suggest that in the instance of an electronic system, users attest to the fact that they have a clinical relationship with the client whose PHI they wish to access.

Type of Access Description Examples

Role-based

Providing access to information and functionality based on role within the organization

• Physician can see all medical information

• Emergency room providers can override consent directives

• Receptionists can only view client demographics



Type of Access Description Examples

Relationship-based

Providing access to information and functionality based on relationship to the client

• Provider only able to view the client record if a member of the care team

• Provider only able to view the client record if patient is part of Provider’s unit

A method of determining access to a client’s information is to develop a matrix where the client is at the centre. Determine the end users who should have access to the client’s information and the functionality to access this information. Also define which roles and relationships the end user must be given to access the client’s information.

The end users should include your system administrators as they will need access to client information for any system problems. Other appropriate IT staff will also need access to client information. Consideration should be given to include business persons (e.g. Privacy Lead) who may need access to audit log reports and override alerts.

10.3.3 Accuracy

You must take reasonable steps to ensure that clients’ information is accurate and sufficient for the purposes for which you require the information.

Personal health information needs to be very accurate because treatment decisions are based on information contained in a record. Accuracy is also very important when you are disclosing PHI because the recipient needs to be assured that the information can be trusted to enable his or her treatment decisions. In a shared PHI repository, the HICs need to be confident that the information in the record is accurate and up-to-date. You must clearly inform the recipient of the PHI if there is any limitation on the information being accurate, complete, or up-to-date. For a shared information system, this means:

• Ensuring the date that the PHI was collected is clearly visible to end-users

• Providing a warning if any PHI is not viewable due to a client’s applied consent directive

• Indicating that the client has challenged the accuracy of his /her PHI in the record.



10.3.4 Allowing Access and Correction Clients normally have the right under PHIPA to access their own personal health information (see PHIPA s52 for some exceptions), including the list of the individuals who accessed their PHI. PHI in shared information repositories is likely to have been created by multiple HICs. The HIC who collected the PHI has the responsibility and right to determine whether the client can access his or her PHI. Therefore, any requests for access have to go to the originating HIC. The Privacy Lead within the organization that received the request should facilitate this process. For example, if the client goes to a community clinic for access to his or her record but the record was created by the local hospital, the local hospital has the responsibility and the right to determine whether the client should be able to access his or her record. The Privacy Lead at the community clinic receiving the request should speak to the Privacy Lead at the hospital to determine whether the client should be provided access to his or her record.

Requests from a client requesting a correction to his or her record should be handled in a similar manner. A client has the right to request a correction to his or her record. In many instances, correcting the record is not practical because the health care providers need to maintain accurate copies of their client records (including if they made a decision based on inaccurate information). If the HIC agrees that the information is inaccurate, the correct information should be appended to the client record to show the information was corrected. If the HIC does not agree with the update, the client has the right to have a statement of disagreement noted in his or her record. In a shared repository, multiple HICs may need to be involved. The request for correction should also go back to the originating HIC.

10.3.5 Limiting Disclosure to that which is Necessary

PHI is the most sensitive information there is about an individual. Disclosing more than is needed can sometimes have a significant impact on the client (e.g., a man whose history of mental health issues is disclosed to a community support agency providing unrelated services and is subsequently stigmatized). Limiting the amount of PHI to be disclosed is an important principle in protecting client privacy and is also required under PHIPA.

There is no precise answer to how much information should be disclosed to another health care provider. Each provider must use his or her own judgment when delivering health care to clients. PHI-sharing initiatives should have general guidelines to direct HICs on what PHI should be disclosed based on the purpose of disclosure. This information should be established in the DSAs. Disclosure should also be controlled by technology where possible.

Ask yourself these questions before disclosing clients’ PHI:

• Is the information required to provide or support healthcare services for the client?

• Is the information more than is required for the purposes for which it will be used?



Case Study

A group of community agencies are establishing a new Patient Referral Program (PRP) which uses an electronic system to enable participating community service agencies to match clients with health service providers. The system will be accessible by users at community service agencies, community health service providers, and hospitals.

The group of agencies realizes the particularly sensitive nature of some of the information which includes mental health diagnoses. The group deploys basic relationship-based access controls and requires every user who views a record to have an active clinical relationship with the patient. Similarly, the group deploys role-based access to information. That is, some users will be able to see the mental health diagnoses while others will not.

For example, a user is only able to view a patient record if that patient has been referred to the user’s community service agency. The system does not allow a user to view the record of a patient not enrolled for services from that particular agency. Similarly, the system enforces role-based protections so that administrators will not be able to see mental health diagnoses but mental health counselors will be able to see them.

*



10.4 Checklist for Collecting, Using and Disclosing

Have you?

Identified which types of users should have access to PHI and what their access rights will be?

Created a list of all the system users and their access rights?

Established other security safeguards to prevent unauthorized access to the system?

Defined and documented in policy the purpose of collection, use and disclosure?

Defined the procedures for collecting, using and disclosing PHI?

Established administrative and technical controls to limit the scope of PHI collected and disclosed to that which is necessary?

Identified all of the authorized information repositories in the initiative (including paper ones)?

Determined an appropriate length of retention for all information repositories?

Created processes to guide how HICs will work together to meet clients’ access and correction rights?





Access and Correction Policy and Procedures

Policies and procedures to guide a client’s access to and correction of his or her PHI

Inquiries and Complaints Policy and Procedures

Policies and procedures to guide HICs’ response to a privacy-related inquiry or complaint

Request for Access Template for a client or SDM to request to view his or her PHI


Request for Correction Template for a client or SDM to request a change in his or her PHI

Denial of Access Notification

Sample letter to the client indicating that a request for access has been denied

Response to Correction Request

Sample letter to the client regarding how the correction request was addressed




11 Managing Privacy Incidents and Complaints A privacy incident refers to an accidental or intentional collection, use, disclosure or retention of PHI that contravenes provisions of PHIPA. Most privacy incidents relate to an unauthorized disclosure of PHI. This has been shown to be relatively true in several instances in Ontario.29

Privacy incidents can happen unknowingly such as not understanding the consent requirements when sharing PHI. It can also happen intentionally, such as looking up the client record of a friend or relative who is not in the provider’s care. It is important that you respond and act quickly to privacy incidents to lessen any potential damage to both the client and your organization.

In an environment with shared accountability for a client record, responding to an incident may involve coordinating efforts with other HICs. It may also involve notifying the governance committee should the incident/complaint require changes in the policies or procedures governing your initiative. The Privacy Lead for the organizations should be responsible for coordinating with other organizations should an incident or complaint span a number of HICs.

29 Example: Ontario IPC Order HO-10: A client's personal health information held by a hospital was accessed by a Diagnostic Imaging Technologist (technologist) who was not providing care to the client.




Term Definition

Privacy Incident

A privacy incident occurs when a HIC or its agents collect, use, disclose, retain or dispose of PHI in an improper or unauthorized manner that contravenes a provision or a regulation of the Personal Health Information Protection Act

Section 12(1) of the Act requires HICs to take steps that are reasonable in the circumstances to ensure PHI in their custody or control is protected against theft, loss and unauthorized use or disclosure, and to ensure that records containing PHI are protected against unauthorized copying, modification or disposal

Source: Information and Privacy Commissioner of Ontario. What to Do When Faced with a Privacy Breach: Guidelines for the Health Sector

Unauthorized Disclosure

Sharing PHI with another organization without consent or legislative authority or sharing more information than is necessary

Source: Based on PHIPA

Privacy Complaint

Concern by an individual that his or her information has been collected, used or disclosed in a manner inconsistent with PHIPA

Source: See www.ipc.on.ca


PHIPA requires that HICs take steps that are reasonable in the circumstances to ensure that PHI in your custody or control is protected against theft, loss, and unauthorized use or disclosure. It also ensures that the records containing the information are protected against unauthorized copying, modification, or disposal.

PHIPA also requires you to notify clients at the first reasonable opportunity if their information becomes stolen, lost or accessed by unauthorized persons. PHIPA does not contain a statutory reporting obligation to the Commissioner. However, it is considered best practice for organizations to inform the IPC of any privacy incidents.

PHIPA Sections

ss15, 16, 56-65



11.3 What you Should Do

You should ensure that privacy is designed into your systems from the beginning to help you avoid privacy incidents and client complaints. Further, you should have privacy and incident management policies and processes in place that clearly define how the organizations are going to work together to address privacy incidents or complaints. Policies act as a guide for staff to know what steps to take to report and contain complaints and privacy incidents.

Dramatic privacy incident are relatively rare. Most incidents often go unnoticed. As a result, one of the key aspects of incident management is identifying a potential incident.

11.3.1 Identifying Potential Privacy Incidents

Technology can significantly help in identifying incidents because a system can log activity and identify when someone views a client record. It can also identify anomalous activity such as users searching for individuals by the same last name. Therefore, auditing is ineffective if no individuals review reports and investigate complaints. The following actions can be followed to identify incidents:

• Regular review of privacy reports

• Regularly review reports on your users and clients (Which client records are staff members viewing? Are these records in the staff member’s care? Who viewed a particular client’s record? Should they be accessing the record?)

• Review privacy reports of vendors

• Request regular reporting from your vendors (e.g., health information network providers) who have access to PHI (Why did they access the PHI? Was the access appropriate? Were they doing so to provide support? Could they have performed the support without accessing PHI?)

• Review list of authorized users

• Review the list of users at your organization from time to time to identify whether the user is still at your organization and to understand whether their access rights should be modified or removed altogether

• Investigate privacy complaints

• Review privacy complaints to identify whether a privacy breach has occurred

Common Privacy Incidents:

• Sharing PHI with another HIC without consent (or legislative authority)

• Other HICs not respecting a client’s consent directive

• Security incident involving unauthorized access

• A provider without a clinical relationship to the client accessing the client’s record



Putting Preventative Measures in Place

The best way to deal with an incident is to avoid it in the first place. Below are some common ways to help avoid privacy incidents.

• Develop common policies and procedures with other organizations for complaints management.

• Establish defined roles and responsibilities of the organizations.

• Conduct Privacy Impact Assessments (PIAs) and Threat and Risk Assessments (TRAs).

• Establish clear administrative controls to limit access and editing rights to records containing PI to only those individuals who have a legitimate need to know.

• Develop agreements with other HICs and vendors.

• Take privacy into account before making contracting decisions or entering into information-sharing agreements.

• Educate staff about privacy rules governing the collection, retention, use, and disclosure, and safe and secure disposal of PHI as set out in PHIPA.

• Ensure that staff/custodians working off-site are aware of their privacy and security responsibilities.

• Develop a privacy culture.

*



11.3.2 Responding to an Incident

When faced with a potential privacy incident, you must respond quickly and ensure appropriate individuals within your organization are immediately notified of the incident (i.e. Privacy Lead and Privacy Officer).

Depending on the nature or seriousness of the privacy incident, there may be a need to contact senior management, client relations, or the information and technology and/or communications department within your organization. Your first two priorities in responding are containment and notification.30 Your organization will need to ensure that the breach is contained and that no further harm is done. You will also need to begin notifying the clients affected by the breach in case they need to take steps to help prevent further damage to their privacy. Once these are contained you continue to investigate and remedy the situation.

Remember that when addressing an incident in a multi-HIC initiative, it is very likely that your organization will have to work with others (e.g. Privacy Sub-Committee, partner organizations) in responding to the incident or implementing protocols or solutions to minimize the risk of future incidents. The HIC responsible for the breach should be the one to manage the breach response. However, they will need to work collaboratively with others if remedial action that they cannot address by themselves is required.

Remember! If a Privacy incident occurs:

• Contain • Notify • Investigate • Remediate

30What to do When Faced with a Privacy Breach: Guidelines for the Health Sector: Ann Cavoukian, Ph.D. Commissioner, Information and Privacy Commissioner, Ontario



11.3.3 Responding to Privacy Complaints

Responding to a privacy complaint is similar to responding to a privacy incident. In the situation where multiple HICs are accountable for the record, a privacy complaint may involve response by several organizations. The client will make a complaint to the organization with which they have the strongest clinical relationship, but they may actually be lodging a complaint that affects other HICs and health information network providers. In this case, the Privacy Leads at the affected HICs should decide who the most appropriate HIC to lead and respond to the complaint is. The responding HIC would work with the other HICs affected as required in mounting an appropriate response to the complaint.



Case Study

The project team for the Diagnostic Imaging Repository (DIR) is developing a plan to manage privacy incidents and complaints for the initiative. Multiple HICs are involved in this initiative so the plan must address how they will work together to manage an incident or complaint because it will likely involve more than one HIC.

Their first step in developing the plan is establishing mechanisms to identify potential incidents. The team decides that they will take a few approaches to identifying incidents. They will build logging and reporting tools into the system to monitor end-user behavior. The Privacy Leads at each of the participating organizations will be required to review the reports on a weekly basis to identify any suspicious activity. The team also develops an audit and compliance policy which allows the Privacy Sub-Committee to review the HICs’ privacy operations to ensure that they are working together effectively in addressing privacy issues and respecting client privacy.

The DIR team also establishes policies and procedures to handle privacy incidents and complaints if they occur. This is particularly important in the context of the DIR initiative because there are multiple hospitals involved. An incident or complaint will very likely involve multiple hospitals or the HIC responsible for an incident may not be the one who collected the PHI initially. Well defined policies and procedures help the hospitals understand how to work together to manage incidents and complaints. They identify who will be responsible for managing the response and the mechanisms in place to address the incident or complaint most effectively.

*



11.4 Checklist for Privacy Incidents and Complaints

Have you:

Identified and documented the Privacy Leads from each of the HICs involved?

Avoided potential privacy breaches and complaints by establishing your initiative with Privacy by Design principles?

Deployed mechanisms to assist you in identifying privacy incidents?

Created reports in the information repository to assist you in reviewing users’ behaviour on the system?

Established policies and procedures that guide staff and contractors in how to work with other organizations to address privacy breaches and complaints?

Provided training to end-users and system administrators on how to address breaches?







Incident Management Policy and Procedures

Policies and procedures to guide HICs’ response to a privacy-related incident


Complaint Form Form to be completed by an individual with a privacy-related complaint

Breach Notification Letter Sample letter to be sent to clients if their privacy is breached



12 Monitoring Compliance Monitoring compliance activities help to identify security and privacy incidents. (See Section 11 for more information about privacy incident management). Acting on instances of non-compliance reduces the risk of future privacy incidents.

Monitoring compliance in the health care system is usually focused on monitoring users’ engaging in improper client access patterns, such as those indicative of unusual behaviour that is not in compliance with your privacy program or privacy legislation. A monitoring solution needs to include reasonable safeguards to ensure that the health information in your custody is protected from intentional or unintentional use or disclosure that is in violation of your privacy program or privacy legislation (i.e., in alignment with PHIPA, agreements, and policies). Your solution should also have effective policies and procedures to respond to and mitigate privacy violations (e.g., incident management policy).

You also need to implement technical solutions that assist you in monitoring user behaviour and you need to carry out manual reviews of the privacy operations to ensure that they are effective.




Term Definition

Audit Review of a process, program or organization to ensure it meets objective standards (such as policies, legislation and related standards)

Compliance The extent to which a process, program or organization meets external standards


PHIPA requires that HICs have information handling processes in place that are compliant with PHIPA and that HICs ensure their agents and vendors follow the same (typically by obligating them contractually). PHIPA also requires that HICs follow the information handling practices that they establish.31


Establishing effective processes and having reliable reporting functionality are key activities to monitoring compliance. Your information management process and privacy reports should be diligently reviewed on a regular basis.

12.3.1 Establishing Processes to Review Compliance

Information systems can facilitate measuring benchmarks by providing reports on who accessed what information or when a consent directive was overridden without consent of the client. However, there must be a process by which these reports are regularly reviewed and investigated when issues are identified. This is particularly true in an environment with shared accountability for the health record.

31 While PHIPA does not explicitly require a monitoring compliance program, one could argue that an organization has not done its due diligence or met the spirit of PHIPA if it does not assess the extent to which the organization is following its own privacy policies, or those to which it must adhere to if it is involved with a broader information sharing initiative.

PHIPA Sections

Section 17



12.3.2 Logging and Reporting

Information systems support your compliance monitoring through tools that allow you to track, log and report on system activity.

12.3.2.1 Logging Logging records the traffic passing through your system and the action taken by the system (e.g., user requests access, system grants access). This recorded information, called a log message, is stored in a central storage location from which reports can be generated. By logging user behaviour and providing reports, you are able to see patterns and identify issues. The following activities should be logged:

• Access to PHI: Log the client, the user who accessed the information, the nature of the information the user accessed (e.g., lab results, demographics), and the date/time that the access occurred.

• Transfers of PHI: If possible, log when PHI was transferred from one HIC to another, the user who initiated the transfer, the PHI transferred (i.e., name of client, type of data), and the date/time of the transfer.

• Changes to consent directives: Log that a consent directive was created, modified or removed; the information to which the consent directive applied; the client to which the consent direct was applied; the person who authorized the change (i.e., client or SDM); and the date/time of the consent directive modification. If the SDM authorized the change, record his or her name and relationship to the client.

• Override of consent directives: Log that a consent directive was overridden, by whom, whether it was with or without consent, and the date/time. If overridden without consent, the reason of the override. If overridden with consent, the individual who gave consent (i.e., client or SDM), and if the SDM, the name and relationship to the client.

12.3.2.2 Alerts

An alert is a type of report generated automatically by the system and sent to the appropriate person about specific events or activities that were logged. An alert is usually sent to

Common types of alerts that are configured into a system are:

• Override without consent: When a consent directive is overridden without the client’s consent (i.e., “breaking the glass”)

• Anomalous activity: When anomalous behaviour is detected, such as looking for a client with the same last name

• VIP flags: When a provider accesses the record of a client who is at higher risk of privacy incidents



the accountable HIC. Alerts may also be sent to the affected client if needed.

You need to determine which types of alerts are appropriate for your initiative and who would receive them.

Alerts indicate that an activity should be investigated (e.g., a provider may be searching for a client who shares his or her last name because the client is in the provider’s care).

12.3.2.3 Reports

Reports are derived from the activity logged by the system. The system should generate reports on a regular or ad hoc basis for the accountable HIC to review and identify potential risks for privacy incidents. It is important that the accountable HIC incorporate these report reviews into his or her regular business process to ensure proactive monitoring of user behaviour.

12.3.3 Reviewing PHI Management and Privacy Operations

Regular reviews of PHI management and privacy operations are necessary to identify privacy incidents, as well as to identify ways to mitigate risks to privacy. Your organization should consider the following activities:

• Review system privacy reports: Regularly review the privacy-related reports that the system generates. This review should become part of the regular business process of the individual accountable for privacy on the initiative.

• Conduct Privacy Impact Assessments: PIAs are a good tool to help you identify gaps and mitigate risks in your privacy program. PIAs also help to identify and mitigate risks to client privacy. It is recommended that you conduct a PIA at various points in the project lifecycle, as well as when an initiative undergoes a substantial change. See the section on Integrating Privacy into Your Project Initiative to find out more on the benefits of PIAs.

• Conduct Operational reviews: Operational reviews are manual reviews of the PHI management processes and the privacy operations. These are similar to PIAs in that they examine all aspects of the initiative from a privacy point-of-view, but they are more focused on how privacy is actually being carried out in the initiative. Operational reviews are an opportunity to compare your initiative

Common types of reports are:

• Views of a client’s record: List of all users who accessed a particular client’s record. This information may also be required if the client lodges a complaint related to how his or her PHI was handled.

• Views by a particular user: A list of the clients that a particular user viewed.

• Changes in consent directives: Changes in the consent directives within a system.

• Consent directives overrides: Instances in which consent was overridden, with or without consent.



against the privacy benchmarks that you established earlier and are most effective when conducted by an independent third party. Use the Readiness Assessment to help you identify the core aspects that should be in place.

12.3.4 Taking Corrective Action

The final component of a monitoring compliance program is taking action. Once you identify an issue or risk, you need to take action to address and correct the risk. In the case of privacy incident, you would follow your incident management procedures to contain and investigate the incident, perform a root cause analysis to identify what caused the incident, and establish practices to minimize the risk of a future incident. A proactive approach in conducting regular privacy reviews will help with early identification of issues within privacy operations (i.e. reviewing system access reports on a regular basis).

If you identify a privacy risk after conducting a PIA or Operational Review, you should take action to mitigate the risk. The PIA or Operational Review normally provides recommendations on how to mitigate risks. Any privacy risks that you identify should be reported to the governance committee or other individuals responsible for the initiative. You should manage the issue until resolution. The nature of the resolution depends on the issue, but common activities include:

• User training

• Changes in privacy-related policies or procedures

• Changes in the way PHI is collected, used or disclosed

• Revisions to the governance model

• Increased communications with clients

To supplement the advice provided in this Toolkit, a good source for comprehensive guidance on establishing a privacy audit program is the Canadian Institute of Chartered Accountants.32

32http://www.cica.ca/



Case Study

The project team for the Patient Referal Program (PRP) is developing a monitoring compliance framework based on the privacy benchmarks they established at the beginning of their project.

The team works with the participating agencies to establish appropriate policies and procedures to guide monitoring compliance. Together, they agree that the Privacy Lead at each agency should conduct monthly reviews of the key privacy audit reports to help monitor user compliance. These audit reports are generated about both the end-users who are using the system, as well as the system administrators responsible for supporting the system.

The PRP project team, together with the participating agencies, agrees that the compliance monitoring framework will include annual reviews of the privacy policies and procedures. The review includes the PRP project team sending a questionnaire to each participating agency to perform a quick self-assessment of its privacy posture. The review also includes selecting two participants at random to take part in a more detailed on site review. An annual review will help strengthen the privacy program and identify any issues that may arise. It also helps the program team and executives to better understand how privacy is protected at the operational level (i.e., how privacy is really handled).

If a significant compliance issue is identified, it is referred to the Privacy Sub-Committee who works with the agency on resolving the issue. The Privacy Sub-Committee reports the issue and the suggested resolution to the Steering Committee. The Privacy Sub-Committee also reports the results of the self-assessments annually.

*



12.4 Checklist for Monitoring Compliance

Have you:

Designed and developed your systems to capture logs, as well as create alerts and reports on end-user and system administrator activity?

Established requirements for and provided training to Privacy Leads related to reviewing the reports on a regular basis?

Established mechanisms that HICs can use to regularly review their operations to ensure compliance?

Developed and documented a monitoring and review schedule?

Established benchmarks against which you can measure the effectiveness of the privacy program?

Maintained a list of the privacy risks associated with the initiative and identified methods to mitigate them?

Identified the decision-making process for determining whether the mitigation measures will be implemented?

Created a standing agenda item for the Privacy Sub-Committee to review arising privacy issues?





Audit Policy and Procedures

Policies and procedures to guide organizations in a compliance review





13 Safeguarding PHI The initiative has responsibility to establish safeguards that protect PHI and clients’ privacy. The collecting organizations have a responsibility to ensure that they are observing these safeguards and protecting PHI from inappropriate use and inadvertent release.

Safeguards should include physical security, technological security and administrative controls. Safeguarding PHI involves implementing controls and safeguards that protect the confidentiality, integrity, and availability of PHI, both in storage and in transit.




Term Definition

Threat and Risk Assessment (TRA)

Generally defined as a formal assessment of the security posture of a health application. A TRA follows specific methodology. The amount of detail required for a TRA depends on the stage of development of the health application.

Refer to eHealth Ontario’s Guide to Information Security for the Health Sector for detailed information on security and risk management.

Source: eHealth Ontario Guide to Information Security for the Health Care Sector - Information and Resources for Complex Organizations

Privacy and Security Architecture (PSA)

A PSA describes how the proposed health application will meet privacy and security goals and objectives. A PSA may exist as a standalone document or be integrated within an overall solution architecture document.

Source: CHI Electronic Health Record Infostructure (EHRi) Privacy and Security Conceptual Architecture,

Version 1.1

Vulnerability Assessment (VA)

A physical examination of the effectiveness of the security controls and safeguards of a health application. A VA is typically conducted from various network access points (e.g. internal, external). A VA makes use of automated tools to scan servers and probe for weaknesses in networks and services.

Source: CWE/SANS TOP 25 Most Dangerous Software Errors

OWASP Top 10 Application Security Risks - 2010

Penetration Test

A Penetration Test is typically a continuation of a VA, with the objective of obtaining something of value, e.g., a text file, password file, or classified document. A penetration test requires a more focused, manual effort, and is potentially more disruptive than a VA.

Source: CWE/SANS TOP 25 Most Dangerous Software Errors

OWASP Top 10 Application Security Risks - 2010




PHIPA requires HICs to implement basic security controls to safeguard PHI. PHIPA does not prescribe specific security controls. The legislation leaves it up to the HIC to implement appropriate controls based on the nature of the information handled, the type of health applications used, and the size of the organization.

PHIPA requirements for HINPs are somewhat more prescriptive, including:

• Providing to HICs, and to the general public, a description of the security controls in place protecting PHI from unauthorized disclosure, modification or destruction.

• Maintaining an audit trail of all transfers of PHI and of all accesses to PHI.

• Notifying HICs in the event of an incident.

• Assessing and documenting the threats, risks and vulnerabilities pertaining to the services offered by the HINP.

• Conducting privacy assessments to document the impact to individuals’ privacy of a given service offered by the HINP.


You should seek the expert advice of security experts who can help establish appropriate security requirements for your initiative and to protect PHI before you start collecting.

All organizations collecting, using or disclosing PHI should implement three types of safeguards to protect the confidentiality, integrity and availability of the PHI:

• Physical Safeguards: Securing physical assets such as computers, networking equipment and storage media. Controlling and monitoring physical access via use of locks, alarms and surveillance devices. Establishing appropriate media handling, disposal and destruction practices.

• Administrative Safeguards: Governance, policies and processes. Background checks, confidentiality agreements, acceptable use policies. Policies for notification and responding to access requests. User registration and access control policies. Incident management procedures.

• Technical Safeguards: Authentication, access control, session management, backup, encryption, network security, antivirus, and other technical controls.

PHIPA Sections

ss10 to 14



Remember! You should seek the expert advice of security experts who can

help establish appropriate security requirements for your

initiative and to protect PHI before you start collecting.

13.3.1 Establishing Security Requirements

There are a number of organizations that have developed extensive guidelines on security requirements for the protection of PHI.

Canada Health Infoway (CHI) developed a comprehensive set of physical, administrative and technical security requirements33 for organizations developing, hosting and accessing health applications. The appropriateness or applicability of these requirements varies depending on the nature of the application and on the role of the organization. Examples are provided below:

1) HICs and HINPs responsible for developing health applications would be largely concerned with implementing technical safeguards such as access control, encryption and audit. These organizations should:

• Ensure that privacy and security business requirements are defined.

• Develop a privacy and security architecture (PSA) that illustrates how requirements are met by the proposed solution.

• Develop detailed privacy and security technical design specifications.

• HICs and HINPs responsible for hosting and supporting health applications would develop safeguards based on the scope and user base of the application. For example:

o A HINP hosting an EHR supporting multiple HICs should develop a comprehensive set of policies and operational processes (e.g., incident management, change management, help desk, registration, audit, and monitoring).

o The hosting provider should also provide a secure hosting facility and be able to ensure availability, as well as recoverability in the event of a disaster.

o A HINP must also support the measures prescribed by PHIPA as noted above.

33Electronic Health Record (EHR) Privacy and Security Requirements V1.1, November 30, 2004, Revised February 7, 2005



2) HIC end-users of health applications should develop safeguards focused primarily on protecting access points (e.g., workstations, portable devices, wireless networks and office premises) and ensuring appropriate user behaviour (e.g., protecting passwords, confidentiality agreements and training).

In addition to the CHI Privacy and Security requirements document referred to above, there are other resources that you can use to develop appropriate security safeguard requirements. COACH published a comprehensive guide34 to securing PHI, and various professional associations and governing bodies published policies and standards of practice35 with respect to protecting PHI.

The Ontario Information and Privacy Commissioner (IPC) issues guidelines and directions that may also assist organizations in developing appropriate safeguard requirements.

13.3.2 Managing Vendors

Agreements with vendors should contain appropriate provisions regarding the vendor responsibility for protecting the security of PHI. The exact provisions depend on the vendor’s role (e.g., development, hosting, management, support).

Your vendors should be required to clearly state whether they will store or handle the PHI outside of Ontario or access the health application hosting environment from locations outside of the province. Appropriate provisions should be included in agreements restricting out-of-province access to PHI where possible. If it is not possible to restrict access to PHI from out-of-province, the agreements should require vendors to still observe the principles of PHIPA.

All vendor access to PHI should be audited and the vendor should be required to provide your organization with a list of all personnel who will access environments containing PHI. Vendor access to environments containing PHI should be allowed only on an “as needed” basis rather than being provided access on an ongoing basis. That is, they would request permission to access the system when required to troubleshoot or provide maintenance. Once completed, their access rights would be cancelled.

Remember! Appropriate provisions should be included in agreements

restricting out-of-province access to PHI where possible.

342009 Guidelines for the Protection of Health Information 35 For example, the Canadian Medical Protective Association (CMPA) issued an Electronic Records Handbook, which includes guidelines for securing PHI.



13.3.3 Establishing Security Policy

At a minimum, a security policy should document the accountabilities and responsibilities of all the people in the initiative who maintain the security of sensitive information such as PHI. The policy should also include responsibilities for responding to access requests and for responding to incidents. Security-related processes and practices should be documented separately from the main security policy document since they are likely to change frequently.

13.3.4 Securing Users Workstations

You should ensure that all workstation operating systems are legally licensed and are kept up-to-date with the latest security patches (there are operating system settings that automate this process). Some third-party applications are particularly prone to security vulnerabilities and should be kept patched and up-to-date. You should not install third-party utilities on users’ workstations if they are not required.

The following security measures should be considered for protecting PHI at users’ workstations:

• If using MS Windows, enable the included firewall software and install effective anti-virus/anti-spy ware protection.

• Most new wireless networking products (i.e. wireless access routers) enable encryption by default. You should not disable encryption, and should use WPA2 encryption where possible.

• Instruct users to never use public Internet access points for accessing or transmitting PHI.

• Ensure that PHI is stored in encrypted form on portable or removable devices (e.g., laptops, tablets, smart phones, CD/DVD, USB sticks).

• Ensure that there are appropriate policies and procedures in place for the secure disposal of any media containing PHI, e.g., hard drives, CD/DVD, printouts.

• Install the latest Web browser versions. For MS Windows use either Internet Explorer 8 or above, or Mozilla 3.6 or above. These browser versions have significantly enhanced privacy and security controls over previous versions. Be sure to review the security and privacy features of the browser, such as private browsing.

Remember! Instruct users to never use public Internet access points for

accessing or transmitting PHI.



13.3.5 Registering Users

When registering (i.e., signing-up) end-users to use health applications, your registrars should positively identify the users by verifying their identification and record their contact information (e.g., telephone numbers, e-mail address) in the event there is a need to contact the user (e.g., for support purposes).

Registrars should keep track of whether users require access to health applications on an ongoing basis and user accounts should be monitored for inactivity and deactivated as appropriate. Your health applications should support the temporary deactivation of user accounts (e.g. to support temporary leaves of absence), as user accounts should not be entirely deleted or removed—only deactivated. There may be a requirement to identify users when reviewing audit logs at a later date.

13.3.6 Authenticating Users

Access to PHI via the Internet (or any untrusted networks) should not be permitted unless the user is authenticated via a strong mechanism such as two-factor or enhanced authentication. Basic user ID and passwords authentication mechanisms are not sufficient to protect PHI that is exposed to the Internet threat environment.

All organizations understand the need to uniquely authenticate end-users of health applications. However, often overlooked is the requirement to uniquely authenticate your administrators, support staff and vendor staff. These types of users should never be allowed to authenticate using shared accounts such as “administrator” or “root.” You should provision your Vendors with separate credentials for all of their staff who access the application environment.

Managing multiple sets of credentials required for different health applications is a challenge for end-users, particularly busy health care practitioners and their staff. Until a province-wide single sign-on (SSO) solution is implemented, the issue of managing multiple sets of credentials will be a problem. The use of password management utilities can serve to help end-users practice good password management. Standalone password management utilities are preferred, but the utilities integrated with popular Web browsers can be secure if configured and used appropriately.

Health applications should be designed so that newly registered users are provisioned with temporary passwords. The users should then be required to change their password upon initial login to the health application. Forcing users to change their passwords on a frequent basis is not conducive to good password management practices. It is preferable to have a user use a strong password that changes infrequently (if at all), than to have the user choose a weak password (or use the same password for all applications).

The need for system-to-system authentication is often overlooked. For example, two systems that exchange HL7 messages across a network should be required to authenticate to one



another. This is typically achieved via the use of TLS/SSL mutual authentication using X.509 certificates. However, less secure methods (simple one-way authentication via passwords) may be acceptable depending on the circumstances.

13.3.7 Controlling Access

With PHI-sharing initiatives, controlling access is a very important issue because users who are not within the circle-of-care often have access to the system. Where possible, you should deploy role and relationship-based access controls. See sub section 10.3.2 in the section on Collecting, Using and Disclosing PHI, for a more comprehensive discussion of role and relationship-based access.

If providing the ability for delegated access (e.g., referrals), the system should provide the option of time-limiting the delegation.

Consent directives are simply another form of access control. They should be considered accordingly when documenting the access control model and when assessing the security of health applications (e.g., TRA).

Any activities relating to consent management (e.g., add or remove a consent directive, override consent) should be recorded in the application audit log. See Section 12, Monitoring and Compliance for more information

13.3.8 Testing and Using Test Information

Past experience has shown that “real” client information (i.e., PHI) is usually required at some point for testing purposes in the lifecycle of a health application. Organizations believing that all testing and troubleshooting can be conducted using anonymized, de-identified or fabricated client information may discover that this is not always the case.

13.3.9 Protecting Information

When implementing your health applications you should create and maintain an inventory of all information repositories (both permanent and temporary) containing PHI. Examples include databases, queues, file directories and temporary folders.

Organizations should take precautions to ensure that in the event that “real” PHI is required for testing or troubleshooting purposes:

• The test environments are appropriately protected with safeguards and controls,

• The test information is completely cleansed or removed from the test environments when testing is completed, and

• Access to the test environments is strictly controlled during testing.

Also see the previous section on de-identification of information.



PHI should not be collected unnecessarily such as if queues or log files containing PHI are required for troubleshooting purposes (e.g., logs of transactions or HL7 messages). The files should be retained for as short a period as possible and queues should be purged on a regularly scheduled basis.

All printed reports (including printable files such as PDFs) should be labeled appropriately, including:

• The sensitivity of the information

• Instructions for handling the information appropriately (e.g., “This information must be handled in accordance with your organization’s policies for the secure use and disposal of sensitive information”)

• The source of the information

• The completeness of the document (e.g. “page 4/5”)

Your applications should be architected and designed in accordance with the principle of identity protection. CHI defines identity protection as a service that facilitates “the separate storage of personal information that uniquely identifies individuals (e.g., name, address, health card number) from health information relating to their care and treatment.” In practice, identity protection is usually achieved by use of an internal identifier such as an ECID.36 This internal identifier is used to link identifying information (e.g., client demographic information) to clinical information and anyone accessing the clinical information on its own would not know to which individual the information pertains.

13.3.10 Auditing

While organizations often have appropriate measures in place for auditing end-user access to PHI, auditing of administrator and vendor access to PHI is often overlooked. HICs are required under the Medicine Act37 to maintain an audit trail of changes to PHI. HINPs are required under PHIPA to maintain an audit trail of all transfers of PHI and all access to PHI.

It is good practice for organizations to conduct proactive monitoring of access to PHI, particularly for clients at elevated risk of disclosure. You should log security-related events, e.g., user authentication events (successful and unsuccessful). You should also have processes and tools for running reports against audit log data to respond to requests from HICs and clients. See Section 12, Monitoring and Compliance for further information.

36EHRi Client Identifier 37Medicine Act, 1991 – O. Reg. 114/94 s. 20.



13.3.11 Encrypting

Organizations should ensure that PHI is strongly encrypted in specific circumstances. Encryption provides another layer of protection from privacy and security threats. As part of good practice, you can refer to several resources (e.g. eHealth Ontario and Canada Health Infoway) for guidance. Generally, there are four situations where information encryption should be mandatory:

1. PHI transmitted across untrusted networks,38e.g., the Internet, must be encrypted while in transit.39

2. Credentials such as passwords and answers to challenge/response questions must be encrypted at all times, in storage and in transit.

3. PHI stored on portable or removable media must be encrypted. Examples include:

• Laptops, netbooks, tablets and smart phones

• USB Keys and flash memory cards

• Removable and external hard drives

• CD-ROM, DVD-ROM and other optical media

• Backup tapes40

4. PHI transmitted across wireless networks must be encrypted while in transit.

38 The eHealth Ontario ONE Network is considered to be a trusted network, therefore, encryption of information in transit is not mandatory 39 It is generally preferable to encrypt information at the transport level (e.g., SSL/TLS), or message level, rather than at the network level (e.g., IPsec) 40 Care should be taken when encrypting backup tapes—the loss of the encryption key will render the information unrecoverable. Standard practice is to only encrypt tapes if the tapes will be moved off-site from the hosting facilities.



Case Study

The Digital Imaging Repository (DIR) project team becomes aware of a privacy incident at a hospital, whereby sensitive PHI of a local politician was accidentally disclosed and became the subject of many rumours in the media. The incident underscores the importance of safeguarding PHI.

The project team reviews its safeguards and determines that PHI is well-protected from external threats, but identifies gaps in the safeguards that protect the PHI from internal threats (i.e., end-users and system administrators).The team needs to be more pro-active to avoid a privacy incident by protecting against malicious and accidental internal threats.

The program team works together with the Privacy Subcommittee to:

• Review training records to ensure that all staff and consultants have undergone privacy and security training and that the training is up to date. Refresher training is conducted annually and as new policies and procedures need to be communicated. Training includes responsibilities regarding confidentiality, best practices for passwords, securing work stations, proper handling and disposal of sensitive materials, and procedures for lost ID badges and visitor access procedures (especially to highly sensitive areas).

• Conduct a review of personnel (in particular those who have access to highly sensitive information and assets that are critical to the functioning of the initiative) and ensure that they have undergone security screening as appropriate and that the screening is up to date.

• Brief managers and system administrators on the importance of system access controls and termination processes. Access to PHI is only granted to authorized persons who require access to the PHI as part of their duties and who have an appropriate level of authority and training to warrant access. Recovery of assets (like ID cards and keys) from terminated individuals is documented.

• Collaborate with IT departments to ensure IT security reviews, such as Threat and Risk Assessments, are conducted periodically.

• Review the incident response policies and procedures and conduct a test of the process to ensure the measures in place will be effective. Where needed, they update the documentation.

• Review the SLA with the Service Provider to ensure the provider’s security and privacy training, and security screening requirements are equivalent or comparable.

*



13.4 Checklist for Safeguarding PHI

Have you:

Conducted TRAs, VAs and security audits as necessary?

Established a minimum benchmark that all HICs must meet?

Established processes for identity verification?

Included appropriate security provisions in vendor agreements?

Developed media handling and disposal policies and processes?

Employed encryption technologies appropriately?

Developed processes for keeping software updated and patched?

Deployed workstation and network security controls (e.g. antivirus, firewalls)?

Reviewed and applied security guidelines from other organizations such as CHI and COACH as necessary?

Trained registration agents (or managers) about granting and controlling access to authorized end-users?

Provided security-related training to end-users (such as best practices for passwords, appropriate disposal of printouts and similar topics.)?








Service Level Agreement Agreement between HIC(s) and HINP(s)



Section 7: Appendices You will find in this section:

• Appendices referred to within the Toolkit



Toolkit Tools and Templates




Access and Correction Policy and Procedures

Policies and procedures to guide a client’s access to and correction of his or her PHI



Breach Notification Letter Sample letter to be sent to clients if their privacy is breached

Complaint Form Form to be completed by an individual with a privacy-related complaint

Confidentiality Agreement

Agreement that agents would sign to guide confidentiality of PHI

Consent Form To be completed by the user obtaining consent

Consent Override Letter Template to inform patient of (temporary) consent directive override, and timeframe of override

Consent Policy and Procedures

Policies to guide consent and consent directive management

Consent Reinstatement Form

To be completed by the client or SDM to reinstate consent for use and disclosure of his or her record

Consent Script Sample script to be read by the person obtaining consent about the purpose of PHI collection and the client’s right to complain and withdraw consent

Consent Withdrawal To be completed by the client or SDM to withdraw consent for use and disclosure of some or all of his or her record

Data Sharing Agreement Agreement to govern data disclosures among HICs




Denial of Access Notification

Sample letter to the client indicating that a request for access has been denied

Incident Management Policy and Procedures

Policies and procedures to guide HICs’ response to a privacy-related incident




Notification to the User Performing a Consent Override

Notification that a shared information repository should present to the end-user when overriding a consent directive

Policies and Procedures Sample of a common set of privacy policies and procedures for healthcare organizations that electronically share PHI

Privacy Impact Assessment

Template for conducting a PIA in shared environment

Privacy Lead Roles and Responsibilities

List of roles and responsibilities for the privacy lead, the organizational representative for privacy issues with respect to the initiative

Privacy Sub-Committee ToR

Terms of Reference for the Privacy Committee, a sub-committee of the Steering Committee for the initiative

Public Notice Sample notice informing clients of the purpose of PHI collection and their right to complain and withdraw consent

Readiness Assessment Template checklist to determine privacy readiness for an initiative

Request for Access Template for a client or SDM to request to view his or her PHI




Request for Correction Template for a client or SDM to request a change in his or her PHI

Response to Correction Request

Sample letter to the client regarding how the correction request was addressed


Risk Response Matrix Template to record and monitor status of recommendations identified during review (i.e., PIA, Readiness Assessment) process

Service Level Agreement Agreement between HIC(s) and HINP(s)

Training Policy and Procedures

Policies requiring an organization to provide privacy-awareness training to its end-users prior to being given access to the system




Glossary of Terms and Acronyms

Term Definition

CCAC Community Care Access Center

CCIM Community Care Information Management

CHC Community Health Centre

CHI Canada Health Infoway

CIHR Canadian Institutes of Health Research

CIPP Certified Information Privacy Professional

CMHA Canadian Mental Health Association

CMPA Canadian Medical Protective Association

COACH Canada’s Health Informatics Association

CSA Canadian Standards Association

CSA Canadian Standards Association

DIR Diagnostic Imaging Repository

DSA Data Sharing Agreement

EHR Electronic Health Record

EHRi Electronic Health Record Infostructure

FIP Fair Information Principle

FIPPA Freedom of Information and Protection of Privacy Act

HCP Healthcare Provider

HIA Health Insurance Act

HIC Health Information Custodian



Term Definition

HINP Health Information Network Provider

HL7 Health Level 7

HSP Health Service Provider

iEHR Interoperable Electronic Health Record

IPC Information and Privacy Commissioner of Ontario

IPC Information and Privacy Commissioner

IPsec Internet Protocol Security

LHIN Local Health Integration Network

LTC Long-Term Care

MFIPPA Municipal Freedom of Information and Protection of Privacy Act

MH&A Mental Health & Addiction

MOHLTC Ministry of Health and Long-Term Care

OECD Organization for Economic Cooperation and Development

OHA Ontario Health Authority?

OLPP Ontario LHIN Privacy Project

OWASP Open Web Application Security Project

PbD Privacy by Design

PHI Personal Health Information

PHIPA Personal Health Information Protection Act

PI Personal Information

PIA Privacy Impact Assessment



Term Definition

PIPEDA Personal Information Protection and Electronic Documents Act

PRP Patient Referral Program

PSA Privacy and Security Architecture

SDM Substitute Decision Maker

SLA Service Level Agreement

SSO Single Sign-on

TLS/SSL Transport Layer Security / Secure Sockets Layer

ToR Terms of Reference

TRA Threat and Risk Assessment

VA Vulnerability Assessment