Embed Size (px)
Citation preview
Privacy and Security Management Plan
VERSION 3.0 (REVISED)
1 | P a g e
Contents Publication History ......................................................................................................................................................5
Glossary........................................................................................................................................................................6
Introduction ..................................................................................................................................................................9
Facilitating Care to Mothers............................................................................................................................................... 9
Facilitating Care to Babies............................................................................................................................................... 10
Supporting Individual Providers....................................................................................................................................... 10
Informing Provider Organizations .................................................................................................................................... 11
Informing the System....................................................................................................................................................... 11
PART 1: Privacy Policies and Procedures...............................................................................................................13
P-01: Privacy Policy in Respect of CHEO’s Status as a Prescribed Person ................................................................... 13
P-02 and S-02: Triennial Review of Privacy and Security Policies and Procedures........................................................ 22
P-02A: Annual and Quarterly Reports on Privacy and Security ...................................................................................... 24
P-03: Transparency of Privacy Policies and Procedures................................................................................................. 26
P-04: Collection of Personal Health Information and P-06: Statements of Purpose for Data Holdings Containing Personal Health Information ............................................................................................................................................ 28
P-05: List of Data Holdings Containing Personal Health Information .............................................................................. 32
P-07: Statements of Purpose for Data Holdings Containing Personal Health Information .............................................. 34
P-08: Limiting Agent Access to and Use of Personal Health Information........................................................................ 39
P-09: Log of Agents Granted Approval to Access/Use/Disclose Personal Health Information........................................ 44
P-10: Use of Personal Health Information for Research.................................................................................................. 45
P-11: Log of Approved Uses of Personal Health Information for Research .................................................................... 51
P-11A: Data Tracking Log ............................................................................................................................................... 51
P-11B: Certificate of Destruction ..................................................................................................................................... 52
P-12: Disclosure of Personal Health Information for Purposes Other Than Research.................................................... 54
P-13: Disclosure of Personal Health Information for Research Purposes and the Execution of Research Agreements. 65
P-14: Template Research Agreement ............................................................................................................................. 73
P-15: Log of Research Agreements ................................................................................................................................ 74
P-16: Data Sharing Agreements...................................................................................................................................... 75
P-17: Template Data Sharing Agreement: Disclosure of Personal Health Information ................................................... 77
P-17A: Template Data Sharing Agreement: Collection of Personal Health Information.................................................. 77
P-18: Log of Data Sharing Agreements........................................................................................................................... 78
P-19: Executing Agreements with Third Party Service Providers in Respect of Personal Health Information ................ 79
P-20: Template Agreement for All Third Party Service Providers.................................................................................... 82
2 | P a g e
P-21: Log of Agreements with Third Party Service Providers.......................................................................................... 83
P-22: Linkage of Records of Personal Health Information............................................................................................... 84
P-23: Log of Approved Linkages of Records of Personal Health Information ................................................................. 87
P-24: De-Identification and Aggregation.......................................................................................................................... 88
P-25: Privacy Impact Assessments ................................................................................................................................. 90
P-26: Log of Privacy Impact Assessments Initiated/Completed ...................................................................................... 94
P-26A: Log of Privacy Impact Assessments Not Undertaken.......................................................................................... 94
P-27: Privacy Audits ........................................................................................................................................................ 95
P-28: Log of Privacy Audits ............................................................................................................................................. 98
P-29: Privacy Breach Management................................................................................................................................. 99
P-29A: Breach Management Protocol ........................................................................................................................... 106
P-29B: Breach Reporting Form ..................................................................................................................................... 108
P-30: Log of Privacy Breaches ...................................................................................................................................... 109
P-31: Privacy Complaints .............................................................................................................................................. 110
P-32: Log of Privacy Complaints and Privacy Inquiries ................................................................................................. 116
P-32A: Complaint Form................................................................................................................................................. 117
P-33: Privacy Inquiries................................................................................................................................................... 118
PART 2: Security Policies and Procedures ...........................................................................................................120
S-01: Information Security Policy .................................................................................................................................. 120
S-02: Ongoing Review of Security Policies and Procedures ......................................................................................... 124
S-03: Ensuring Physical Security of Personal Health Information ................................................................................. 125
S-04: Log of Agents with Access to the BORN Work Premises .................................................................................... 129
S-05: Retention of Records of Personal Health Information.......................................................................................... 130
S-06: Retention of Records of Personal Health Information on Mobile Devices ........................................................... 133
S-06A: Agreement for Use of Mobile Devices/Remote Access ..................................................................................... 137
S-06B: Log of Agent Use of Mobile Devices/Remote Access ....................................................................................... 138
S-07: Secure Transfer of Records of Personal Health Information ............................................................................... 139
S-08: Secure Disposal of Records of Personal Health Information ............................................................................... 142
S-08B: Certificate of Destruction of Personal Health Information.................................................................................. 144
S-09: Passwords and Multi-Factor Authentication......................................................................................................... 145
S-10: System Control and Audit Logs ........................................................................................................................... 147
S-11: Patch Management.............................................................................................................................................. 151
S-12: Change Management .......................................................................................................................................... 153
S-13: Back-up and Recovery of Records of Personal Health Information..................................................................... 157
3 | P a g e
S-14: Acceptable Use of Technology ............................................................................................................................ 159
S-15: Security Audits ..................................................................................................................................................... 161
S-16: Log of Security Audits .......................................................................................................................................... 164
S-17: Security Breach Management.............................................................................................................................. 165
S-18: Log of Information Security Breaches.................................................................................................................. 173
S-19: Application Security ............................................................................................................................................. 174
S-20: Encryption & Key Management ........................................................................................................................... 176
S-21: Roles Based Access Controls for the Azure Environment ................................................................................... 180
PART 3: Human Resources Policies and Procedures ..........................................................................................182
HR-01 and HR-03: Privacy and Security Training and Awareness ............................................................................... 182
HR-02 and HR-04: Log of Attendance at Privacy and Security Training ....................................................................... 186
HR-05: Execution of Confidentiality Agreement by Agents ........................................................................................... 187
HR-06: Template Confidentiality Agreement with Agents.............................................................................................. 189
HR-07: Log of Executed Confidentiality Agreements with Agents................................................................................. 190
HR-08 and HR-09: Job Description for Position(s) Delegated Day-to-Day Authority to Manage the Privacy and Security Programs....................................................................................................................................................................... 191
HR-10: Termination or Cessation of the Employment or Contractual Relationship....................................................... 192
HR-11: Discipline and Corrective Action........................................................................................................................ 194
PART 4: Organizational and Other Policies and Procedures...............................................................................196
O-01 and O-02: Privacy and Security Governance and Accountability Framework ...................................................... 196
O-03: Terms of Reference for Committees with Roles with Respect to the Privacy Program and/or Security Program197
O-04: Corporate Risk Management Framework............................................................................................................ 201
O-05: Corporate Risk Register ...................................................................................................................................... 204
O-06: Maintaining a Consolidated Log of Recommendations ....................................................................................... 205
O-07: Consolidated Log of Recommendations.............................................................................................................. 206
O-08: Business Continuity and Disaster Recovery Plan................................................................................................ 207
O-08A: Business Continuity Incident Summary Report ................................................................................................. 211
4 | P a g e
Publication History
A detailed publication history is available on the BORN shared drive at:
GENERAL\Privacy\BORN Privacy and Security Management Plan
Version Changes
Version 3
(Revised)
Updates incorporated as a result of review by Information and Privacy
Commissioner of Ontario in 2020
Version 3 Updates based on new policies and procedures document for migration to Azure,
revised governance and other initiatives as a result of the annual review process
commenced August 2018.
Version 2 October 28, 2016. Communicated to BORN Agents.
Version 1.9c Significant updates following on-going review from 2014 – 2016.
Version 1.9b Tracking all revisions between version submitted to IPC in October 2013 to
approval of version 2.0*.
Version 1.9a Submitted to Information and Privacy Commissioner of Ontario as part of the
three-year review of prescribed persons and prescribed entities. See Description of
Changes below this table to review new and changed content.
Version 1.9 Formatting changes throughout document.
Version 1.8 Original BORN Privacy and Security Management Plan Approved by Information
and Privacy Commissioner of Ontario in October 2011
5 | P a g e
Glossary Term Definition
Agent In relation to BORN, a person that, with the authorization of BORN, acts for or
on behalf of BORN in respect of PHI for BORN purposes, and not the agent’s
own purposes, whether or not that agent has the authority to bind BORN and
whether or not that agent is employed by BORN and whether or not the agent
is being remunerated by BORN.
Application Service
Provider
The Service Provider organization responsible for developing the application
code and database leveraged by BORN for the BIS, including maintenance and
support services. The Application Service Provider also provides managed
services.
BIS The BORN Information System, comprised of the application code and
database used by BORN and BORN’s Agents for the registry functions.
BORN “Children’s Hospital of Eastern Ontario-Ottawa Children’s Treatment Centre with respect to the Better Outcomes Registry and Network of Ontario” or
simply “Better Outcomes Registry and Network of Ontario”. BORN is
recognized in regulations under s. 39(1) (c) of PHIPA as a prescribed person
who compiles or maintains a registry of Personal Health Information.
CEO Chief Executive Officer of CHEO
CHEO Children’s Hospital of Eastern Ontario – Ottawa Children’s Treatment Centre
Communications Lead A CHEO employee who is delegated certain responsibilities for implementing
changes to web site materials and printed as described in this Plan.
Coordinators
A CHEO employee who is delegated certain responsibilities for coordinating
data collection. Such Agents may be situated across the Province of Ontario
and form part of the BORN perinatal engagement team that support high
quality data collection and use from health information custodians providing
data to BORN.
Data Dictionary A dictionary of each data element in the BORN information system including a
description of the data element and a list of its parameters.
Data Request and
Research Coordinator
The CHEO employees that are delegated certain responsibilities for
implementing activities related to use and scientific analysis of BORN
information and disclosure requests (including de-identified and aggregated
disclosure requests) as described in this Plan.
6 | P a g e
Term Definition
Data Requestor
A person requesting access to Personal Health Information or data created
using Personal Health Information (such as aggregated data or De-identified
Data).
Data Sharing
Agreement
A data sharing agreement with participating organizations that sets out the
rights and responsibilities of the organization and BORN with regard to
Personal Health Information.
De-identification
The process of removing or obscuring personal information from a record or
data set to the extent necessary so that it is no longer reasonably foreseeable
in the circumstances that it could be used, either alone or in combination with
other information, to identify an individual.
De-identification
Tools
The software tools and related services, if any, used for the De-identification
of data including (in the case of products marketed by Privacy Analytics or
their successors) the products referred to as Eclipse and PARAT and any
successor products used by BORN.
Executive Director The Executive Director of BORN.
Health Care Has the meaning set out in s. 2 of PHIPA.
Hosting Provider
The organization responsible for hosting the servers which contain the
application code and database leveraged by BORN for collection, use and
disclosure of the Registry information.
Information Security
Officer
The CHEO employee who is delegated certain responsibilities for
implementing activities related to technology and information security as
described in this Plan.
Mobile Computing
Equipment
Includes laptops, Universal Serial Bus (USB) flash drives, external hard drives,
CDs, DVDs and other authorized mobile and mass storage devices.
Personal Health
Information or PHI Has the meaning set forth in section 4 of PHIPA.
PHIPA
Personal Health Information Protection Act, S.O. 2004 is Ontario’s health-
specific privacy legislation. It governs the manner in which Personal Health
Information may be collected, used and disclosed within the Health Care
system.
Plan This Privacy and Security Management Plan.
7 | P a g e
Term Definition
Privacy Officer The CHEO employee who is delegated certain responsibilities for
implementing activities related to privacy as described in this Plan.
Research Has the meaning set out in section 2 of PHIPA.
Research Ethics Board Has the meaning set out in section 2 of PHIPA.
Service Provider An organization who provides goods or services under Section 10(4) of PHIPA
and related provisions.
System Administrator
A CHEO employee who is delegated certain responsibilities for managing the
administration of the BIS, including management of the database, users,
critical applications, and elements of the disaster recovery and business
continuity plan.
8 | P a g e
Introduction BORN is a registry established in Ontario under PHIPA for the purpose of facilitating and/or improving
the provision of Health Care in Ontario, with a vision for the best possible beginnings for lifelong health.
A trusted source for timely, high-quality maternal-child health information, BORN facilitates and/or
improves the care offered to mothers and children through a number of current or anticipated
initiatives:
Facilitating Care to Mothers 1. Gestational Diabetes Screening Reminder. Mothers testing positive for
gestational diabetes require follow-up as they are at increased risk for Type 2 diabetes and its
many resultant complications later in life. The Registry can gather the gestational diabetic status
from any of a number of antenatal providers (family doctor, midwife, obstetrician, birthing
hospital) and then alert the primary care physician to ensure appropriate follow-up care is
offered. (This is under development and will include informing the affected persons that the
disclosure will occur. These persons will be offered the option to opt-out of the program by
filling out an opt-out form that will be available on the BORN website at www.BORNOntario.ca)
2. Improving Screening Algorithms. Screening is a mechanism to assess and report
risk and as such, involves false-positive and false-negative results. While this is expected, the
anxiety for families upon receiving a positive screen is significant, and the impact on individuals
with a false negative result can be catastrophic. By gathering all screening results and all
associated follow-up and outcome information, trained analysts can review the information to
identify triggers for the false results. Once analyzed, the screening thresholds can be adjusted to
reduce false-positive and false-negative results. The costs of false negative can be significant –
from lifelong disability to potential death. Reduction in the false positives will reduce the
number of families impacted by the anxiety associated with a positive result.
3. Ontario Perinatal Record. Complete pregnancy history and documentation of care is
tracked across providers using the provincially-supported Ontario Perinatal Record (previously,
the Antenatal 1 and Antenatal 2 forms). These forms should be sent to the birthing hospital at
35 weeks’ gestation. BORN survey results, however, suggest that persons frequently give birth
without their providers having access to this information – either they deliver unexpectedly,
early, or the forms cannot be located. Providing access to these forms in emergent situations
will ensure that providers have key clinical information available and also reduces the
duplication of tests used to facilitate care (ultrasounds and laboratory).
9 | P a g e
Facilitating Care to Babies 1. Missed Screens. Newborn Screening Ontario tests for 29 rare diseases in newborns. Test
results can lead to early identification and proper, life-saving treatment. By capturing every birth
in the province and then cross-referencing to every baby tested by Newborn Screening Ontario,
BORN can promptly identify the babies that have not been tested and inform the primary care
provider to ensure the test is offered.
2. Being born in the right place at the right time. Newborns from high-risk
pregnancies do best when they are born in the centre best equipped to handle their complex
needs (e.g. being born in the best possible place at the right time). For example, if neonatal
surgery is required, delivering at a hospital that can provide that care is critical to the best
possible outcome for the baby. Hospitals across the province have specific levels of care they
can provide. Ensuring they are appropriately accepting or diverting patients is key to improving
outcomes for this vulnerable population.
Supporting Individual Providers 1. NTQA. Nuchal translucency (NT), a measurement on the neck of the fetus during ultrasound,
is a key component in the prenatal screening algorithm. With values smaller than a millimetre
being an important differentiation, it is critical that sonographers measure it accurately. Much
work has been done internationally on quality assurance of NT measurements that involve
plotting all measurements done by a single sonographer and comparing the distribution to
accepted norms. BORN is able to collect these key measurements from labs across the province
and report back to sonographers and their managers on the quality of their work. By minimizing
errors in NT measurements, prenatal screening results will be much more accurate, reducing
false positives and false negatives and the associated repeat tests and analysis.
2. Discrepant Practice. Key indicators such as caesarean section rates and other labour
interventions show significant variation across the province. Tracking, reporting and addressing
these variations will ensure persons in the province are offered consistent, high-quality and
appropriate care. Once data are available, BORN coordinators will work with the hospital or
individual provider to understand why their rates are discrepant and to develop and implement
quality improvement strategies.
3. Midwifery Billing. In order to be the authoritative source for births in the province of
Ontario, midwifery information must be combined with hospital birth information. Timely, high-
quality data collection is supported by having the data entry linked to payment. The Ministry of
Health has asked that BORN collect, on their behalf, both clinical and administrative data
elements associated with the billing agreement between the Ministry of Health and the Ontario
midwifery community.
10 | P a g e
Informing Provider Organizations 1. Access to Aggregate data. Health-care providers collect key clinical information for
an individual as part of every visit such as the clinical details associated with labour, including
the indications for interventions, the timing of the labour, the medications and analgesia
administered and final outcome for mother and baby. It is only when these data are aggregated
that the information highlights important trends in the care being provided, for example, many
persons having emergency caesarean sections, or many persons being induced rather than
labour starting spontaneously. Providers are willing to invest the time required to enter the
information into the BORN system because it provides them great value for program planning
and management of care to analyse their data in aggregate.
2. Benchmarks and Key Performance Indicators. The aggregate information
does allow for analysis of a provider’s own information. That same information becomes much
more meaningful when compared to one’s peers through the use of Benchmarks or when
compared to Key Performance Indicators with organizational targets. With 100% of birthing
hospitals and midwives providing data to BORN, we are well positioned to facilitate access to
key benchmarks by geography and level of care for care providers across the province.
Informing the System 1. Unexplained poor outcomes, such as increased anomalies. As an
authoritative source of maternal-child health outcomes information, BORN is the only
organization in the province with timely access to related health trends in the population. For
example, a potential cluster of congenital anomalies was suspected in south-western Ontario. It
was through detailed analysis of the data entry, outcomes, risk factors, and interventions using
BORN data that the signal of a potential cluster was found to be in error.
2. Reports. The Ontario Health Care system is dependent on high-quality information for
decision making. Public Health Units regularly request reports from BORN to plan the delivery of
services in their region. Using aggregate information from the BORN information System, we can
inform regions and populations of key trends that need to be addressed.
3. Effectiveness. Providing feedback to Public Health Units and health promotion agencies on
the effects of their campaigns around smoking cessation, breastfeeding promotion, prenatal
class attendance and the relationships between these campaigns and newborn and childhood
outcomes will help improve the care provided to mothers and children.
4. Determinants of Health. Providing health policy makers with information on the
determinants of health (through collection of demographic information) and outcomes will help
create the knowledge of how these factors affect health status of mothers, infants and children.
11 | P a g e
Every data element collected in the BORN Information System is collected for the purpose of facilitating
and improving the provision of Health Care. The conceptual model used is based on the following:
Identifiers + Health Status + Health Risk Factors + Care Provided = Health Outcomes
High-quality information in each of these categories helps BORN fulfill the purposes defined above.
Clinical data in the system provide the authoritative information and context required to make the
decisions and conclusions in support of the registry function. To illustrate, we use the example of a
caesarean section at 36 weeks, which would be appropriate for a mother with preeclampsia, but not for
a healthy first-time mother with no risk factors and good health status. When studying caesarean
section rates, it is important to differentiate between these two scenarios before drawing conclusions
about the care being provided.
Beyond the data system, BORN is employing a number of supporting strategies:
A team of BORN Coordinators across the province work with data providers to ensure
information is timely and of the highest possible quality.
A data analysis and research team at BORN translate the data into information and knowledge
for users, providers, and planners. They also facilitate access to BORN data for Research, subject
to the strict requirements of PHIPA.
Governance structures are implemented to ensure appropriate oversight and expertise required
to make informed and responsible decisions.
BORN is a prescribed person under PHIPA for the purposes of facilitating or improving the provision of
Health Care for mothers, infants and children. Section 13(2) of Ontario Regulation 329/04-General
(Regulation), enacted under PHIPA requires BORN as a prescribed registry, requires that in place
practices and procedures to protect the privacy of individuals whose Personal Health Information BORN
receives. This Plan describes those practices and procedures.
12 | P a g e
13 | P a g e
PART 1: Privacy Policies and Procedures
P-01: Privacy Policy in Respect of CHEO’s Status as a Prescribed Person The purpose of this policy is to ensure that BORN has a privacy and security accountability framework to
implement its status and overall responsibility as a prescribed person under PHIPA.
Figure 1: Accountability Structure
Status of Prescribed Registry The Children’s Hospital of Eastern Ontario (CHEO) is a prescribed person in respect of BORN as provided
for in section 13(1) of Ontario Regulation 329/04-General (Regulation), enacted under PHIPA for the
purposes of facilitating or improving the provision of Health Care for mothers, infants, and children.
Section 13(2) of Ontario Regulation 329/04-General (Regulation) requires BORN, as a prescribed registry,
to:
Have in place practices and procedures to protect the privacy of individuals whose Personal
Health Information BORN receives
Maintain the confidentiality of that information
Have its practices and procedures approved by the Information and Privacy Commissioner of
Ontario every three years
BORN is committed to complying with the provisions and regulations of PHIPA applicable to a person
holding a registry, as well as any other applicable legislation.
CHEO Board of Directors
CHEO Chief Executive Officer
CHEO VP Child Development and
Community Services
BORN Executive Director
Privacy and Security Review
Committee
Data Holdings Committee
PHI Disclosure Committee
Research Review Committee
Data Quality Committee
Privacy and Security Accountability Framework BORN has developed comprehensive privacy and security policies and procedures to ensure compliance
with PHIPA and its regulation.
As illustrated in figure 1, BORN’s accountability is through CHEO. CHEO’s CEO has delegated the day to day responsibility for ensuring compliance with PHIPA and its regulation to BORN’s Executive Director.
Also illustrated are a number of internal committees that have been established to provide guidance
and advice to BORN’s Executive Director on matters of privacy, security and the collection, quality, and
disclosure of data. The Executive Director also receives guidance from other teams, including the BORN
Executive Team and the BORN Leadership Team.
Privacy and Security Review Committee (PSRC) The PSRC has the mandate to review and approve the necessary elements of BORN’s privacy and
security frameworks that are required for compliance with the Personal Health Information Protection
Act, 2004 and its regulation as well as with guidelines for registries issued by the Information and
Privacy Commissioner (IPC). Identifying and managing risk is part of the culture and day to day
responsibility of all BORN staff. The PSRC is the escalation authority for significant privacy and security
risks faced by BORN.
Data Holdings Committee (DHC) The DHC ensures that the data that BORN collects is aligned with BORN’s purposes, that BORN collects
only the Personal Health Information than is reasonably necessary to meet those purposes and that a
current listing and brief description of BORN’s data holdings is developed and maintained. This includes
identifying new statements of purpose that may improve or facilitate the provision of Health Care using
BORN data holdings.
PHI Disclosure Committee (PDC) The PHI Disclosure Committee (PDC) is responsible for reviewing and approving all requests for the
disclosure of Personal Health Information pursuant to PHIPA and its regulation. The PDC also reviews
and approves record level (i.e., non-aggregated) De-identified data disclosure requests. The PHI
Disclosure Committee is also responsible for reviewing any changes to the methods used to De-identify
Personal Health Information under P-24: De-identification and Aggregation.
Research Review Committee (RRC) The RRC is responsible for reviewing, approving and/or denying requests for the use of Personal Health
Information for research purposes. The RRC is responsible for reviewing requests for the disclosure of
Personal Health Information for research purposes which are ultimately referred to the PHI Disclosure
Committee for approval.
Data Quality Committee (DQC) BORN is an authoritative source of accurate, trusted, and timely data used to monitor, evaluate, and
plan for the best possible beginnings for lifelong health. The purpose of the DQC is to facilitate the
implementation and refinement of BORN’s data quality framework, including overseeing and assessing
14 | P a g e
the quality of BORN’s data and developing and implementing plans, processes and tools to enhance data
quality.
Additional Roles and Responsibilities The Executive Director has delegated responsibility for:
Day to day management of privacy matters to the Privacy Officer
Day to day management of information security matters to the Information Security Officer
Day to day management of Research and other aggregated and/or De-identified disclosure requests for the purposes of improving or facilitating Health Care to the Data Request and Research Coordinator
The Privacy Officer, Information Security Officer and the Data Request and Research Coordinator(s) can
delegate work to other BORN employees.
The duties and responsibilities of the Privacy Officer focus on developing and maintaining a strong
culture of privacy at BORN and include:
Management of the privacy program, including monitoring compliance, conducting regular
audits and providing reports to senior management and recommendations for changes to
policies or procedures
Execution of privacy training
Execution and oversight of privacy impact assessments
Responding to inquiries or complaints related to BORN privacy practices
Any and all related privacy oversight
The duties and responsibilities of the Information Security Officer include managing the security
program as follows:
Management of the security program, including monitoring compliance, conducting regular
audits and providing reports to senior management and recommendations for changes to policy
or procedures
Execution of security training
Execution and oversight of threat and risk assessments
Execution and oversight of vulnerability assessments
Any and all related security oversight
Responsibility for the technology used to collect and securely store the Personal Heath Information used by BORN
15 | P a g e
The Data Request and Research Coordinators have responsibility for coordinating the review of all use
and disclosure requests with the PHI Disclosure Committee and/or the Research Review Committee to
ensure that they comply with the requirements of PHIPA and its regulation. The Data Request and
Research Coordinators are also responsible for ensuring that De-identification is conducted in
accordance with this Plan.
Collection of Personal Health Information BORN collects Personal Health Information for the purpose of facilitating or improving the provision of
Health Care in compliance with s. 39(1)(c) of PHIPA.
The types of Personal Health Information collected include demographic information (e.g. age, postal
code) and clinical information about fetuses, newborn babies, children and their mothers (including
pregnancy history, medical history and a summary of care provided during pregnancy, labour, birth and
the newborn and early childhood periods).
This information is collected from health information custodians involved in the care of children,
newborns and their mothers.
BORN ensures that the collection of Personal Health Information is consistent with PHIPA and its
regulation. BORN does not collect Personal Health Information if other information will serve the
purpose and does not collect more Personal Health Information than is reasonably necessary to meet
the purposes outlined above.
BORN collects only those data elements that have been identified through the rigorous review process
undertaken by the Data Holdings Committee. As described in this Plan, the Data Holdings Committee
has been delegated responsibility for:
Reviewing new proposed BORN data holdings
Reviewing new statements of purpose that may improve or facilitate the provision of Health
Care
Reviewing BORN’s existing data holdings to ensure their statements of purpose are still relevant
and necessary for the identified purposes including: the purpose of the data holding, the PHI
contained in the data holding, the source(s) of the PHI, and the need for PHI in relation to the
identified purpose
Use of Personal Health Information BORN uses the Personal Health Information that it collects for the purposes of facilitating or improving
the provision of Health Care. Such activities may encompass:
Identifying where appropriate care has not been received and facilitate access to care and
treatment for mothers, infants and children (e.g. identifying false negative screens and
informing the relevant Health Care provider in order to enable them to offer parents
appropriate care for their baby)
Facilitating continuous improvement of screening thresholds to minimize missed cases
16 | P a g e
Raising alerts where maternal and/or newborn outcomes are clinically or statistically discrepant
with accepted norms
Enabling Health Care providers to improve care by providing them the information and tools to
compare themselves with peers and/or benchmarks
Identifying strategies to improve the quality and efficiency of care for mothers, infants and
children
Creation of reports that can be used to provide the Ministry of Health and Long-Term Care, and
Public Heath Units with comprehensive and timely information to support effective planning
and management of Health Care delivery for mothers, babies and children in the province
Information provided in reports to the Ministry of Health, and Public Health Units does not contain
Personal Health Information or identify individuals; they present an overview of aggregated Health Care
data. The reports are carefully reviewed to ensure there is no risk of re-identification through small cell
counts or other forms of possible residual disclosure as per p.24: De-identification and Aggregation. The
reports are made available through the BORN website at www.BORNOntario.ca.
BORN ensures that each identified use of Personal Health Information is consistent with the uses of
Personal Health Information permitted by the Act and its regulations. BORN does not use Personal
Health Information if other information will reasonably serve the purpose and does not use more
Personal Health Information than is reasonably necessary to meet the purpose, using de-identified or
aggregate information wherever possible.
BORN may use Personal Health Information to conduct Research only when the strict requirements of
PHIPA are adhered to, including review by a Research Ethics Board as per p.10: Use of Personal Health
Information for Research.
BORN remains responsible for Personal Health Information used by its Agents. Access and use by Agents
is strictly controlled. Agents are trained on their privacy obligations and sign a Confidentiality Agreement
acknowledging the requirements to use only the information necessary for their work, to keep Personal
Health Information secure at all times, and to notify BORN of any discovered or suspected breach as per:
P-08: Limiting Agent Access to and Use of Personal Health Information
P-29: Privacy Breach Management
HR-01 and HR-03: Privacy and Security Training and Awareness
HR-05: Execution of Confidentiality Agreements by Agents
17 | P a g e
Disclosure of Personal Health Information The PHI Disclosure Committee has responsibility for reviewing all requests for disclosure of Personal
Health Information.
The Research Review Committee has responsibility for reviewing all requests for use of Personal Health
Information for Research (including use of Personal Health Information for Research for subsequent
disclosure of record level data that has undergone De-identification prior to such disclosure).
In cases involving disclosure of Personal Health Information for Research that has not undergone De-
identification (including De-identification through aggregation) prior to disclosure (if any), the Research
Review Committee will review requests and then refer the matter with its recommendations to the PHI
Disclosure Committee for consideration and possible approval.
BORN does not disclose Personal Health Information if other information serves the purpose and does
not disclose more Personal Health Information than is reasonably necessary to meet the purpose.
Personal Health Information is disclosed to the following groups and for the following purposes, in
accordance with the disclosures of Personal Health Information permitted by PHIPA and its regulation:
To health information custodians, when facilitating access for mothers, babies and children for
care and treatment; for example, to ensure appropriate screening is offered in a meaningful
timeframe;
To a prescribed entity for the management, evaluation, monitoring or planning for the health
system
To Researchers for Research purposes as defined in PHIPA. Personal Health Information is
provided to Researchers only if de-identified information is not sufficient to conduct the
Research. The research plan must be approved by a Research Ethics Board, meet the
requirements set out in PHIPA, and be approved by the Data Request and Research Coordinator
who ensures that the minimum amount of Personal Health Information and the least
identifiable information is disclosed
More information on the disclosure of Personal Health Information is provided in:
P-12: Disclosure of Personal Health Information for Purposes other than Research
P-13: Disclosure of Personal Health Information for Research Purposes and the Execution of
Research Agreements
P-24: De-Identification and Aggregation
18 | P a g e
Disclosure of De-identified and/or Aggregate Personal Health Information The Data Request and Research Coordinator has responsibility for reviewing all De-identified and/or
aggregate information prior to its disclosure in order to ensure that it is not reasonably foreseeable in
the circumstances that the information could be used, either alone or with other information, to identify
an individual. The Data Request and Research Coordinator is assisted by the user of the De-Identification
Tools for empirical assessment regarding risk of re-identification.
De-identified and aggregated data generated from Personal Health Information may be disclosed to
third parties. For example, these may include:
Public Health Units to facilitate the appropriate planning, monitoring and provision of Health
Care
Researchers for research purposes
Ministry of Health to inform policy and planning
Secure Retention, Transfer and Disposal of Records containing Personal Health Information BORN prohibits paper records of personal health information.
BORN ensures that electronic records are kept safe and secure as follows:
Electronic records of personal health information are securely retained in identifiable format within the transactional database for 28 years after which they are converted to a de-identified format and then securely destroyed. Secure retention, timeline, and secure destruction are detailed in:
S-05: Secure Retention of Records of Personal Health Information
S-08: Secure Disposal of Records of Personal Health Information
Electronic records of Personal Health Information are securely transferred and disposed of as
per:
S-07: Secure Transfer of Records of Personal Health Information, and
S-08: Secure Disposal of Records of Personal Health Information
19 | P a g e
Implementation of Administrative, Technical and Physical Safeguards BORN has in place administrative, technical and physical safeguards to protect the privacy of individuals
whose Personal Health Information is received and to maintain the confidentiality of that information.
BORN takes steps to protect Personal Health Information against theft, loss and unauthorized use or
disclosure and to protect records of Personal Health Information against unauthorized copying,
modification or disposal. These safeguards are set out in:
S-01: Information Security Policy
S-09: Passwords
S-13: Back-up and Recovery of Records of Personal Health Information
S-14: Acceptable Use of Technology
HR-05: Execution of Confidentiality Agreement by Agents
Privacy and security policies and procedures are reviewed at least once prior to each scheduled review
by the IPC pursuant to subsection 13(2) of the Regulation under the Act by the Privacy and Security
Review Committee as per S-02: Ongoing Review of Security Policies and Procedures.
Inquiries, Concerns or Complaints Related to Information Practices All inquiries, concerns or complaints related to the privacy policies and procedures of BORN and BORN’s compliance with PHIPA and its regulation must be directed to:
Privacy Officer
CHEO Centre for Practice Changing Research building
401 Smyth Road
Ottawa ON K1H 8L1 Email: [email protected]
See the BORN website at www.BORNOntario.ca
Individuals may also direct complaints regarding the compliance of BORN to the Information and Privacy
Commissioner of Ontario:
Information and Privacy Commissioner of Ontario
2 Bloor Street East
Suite 1400
Toronto, ON M4W 1A8
Telephone: Toronto Area: 416-326-3333
Toll Free (within Ontario): 1-800-387-0073
TDD/TTY: 416-325-7539 Fax: 416-325-9195
20 | P a g e
Transparency of Practices in Respect of Personal Health Information BORN Ontario makes its privacy policies available on the BORN website at www.bornontario.ca,
including P-01: Privacy Policy in Respect of CHEO’s Status as a Prescribed Person and the Statement of
Information Practice. The privacy policies can also be obtained by contacting the Privacy Officer as per
above.
Compliance Audit and Enforcement BORN Ontario Agents must comply with this Plan. Compliance is audited on an ongoing basis by the
Privacy Officer in accordance with P-27: Privacy Audits and S-15: Security Audits.
BORN Agents are required to notify the Privacy Officer at the first reasonable opportunity of a breach or
suspected breach in accordance with P-29: Privacy Breach Management or S-17: Security Breach
Management, as applicable. Consequences of breach are detailed in each respective breach policy as
well as in P-01: Privacy Policy in Respect of CHEO’s Status as a Prescribed Person. HR-11: Discipline and
Corrective Action which clarifies:
The BORN Ontario Confidentiality Agreement states that a breach of the terms of the
Confidentially Agreement, BORN Ontario policies and procedures, and/or the provisions of the
Personal Health Information Protection Act, 2004 may result in disciplinary action which can
include termination of employment or legal action.
21 | P a g e
22 | P a g e
P-02 and S-02: Triennial Review of Privacy and Security Policies and Procedures
Purpose The purpose of this policy is to ensure that BORN has in place an effective policy to enable ongoing
review of its privacy and security policies and procedures.
Policy BORN undertakes a review of its privacy and security policies and procedures at least once prior to each
triennial review by the IPC pursuant to subsection 13(2) of the Regulation under the Act. The purpose of
a review is to determine whether amendments are needed or whether new policies and procedures are
required to ensure that BORN meets industry standards and best practices. Agents who become aware
of areas where the BORN privacy and security policies and/or procedures are inadequate, inoperable or
for any other reason could be improved are encouraged to report those concerns or suggestions to the
Privacy or the Information Security Officer.
Responsibility Privacy Officer and Information Security Officer
Procedure The Privacy Officer and Information Security Officer initiate a review of privacy and security policies and
procedures:
Every three years or more frequently as appropriate having regard to nature of ongoing risks,
organizational changes, or technology changes
When a serious breach has occurred in which Personal Health Information in BORN’s custody or
control has been lost, stolen or disclosed without proper authorization
When an order, fact sheet, guideline or best practice is issued by the Information and Privacy
Commissioner
When amendments are made to PHIPA and its regulation that are relevant to BORN as a
prescribed registry
In undertaking the review, the Privacy Officer and Information Security Officer may consult with relevant
Agents, consultants, Service Providers and data providers for possible privacy and security enhancing
changes to existing BORN policies and procedures.
In determining whether amendments and/or new privacy or security policies and procedures are
necessary, the Privacy Officer and Information Security Officer both consider:
Concerns or issues raised by Agents, Service Providers or data providers
Recommendations arising from complaints and inquiries
Recommendations arising from privacy and security audits and investigations into privacy and
security breaches
Recommendations arising from privacy impact assessments
Orders, recommendations, guidelines, fact sheets and best practices issued by the Information
and Privacy Commissioner
Any relevant amendments to PHIPA and its regulations
Evolving industry standards and best practices
Whether BORN privacy and security policies and procedures continue to be consistent with
actual practices
Whether there is consistency between and among the privacy and security policies and
procedures and practices implemented
Based on the review and analysis, the Privacy Officer and/or Information Security Officer forwards to the
Privacy and Security Review Committee for review and approval a written report or updated draft of
policies and procedures that includes:
Recommended amendments/additions/deletions
Rationale for the proposed amendments/additions/deletions
Anticipated impact of executing or not executing the proposed changes
The Privacy and Security Review Committee reviews the report or updated draft policies and procedures
and communicates their decisions to the Privacy Officer and/or Information Security Officer.
The Privacy Officer and/or Information Security Officer makes any required changes requested by the Privacy and Security Review Committee and forwards to the Executive Director, for review and approval,
the report or updated draft of policies and procedures containing:
Recommended amendments/additions/deletions
Rationale for the proposed amendments/additions/deletions
Anticipated impact of executing or not executing the changes
If approved, all communications materials (website, brochure) are modified as appropriate to reflect the
changes, ensuring clear language.
The Privacy Officer and/or Information Security Officer:
Communicates the changes to all management and staff
Advises any affected third parties
Revises training materials
23 | P a g e
24 | P a g e
Amends existing agreements and template agreements, as required
The Privacy Officer and Information Security Officer use reasonable efforts to ensure that the annual
review process and development of amendments and/or changes is completed within a three month
time period and that communication of amendments/changes is completed within a further one month
period.
Document Retention The Privacy Officer and the Information Security Officer will both maintain:
Relevant notes of meetings with Agents, Service Providers and data providers (if any)
Summary of decisions with the Privacy and Security Review Committee
All correspondence pertaining to the revisions
P-02A: Annual and Quarterly Reports on Privacy and Security The Privacy Officer and Information Security Officer prepare a quarterly report on privacy and security.
The report is reviewed and approved by the Privacy and Security Review Committee. The Privacy Officer
and Information Security Officer will also prepare an annual report to be reviewed and recommended by
the PSRC to the Executive Director. Based on this report, each year the Vice President of Child
Development and Community Services will be supplied with a written report by the Executive Director
addressing the initiatives undertaken by the privacy and security programs including training,
development of policies, procedures, audits undertaken, privacy impact assessments, threat risk
assessments, privacy and security breaches, privacy complaints that were investigated, and the status of
any recommendations that were made from the investigations. The Vice President of Child Development
and Community Services will present such findings to a committee of the CHEO Board of Directors.
The following sets out the quarterly report format:
QUARTERLY REPORTS ON PRIVACY AND SECURITY
BACKGROUND
BORN’s status under PHIPA
Privacy and Security Governance at BORN QUARTERLY REVIEW
Training and Awareness Privacy and security training for staff
Data Sharing Data collections and health information custodians from whom the data are collected Data uses and disclosures Data Sharing Agreements and Research Agreements
Audits and Compliance Privacy impact assessments, privacy and security audits and threat risk assessments, their
recommendations, and the status of their implementation
Incident Management Privacy inquiries and complaints and their resolution Privacy and security breaches, if any, related recommendations and the status of their
implementation Any other privacy and security related issues, as applicable
Other Committee Meeting Activities Include a summary of the meeting dates for the PHI Disclosure Committee, the Research
Review Committee, and the Data Holdings Committee meetings (during applicable quarter)
25 | P a g e
P-03: Transparency of Privacy Policies and Procedures
Purpose The purpose of this policy is to ensure an appropriate level of transparency of BORN’s registry functions
for the public and other stakeholders.
Policy BORN makes publicly available a plain language description of the functions of the registry compiled and maintained by it, including a summary of the practices and procedures that are in place for protecting
confidentiality of the information.
BORN also makes publicly available other material as described in this policy.
Responsibility Privacy Officer
Procedure The Privacy Officer works with the Communications Lead to provide summary information to the public
and stakeholders on BORN policies and procedures in language that is clear and non-technical.
The Privacy Officer ensures that the information on the website at and in brochures (if any) includes:
A description of BORN privacy policies
Frequently Asked Questions related to BORN privacy policies and procedures
Results from the Information and Privacy Commissioner review of BORN’s privacy policies and procedures
A list of data holdings of Personal Health Information maintained by BORN
Summaries of privacy impact assessments conducted by BORN
Title, mailing address and contact information of the Privacy Officer to whom inquiries, concerns
or complaints regarding compliance may be directed.
The Privacy Officer works with the Communications Lead to ensure that the website and/or Frequently
Asked Questions include:
Status of BORN as a prescribed registry under PHIPA and its regulation, and a summary of the
duties and responsibilities arising from this status
A description of the policies and procedures implemented in respect of Personal Health
Information
Types of Personal Health Information collected
Health information custodians from whom this information is typically collected
26 | P a g e
The purposes for which Personal Health Information is collected and used
The circumstances in which and the purposes for which Personal Health Information is disclosed
and the persons or organizations to which it is typically disclosed
The legal authority for the collections, uses and disclosures
Administrative, technical and physical safeguards implemented to protect the information
against theft, loss, and unauthorized use, disclosure, copying, modification or disposal
Title, mailing address and contact information of the Privacy Officer to whom inquiries, concerns
or complaints regarding compliance with BORN Ontario privacy and security policies and
procedures and/or compliance with Personal Health Information Protection Act, 2004 and its
regulation may be directed.
Note: Information will not be made public if it reasonably appears that doing so would affect the
security of Personal Health Information or the BORN System that protects that information.
Updates to public and stakeholder materials are addressed as per P-02 and S-02: Triennial Review of
Privacy and Security Policies and Procedures.
Note: The master copy of any print materials (brochures, reports, etc.) is the electronic version online. If
the online version is changed, the Communications Lead is responsible for ensuring the changes are
reflected in a timely way in any print versions.
27 | P a g e
P-04: Collection of Personal Health Information and P-06: Statements of Purpose for Data Holdings Containing Personal Health Information
Purpose The purpose of this policy is to ensure that BORN limits the collection of Personal Health Information in
accordance with the requirements set forth by PHIPA and best practices for privacy protection.
Policy BORN only collects Personal Health Information if the collection is permitted by PHIPA and its
regulation.
BORN does not collect Personal Health Information that will not reasonably facilitate or improve the
provision of Health Care or if other information will serve the purpose of the Registry.
BORN collects only those data elements that have been identified through the review process set out
below. The purpose of the review process is to identify the minimum data elements necessary to
achieve the Registry’s purpose of facilitating and improving the provision of care to mothers, infants and
children.
Responsibility Data Holdings Committee
Procedure The DHC will meet approximately every two months. Additional meetings will be scheduled as required.
At the first meeting of the fiscal year, the DHC will develop its work plan and schedule for the year. The
DHC has responsibility for the following:
Statements of Purpose and BORN data holdings: Identify and consider any requests for new statements of purpose that may improve or facilitate
the provision of health care using BORN data holdings
Identify the requirement for a Privacy Impact Assessment (PIA) of new holdings of data or PHI
from data contributors in Ontario and review relevant PIAs, considering risks and mitigation
strategies
Review any proposed new data holdings or any changes to existing data holdings, confirming the
fit with BORN’s purposes and recommending the approval, change, or rejection of the collection
of these data holdings
On an annual basis, review BORN’s data holdings to ensure their statements of purpose are still relevant and retaining them is necessary for the identified purposes
Revise documentation, as necessary, that includes the following for each data holding:
o the purpose of the data holding
o the PHI contained in the data holding
28 | P a g e
o the source(s) of the PHI including the health information custodians from whom the
data will be collected
o the need for PHI in relation to the identified purpose
Ensure that a summary list of BORN’s data holdings of PHI are publicly communicated through
BORN’s website
Disposal Determine when the data collected by BORN is no longer needed to fulfill its purposes as a
prescribed registry and collection of that particular data must be discontinued, and existing data
must be de-identified or destroyed
Data Elements and Enhancements Review and advise on the addition of new data elements and review and approve proposed
enhancements to existing BORN data elements to improve accuracy, clinical relevancy, usability
and/or reliability considering:
whether the data collection is permitted by the Personal Health Information Protection
Act (PHIPA) and its regulation;
whether any and all conditions or restrictions set out in PHIPA and its regulation have
been satisfied;
whether other information (i.e. de-identified and/or aggregate information) will serve
BORN’s purposes; and,
no more PHI is being collected than is reasonably necessary to serve BORN’s purposes.
The DHC will establish the necessary working groups to review proposed enhancements and BORN data
elements in more detail for all of BORN’s data holdings. Such working groups will address minor
enhancements but all changes of substance will be reviewed and approved by DHC (See Appendix A to
the committee’s terms of reference).
The review process should involve the following.
1. In determining the data holdings and data elements therein to be collected, and any new statements
of purpose to be considered, the Data Holdings Committee may consult with health information
custodians and key experts in the field of maternal, infant and child health and other experts as
warranted.
2. In determining the data holdings and elements to be collected and their statements of purpose,
the Data Holdings Committee considers whether:
The collection is permitted by PHIPA and its regulation
Whether other information, namely de-identified and/or aggregate information, will
serve the purpose of the Registry, and
29 | P a g e
Whether no more Personal Health Information is being requested than is reasonably
necessary to meet the purpose of the Registry
Whether the rationale or statements of purpose for each data holding can be linked to
the need for the data in relation to the identified purpose of the Registry
Any risks identified in privacy impact assessments undertaken by BORN regarding new
data holding (where applicable)
Any conditions that must be satisfied prior to collection
Whether appropriate data sharing agreements are in place or pending
3. In respect of any new data holdings or statements of purpose, the Data Holdings Committee will
record in its record of decisions including :
The proposed list of data elements and/or data holdings and the associated statements
of purpose
The proposed list of health information custodians from whom the data elements or
data holdings will be collected
Any newly proposed statements of purpose that have been approved
Any changes to the content of policy P-07: Statements of Purpose for Data Holdings
Containing Personal Health Information that are recommended as a result of new
proposed statements of purpose
4. The DHC is accountable to and reports to the BORN Executive Director. Where significant
changes to BORN’s data holdings are proposed the DHC will inform the Executive Director. On
an annual basis, the DHC will provide an update on BORN’s data holdings, data elements, and
enhancements to BORN’s Executive Director.
5. The Privacy Officer has responsibility for ensuring that a signed data sharing agreement is
executed before data are collected. Where there are revisions made to data holdings, a revised
data sharing agreement must be completed before collection of data proceeds. See P-16: Data
Sharing Agreements. All BORN statements of purpose are outlined in data sharing agreements.
The Privacy Officer will ensure that, to the extent not reflected in any pre-exiting data sharing
agreements that expressly list approved purposes, any new purposes will be incorporated as
each agreement is amended or restated.
6. The DHC will ensure any new statements of purpose that have been approved are reflected in an
update to P-07: Statements of Purpose for Data Holdings Containing Personal Health Information.
7. The DHC will inform Service Providers (as appropriate) and ensures that any conditions or
restrictions that must be satisfied prior to the collection of Personal Health Information have
been satisfied.
30 | P a g e
8. The DHC will inform the Communications Lead in order to update the website with any changes to
the data holdings, the Personal Health Information contained in each data holding, the source of the
Personal Health Information and/or the statement of purpose for each data holding in relation to the
identified purpose of the Registry. Changes to collections and statements of purpose are made public
in accordance with P-03: Transparency of Privacy Policies and Procedures.
9. The Privacy Officer is to ensure that updates P-07: Statements of Purpose for Data Holdings
Containing Personal Health Information that include new statement of purpose are communicated
to Agents.
Secure Collection Personal Health Information is collected electronically through secure internet connections and may
involve manual data entry and automated extraction and uploading from existing hospital information
systems and lab information systems. See S-07: Secure Transfer of Records of Personal Health
Information.
Retention and Secure Disposal Subject to any earlier date decided by the DHC, records will be maintained in identifiable form within
the transactional database for 28 years and then converted to a de-identified format as per S-05: Secure
Retention of Records of Personal Health Information and then destroyed as per S-08: Secure Disposal of
Records of Personal Health Information. BORN does not return records of personal health information.
Secure Transfer Records of personal health information as securely transferred as per S-07: Secure Transfer of Records of
Personal Health Information.
Document Retention The Data Holdings Committee is responsible for securely maintaining:
A list of all data elements or holdings to be collected, the health information custodians from
whom the Personal Health Information is to be collected, and the rationale or statement of
purpose(s) for each data element
Any relevant correspondence
31 | P a g e
32 | P a g e
P-05: List of Data Holdings Containing Personal Health Information BORN data holdings consist of a single holding called the BORN Information System (BIS) as well as
several historical and/or stand-alone datasets, as follows:
BORN Information System The BORN Information System is a single data holding comprised of Personal Health Information
collected from the following health information custodians:
Prenatal and newborn screening providers
Hospitals
Midwives
Outpatient clinics
Fertility clinics
Family Health Teams/Primary Care Providers
Birth Centres
Autism Treatment Centres
Public Health Units
The unique data collections within the BIS are provided by various health information custodians for
specific maternal, newborn and child encounters with the Health Care system, including:
Prenatal screening laboratory results (including ultrasound information)
Prenatal and pediatric cytogenetics results
Genetics/MFM Encounter (formed by the merger of Prenatal screening follow-up and Antenatal
specialty for fetal anomalies information)
Antenatal general for pregnancy status and care information
Labour information, birth and postpartum information for mothers and babies
Special care nursery and Neonatal intensive care unit information
Newborn screening laboratory and results information
Newborn screening follow-up for diagnosis information
Ontario Antenatal Record from Family Health Teams (primary care pilot project)
Fertility information from the CARTR+ (Canadian Assisted Reproductive Technology) database
Well baby and child data for standardized assessment tools (Rourke Baby Record (RBR) Ontario,
Nipissing District Developmental Screen (ndds)) as well as height and weight
Autism information from the Child and Adolescent Needs and Strengths tool
Healthy Baby Healthy Child (HBHC) provincial screening tool
CANImmunize- Historical datasets from a pilot with participating public health units
Niday Perinatal and NICU/ICU Database (after 2010)
FAN (Fetal Alert Network) historical database The historical dataset from one of BORN’s founding members.
Prenatal Screening Ontario (PSO) historical database The historical dataset from one of BORN’s founding members.
Niday Perinatal and NICU/ICU Database The historical dataset (i.e., prior to 2010) from one of BORN’s founding members.
Ontario Midwifery historical database The historical dataset from one of BORN’s founding members.
CARTR (Canadian Assisted Reproductive Technology) historical database Historical fertility data.
NIPT (non-invasive prenatal testing) Historical dataset for NIPT (prior to Ontario patriation of NIPT).
Cytogenetics Historical datasets for antenatal and newborn cytogenetic analyses from regional cytogenetics
laboratories
Ontario Midwifery Invoicing System (MIS)
Invoicing data that includes expectant parents’ anticipated delivery date
COVID-19 Infection Data Limited data on the clinical characteristics of COVID-19 infection in pregnant women
commencing 2020
33 | P a g e
34 | P a g e
P-07: Statements of Purpose for Data Holdings Containing Personal Health Information Children’s Hospital of Eastern Ontario (CHEO) in respect of BORN is listed as a prescribed person in
section 13 of Regulation 329/04 to Ontario’s PHIPA (PHIPA). Prescribed persons, referred to as
prescribed registries, are a specific class of organization permitted under PHIPA to collect Personal
Health Information from health information custodians (without individuals’ consent) for the purposes
of facilitating and improving the provision of Health Care. In turn, prescribed registries are permitted to
use and disclose Personal Health Information received from health information custodians (without
consent) for the same purposes as permitted under s. 49(1) of the Act.
CHEO and the Ministry of Health and Long-Term Care established BORN:
To build and manage the maternal/child Registry
To build a source of accurate and timely maternal-infant-child information for facilitating and
improving the provision of Health Care to pregnant persons and children in Ontario
For analysis of maternal, newborn and child data to support decision making by Health Care
providers and planners
The BORN Statements of Purpose to facilitate and improve the provision of Health Care are:
A. Identifying where appropriate care has not been received and facilitating access to care and
treatment for mothers, infants and children. For example: identifying false negative screens and
informing the relevant Health Care provider in order to enable them to offer parents appropriate
care for their baby.
B. Facilitating continuous improvement of Health Care delivery tools to minimize adverse outcomes.
For example: improvement of screening algorithm and cut-offs to minimize missed screens.
C. Raising alerts where maternal and/or newborn outcomes are statistically discrepant with accepted
norms. For example: an increase in congenital anomalies associated with a specific geographic
region suggesting a toxic exposure or a provider being identified as performing too many
episiotomies as compared to peers, leading to poor maternal outcomes.
D. Enabling Health Care providers to improve care by providing them the information and tools to
compare themselves with peers and/or benchmarks.
E. Knowledge translation to improve the quality and efficiency of care for mothers, infants and
children. For example: identifying strategies for health information custodians for continuous quality
improvement.
F. Creating reports that can be used to provide the Ministry of Health and Long-Term Care and Public
Heath Units with comprehensive and timely information to support effective planning and
management of Health Care delivery for mothers, babies and children in the province.
G. Facilitate the provision of health care to a pregnant person and/or baby through the pre-population
of personal health information used by or between health information custodians within the circle
of care of a pregnancy and/or resulting delivery (including post-partum care and newborn care).
In deciding the data elements to include in the BORN dataset, each element is reviewed to ensure it is
required to be collected in order to achieve the purposes of the BORN Registry. The following
framework outlines the five types of information that are required.
1. Identifiers
2. Health Status
3. Health Risk Factors
4. Care Provided
5. Health Outcomes
The combination of all of these data types is required for the successful operation of the registry. Details
and examples of each:
Identifier
When instances of insufficient care are identified it is critical that BORN have in place a mechanism
by which to alert the mother or care provider of the opportunity to improve care in a timely way.
The identifiers must also allow the mother and child data to be augmented with additional health
information to allow the health status, care provision and outcomes to be combined as outlined in
the subsequent sections. Identifiers that allow the pregnant person to be uniquely identified and
appropriately contacted are required to meet the purposes of the Registry. We will regularly review
identifiers to determine if fewer data elements would be sufficient for these purposes.
Examples
1. Missed Screen. Newborn Screening Ontario tests for 28 rare diseases in newborns. Test
results can lead to early identification and proper, life-saving treatment. By capturing every birth
in the province and then cross-referencing to every baby tested by Newborn Screening Ontario,
BORN can promptly identify the babies that have not been tested and inform the primary care
provider to ensure the test is offered.
2. Missed Case. A child screens negative for PKU in prenatal screening. Several months later the
child is diagnosed with PKU by other means. It is critical that the identifiers on the two records
allow the two to be linked, such that Newborn Screening Ontario learns that there are problems
with the screening test.
Health Status
The health outcome of both mother and child is dependent upon the current health status of each.
A complete understanding of the current health status of the mother and the child is needed to
identify situations where additional care may be required.
35 | P a g e
Examples
1. Gestational diabetes screening reminder. Mothers testing positive for gestational
diabetes require follow-up as they are at increased risk for Type 2 diabetes and its many
resultant complications later in life. The Registry can gather this health status information from
a number of antenatal providers (family doctor, midwife, obstetrician, and birthing hospital) and
alert the primary care physician to ensure appropriate follow-up care is offered. This can prove
to have important long-term benefits for the mother and the system resources.
2. Antenatal 1 and 2 Forms. Complete pregnancy history and documentation of care is
tracked across providers using the provincially mandated Antenatal 1 and Antenatal 2 forms.
These forms should be sent to the birthing hospital at 35 weeks’ gestation. A survey by BORN
suggests that pregnant persons frequently deliver without their providers having access to the
information – either they deliver unexpectedly, early, or the forms cannot be located. Providing
access to these forms in emergent situations ensures that providers have key clinical
information available and also reduces the duplication of tests used to facilitate care
(ultrasounds and laboratory)
Health Risk Factors
The health outcome of both the mother and the child can be impacted by the demographics of both.
BORN must understand the current status of the mother and child to identify situations where
additional care may be required.
Examples:
1. Unexplained poor outcomes, such as increased anomalies. As an authoritative
source of maternal-child health outcomes information, BORN is the only organization in the
province with timely access to health trends in the population. Previously, a cluster of congenital
anomalies was suspected in south western Ontario. It was through detailed analysis of the data
entry, outcomes, risk factors and interventions that the signal was found to be in error. Should a
legitimate signal be found, prevention of further congenital anomalies is possible by identifying
persons from the registry and offering them (through their health provider) further screening,
diagnostic testing or therapy.
2. Linking Risk to Outcomes. Persons who develop preeclampsia during pregnancy are at
increased risk for cardiovascular disease later in life. The outcomes cannot be studied if the
overall pregnancy environment is not understood.
Care Provided
The Registry must know what care has been provided for two reasons:
1. To quickly identify situations where care is insufficient (e.g. baby born, but no newborn
screen completed).
36 | P a g e
37 | P a g e
2. To link ‘Care Provided’ to ‘Outcomes’ to develop the knowledge required to improve care to
the maternal/child population
Examples include or may include:
Missed Screen. A baby was born in the community but was not offered newborn screening.
Whether newborn screening was or was not offered must be captured in the system to identify
the newborns not yet screened.
NTQA. Nuchal translucency (NT), a measurement on the neck of the fetus during ultrasound, is
a key component in the prenatal screening algorithm. With values smaller than a millimetre
being an important differentiation, it is critical that sonographers measure it accurately. Much
work has been done internationally on quality assurance of NT measurements that involve
plotting all measurements done by a single sonographer and comparing the distribution to
accepted norms. BORN is able to collect these key measurements from labs across the province
and report back to sonographers and their managers on the quality of their work. By minimizing
errors in NT measurements, prenatal screening results will be much more accurate, reducing
false positives and false negatives and the associated repeat tests and analysis.
Discrepant Practice. Evidence associated with labour, birth and newborn care in the
province shows significant variation in key indicators such as caesarean section rates and other
labour interventions. Tracking, reporting and addressing these variations will ensure persons in
the province are offered consistent, high-quality and appropriate care. Once data are available,
BORN coordinators will work with the hospital or individual provider to understand why their
rates are discrepant and develop and implement quality improvement strategies.
Access to Aggregate data. Health care providers collect key clinical information for an
individual as part of every visit, for example, the clinical details associated with labour including
the indications for interventions, the timing of the labour, the medications and analgesia
administered and final outcome for mother and baby. It is only once this data are aggregated
that the information highlights important trends in the care being provided, for example, many
persons having emergency C-sections, many persons being induced rather than labour starting
spontaneously. Providers are willing to invest the time required to enter the information into
the BORN system because it provides them great value for program planning and management
of care to analyse their data in aggregate.
Health Outcomes
By connecting ‘Health Status’ and ‘Care Provided’ to maternal/newborn ‘Outcomes’, BORN can
improve the provision of Health Care to pregnant persons, babies and children in Ontario.
Examples:
Improving Screening Algorithms. Screening is a mechanism to assess and report risk and as
such, involves false-positive and false-negative results. While this is expected, the anxiety for
families upon receiving a positive screen is significant, and the impact on individuals with a false
negative result can be catastrophic. By gathering all screening results and all associated follow-up
and outcomes information, trained analysts can review the information to identify triggers for the
false results. Once analyzed, the screening thresholds can be adjusted to reduce false-positive and
false-negative results. The costs of false negative can be significant – from lifelong disability to
potential death. Reduction in the false positives will reduce the number of families impacted by the
anxiety associated with a positive result.
1. Effectiveness. Providing feedback to public health units and health promotion agencies on the
effects of their campaigns around smoking cessation, breastfeeding promotion, prenatal class
attendance and the relationships between these and newborn and childhood outcomes will help
improve the care provided to mothers and children.
2. Reports. The Ontario Health Care system is dependent on high quality information for decision
making. Public Health Units regularly request reports from the BORN founding members to plan
the delivery of services in their region. Using aggregate information from the BORN System, we
can inform regions and populations of key trends that need to be addressed.
The BORN Data Dictionary document lists each data element collected by the BORN Information System.
38 | P a g e
P-08: Limiting Agent Access to and Use of Personal Health Information
Purpose The purpose of this policy is to ensure that BORN limits access to and use of Personal Health Information
by Agents.
Policy Access to Personal Health Information by Agents is based on the “need to know” principle, embodied in
role-based access. Duties of Agents with access to Personal Health Information are segregated in order
to avoid a concentration of privileges that would enable a single Agent to compromise Personal Health
Information.
BORN prohibits Agents from accessing and using Personal Health Information except as necessary for his
or her employment or contractual responsibilities.
BORN requires Agents to access and use the minimum amount of identifiable information reasonably
necessary for carrying out their day-to-day employment, contractual or other responsibilities with
BORN.
BORN prohibits access to and use of Personal Health Information if other information, such as de-
identified and/or aggregate information pursuant to P-24: De-Identification and Aggregation, will serve
the purpose.
BORN prohibits Agents from using de-identified and/or aggregate information, either alone or with
other information to identify an individual, including attempting to decrypt information that is
encrypted, attempting to identify an individual based on unencrypted information and attempting to
identify an individual based on prior knowledge.
Responsibility Privacy Officer
Procedure As per policy S-05: Retention of Records of Personal Health Information, BORN permits the storage of
PHI in two environments, the BORN Information System and the BORN PHI Drive.
All Agents must be approved for access to and use of Personal Health Information by completing one or
both of the following:
1. P-08A: BORN PHI Access Request Form: BORN Information System (BIS)
2. P-08B: BORN PHI Access Request Form: BORN PHI Drive
Both forms specify:
The purpose for which access is required
39 | P a g e
o The Agent’s manager set out the purpose for access as related to the requirements of
the position
The time frame for access and use
o All access subject to annual renewal
P-08A: BORN PHI Access Request Form: BORN Information System (BIS) The data holdings to which access is required
o Staging environment or production environment
The type and level of access required; there are five types of access classified as roles, as
follows:
o Data Entry Roles: create, read, update, delete privileges
o Reporting Roles: read only
o Administrative Roles: each administrative role has defined privileges for create, read,
update, delete or view, as appropriate
o Administrative Roles for the Online Data Dictionary Tool Roles: multiple roles exist each
with defined privileges for create, read, update, delete, or read only
o Direct Database Access: read only back end access
The data holdings to which access is required
Note: The Agent Data Access Form does not assign the authority to disclose Personal Health
Information. Any disclosure of Personal Health Information must follow the appropriate disclosure
policy.
Approval Process 1. The supervisor of an Agent recommends what access to and use of Personal Health Information
is required for an Agent to fulfill his or her mandate. In determining what access and use to
recommend, the supervisor must consider the following criteria:
The Agent routinely requires access to and use of Personal Health Information on an
ongoing basis or for a specified period for his or her employment, contractual or other
responsibilities
De-identified and/or aggregate information will not serve the identified purpose
No more Personal Health Information will be accessed and used than is reasonably
necessary to meet the identified needs of the role
The access and use recommendations meet and do not exceed the functions to be
performed as per the BORN job specification or contract
Any conditions or restrictions to be imposed on access and use (i.e. no access to specified
data elements)
40 | P a g e
Rationale for the recommendations
2. The supervisor of an Agent completes and signs an Agent Data Access form based on the
recommendation. The supervisor forwards to the Privacy Officer for approval:
The completed Agent Data Access form, including justification for access as related to the
Agent’s job
3. The Privacy Officer reviews the application form and any supporting
documentation/recommendation and contacts the supervisor with any clarification questions.
The Privacy Officer considers all the criteria in determining whether to approve or deny access
and use, and also considers:
The data will be used in a manner that is consistent with the purposes for which it was
originally collected
The identified purpose for which access to and use of Personal Health Information is
requested is permitted by PHIPA and its regulation, and cannot be reasonably accomplished
without Personal Health Information
Functions to be performed as per BORN job specification or contract
4. If the Privacy Officer denies access, the Privacy Officer notifies the Agent and his/her supervisor in
writing with an explanation of the reasons.
5. Where the Privacy Officer approves an application based on all criteria and the recommendation
of the Agent’s supervisor, the Privacy Officer informs the supervisor and executes the Agent
Data Access Form with the Agent.
6. The Privacy Officer forwards the signed Agent Data Access form to the BORN System
Administrator.
7. The BORN System Administrator:
Enables the access
Records the information in P-09: Log of Agents Granted Approval to
Access/Use/Disclose Personal Health Information
Signs the Agent Data Access Form
Returns the Agent Data Access Form to the Privacy Officer
8. The Privacy Officer maintains hard copy originals of all signed Agent Data Access Forms.
P-08B: BORN PHI Access Request Form: BORN PHI Drive
A copy of the Standard Operating Procedure (SOP) for access to the BORN PHI Drive is stored on the Departmental Drive (\General\Standard Operating Procedure (SOP)). The SOP documents the procedures used to grant access to the BORN PHI drive.
41 | P a g e
Conditions and Restrictions on the Approval The Privacy Officer ensures that all Agents have in place a signed Confidentiality Agreement before
being given access to Personal Health Information. See HR-05: Execution of Confidentiality Agreement
by Agents`.
Annual Renewal All approved accesses and uses of Personal Health Information are subject to an expiry after one year or
sooner based on request. Agents and their supervisors request approval on an annual basis one year
from the date approval is granted and follow the policy and procedures set out herein. For situations
where access cannot be set to automatically expire by virtue of limitations in the technology, the BORN
privacy officer maintains a reminder system to manually disable access on the same basis.
Notification and Termination of Access and Use As per HR-10: Termination or Cessation of the Employment or Contractual Relationship, agents and
their supervisors are required to notify the Executive Director and the Privacy Officer of the termination
of an employment or contractual relationship two weeks in advance, if possible. The notification must
be via e-mail and contain the following information:
Name of Agent
Termination date
Reasons for termination
Within three days, the Executive Director, or designate forwards the name of the Agent and the
termination date to the BORN System Administrator who arranges for the withdrawal of access to
Personal Health Information on termination date and updates P-09: Log of Agents Granted Approval to
Access/Use/Disclose Personal Health Information.
Retention of Personal Health Information An Agent who is granted approval to access and use Personal Health Information by BORN must securely
retain the records of Personal Health Information in compliance with S-06: Secure Retention of Personal
Health Information.
Secure Disposal of Personal Health Information An Agent granted approval to access and use Personal Health Information must securely dispose of the
records of Personal Health Information in compliance with S-08: Secure Disposal of Personal Health
Information.
Tracking Approved Access to and Use of Personal Health Information The BORN System Administrator maintains a log of Agents granted approval to access, use and disclose
Personal Health Information by BORN. See P-09: Log of Agents Granted Approval to
Access/Use/Disclose Personal Health Information and S-10: System Control and Audit Logs.
Document Retention The Privacy Officer is responsible for securely maintaining all files relating to Agent access and use of
Personal Health Information, including:
42 | P a g e
Agent Data Access Forms Letters of denial of access, where applicable
Notices of Termination/change from BORN supervisors
All correspondence with the System Administrator
Signed Confidentiality Agreements
The System Administrator securely maintains the Log of Agents Granted Approval to
Access/Use/Disclose Personal Health Information. Documents are retained in the BORN shared drive.
P-08A: BORN PHI Access Request Form (BIS) The BIS Access Form is located on the BORN shared drive.
\Privacy\BIS and X Drive Access Forms\Agent Data Access Forms\
P-08B: BORN PHI Access Request Form (PHI Drive) The PHI Drive Access Form is located on the BORN shared drive.
\Privacy\BIS and X Drive Access Forms\Agent Data Access Forms\
The Standard Operating Procedure (SOP) to obtain access and complete the forms is located on the
BORN departmental drive: \General\Standard Operating Procedure (SOP)
43 | P a g e
44 | P a g e
P-09: Log of Agents Granted Approval to Access/Use/Disclose Personal Health Information The log of Agents Granted Approval to Access/Use/Disclose Personal Health Information is saved in the
privacy folder:
GENERAL\Privacy\Logs Populated\Privacy\P-09 - Log of Agents Granted Approval to Access-Use-
Disclose
The following fields are captured in the Log of Agents Granted Approval to Access/Use/Disclose Personal
Health Information:
Name of Agent
Data Holding
Level and type of access
Any conditions imposed on access
Data access granted
Level and type of use
Data use granted
Any condition imposed on use
Level and type of disclosure
Any conditions imposed on disclosure
Timeframe that applies to the authorization – automatically set to 1 year unless subject to shorter
timeframe (if less than one year, specify timeframe)
Date access terminated
Reason access terminated
P-10: Use of Personal Health Information for Research
Purpose The purpose of this policy is to identify BORN policies and procedures on the use of Personal Health Information by Agents for research purposes.
Policy BORN limits the use of Personal Health Information to those purposes authorized by PHIPA and its regulation.
BORN permits use of Personal Health Information for research purposes as authorized under PHIPA where
Agents meet the requirements for research provided in PHIPA section 44 and associated regulations
The purpose for the use is in accordance with the stated purpose for the Registry
BORN will not use Personal Health Information for research purposes if other information will serve the research purpose. BORN will not use more Personal Health Information than is reasonably necessary to meet the identified research purpose.
Procedure This procedure covers three types of use:
1. Use of Personal Health Information for Research
2. Use of De-identified Information for Research
3. Use of Aggregate Information for Research
Use of Personal Health Information for Research
Review Process 1. Agents interested in a prospective research project should consult with the appropriate subject
matter expert within BORN. This facilitates identification of potential redundancy in research or
opportunities for collaboration.
2. Agents requesting the use of Personal Health Information as part of a research data set must submit
to the Data Request and Research Coordinator:
45 | P a g e
A completed Data Request Form (available on the BORN website)
A research plan, where the research plan must be in writing and must fulfill the requirements
set out in section 44(2) of PHIPA and section 16 of the regulation.
3. The Data Request and Research Coordinator reviews the Data Request Form for completeness and
to confirm that the request constitutes a Research use. In the context of PHIPA, Research means a
systematic investigation designed to develop or establish principles, facts or generalizable
knowledge, or any combination of them, and includes the development, testing and evaluation of
research. The request is not research if it:
Does not test a specified hypothesis
Is intended to provide data for quality improvement or resource allocation analysis
Relates to improving care for a specific individual
Does not create new knowledge
4. Once the review of the Data Request Form is complete, the Research Review Committee undertakes
a further review of the Data Request Form, the Research plan, a copy of the decision of a Research
Ethics Board that approved the research plan (unless such approval is still pending), any relevant
electronic correspondence with the Agent regarding the research request (where such information
has not been otherwise supplied or summarized), and the list of the proposed data elements to:
Determine that the research plan complies with the requirements of PHIPA, including its
regulation1
1 A research plan must be in writing and must set out, (a) the affiliation of each person involved in the research; (b) the nature and objectives of the research and the public or scientific benefit of the research that the researcher anticipates; and (c) all other prescribed matters related to the research, e.g., (1) A description of the research proposed to be conducted and the duration of the research. (2) A description of the personal health information required and the potential sources. (3) A description of how the personal health information will be used in the research, and if it will be linked to other information, a description of the other information as well as how the linkage will be done. (4) An explanation as to why the research cannot reasonably be accomplished without the personal health information and, if it is to be linked to other information, an explanation as to why this linkage is required. (5) An explanation as to why consent to the disclosure of the personal health information is not being sought from the individuals to whom the information relates. (6) A description of the reasonably foreseeable harms and benefits that may arise from the use of the personal health information and how the researchers intend to address those harms. (7) A description of all persons who will have access to the information, why their access is necessary, their roles in relation to the research, and their related qualifications. (8) The safeguards that the researcher will impose to protect the confidentiality and security of the personal health information, including an estimate of how long information will be retained in an identifiable form and why. (9) Information as to how and when the personal health information will be disposed of or returned to the health information custodian. (10) The funding source of the research. (11) Whether the researcher has applied for the approval of another research ethics board and, if so the response to or status of the application. (12) Whether the researcher’s interest in the disclosure of the personal health information or the performance of the research would likely result in an actual or perceived conflict of interest with other duties of the researcher.
46 | P a g e
47 | P a g e
Confirm that the research plan has been or will be approved by a Research Ethics Board
Determine that the purpose for the use is in accordance with the stated purpose for the
prescribed Registry
Determine that the Personal Health Information being requested is consistent with the Personal
Health Information identified in the written research plan as approved by the Research Ethics
Board (or as will be supplied for approval by the Research Ethics Board)
Determine whether aggregate data or de-identified information could meet the identified
research need where Personal Health Information is being requested
Where Personal Health Information is being requested, the Data Request and Research
Coordinator works with the Agent undertaking research to refine the list of data elements in
support of the research request. The purpose of this process is to ensure that the minimum
number of data elements and the least identifiable information are used while maintaining the
feasibility of the research project
Approval Process The RRC will make advisory decisions regarding the use of BORN data related to all research requests.
Where the use of Personal Health Information for research purposes has been approved by the
committee, the Data Request and Research Coordinator prepares an email of approval which sets out:
Purpose of the research
Rationale for the approval of the use for research purposes
Any conditions or restrictions that will be imposed
List of agreed-upon data elements
Approved requests are communicated electronically by the Data Request and Research Coordinator to
the Agent. For Agents requesting use of Personal Health Information for research purposes, approvals
are conditional on the execution of a BORN Confidentiality Agreement.
The Data Request and Research Coordinator updates P-11: Log of Approved Uses of Personal Health
Information for Research as applicable.
Provision of Data set Containing Personal Health Information The Data Request and Research Coordinator arranges for the data set to be generated.
Once the data set is prepared, the Data Request and Research Coordinator:
Checks the data set against the list of agreed-upon data elements for accuracy
Ensures that any conditions or restrictions have been satisfied
Updates P-11: Log of Approved Uses of Personal Health Information for Research, as applicable,
including date of use, data retention period,
Directs the Agent to the data set on a secure, encrypted drive equipped with appropriate access
controls.
The Agent’s supervisor and Privacy Officer is responsible for monitoring the Agent’s compliance with
the documentation including any restrictions or conditions on the use of the Personal Health
Information for research purposes.
Retention The policy sets out that the Agent ensures the data set is stored on a secure, encrypted drive equipped
with appropriate access controls as per BORN policy S-05: Retention of Records of Personal Health
Information and ensures that retention is compliant to the Research Ethics Board approved written
research plan.
Disposal/Destruction of Personal Health Information The P-11: Log of Approved Uses of Personal Health Information for Research tracks the disposal date for
the Data Request and Research Coordinator or Privacy Officer to follow-up. The Privacy Officer ensures
that the Agent is contacted regarding the disposal date if the Agent has not provided BORN with written
confirmation of disposal within seven days of the disposal date in the Data Tracking Log.
All certificates of destruction provided by Agents must include the following information (see P-11B:
Certificate of Destruction):
List of the records of Personal Health Information to be securely destroyed
Description of the secure disposal of the records
The date, time and method of secure disposal employed
The name and signature of the Agent(s) who performed the secure disposal and a person who
witnessed the destruction
Certificates of destruction must be received by the Data Request and Research Coordinator, Privacy
Officer or designate within one week of the date of destruction set out in the written research plan or
the agent is in breach of this policy and BORN may take measures as per HR-11: Discipline and
Corrective Action. BORN may also notify the Agent’s professional body, the Information and Privacy
Commissioner and any other suitable oversight body that the Agent is in breach and, where appropriate,
lodge a complaint against the Agent.
Use of De-identified Information for Research Due to the sensitive nature of de-identified information, it will be treated as Personal Health
Information and follow the procedure above, P-10: Use of Personal Health Information for Research
except the data set is prepared in compliance with BORN policy P-24: De-Identification and Aggregation,
which:
Documents the approved BORN definition of de-identified data and,
48 | P a g e
Mandates the use of the De-identification Tools for empirical assessment regarding risk of re-
identification
Agents are prohibited from using the de-identified information, either alone or with other information,
to identify an individual, including attempting to decrypt information that is encrypted, attempting to
identify an individual based on unencrypted information and attempting to identify an individual based
on prior knowledge. This provision is ensured through the Confidentiality Agreement.
Use of Aggregate Information for Research
Review Process 1. Agents requesting the use of aggregate information for Research set must submit to the Data
Request and Research Coordinator:
A completed Data Request Form (available from the DART team or from the BORN website)
A research plan, where the research plan must be in writing and must fulfill the requirements
set out in section 44(2) of PHIPA and section 16 of the regulation
A copy of the decision of a Research Ethics Board that approved the research plan (unless such
approval is still pending)
2. The Data Request and Research Coordinator reviews the Data Request Form for completeness and
to confirm that the request constitutes a research use. In the context of PHIPA, Research means a
systematic investigation designed to develop or establish principles, facts or generalizable
knowledge, or any combination of them, and includes the development, testing and evaluation of
research. The request is not research if it:
Does not test a specified hypothesis
Is intended to provide data for quality improvement or resource allocation analysis
Relates to improving care for a specific individual
Does not create new knowledge
3. Once the review of the Data Request Form is complete, the Research Review Committee undertakes
a further review to:
Determine that the research plan complies with the requirements of PHIPA
Confirm that the research plan has been approved (or, more likely will be approved) by a
Research Ethics Board
Determine that the purpose for the use is in accordance with the stated purpose for the
prescribed Registry
49 | P a g e
Determine that the aggregate Information being requested is consistent with the information
identified in the written research plan approved (or to be approved) by the Research Ethics
Board
Approval Process Where the Research Review Committee approves the use of aggregate information for research
purposes the Data Request and Research Coordinator prepares an official letter of approval which sets
out:
Purpose of the research
Rationale for the approval of the use for research purposes
Any conditions or restrictions that will be imposed
Approved requests are communicated electronically by the Data Request and Research Coordinator to
the Agent. Approvals are conditional on the execution of a BORN Confidentiality Agreement which the
Data Request and Research Coordinator verifies with the Privacy Officer.
Agents are prohibited from using the information, either alone or with other information, to identify an
individual, including attempting to decrypt information that is encrypted, attempting to identify an
individual based on unencrypted information and attempting to identify an individual based on prior
knowledge. This is done via the Confidentiality Agreement.
Provision of Aggregate Information The Data Request and Research Coordinator arranges for the aggregate information to be generated in
compliance with P-24: De-Identification and Aggregation and informs the Agent when it is ready for use.
The Data Request and Research Coordinator updates the Log of Approved Uses of Personal Health
Information for Research.
Document Retention The Data Request and Research Coordinator is responsible for the retention of:
Data Request form
Written research plan
A copy of the decision of a Research Ethics Board that approved the research plan
List of agreed-upon data elements
Data Request and Research Coordinator ’s letter of approval
Approval from the Privacy and Security Review Committee, where applicable
Log of Approved Uses of Personal Health Information for Research
The Privacy Officer is responsible for the retention of:
50 | P a g e
51 | P a g e
Signed Confidentiality Agreements for all agents
Certificates of Destruction
Documents are retained in the BORN shared drive.
P-11: Log of Approved Uses of Personal Health Information for Research The Log of Approved Uses of Personal Health Information is maintained by the Data Request and
Research Coordinator and is automatically stored in BORNs computer system. The log contains:
Name and identification number of research study
Agent last name/Agent first name
Date of Research Ethics Board approval
Date of Research Review Committee approval
Date Personal Health Information provided to Agent
Nature of Personal Health Information
Retention period as per Research Ethics Board plan (if applicable)
Date of secure disposal of Personal Health Information/certificate of destruction received (if
applicable)
P-11A: Data Tracking Log The Data Tracking Log is maintained by the Data Request and Research Coordinator and is
automatically stored in BORNs computer system BORN File #
Date Written Request Received
Data Requestor Last Name
Data Requestor First Name
On behalf of/for
Description of data request
BORN Database that provides answer
De-identification Assessment required Y/N
Permission to release granted by
Date and Initials of person completing final check of data output before sending to Data Requestor
Date data sent to Data Requestor and mode of transfer
Internal Notes
P-11B: Certificate of Destruction
TECHNICAL GUIDELINES FOR SECURE DESTRUCTION OF CONFIDENTIAL INFORMATION
INTRODUCTION As set out in your Research Agreement, use of BORN data is time limited. Your organization must ensure
that all BORN data—the original and/or copies of the data in your custody or control—is destroyed in a
secure manner by the date specified in your Research Agreement.
“Destroy in a secure manner” means to destroy the data in such a manner that reconstruction is not
reasonably foreseeable.
This document explains BORN’s minimum requirements for secure destruction of data.
GENERAL GUIDELINES Paper, CDs, DVDs or similar portable optical/magnetic disks (e.g. floppy disks or Blu-Ray Discs) including
rewritable formats are to be physically destroyed using a crosscut-shredding machine.
Computers, servers, other media, including hard disks, floppy drives, optical disks, USB keys/flash drives
and magnetic tapes require physical destruction, degaussing (where appropriate) and a complete
sanitizing overwrite of the entire medium are preferred methods of secure destruction of electronic
media.
If the computer, server or other device remains in the secure custody of the accountable organization,
then selective wiping of individual files and/or folders is permitted. Confirmation must be provided that
the device containing BORN data will be subject to an end-of-life secure destruction by physical
destruction, degaussing (where appropriate) or a complete sanitizing overwrite of the entire medium in
accordance with industry best practices.
Back-up systems containing BORN confidential information must be physically destroyed, degaussed
(where appropriate) or subject to complete sanitizing overwrite. If this is not attainable within the
timeframes set out in the Research Agreement, the certificate of destruction must:
Certify that backup systems are secure and that the contents are recovered only for business continuity and disaster recovery purposes
Describe how the policies and procedures around backup systems will result in secure destruction of the data
Confirm that back-up media are subject to an end-of-life program that includes physical destruction, degaussing (where appropriate) or complete sanitizing overwrite of all spaces in accordance with industry best practices.
52 | P a g e
CERTIFICATE OF DESTRUCTION The content of the certificate of destruction is outlined below:
The information described below was destroyed in the normal course of business pursuant to the
organizational retention schedule and destruction policies and procedures.
Organization:
Organization Contact:
Date and time of Destruction:
Authorized By:
List and/or Description of Personal Health Information or De-identified Data or Data Disposed
Of/Destroyed:
Inclusive Dates Covered:
METHOD OF DESTRUCTION:
Overwriting
Pulping
Pulverizing
Grinding
Shredding
Degaussing/secure wiping utility (provide details: ______________________________
Other: _________________________________________________________________
Records Destroyed By* (print and sign):
Witnessed By (print and sign):
Department Manager:
*If records destroyed by outside firm, must confirm a contract exists
53 | P a g e
P-12: Disclosure of Personal Health Information for Purposes Other Than Research
Purpose The purpose of this Policy is to ensure that BORN only discloses Personal Health Information for those
purposes authorized by PHIPA and its regulation.
Policy BORN limits the disclosure of Personal Health Information to those purposes permitted under PHIPA and
its regulation.
BORN will not disclose Personal Health Information if other information will serve the purpose and will
not disclose more Personal Health Information than is reasonably necessary to meet the purpose.
Responsibility Data Request and Research Coordinator, Privacy Officer
Procedure Any decisions made by the PHI Disclosure Committee to disclose Personal Health Information must
involve the Executive Director and be approved of by the Executive Director.
BORN permits the disclosure of personal health information for purposes other than research only in the
following circumstances in accordance with the Personal Health Information Protection Act, 2004 and its
regulation:
1. For the purpose of carrying out a statutory or legal duty as per section 49(1) (b) of PHIPA
2. For the purpose for which the health information custodian was authorized to disclose the
information under PHIPA section 49(1)(a)
3. To a prescribed planning entity under regulation section13(5) of PHIPA
4. To a health data institute under section 13(5) and section 47 of PHIPA
Type 1: Disclosures Under section 49(1)(b) The Privacy Officer informs the Data Request and Research Coordinator of all disclosures for the
purpose of carrying out a statutory or legal duty as per section 49(1) (b) of PHIPA. The Data Request and
Research Coordinator enters the data disclosure into the Data Tracking Log.
Type 2: Disclosures Under section 49(1)(a)
Review Process BORN discloses personal health information under section 49(1) (a) to facilitate and improve the
provision of Health Care.
54 | P a g e
A health information custodian requesting disclosure of Personal Health Information for non-research
purposes must complete a P-12A: Data Request Forms available on the BORN website and submits the
completed form electronically to the Data Request and Research Coordinator.
The Data Request and Research Coordinator reviews the Data Request Form along with the Information
Security Officer and the Privacy Officer to:
Determine if the disclosure is permitted or required under PHIPA and its regulation
Determine that the purpose for the disclosure is in accordance with the stated purpose for the
prescribed Registry as defined in P-07: Evidence: Statements of Purpose for Data Holdings
Containing Personal Health Information (where purposes are listed under A – F)
Confirm that the Personal Health Information is indeed reasonably required for the purpose and
that no other information, such as de-identified or aggregate information would suffice for the
purpose
Determine that no more personal health information is being requested than is reasonably
necessary to meet the identified purpose; where Personal Health Information is being requested
Examples of the types of disclosures by BORN under section 49(1)(a) include:
Missed screen: Where BORN is disclosing to a health information custodian under section 49(1)
(a) that a necessary screening procedure for a mother or newborn has been missed, the BORN
Information System produces an Alert report that is available to the clinical program impacted
by the missed screen.
The leadership of the clinical program is responsible for contacting the appropriate Health Care
providers.
Gestational Diabetes follow-up screen: Where BORN is disclosing to a health information
custodian under section 49(1) (a) that a mother tested positive during her pregnancy for
gestational diabetes, and as such requires follow-up screening following the birth of her child,
the BORN System will produce a report that is sent to primary Health Care providers detailing
the patients requiring the follow-up screening test. This disclosure is under development and
will include informing the affected persons that the disclosure will occur. These persons will
be offered the option to opt-out of the program by filling out an opt-out form that will be
available on the BORN website at www.BORNOntario.ca
Once the review is complete and it is determined that all conditions are satisfied and that Personal
Health Information is required for the disclosure, the Data Request and Research Coordinator forwards a
request to the PHI Disclosure Committee for review and approval and provides the following:
Background of the project including how it aligns with BORN purposes
Rationale for the recommendation to approve the disclosure
List of agreed-upon data elements
Method of disclosure
Results of the review by the Data Request and Research Coordinator, Information Security
Officer and Privacy Officer
Any relevant electronic correspondence
55 | P a g e
Approval Process Denied requests and the reasons for the decision are communicated electronically by the Data Request
and Research Coordinator to the health information custodian.
Where the PHI Disclosure Committee approves the disclosure, the Data Request and Research
Coordinator will prepare an official letter of approval which sets out:
Purpose of the project
Rationale for the approval of the use for non-research purposes
Any conditions or restrictions that will be imposed
List of agreed-upon data elements
Approvals are conditional on the execution of a data sharing agreement.
The Data Request and Research Coordinator:
Communicates the approval to the health information custodian
Forwards to the Privacy Officer a letter or approval, along with a link to the secure BORN drive
containing the supporting project documentation
The Data Request and Research Coordinator updates the Data Tracking Log.
Data Sharing Agreement BORN executes a data sharing agreement with the health information custodian as per P-16: Data
Sharing Agreements and as per P-17: Template Data Sharing Agreement: Disclosure of Personal Health
Information and:
• Informs the Data Request and Research Coordinator that the data sharing agreement has been fully
executed
• Enters the disposal date into the log P-18 Log of Data Sharing Agreements. The log is monitored for
upcoming dates of disposal by the Privacy Officer, for follow-up
• Sends a copy of the executed data sharing agreement to the health information custodian.
The Data Request and Research Coordinator updates the Data Tracking Log.
Provision of Personal Health Information The Data Request and Research Coordinator arranges for the data set to be prepared as per the method
of disclosure approved by the Disclosure of Personal Health Information Committee.
The Data Request and Research Coordinator:
Cross checks the data generated or built as per the method of disclosure approved by the
Disclosure of Personal Health Information Committee against the list of agreed-upon data
elements in the data sharing agreement
Ensures that any conditions or restrictions have been satisfied
Ensures the data set is password protected or equivalent
Secure Transfer of Personal Health Information The records of personal health information are securely transferred, compliant to S-07: Secure Transfer
of Records of Personal Health Information. The specific method of transfer is documented in the data
56 | P a g e
sharing agreement. The health information custodian confirms receipt of the data to the Data Request
and Research Coordinator, who updates the Data Tracking Log.
Disposal/Destruction of Personal Health Information The data sharing agreement specifies data retention dates and method, notification and verification of
the disposal of Personal Health Information where applicable. The health information custodian must
comply with the requirements set out in the data sharing agreement, and provide a Certificate of
Destruction (included in the data sharing agreement) to the Privacy Officer within the timeframes set
out in the data sharing agreement, where applicable. The method of secure disposal mandated by the
data sharing agreement is consistent with PHIPA and its regulation, with orders issued by the
Information and Privacy Commissioner of Ontario, including Order HO-001 and Order HO-006, and with
guidelines, fact sheets and best practices issued by the Information and Privacy Commissioner of
Ontario including Fact Sheet 10.
Upcoming dates of disposal are monitored by the Privacy Officer in log P-18 Log of Data Sharing
Agreements for follow-up. The Privacy Officer ensures that the recipient is contacted regarding the
disposal date if the Privacy Officer has not received the certificate of destruction on the date set out in
the data sharing agreement, as applicable.
If action is not taken by the recipient within seven days of the disposal date in the data sharing
agreement, the recipient is in breach of the Agreement and BORN may take all measures authorized by
the Agreement. BORN may also notify the Information and Privacy Commissioner that the recipient is in
breach and lodge a complaint.
Type 3 and 4: Disclosures to a Prescribed Entity or a Health Data Institute Under regulation section 13(5) and section 47 of PHIPA
Review Process A prescribed entity or data institute requesting disclosure of Personal Health Information for non-
research purposes must complete a P-12A: Data Request Forms available on the BORN website and
submit the completed form electronically to the Data Request and Research Coordinator.
The Data Request and Research Coordinator reviews the Data Request Form along with the Information
Security Officer and the Privacy Officer to:
57 | P a g e
Determine if the disclosure is permitted or required under PHIPA and its regulation
Determine if the purpose for the disclosure is in accordance with the stated purpose for the BORN
Registry
Confirm that the Personal Health Information is indeed reasonably required for the purpose and
that no other information, such as de-identified or aggregate information would suffice for the
purpose
Confirm that the amount of information that is requested is limited to the minimum amount
reasonably required to meet the purpose
Once the review is complete and it is determined that all conditions are satisfied and that Personal
Health Information is required for the disclosure, the Data Request and Research Coordinator forwards a
request to the PHI Disclosure Committee for review and approval and provides the following:
Background of the project including how it aligns with BORN purposes
Rationale for the recommendation to approve the disclosure
List of agreed-upon data elements
Method of disclosure
Results of the review by the Data Request and Research Coordinator, Information Security
Officer and Privacy Officer
Any relevant electronic correspondence
Approval Process Denied requests and the reasons for the decision are communicated electronically by the Data Request
and Research Coordinator to the prescribed entity or data institute.
Where the PHI Disclosure Committee approves the disclosure, the Data Request and Research
Coordinator will prepare an official letter of approval which sets out:
Purpose of the project
Rationale for the approval of the use for non-research purposes
Any conditions or restrictions that will be imposed
List of agreed-upon data elements
Approvals are conditional on the execution of a data sharing agreement.
The Data Request and Research Coordinator:
Communicates the approval to the prescribed entity or data institute
Forwards to the Privacy Officer the letter or approval, along with a link to the secure BORN drive
containing the supporting project documentation
The Data Request and Research Coordinator updates the Data Tracking Log.
Data Sharing Agreement BORN executes a data sharing agreement with the recipient as per P-16: Data Sharing Agreements and
as per P-17: Template Data Sharing Agreement: Disclosure of Personal Health Information and:
58 | P a g e
Informs the Data Request and Research Coordinator that the data sharing agreement has been
fully executed
The log is monitored for upcoming dates of disposal by the Privacy Officer, for follow-up.
Sends a copy of the executed data sharing agreement to the recipient
The Data Request and Research Coordinator updates the Data Tracking Log.
Provision of Personal Health Information The Data Request and Research Coordinator provides a copy of the data element list from the data
sharing agreement to a BORN analyst who produces the data set as per the list of data elements and a
specification list of the data set for the Data Request and Research Coordinator.
The Data Request and Research Coordinator:
Directly cross checks the information on the specification list against the data element list on
the data sharing agreement
Ensures that any conditions or restrictions have been satisfied
Ensures the data set is password protected
Secure Transfer Disclosures to a prescribed entity or data institute are done using the secure network provided by the
prescribed entity or data institute. The prescribed entity or data institute e-mails the Data Request and
Research Coordinator confirming receipt. The Data Request and Research Coordinator records the date
of disclosure and receipt of the data set information in the Data Tracking Log.
Disposal/Destruction of Personal Health Information The data sharing agreement specifies data retention dates and method, notification and verification of
the disposal of Personal Health Information. The prescribed entity or data institute must comply with
the requirements set out in the data sharing agreement, and provide a certificate of disposal to the
Privacy Officer within the timeframes set out in the data sharing agreement.
Upcoming dates of disposal are monitored by the Privacy Officer in log P-18 Log of Data Sharing
Agreements for follow-up. The Privacy Officer ensures that the recipient is contacted regarding the
disposal date if the Privacy Officer has not received the certificate of destruction on the date set out in
the data sharing agreement, as applicable.
59 | P a g e
If action is not taken by the prescribed entity or data institute within seven days of the disposal date in
the data sharing agreement, the prescribed entity or data institute is in breach of the Agreement and
BORN may take all measures authorized by the Agreement. BORN may also notify the Information and
Privacy Commissioner that the prescribed entity or data institute is in breach and lodge a complaint.
Disclosure of De-identified Data for Purposes Other Than Research
Review and Approval Process Individuals or organizations requesting disclosure of de-identified data for non-research purposes must
complete a P-12A: Data Request Forms2 available on the BORN website and submit the completed form
electronically to the Data Request and Research Coordinator.
Upon receipt of the completed form, the Data Request and Research Coordinator will review the Data
Request Form for completeness and to confirm that the project does not constitute a research use. The
request is considered Research in the context of PHIPA using the same tests as described in P-10: Use of
Personal Health Information for Research).
If the project is determined to be Research, the Data Request and Research Coordinator informs the
Data Requestor in writing of the need to proceed as per P-13: Disclosure of Personal Health
Information for Research Purposes and the Execution of Research Agreements.
Data Request and Research Coordinator works with the Data Requestor to compile a list of data
elements in support of the request. The purpose of this process is to ensure that the minimum number
of data elements and the least identifiable information are used while maintaining the feasibility of the
project. This process generally requires at least one and sometimes two or more meetings to discuss the
project and data.
2 All Data Request Forms accepted by BORN must contain a signed acknowledgment in a form approved of by CHEO legal department that the prospective recipient will not use the information received from BORN, either alone or with other information, to identify an individual. This is intended to ensure that all acknowledgments are obtained and recorded automatically in advance using our electronic forms. This procedure change is part of our redesigned DART process and the new forms will be implemented on or before October 31, 2020.
60 | P a g e
The PHI Disclosure Committee is then convened to review the Data Request Form and
recommendations of the Data Request and Research Coordinator to:
Determine if the disclosure is permitted or required under PHIPA and its regulation
Determine that the purpose for the disclosure is in accordance with the stated purpose for the
prescribed Registry as defined in P-07: Evidence: Statements of Purpose for Data Holdings Containing Personal Health Information
Confirm that the amount of information that is requested is limited to the minimum amount
reasonably required to meet the purpose
Determine any other requirements, conditions, or restrictions that might be added to the standard
data sharing agreement in these circumstances
Denied requests and the reasons for the decision are communicated electronically by the Data Request and Research Coordinator to the Data Requestor.
Approved requests are communicated electronically by the Data Request and Research Coordinator to
the Data Requestor.
The Data Request and Research Coordinator or designate prepares an official letter of approval which
sets out:
Purpose of the project
Rationale for the approval of the use for non-research purposes
Any conditions or restrictions that will be imposed
List of agreed-upon data elements
Approvals are conditional on the execution of a data sharing agreement.
The Data Request and Research Coordinator forwards to the Privacy Officer the letter of approval, along
with a link to the secure BORN drive containing the supporting project documentation.
The Data Request and Research Coordinator updates the Data Tracking Log.
Data Sharing Agreement BORN executes a data sharing agreement with the individual or organization as per P-16: Data Sharing
Agreements and as per P-17: Template Data Sharing Agreement: Disclosure of Personal Health
Information and:
Informs the Data Request and Research Coordinator that the data sharing agreement has been
fully executed
Enters the disposal date into the log P-18 Log of Data Sharing Agreements. The log is monitored
for upcoming dates of disposal by the Privacy Officer, for follow-up
Sends a copy of the executed data sharing agreement to the recipient
Provision of De-identified Data The Data Request and Research Coordinator arranges for the de-identified data set to be generated,
where the BORN definition of de-identified data and method of de-identification is mandated in policy
61 | P a g e
62 | P a g e
P-24: De-Identification and Aggregation. As per this policy, the BORN data analyst uses the De-
identification Tools for empirical assessment regarding risk of re-identification.
Once the data set is prepared, the Data Request and Research Coordinator:
Undertakes a final review of the data to:
o Check for any residual risk of re-identification – to ensure the data set does not identify
an individual and that is not reasonably foreseeable in the circumstances that the
information could be utilized, either alone or with other information, to identify an
individual
o Verify the data against the approved list and the data sharing agreement, check quality
and frequencies, validate any documentation written to accompany the dataset (data
dictionary, for example)
Ensures that any conditions or restrictions have been satisfied
Ensures that the data set is password protected
Ensures that the data set does not identify an individual
Secure Transfer The method by which the personal health information must be compliant to S-07: Secure Transfer of
Records of Personal Health Information. The specific method of transfer is documented in the data
sharing agreement. The recipient contacts the Data Request and Research Coordinator to confirm
receipt of the data and to obtain the password.
The Data Request and Research Coordinator records the information in the Data Tracking Log.
Disclosure of Aggregate Data for Purposes Other Than Research
Review and Approval Process Individuals or organizations requesting disclosure of aggregate data for non-research purposes must
complete a P-12A: Data Request Form, which is available on the BORN website and then submit the
completed form electronically to the Data Request and Research Coordinator.
Upon receipt of the completed form, the Data Request and Research Coordinator will review the Data
Request Form for completeness and to confirm that the project does not constitute a research use. The
request is considered research if it:
Tests specific hypotheses
Is designed to develop or establish principles, facts, or generalizable knowledge
If the project is determined to be research, the Data Request and Research Coordinator informs the
Data Requestor in writing of the need to proceed as per P-13: Disclosure of Personal Health
Information for Research Purposes and the Execution of Research Agreements unless aggregated.
The Data Request and Research Coordinator also reviews the Data Request Form to:
Determine if the disclosure is permitted or required under PHIPA and its regulation
Determine that the purpose for the disclosure is in accordance with the stated purpose for the
prescribed Registry as defined in P-07: Evidence: Statements of Purpose for Data Holdings
Containing Personal Health Information
Confirm that the amount of information that is requested is limited to the minimum amount
reasonably required to meet the purpose. The Data Request and Research Coordinator works
with the Data Requestor to refine the data request as necessary.
Denied requests and the reasons for the decision are communicated electronically by the Data Request
and Research Coordinator to the Data Requestor.
Approved requests are communicated electronically by the Data Request and Research Coordinator to
the Data Requestor.
The Data Request and Research Coordinator enters the information into the Data Tracking Log.
Provision of Aggregate Data The Data Request and Research Coordinator arranges for the aggregate information to be generated in
compliance with P-24: De-Identification and Aggregation and informs the Data Requestor when it is
ready for use.
Once the data are prepared, the Data Request and Research Coordinator:
Undertakes a final review of the data to identify any residual risk of re-identification (ensures
the data set does not identify an individual and that is not reasonably foreseeable in the
circumstances that the information could be utilized, either alone or with other information, to
identify an individual)
Ensures that any conditions or restrictions have been satisfied
63 | P a g e
Ensures that the data is password protected
Ensures the release e-mail contains the following boiler plate information: This message, including any attachments, contains confidential information and is for the sole
use of the intended recipient(s). Any unauthorized use, disclosure or distribution is prohibited. If
you are not the intended recipient, please notify the sender immediately and destroy the original
message. The intended recipient of this message will not use the information, either alone or
with other information, to attempt to identify or re-identify an individual. This includes
attempting to decrypt information that is encrypted, attempting to identify an individual based
on unencrypted information and attempting to identify an individual based on prior knowledge.
Secure Transfer of Aggregate Data and Acknowledging Receipt of Data Approved request for aggregate data are sent via e-mail, compliant to S-07: Secure Transfer of Records
of Personal Health Information. The recipient contacts the Data Request and Research Coordinator to
confirm receipt of the data and to obtain the password (unless it has been already sent by a separate
communication), where applicable.
The Data Request and Research Coordinator records the information in the Data Tracking Log.
Document Retention The Data Request and Research Coordinator has responsibility for the retention of:
Data Request Form
Data Tracking Log
Correspondence between the Data Requestor and BORN
Relevant documentation from the De-identification Tools
The Privacy Officer has responsibility for the retention of all data sharing agreements and the log of data
sharing agreements.
Documents are retained in the privacy folder.
P-12A: Data Request Forms BORN has Data Request Forms that are available and include:
BORN Record Level Data Request Form
BORN Aggregate Data Request Form
There may be other Data Request Forms that are from time to time used and are available from BORN
upon request or as available at BORN’s website.
64 | P a g e
P-13: Disclosure of Personal Health Information for Research Purposes and the Execution of Research Agreements
Purpose The purpose of this policy is to ensure that BORN only discloses Personal Health Information for
research purposes in accordance with PHIPA and its regulation.
Policy BORN permits disclosure of Personal Health Information for research purposes as authorized under
PHIPA and its regulation. Researchers must meet the requirements for research disclosure provided in
section 44 of the Act and associated regulations.
BORN will not disclose Personal Health Information for research purposes if other information will serve
the research purpose.
BORN will not disclose more Personal Health Information than is reasonably necessary to meet the
identified research purpose.
Responsibility Data Request and Research Coordinator
Procedure This procedure covers three types of disclosure:
Disclosure of Personal Health Information for Research
Disclosure of De-identified Information for Research
Disclosure of Aggregate Information for Research
Review and Approval of the Disclosure of Personal Health Information for Research Researchers requesting disclosure of Personal Health Information must submit:
A completed Data Request Form (available on the BORN website)
A research plan, where the research plan must be in writing and must fulfill the requirements
set out in section 44(2) of PHIPA and section 16 of the regulation.
A copy of the decision of a Research Ethics Board that approved the research plan (unless such
approval is still pending)
The Data Request and Research Coordinator reviews the Data Request Form for completeness and to
confirm that the request constitutes a Research use in the context of PHIPA using the test described in
P-10: Use of Personal Health Information for Research.
Where Personal Health Information is being requested, the Data Request and Research Coordinator
works with the researcher to compile a list of data elements in support of the research request. The
65 | P a g e
purpose of this process is to ensure that the minimum number of data elements and the least
identifiable information are used while maintaining the feasibility of the research project. This process
generally requires at least one and sometimes two or more meetings to discuss the project and data.
Once the review of the Data Request Form is complete, the Research Review Committee undertakes a
further review to:
Determine that Personal Health Information disclosure is authorized by PHIPA and its regulation
Confirm that the research plan has been approved by a Research Ethics Board or that such
approval will be sought and obtained before any data release
Determines that the purpose for the disclosure is in accordance with the stated purpose of
BORN
Determine that the Personal Health Information being requested is consistent with the Personal
Health Information identified in the written research plan approved by the Research Ethics
Board
Determines if the data are available to answer the research question
Considers the scientific merit (whether the data and approach are appropriate to answer the
question) and whether there is opportunity for collaboration with others working on a similar
question
Determines whether aggregate data or de-identified record-level data would meet the identified
research need to the extent that it has not already been determined by the Research Ethics
Board
For data that will not undergo De-identification pursuant to P-24: De-Identification and Aggregation,
the Research Review Committee will make recommendations to the PHI Disclosure Committee
regarding the disclosure of PHI for research requests for data that has not undergone De-identification,
and the matter will be considered by the PDC for possible approval.
For cases where the PHI will undergo De-identification pursuant to P-24: De-Identification and
Aggregation, the RRC may approve or deny the request based on its own review; provided, however
that the PDC must also approve record level (i.e., non-aggregated) De-identified data disclosure
requests.
In all cases of approval, the Data Request and Research Coordinator prepares an official letter of
approval which sets out:
Purpose of the research
Rationale for the approval of the use for research purposes
Any conditions or restrictions that will be imposed
66 | P a g e
List of agreed-upon data
Approved requests are communicated electronically by the Data Request and Research Coordinator to
the researcher. Approvals are conditional on the execution of a BORN research agreement (except
where aggregated data is being sought).
The Data Request and Research Coordinator stores the following information:
Data Request Form
Research plan
A copy of the decision of a Research Ethics Board that approved the research plan
List of agreed-upon data elements
Recommendation from the Research Review Committee and approval from the PHI Disclosure
Committee
Data Request and Research Coordinator ’s letter of approval
Research Agreement for the Disclosure of Personal Health Information for Research The Privacy Officer prepares a research agreement with the researcher as per P-14: Template Research
Agreement and arrange for it to be fully executed. The Privacy Officer:
Informs the Data Request and Research Coordinator and Privacy Officer that the research
agreement has been fully executed
Enters the disposal date/retention period into P-15: Log of Research Agreements for follow-up.
Updates P-15: Log of Research Agreements as applicable
Sends a copy of the executed Research Agreement to the researcher.
Preparation of Personal Health Information for Research The Data Request and Research Coordinator provides a copy of the data element list from the research
agreement or the agreed upon list of data elements to a BORN analyst who produces for the Data
Request and Research Coordinator:
The data set as per the list of data elements
A specification list of the data set for the Data Request and Research Coordinator
The Data Request and Research Coordinator assigns a second BORN analyst to:
Cross check the information on the specification list and data set against the data element list
on the research agreement and review code
The Data Request and Research Coordinator:
67 | P a g e
Ensures that any conditions or restrictions have been satisfied
Ensures the dataset is password protected
Secure Transfer of Personal Health Information for Research The Data Request and Research Coordinator transfers the data set as per S-07: Secure Transfer of
Records of Personal Health Information. The researcher must call the Data Request and Research
Coordinator to confirm receipt of the data and to obtain the password.
The Data Request and Research Coordinator updates the Data Tracking Log and P-15: Log of Research
Agreements as applicable.
The Privacy Officer is responsible for monitoring the researcher’s compliance with the Research
Agreement including any restrictions or conditions on the use of the Personal Health Information for
research purposes.
Disposal/Destruction of Personal Health Information for Research In accordance with the Research Agreement which specifies data retention dates and method,
notification and verification of the disposal of Personal Health Information, the researcher must destroy
the Personal Health Information and provide confirmation of disposal as per the applicable Research
Agreement.
The Privacy Officer monitors P-15: Log of Research Agreements for follow-up. The Privacy Officer
ensures that the researcher is contacted regarding the disposal date if the researcher has not provided
BORN with written confirmation of disposal as per the requirements of the Research Agreement within
seven days of the disposal date.
All certificates of destruction provided by researchers must include the following information (see P-
11B: Certificate of Destruction):
List of the records of Personal Health Information to be securely destroyed
Description of the secure disposal of the records
The date, time and method of secure disposal employed
The name and signature of the Agent(s) who performed the secure disposal, and a person who
witnessed the destruction
The method of secure disposal mandated by BORN P-11B: Certificate of Destruction is consistent with
PHIPA and its regulation, with orders issued by the Information and Privacy Commissioner of Ontario,
including Order HO-001 and Order HO-006, and with guidelines, fact sheets and best practices issued by
the Information and Privacy Commissioner of Ontario including Fact Sheet 10.
The Privacy Officer must receive certificates of destruction within one week of the date of destruction
set out in Research Agreement.
68 | P a g e
If the certificate of destruction is not received within this time period, the researcher is in breach of the
Agreement and BORN may take all measures authorized by the Research Agreement. BORN may also
notify the researcher’s professional body, the Information and Privacy Commissioner and any other
suitable oversight body that the researcher is in breach and, where appropriate, lodge a complaint
against the researcher.
Extending the Research Project If a researcher wishes to extend the retention period to continue the same research project for which
the approval was granted:
The researcher applies in writing to the Data Request and Research Coordinator. The written
application for extension must include:
o The reason(s) retention of the Personal Health Information continues to be required
o Proposed new date of destruction
o Letter of approval for the extension obtained by the researcher from the Research
Ethics Board for extension of the retention period
If the application for extension is approved by the Research Ethics Board, the Data Request and
Research Coordinator sends a copy of the Approval Letter to the Privacy Officer with a request
that the Research Agreement be revised as outlined in the Research Ethics Board letter of
approval
BORN executes a revised Research Agreement
The Data Request and Research Coordinator updates the Data Tracking Log to reflect the new
retention period and destruction date
The Privacy Officer enters the revised data disposal date into the log of Research Agreements
Note: A researcher is prohibited from using Personal Health Information for any use not specified in the
applicable Research Agreement. To retain Personal Health Information for other purposes, the
researcher must undertake a new application as per this process.
Disclosure of De-identified Information for Research Due to the sensitive nature of de-identified information, it will be treated as Personal Health
Information and follow the procedure above, Disclosure of Personal Health Information for Research,
with the following differences:
There is no need for approval by the PHI Disclosure Committee. Rather, the Research Review Committee may review and approve the request.
The data set is prepared in compliance with BORN policy P-24: De-Identification and Aggregation which:
o Contains the approved BORN definition of de-identified data and,
69 | P a g e
o Mandates the use of the De-Identification Tools for empirical assessment regarding risk
of re-identification.
Researchers are prohibited from using the de-identified information , either alone or with other
information, to identify an individual, including attempting to decrypt information that is encrypted,
attempting to identify an individual based on unencrypted information and attempting to identify an
individual based on prior knowledge. This is done via the Research Agreement.
The Data Request and Research Coordinator:
Undertakes a final review of the data to ensure that it does not identify an individual and that is
not reasonably foreseeable in the circumstances that the information could be utilized, either
alone or with other information, to identify an individual
Enters the information into the Data Tracking Log
Disclosure of Aggregate Information for Research
Review Process Researchers requesting the use of aggregate information for research must submit to the Data Request
and Research Coordinator:
A completed Data Request Form (available on the BORN website)
A research plan, where the research plan must be in writing and must fulfill the requirements
set out in section 44(2) of PHIPA and section 16 of the regulation
A copy of the decision of a Research Ethics Board that approved the research plan
The Data Request and Research Coordinator reviews the Data Request Form for completeness and to
confirm that the request constitutes a Research use for the purposes of PHIPA (see P-10).
Once the review of the Data Request Form is complete, the Data Request and Research Coordinator
submits to the Research Review Committee who undertakes a further review to:
Determine that the research plan complies with the requirements of PHIPA
Confirm that the research plan has been approved by a Research Ethics Board
Determine that the purpose for the use is in accordance with the stated purpose for the
prescribed Registry
Determine that the aggregate Information being requested is consistent with the information
identified in the written research plan approved by the Research Ethics Board
Approval Process Where the Data Request and Research Coordinator approves the use of aggregate information for
research purposes, the approval is communicated electronically to the researcher.
70 | P a g e
Provision of Aggregate Information The Data Request and Research Coordinator arranges for the aggregate information to be generated in
compliance with P-24: De-Identification and Aggregation and informs the Data Requestor when it is
ready for use.
Once the data is prepared, the Data Request and Research Coordinator:
Undertakes a final review of the data to identify any residual risk of re-identification (ensures
the data set does not identify an individual and that is not reasonably foreseeable in the
circumstances that the information could be utilized, either alone or with other information, to
identify an individual)
Ensures that any conditions or restrictions have been satisfied
Ensures that the data is password protected
Ensures the e-mail contains the following boiler plate information:
This message, including any attachments, contains confidential information and is for the sole use of the
intended recipient(s). Any unauthorized use, disclosure or distribution is prohibited. If you are not the
intended recipient, please notify the sender immediately and destroy the original message. The intended
recipient of this message will not use the information, either alone or with other information, to attempt
to identify or re-identify an individual. This includes attempting to decrypt information that is encrypted,
attempting to identify an individual based on unencrypted information and attempting to identify an
individual based on prior knowledge.
Secure Transfer of Aggregate Data and Acknowledging Receipt of Data Approved request for aggregate data are sent via e-mail, compliant to S-07: Secure Transfer of Records
of Personal Health Information. The recipient contacts the Data Request and Research Coordinator to
confirm receipt of the data, where applicable.
The Data Request and Research Coordinator updates the Data Tracking Log and the Log of Research
Agreements.
Document Retention The Data Request and Research Coordinator is responsible for the retention of:
Data Request Form
Research plan
Decision of the Research Ethics Board that approved the research plan
Correspondence from the CHEO Research Ethics Board
De-identification documentation, where applicable
Approval from the PHI Disclosure Committee, where applicable
71 | P a g e
Correspondence between the researcher and BORN
Data Tracking Log
The Privacy Officer is responsible for the retention of:
Results of any audits performed by BORN
All records are maintained in the privacy folder.
72 | P a g e
P-14: Template Research Agreement The approved Research Agreement template is saved on the BORN Privacy drive:
GENERAL\Privacy\Agreements\Templates for all agreements\Research Agreement Template
73 | P a g e
74 | P a g e
P-15: Log of Research Agreements The log of Research Agreements is saved on the BORN Science drive:
BORN Science\BORN Data Requests and Forms\Data request logs
The following fields are captured in the Log of Research Agreements:
Name of research study
Principal researcher last name
Principal researcher first name
Date of written application received
Date of written research protocol received
Date of Research Ethics Board written decision approving plan
Dataset de-identified (Y/N)
If NO to de-identification provide explanation
Date Research Agreement executed
Date of approval to disclose Personal Health Information or de-identified data for research was
granted (by BORN Research Review Committee)
Date Personal Health Information or de-identified data was disclosed
Nature of Personal Health Information or de-identified data (data source description)
PHI or de-identified data
Retention period as per Research Ethics Board
Secure disposal due date
Date certificate of destruction was received
Any Research Agreement amendments
P-16: Data Sharing Agreements
Purpose The purpose of this policy is to ensure that BORN effectively executes data sharing agreements.
Policy BORN requires the execution of a data sharing agreement when BORN is:
Collecting Personal Health Information from health information custodians (hospitals, midwifery
practice groups and laboratories, clinics) for the purposes of BORN
Disclosing Personal Health Information for purposes other than research
Responsibility Privacy Officer
Procedure Data sharing agreements are managed by the Privacy Officer.
The Privacy Officer:
o Ensures that all disclosures are approved in accordance with CERTIFICATE OF DESTRUCTION
o The content of the certificate of destruction is outlined below:
The information described below was destroyed in the normal course of business pursuant to the
organizational retention schedule and destruction policies and procedures.
Organization:
Organization Contact:
Date and time of Destruction:
Authorized By:
List and/or Description of Personal Health Information or De-identified Data or Data Disposed
Of/Destroyed:
Inclusive Dates Covered:
METHOD OF DESTRUCTION:
Overwriting
Pulping
Pulverizing
Grinding
Shredding
Degaussing/secure wiping utility (provide details: ______________________________
Other: _________________________________________________________________
75 | P a g e
Records Destroyed By* (print and sign):
Witnessed By (print and sign):
Department Manager:
*If records destroyed by outside firm, must confirm a contract exists
76 | P a g e
o P-12: Disclosure of Personal Health Information for Purposes Other Than Research and all
collections are approved in accordance with P-04 & P-06: Collection of Personal Health
Information and Statements of Purpose for Data Holdings Containing Personal Health
Information.
o Develops a data sharing agreement based on P-17: Template Data Sharing Agreement:
Disclosure of Personal Health Information or P-17A: Template Data Sharing Agreement:
Collection of Personal Health Information
o Executes the data sharing agreement with the health information custodian from/to whom
BORN is collecting/disclosing Personal Health Information
o Updates P-18: Log of Data Sharing Agreements including the agreement expiry date. Expiry
dates are monitored by the Privacy Officer for follow-up.
o Informs the System Administrator as applicable
The System Administrator oversees access to the BORN Database. Audit logs are defined to ensure
all Personal Health Information access and changes are captured, including who has accessed a
record, what they have accessed and what changes were made. The System Administrator has
access to these logs for two reasons:
1. To perform audits of Personal Health Information access
2. To allow for investigations should there be a privacy breach
Where the data sharing agreement relates to a disclosure, the Privacy Officer notifies the Data Request
and Research Coordinator of the disclosure for the purposes of updating the Data Tracking Log.
Document Retention The Privacy Officer is responsible for storing a hard copy of the data sharing agreement and any related
documentation in a locked storage unit in an area with controlled access.
The Privacy Officer is responsible for storing copies of all data sharing agreements, any related
documentation, and the log of data sharing agreements on the BORN shared drive.
The Data Request and Research Coordinator is responsible for maintaining the updated Data Tracking
Log.
Documents are retained in the BORN shared drive.
77 | P a g e
P-17: Template Data Sharing Agreement: Disclosure of Personal Health Information The approved Data Sharing Agreement: Disclosure of Personal Health Information template is saved in
the privacy folder:
GENERAL\Privacy\Agreements\Templates for all agreements\ Disclosure Data Sharing Agreement Template
P-17A: Template Data Sharing Agreement: Collection of Personal Health Information The approved Data Sharing Agreement: Collection of Personal Health Information template is saved in
the privacy folder:
GENERAL\Privacy\Agreements\Templates for all agreements\ Collection Data Sharing Agreement Template
78 | P a g e
P-18: Log of Data Sharing Agreements The log of Data Sharing Agreements is saved on the BORN shared drive:
• BORN\~GENERAL\Privacy\Logs Populated\Privacy
The following fields are captured in the Log of Data Sharing Agreements:
• Name of agency or person from whom Personal Health Information was collected
• Date collection or disclosure of Personal Health Information was approved
• Date the data sharing agreement was executed
• Date that Personal Health Information was collected or disclosed
• Nature of the Personal Health Information
• Retention period or expiry of agreement
• Date of secure disposal of Personal Health Information
• Date certificate of destruction received
79 | P a g e
P-19: Executing Agreements with Third Party Service Providers in Respect of Personal Health Information
Purpose The purpose of this policy is to ensure that BORN executes agreements with Service Providers in respect
of Personal Health Information.
Policy A written agreement must be entered into with Service Providers prior to permitting access to and use
of Personal Health Information including:
Those third party service providers that retain, use, transfer or dispose of records of Personal
Health Information, and
Those third party service providers that use electronic means to collect, use, modify, disclose,
retain or dispose of Personal Health Information (electronic service providers)
Responsibility Privacy Officer
Procedure
Review and Approval Process Agreements with third-party service providers are initiated by the appropriate Executive Director based
on level of sign-off authority according to CHEO procurement policies.
1. The applicable Executive Director forwards to the Privacy Officer a written request for a Service
Provider Agreement. The written request must include:
A description of the task to be performed by the third party
A copy of the request for proposal or statement of work
A copy of the successful proposal
Type and level of Personal Health Information to which the third party will be given
access
Why the functions cannot be performed with de-identified and/or aggregate data
Confirmation that no more Personal Health Information will be used than is reasonably
necessary for the purpose
Whether Personal Health Information will be removed from the BORN Ontario server
The Privacy Officer reviews the request, creates an Agreement and forwards it to the
Executive Director
80 | P a g e
Note: Each Agreement is normally based on the template. Material variations to the
template are to be approved of by the Executive Director and CHEO legal, in regard to
industry standards, BORN’s compliance requirements under PHIPA and its regulation, and
the material requirements of the Manual. By way of illustration, this means that in
circumstances where personal health information that is hosted in Canada by a service
provider who does not have access to the data by virtue of encryption, the fact that the
agreement lacks a description of the status of BORN under PHIPA (and the duties and
responsibilities arising from this status) is not considered a material concern in the
circumstances. Similarly, in circumstances where personal health information is hosted in
Canada by a service provider who does not have access to the data by virtue of encryption,
the fact that the agreement lacks advanced notice of intention to subcontract and lacks the
requirement to deliver actual terms is not considered a material concern in the
circumstances.
2. The applicable Executive Director or other authorized signatory executes the Service Provider
Agreement, provides the third party with one signed agreement and returns one signed
agreement to the Privacy Officer
3. The Privacy Officer updates P-21: Log of Agreements with Third Party Service Providers.
Where information is removed and destruction of the information is required, the Privacy
Officer monitors the date in P-21: Log of Agreements with Third Party Service Providers for
follow-up.
4. The Privacy Officer electronically informs the Information Security Officer of:
The name of the Third Party
Recommendation for access
Type and level of access and use
Any conditions or restrictions to be imposed on access and use (e.g. no access to
specified data elements)
Timeframe that applies to the authorization
5. The Information Security Officer records the information in P-09: Log of Agents Granted
Approval to Access/Use/Disclose Personal Health Information.
Changes to a Service Provider Agreement The Executive Director must notify the Privacy Officer and the Information Security Officer in writing as
soon as possible when changes are made to the Service Provider Agreement. The written notification
sets out:
Name of the Agent
Date at which access is to be terminated, if applicable
81 | P a g e
Any changes to the type of access
Reasons for the termination, if applicable
The Information Security Officer implements the changes to the type of access or terminates Agent
access, and updates P-09: Log of Agents Granted Approval to Access/Use/Disclose Personal Health
Information.
Disposal/Destruction of Personal Health Information The Service Provider Agreement specifies retention dates and requirements for secure
retention/destruction as well as a Certificate of Destruction, as applicable.
All certificates of destruction must include the following information:
List of the records of Personal Health Information to be securely destroyed
Description of the secure disposal of the records
The date, time and method of secure disposal employed
The name and signature of the individual who performed the secure disposal, and a person who
witnessed the destruction
The method of secure disposal mandated by BORN P-11B: Certificate of Destruction) is consistent with
PHIPA and its regulation, with orders issued by the Information and Privacy Commissioner of Ontario,
including Order HO-001 and Order HO-006, and with guidelines, fact sheets and best practices issued by
the Information and Privacy Commissioner of Ontario including Fact Sheet 10.
If the Privacy Officer has not received the Certificate of Destruction within seven days of the date in the
Service Provider Agreement, the Third Party is in breach of the agreement and the Privacy Officer may
take all measures authorized by the agreement. The Privacy Officer may notify the Information and
Privacy Commissioner that the Third Party Service Provider is in breach and, where appropriate, lodge a
complaint.
Document Retention The Privacy Officer is responsible for retaining:
Correspondence with the Executive Director and other agreement stakeholders that have been
supplied to the Privacy Officer
Service Provider Agreement
Log of Agreements with Third Party Service Providers
The Privacy Officer is responsible for retaining in hard copy:
Executed Service Provider Agreement
The Information Security Officer, is responsible for retaining:
82 | P a g e
Log of Agents Granted Approval to Access/Use/Disclose Personal Health Information
System Control and Audit Logs
Documents are retained in the BORN shared drive.
P-20: Template Agreement for All Third Party Service Providers The approved Service Provider Agreement template is saved on the BORN shared drive:
GENERAL\Privacy\Agreements\Templates for all agreements\Service Provider Agreement Template
83 | P a g e
P-21: Log of Agreements with Third Party Service Providers The Log of Agreements with Third Party Service Providers is saved on the BORN shared drive:
GENERAL\Privacy\Logs Populated\Privacy
The following fields are captured in the Log of Agreements with Third Party Service Providers:
Name of Third Party Service Provider
Nature of services provided by Third Party
Date of agreement
Date that Personal Health Information or access to records provided
Nature of Personal Health Information
Date of termination of agreement
Date certificate of destruction received
84 | P a g e
P-22: Linkage of Records of Personal Health Information
Purpose The purpose of this policy is to ensure that BORN appropriately links records of Personal Health
Information.
Policy Data linkage refers to the act of connecting an individual person’s information from at least two sources
for a specific purpose.
BORN permits linkage of Personal Health Information for the following purposes:
Identifying where appropriate care has not been received and facilitating access to care and
treatment for mothers, infants and children
Facilitating continuous improvement of Health Care delivery tools to minimize adverse
outcomes
Raising alerts where maternal and/or newborn outcomes are statistically discrepant with
accepted norms
Looking across the continuum of care of an individual or population (pregnancy to birth to
young childhood) to improve the quality and efficiency of care for mothers, infants and children.
For example, linking health outcome information to interventions allows for the analysis of the
quality of the care being provided
Creating reports that can be used to provide the Ministry of Health, Local Health Integration
Networks, and Public Health Units with comprehensive and timely information to support
effective planning and management of Health Care delivery for mothers, babies and children in
the province.
BORN permits the following types of record linkages:
1. Linkage of records of Personal Health Information solely in the custody of BORN for the
exclusive purposes of BORN
2. Linkage of records of Personal Health Information in the custody of BORN with records of
Personal Health Information to be collected from another person or organization for the
exclusive purposes of BORN
3. Linkage of records of Personal Health Information solely in the custody of BORN for the purposes of disclosure to another person or organization
4. Linkage of records of Personal Health Information in the custody of BORN with records of
Personal Health Information to be collected from another person or organization for the
exclusive purposes of that other person or organization
85 | P a g e
Responsibility Data Request and Research Coordinator and Privacy Officer
Procedure
Review and Approval Process
All linkages require review and approval.
In the case of a research project, the approval for the linkage rests with the Research Review Committee
who review, approve and log the linkage by confirming that it is described in the research plan and the
REB approval; they must also confirm it is allowed by any applicable in-bound data sharing agreements.
For BORN’s internal work (e.g. linkage with CIHI or Stats Canada data), the need for linkage is outlined by
a specific group (data quality, a clinical program, or technical group) and is documented in a project
memorandum and approved by the BORN management group (i.e., the Executive Director and BORN
Managers) who review, approve (or deny) such decision by email, and log the linkage. Approval is
granted where such linkage is necessary for the purposes of improving and/or facilitating care, it is
permitted under the applicable data sharing agreement, any applicable REB approvals and research
plans, and it is in compliance with PHIPA and its regulation. In all cases, approved linkages are logged in
the Log of Approved Linkages of Records of Personal Health Information by the Manager of Health
Outcomes or designate. Decisions are communicated to the original requestor by email by the Manager
of Health Outcomes (or designate). If there are any conditions to the approval these are noted in the
approval.
Where the linked records of Personal Health Information are disclosed by BORN to another person or
organization:
The disclosure is approved as per P-13: Disclosure of Personal Health Information for Research
Purposes and the Execution of Research Agreements or P-12: Disclosure of Personal Health
Information for Purposes Other Than Research, as applicable
Where the linked records of Personal Health Information are used by BORN for research:
The use is approved as per P-10: Use of Personal Health Information for Research
Where the linkage of records of Personal Health Information solely in the custody of BORN is
exclusively for the purposes of BORN as a prescribed registry:
The linked records of Personal Health Information are de-identified and/or aggregated as per P-
24: De-Identification and Aggregation. Data are kept in identifiable, but secure, format to allow
for ongoing linking as new data are entered into the system. To the extent possible, only de-
identified and/or aggregate information will be used by Agents of BORN for project-specific
analyses
86 | P a g e
Process for the Linkage of Records of Personal Health Information
BORN Information System – Link Queue A linking and matching algorithm has been developed to automate the process of linking information
where sufficient information exists within the BORN Information System. The algorithm uses personal
identifiers to determine if records should be linked automatically. Where a ‘potential’ link is found –
likely a match but not sufficient information to be certain – human interaction is required to complete
the work. A designated Agent (linking and matching resource) has responsibility for managing the queue
of potential linked records.
BORN Information System – External Link Queue The BORN Information System contains a function that allows a designated Agent to load an external
dataset into its linking and matching engine. A report is then produced listing automatic, potential, and
non-matched patients. This report is used by BORN agents to facilitate data requests that require
external datasets.
Third Party Datasets or other Holdings Not Forming Part of the BIS BORN Agents use statistical analysis software (e.g. SAS and R) to link other datasets with data extracted
from the BIS.
Linkage occurs to bring together separate datasets, usually to improve the ascertainment of cases,
exposures or outcomes. At BORN, this usually involves linking a dataset held outside the BIS with data
held inside the BIS for research or internal needs.
Linkage strategies include deterministic and probabilistic approaches. Deterministic linkage compares
one or more identifiers across databases and a link is made when there is agreement. Probabilistic
linkage is a multi-step and iterative process that takes into account a wider range of quasi-identifiers
and assigns a weight to each one. The weights are used to calculate the probability that two records
belong to the same individual. For datasets with strong identifiers (OHIP numbers), BORN uses
deterministic linkage. For datasets with no strong identifiers, we rely on probabilistic linkage including
variables such as date of birth, sex, birthweight, location of birth, gestational age etc.). A number of
BORN epidemiologists have developed expertise in linking complex datasets.
Retention Linked records of Personal Health Information are retained in compliance with S-05: Secure Retention
of Records of Personal Health Information until they are de-identified and/or aggregated as per P-24:
De-Identification and Aggregation.
Secure Disposal Records of Personal Health Information linked by BORN are securely disposed of in compliance with the
S-08: Secure Disposal of Records of Personal Health Information.
87 | P a g e
P-23: Log of Approved Linkages of Records of Personal Health Information
For linkages within the BIS, BORN maintains a BIS audit database recording these linkages.
The log of Log of Approved Linkages of Records of Personal Health Information is saved in Visor. The
following fields are captured in the Log of Approved Linkages of Records of Personal Health Information:
Name of organization
Agent last name
Agent first name
Date linkage approved
Nature of Personal Health Information
Fields used for linking of Personal Health Information
88 | P a g e
P-24: De-Identification and Aggregation
Purpose The purpose of this policy is to ensure that BORN implements appropriate data de-identification and
aggregation practices.
Policy BORN prohibits the use or disclosure of Personal Health Information if other information, namely de-
identified and/or aggregate information, will serve the identified purpose.
Where information is aggregated, but includes information about individuals in groups of five (5) or less,
the information will not be released.
Agents are prohibited from using de-identified and/or aggregate information, alone or in combination
with other information, to identify an individual. This requirement is contained in all Research
Agreements and data sharing agreements.
De-identified information refers to records that have had enough personal information removed or
obscured such that the remaining information does not identify an individual and there is no reasonable
basis to believe that the information alone can be used to identify an individual.
Aggregate information refers to summed and/or categorized data that is analyzed and placed in a
format that precludes further analysis (e.g. tables or graphs) that could reveal an individual’s identity.
Information is aggregated so that individual records cannot be reconstructed.
Identifying information refers to information that identifies an individual or that it is reasonably
foreseeable in the circumstances could be used either alone or with other information to identify an
individual.
Responsibility Data Request and Research Coordinator, Privacy Officer
Procedure
De-identified Data BORN uses the De-Identification Tools for all uses and disclosures of de-identified data.
The Data Request and Research Coordinator submits a request to a BORN data analyst to assess the
level of re-identification risk of a particular data set using the De-identification Tools for all uses and
disclosures of de-identified data. A pre-determined low level of risk (0.1) will be considered an
acceptable level of risk.
In addition, de-identified and/or aggregate data including information of cell-sizes of five (5) or less is
reviewed by the Data Request and Research Coordinator prior to every use or disclosure in order to
ensure that the information does not identify an individual and that it is not reasonably foreseeable in
the circumstances that the information could be utilized to identify an individual, as per:
89 | P a g e
• P-10: Use of Personal Health Information for Research
• P-12: Disclosure of Personal Health Information for Purposes Other Than Research
• P-13: Disclosure of Personal Health Information for Research Purposes and the Execution of
Research Agreements The process ensures that a minimum number of data elements are used to achieve the purpose of the
disclosure or use. This process is iterative and may require a number of assessments before the
combination of data elements and de-identification strategies falls below the pre-set threshold.
When the de-identification process is complete and an acceptable threshold for risk of re-identification
has been achieved, the BORN data analyst:
Notifies the Data Request and Research Coordinator and
E-mails a copy of the risk analysis report that documents the correct de-identification threshold
with respect to the use or disclosure
The use of de-identification is mandated as per the following policies:
• P-10: Use of Personal Health Information for Research
• P-12: Disclosure of Personal Health Information for Purposes Other Than Research
• P-13: Disclosure of Personal Health Information for Research Purposes and the Execution of
Research Agreements
For information regarding use of De-identification Software and procedures related thereto, see
Standard Operating Procedure (SOP) for Dataset De-identification Process using Eclipse.
Aggregated Data BORN suppresses cell sizes of five (5) or less.3 Aggregated data including information of cell-sizes of five
(5) or less is reviewed by the Data Request and Research Coordinator prior to every use or disclosure in
order to ensure that the information does not identify an individual and that it is not reasonably
foreseeable in the circumstances that the information could be utilized to identify an individual, as per:
• P-10: Use of Personal Health Information for Research
• P-12: Disclosure of Personal Health Information for Purposes Other Than Research
• P-13: Disclosure of Personal Health Information for Research Purposes and the Execution of
Research Agreements
3 BORN’s exceptions policy states that with respect to cell sizes of five or less, regard must be had to the restrictions related to cell-sizes contained in Data Sharing Agreements, Research Agreements and written research plans pursuant to which the personal health information was collected by BORN. Additionally, consideration must go to whether the risk is remote in the circumstances that it (i.e., the small cell sized data) could be used alone or in combination with other information to identify an individual. The PDC will make these determinations on a case-by-case basis in consideration of the foregoing constraints.
90 | P a g e
P-25: Privacy Impact Assessments
Purpose The purpose of this policy is to ensure that BORN has in place effective policies to assess the impact of
new or modified activities that involve the collection, use or disclosure of Personal Health Information.
Policy A privacy impact assessment is a detailed assessment undertaken to identify the actual or potential
effects that a proposed project will have on the privacy of those whose personal information is included
in the proposed project. A privacy impact assessment also identifies ways in which privacy risks may be
mitigated.
BORN undertakes privacy impact assessments:
On existing programs, processes and systems when there are significant changes relating to the
collection, access, use or disclosure of Personal Health Information
In the design of new programs, processes and systems involving Personal Health Information
On any other programs, processes and systems with privacy implications, as recommended by
the Privacy Officer
Privacy impact assessments are updated in the following circumstances:
During the detailed design and implementation stage, where a conceptual privacy impact
assessment was done during the design stage
Significant changes to purposes, data collection, uses or disclosures
Significant changes to functionality of the service technology
Change in vendor/technology partner
Implementation of a new service delivery or management technology that stores, transmits, or
retrieves Personal Health Information
When the Privacy Officer determines that an update is required
Every three years, at a minimum
Privacy impact assessments are not required where existing programs, processes and systems are
changed or new programs, processes, and systems are implemented, if no personal information or
Personal Health Information is involved.
Responsibility Privacy Officer
91 | P a g e
Procedure The Executive Director is required to provide the Privacy Officer with a written description of proposed
new programs and/or changes to existing information systems, technologies or programs involving
Personal Health Information at the design stage.
The Privacy Officer evaluates the need for a privacy impact assessment.
In respect of new programs or changes to existing information systems, technologies or programs
involving Personal Health Information, the Privacy Officer conducts a privacy impact assessment at the
design stage to ensure that privacy protections can be designed into the new system. Following this:
For new programs: the Privacy Officer ensures that a second privacy impact assessment is
undertaken once the program is implemented to ensure that all recommendations have been
fully implemented
For changes to existing information systems, technologies or programs: the Privacy Officer
reviews the systems, technologies or programs on completion of implementation of changes to
ensure that all recommendations contained in the privacy impact assessment have been
implemented and will make a note of this in P-26: Log of Privacy Impact Assessments
Initiated/Completed
The Privacy Officer, in conjunction with the Information Security Officer, develops a timetable
for the conduct of privacy impact assessments related to existing holdings to ensure privacy
impact assessments are reviewed and refreshed on an on-going basis, and are repeated every
three years at a minimum.
If a privacy impact assessment is required, the Privacy Officer defines the scope and requirements of the
privacy impact assessment based on the Privacy Impact Assessment Guidelines for the Ontario PHIPA
published by the Information and Privacy Commissioner of Ontario.
Where the privacy impact assessment is being outsourced, the Privacy Officer completes a request for
proposal process, executes the contract, monitors the process, and receives the completed report and
recommendations.
Where the privacy impact assessment is conducted in-house, the Privacy Officer leads the process,
working with the Information Security Officer, to:
Collect the information required for analysis
Analyze the information received
Write the report and recommendations
The content of the privacy impact assessment includes:
Data holding, information system, technology or program at issue
92 | P a g e
Nature and type of Personal Health Information collected, used or disclosed or that is proposed
to be collected, used or disclosed
Sources of the Personal Health Information
Purposes for which the Personal Health Information is collected, used or disclosed or is
proposed to be collected, used or disclosed
Reason that the Personal Health Information is required for the purposes identified
The flows of the Personal Health Information
Statutory authority for each collection, use and disclosure of Personal Health Information
identified
Limitations imposed on the collection, use and disclosure of the Personal Health Information;
Whether or not the Personal Health Information is or will be linked to other information
Retention period for the records of Personal Health Information
Secure manner in which the records of Personal Health Information are or will be retained,
transferred and disposed of
Functionality for logging access, use, modification and disclosure of the Personal Health
Information and the functionality for auditing logs for unauthorized use or disclosure
Administrative, technical and physical safeguards implemented or proposed to be implemented
to protect the Personal Health Information
Risks to the privacy of individuals whose Personal Health Information is or will be part of the
data holding, information system, technology or program and an assessment of the risks
Recommendations to address and eliminate or reduce the privacy risks identified
Any Threat Risk Assessments (TRAs) that have been completed, or plans to complete a TRA
Any reference documentation
The identity of members of the team and contributors
The Privacy Officer submits the completed privacy impact assessment and recommendations to the
Privacy and Security Review Committee and the Executive Director for review.
When the written approval of the Executive Director has been received, the Privacy Officer proceeds to
implement any recommendations arising from the privacy impact assessment.
The Privacy Officer, working with the Information Security Officer, develops and implements a process for addressing the recommendations arising from the privacy impact assessment, including:
Assigning responsibilities to Agent(s)
93 | P a g e
Setting timelines
Monitoring timelines
Monitoring implementation of recommendations
The Privacy Officer develops and maintains P-26: Log of Privacy Impact Assessments
Initiated/Completed and P-26A: Log of Privacy Impact Assessment Not Undertaken. Logs and the
timetable for privacy impact assessments of existing holdings are forwarded by the Privacy Officer to the
Privacy and Security Review Committee on a quarterly basis along with the quarterly report on privacy
and security.
The Privacy Officer works with the Communications Lead to draft executive summaries of relevant
privacy impact assessments for posting on the BORN website. Copies of all privacy impact assessments
are saved to the in the BORN shared drive.
Document Retention The Privacy Officer has responsibility for the retention of:
All privacy impact assessments and related documents
P-26: Log of Privacy Impact Assessments Initiated/Completed and
P-26A: Log of Privacy Impact Assessments Not Undertaken
Timetable for regular privacy impact assessments of existing holdings
The Communications Lead has responsibility for the retention of all communications plans related to
privacy impact assessments.
Documents are retained in the BORN shared drive.
94 | P a g e
P-26: Log of Privacy Impact Assessments Initiated/Completed The Log of Privacy Impact Assessments Initiated/Completed is saved on the BORN shared drive:
GENERAL\Privacy\Logs Populated\Privacy
The following fields are captured in the Log of Privacy Impact Assessments Initiated/Completed:
Data Holding/Information System/Technology/Program of Personal Health Information
Date, privacy impact assessment completed or expected to be completed
Agent(s) responsible
privacy impact assessment recommendations
Agent responsible for addressing each recommendation
Date recommendations to be implemented
Manner in which each recommendation was or is to be addressed
Date recommendations implemented
P-26A: Log of Privacy Impact Assessments Not Undertaken The log of Log of Privacy Impact Assessments Not Undertaken is saved on the BORN shared drive:
GENERAL\Privacy\Logs Populated\Privacy
The following fields are captured in the Log of Privacy Impact Assessments Not Undertaken:
Data Holding/Information System/Technology/Program of Personal Health Information
Reason the privacy impact assessment not undertaken
Agent responsible for decision to not conduct the privacy impact assessment
P-27: Privacy Audits
Purpose The purpose of this policy is to ensure that BORN conducts regular privacy audits and appropriately
manages findings and recommendations resulting from these audits.
Policy The Privacy Officer conducts regular privacy audits to:
Assess organizational compliance with privacy policies and procedures to ensure that they
continue to reflect the requirements of PHIPA and its regulation as well as privacy best practices
On external parties to assess compliance with Research, Data Sharing and Third-party Service
Provider agreements
Assess compliance of Agents permitted to access and use Personal Health Information as per
95 | P a g e
P-08: Limiting Agent Access to and Use of Personal Health Information. Audits are conducted on
a selection of Agents designed each month to ensure that every Agent with access to Personal
Health Information is selected at least once every 12 months.
Responsibility Privacy Officer
Procedure
Privacy Compliance of Agents in the BORN Organization The Privacy Officer is responsible for developing and implementing an annual plan and schedule for the
audit of privacy policies and procedures and Agent compliance.
The Privacy Officer develops the annual privacy auditing plan which includes:
Specific area(s) to be audited
Purposes of the privacy audits
Frequency of the audits
Timeframes for the privacy audits
Nature and scope of the privacy audits (e.g. document reviews, interviews, group discussions,
questionnaires, file reviews, site visits, inspections)
Agent(s) responsible for conducting the privacy audits
Framework for the review, including questions or areas of concern
Criteria to be considered in developing the audit plan include the following:
Annual reviews must include three areas: policy, operational effectiveness and physical security
In selecting specific areas, preference is given to areas considered high risk in terms of
protecting privacy (e.g. destruction of records, internal data access procedures, mobile devices)
Importance of assessing compliance with all privacy policies, procedures and practices and not
just core privacy policies
New orders, guidelines and best practices recently issued by the Information and Privacy
Commissioner
Recent breach occurrence(s)
Recent implementation of recommendations resulting from a privacy impact assessment
Concerns raised by Agents
96 | P a g e
The Privacy Officer forwards the annual audit plan and schedule to the Privacy and Security Review
Committee and the Executive Director.
When written approval to proceed is received from the Executive Director, the Privacy Officer prepares
a written plan outlining the process to be followed for each privacy audit:
The Privacy Officer schedules the audit and provides notification to Agents and/or third parties as
applicable. The notification includes:
Statement that BORN is undertaking an audit
Purpose of the audit
Scope of the audit (site visit, inspection, interview, document review)
List of documentation required for review, if applicable
Date and time that Privacy Officer will be contacting the Agent/third party
The Privacy Officer documents the results of the site visits, inspections, interviews, and document
reviews, and based on these findings prepares a report which includes:
Background o Purpose of the privacy audit
o Timeframe for the privacy audit
o Agent(s) responsible for conducting the audit
o Agents/third parties interviewed, site visits, documents reviewed, inspections
o Framework for the review, including questions or areas of concern
o Any other activities pursued in conducting the review
Findings from the review
Recommendations arising from the review
Action plan to address recommendations, including timeframes. Remedial actions identified in the
action plan could include:
o Changes to BORN policies and procedures
o Changes to training materials and/or communications materials
o Changes to contracts with Agents or service providers
o Discipline of responsible individuals as per HR-11: Discipline and Corrective Action.
97 | P a g e
The Privacy Officer provides a copy of the audit report and action plan to the Executive Director, the
Privacy and Security Review Committee, and the Executive Director for review and comment within one
month of completion of the report.
When the written approval of the Executive Director has been received, the Privacy Officer:
Implements the action plan(s), assigning responsibilities and establishing timelines
Monitors implementation, and
Provides quarterly status updates to the Privacy and Security Review Committee in the quarterly
report on privacy
Where the action plan includes amendments to privacy policies and procedures and/or protocols, the
Privacy Officer revises the policies, procedures and/or protocols as required, having regard to orders,
guidelines and best practices issued by the Information and Privacy Commissioner, industry best
practices, and any legislative changes.
The Privacy Officer works with the Communications Lead to ensure that changes to policies, procedures
and/or protocols are reflected in training materials, communications materials (where applicable) and
are reflected on the BORN shared drive.
The Privacy Officer is responsible for including in the quarterly reports on Privacy and Security:
Results of each privacy audit
Recommendations of each privacy audit
Status of implementation of the recommendations of each privacy audit
The Privacy Officer maintains P-28: Log of Privacy Audits.
The Privacy Officer enters the recommendations of each privacy audit in O-07: Consolidated Log of
Recommendations.
Document Retention The Privacy Officer is responsible for the retention of:
Annual audit plan
All audit reports and action plans and related materials
All quarterly status updates (in the quarterly report on privacy)
Log of Privacy Audits
Documents are retained in the BORN shared drive.
P-28: Log of Privacy Audits The Log of Privacy Audits is saved on the BORN shared drive:
98 | P a g e
GENERAL\Privacy\Logs Populated\Privacy
The following fields are captured in the Log of Privacy Audits:
Nature and type of privacy audit
Expected/actual date completed
Agent(s) responsible for completing
Findings and recommendations
Agent(s) responsible for addressing each recommendation
Date recommendation to be addressed
Manner recommendation to be addressed
Date recommendation addressed
99 | P a g e
P-29: Privacy Breach Management
Purpose The purpose of this policy is to ensure that BORN addresses the identification, reporting, containment,
notification, investigation and remediation of privacy breaches as defined in this policy. This policy also
applies to suspected privacy breaches (where indicated).
Policy A privacy breach is:
The collection, use and disclosure of Personal Health Information that is not in compliance with
PHIPA and its regulation
A contravention of BORN privacy policies, procedures or protocols
A contravention of a BORN Confidentiality Agreement or the terms and conditions in data
sharing agreements, Research Agreements, and Agreements with Service Providers retained by
BORN
Circumstances where Personal Health Information is stolen, lost or subject to unauthorized use
or disclosure or where records of Personal Health Information are subject to unauthorized
copying, modification or disposal
Agents must notify the Privacy Officer as soon as reasonably possible, and do whatever is reasonably
possible to contain a breach or suspected breach, whether internal or external, and mitigate its effects
immediately as per to HR-01 and HR-03: Privacy and Security Training Awareness.
Contact Information for the Privacy Officer
Privacy Officer
CHEO Research Institute/CPCR
401 Smyth Road Ottawa ON K1H 8L1
Email: [email protected]
Phone: 613-737-7600 x 6038 Fax: 613-737-6504
BORN website: www.BORNOntario.ca
Responsibility Privacy Officer
100 | P a g e
Procedure
Identification and Containment Agents must notify the Privacy Officer as soon as reasonably possible of any privacy breach or suspected
privacy breach. The notification of a privacy breach may be made verbally to the Privacy Officer and must
include:
• Type of suspected breach
• Location of suspected breach
• Any actions taken by the reporting Agent to contain the breach
An Agent who discovers a breach or suspected breach is required to initiate the process of containment.
The verbal notification must be followed up as soon as possible by completion of a P-29B: Breach Reporting
Form to be forwarded by the Agent to the Privacy Officer. The completed Breach Reporting Form includes:
• Name and position of the individual who discovered the incident
• Date and time of discovery of the incident
• Estimated time and date the breach occurred, if known
• Type of breach (loss, theft, inadvertent disclosure)
• Cause of breach, if known
• Description of information involved in the breach
• Actions taken by Agent reporting the breach to contain the breach
• Any other individuals or organizations involved in the breach (or its notification) and contact
information for relevant individuals
The Privacy Officer, together with the appropriate Agent(s), works immediately to further contain the
breach. The Privacy Officer:
• Determines whether the breach or potential breach would allow unauthorized access to any
other data and takes whatever action is required to ensure that no further breaches can occur
through the same means (e.g. change password, shut down the system) and that the breach is
contained
• Determines what (if any) Personal Health Information has been stolen, lost or accessed, used,
disclosed, copied, modified or disposed of in an unauthorized manner
• Securely retrieves hard copies of any Personal Health Information that has been disclosed or
ensures as much as possible of the breached information has been disposed of in a secure
manner
• Ensures no copies of the Personal Health Information have been made or retained by the
individual who was not authorized to retrieve or receive the information
The Privacy Officer confirms the suspected breach. If the Privacy Officer determines that the confirmed
breach also contains a breach of security, S-17: Security Breach Management also applies. If the breach
is exclusively a breach of security then only S-17: Security Breach Management applies.
101 | P a g e
102 | P a g e
If the Privacy Officer determines that the breach involves theft or impacts personal safety, the Privacy
Officer:
• Alerts the Executive Director of BORN Ontario and the CEO of CHEO and informs them that the
police will be notified
• Notifies the police
Notification of Executive Director When the Privacy Officer determines that a privacy breach has occurred, the Privacy Officer immediately
sends an e-mail to the Executive Director indicating that:
• A privacy breach has occurred and whether it is internal or external
• A brief description of the nature and extent of the breach, including what information has been
breached
• Actions taken by the Agent reporting the breach and by the Privacy Officer to contain the breach
• Whether hard copies of the information have been successfully retrieved or the breached
information has been destroyed
• The police have been notified and why, if applicable.
The Executive Director, along with the Privacy Officer, reviews the containment measures implemented
to determine that the privacy breach has been effectively contained. Where further measures are
required, the Executive Director works with the Privacy Officer to ensure secure containment.
As soon as reasonably possible, the Executive Director will advise the CHEO VP Provincial Programs and
Chief Innovation Officer and a description of any further efforts at containment. The Privacy Officer will
advise the CHEO Chief Privacy Officer.
When the breach has been contained, the Executive Director and the Privacy Officer give consideration
to reporting the breach to the Information and Privacy Commissioner, taking into account:
• The sensitivity of the Personal Health Information
• Whether the disclosed information could be used to commit identity theft
• Whether there is a reasonable chance of harm from the disclosure
• The number of people affected by the breach
• Whether the information was fully recovered without further disclosure
• Any legal requirements to provide notification under PHIPA (e.g., Ontario Regulation 329/04
under PHIPA, section 6.3)
Any guidance’s issued by the Information and Privacy Commissioner (e.g., see Guidelines for the Health
Sector – Reporting a Privacy Breach to the IPC, dated September 2019) Where a decision has been taken
to inform the Information and Privacy Commissioner, the Privacy Officer sends an e-mail to the Office of
the Information and Privacy Commissioner indicating that:
• A privacy breach has occurred and whether it is internal or external
• A brief description of the nature and extent of the breach, including what information has been
breached
• Actions taken by the Agent reporting the breach and the Privacy Officer to contain the breach
• Whether hard copies of the information have been successfully retrieved or the breached
information has been destroyed
• The police have been notified and why, if applicable
The Privacy Officer also informs the Leadership Team and the Communications Lead in writing of the
actions taken to date and the notification of the Information and Privacy Commissioner.
For all privacy breaches, the Privacy Officer meets with BORN Ontario staff to inform them of the nature
and extent of the breach and keeps them regularly informed throughout the investigation and
remediation process.
For all privacy breaches, the Privacy Officer e-mails updates to the Leadership Team and the
Communications Lead on an on-going basis.
The Privacy Officer enters the information into P-30: Log of Privacy Breaches.
Investigation Once the breach has been contained and the Executive Director has been informed, the Privacy Officer
together with the appropriate BORN Agents initiates a comprehensive investigation, including
interviews, document reviews, site visits and inspections. The review will determine:
• Organizations involved in the breach
• Cause of the breach
• Data elements involved
• Number of individuals affected by the breach
• Identification of the individuals affected by the breach
• Any harm that may result from the breach, including:
o Security risk
o Identity theft or fraud
o Hurt, humiliation, damage to reputation
• Actions required to prevent future breaches
• The Privacy Officer completes the comprehensive investigation within four weeks from the time
the breach was reported and prepares a comprehensive report for the Executive Director,
including:
• Date of the privacy breach
• Date that the privacy breach was identified or suspected
• Nature of the breach - whether it was determined to be a privacy breach and whether it was
internal or external
• Nature of the Personal Health Information that was the subject matter of the privacy breach
• Facts or events relevant to the breach
• Date that the privacy breach was contained and the nature of the containment measures
• Date that the health information custodian or other organization that disclosed the Personal
Health Information to BORN was notified
103 | P a g e
• Date that the investigation of the privacy breach was completed
• Agent(s) responsible for conducting the investigation
• Recommendations for corrective measures arising from the investigation
• Agent(s) assigned to address each recommendation; the date each recommendation is expected
to be addressed
The Executive Director reviews the report and forwards it to the Privacy and Security Review Committee
for its recommendation to proceed with implementation of the recommendation.
Preventing Further Breaches The Privacy and Security Review Committee provides written approval of the corrective measures
recommendations to the Privacy Officer.
The Privacy Officer:
• Assigns Agent(s) to implement changes
• Establishes timelines for implementation
• Monitors and tracks these activities to ensure that recommendations are implemented within
the stated timelines
The Privacy Officer maintains and monitors the Log of Privacy Breaches.
Where the breached information has been securely destroyed by the organization to which the
information was disclosed, the Privacy Officer obtains written confirmation related to the date, time and
method of secure disposal and records this confirmation in the Log of Privacy Breaches.
The Privacy Officer:
• Undertakes any required educational campaign within BORN Ontario (and associated
organizations) as necessary to educate Agents on any changes to policies and procedures and
how to avoid further breaches
• Reviews BORN Ontario Breach Management Protocol for potential improvements
• Reviews agreements with Third Parties, health information custodians and Researchers for
potential improvements
• Takes appropriate action, which may include termination as per HR-11: Discipline and
Corrective Action, regarding the individual responsible for the breach, as per the BORN
Confidentiality Agreement. Human resources and accreditation bodies may be involved, as
appropriate
The Privacy Officer provides a written status report and a copy of the Log of Privacy Breaches to the
Privacy and Security Review Committee on a quarterly basis (included in the quarterly report on privacy
and security).
The Privacy Officer includes a description of the nature and extent of privacy breaches, the causes,
recommendations and status of the implementation of those recommendations in:
• The quarterly report to the Privacy and Security Review Committee and the Leadership Team
104 | P a g e
105 | P a g e
• The Annual Report on Privacy and Security
Notification of Health Information Custodians and Others
Whenever personal health information is or is believed to be stolen, lost or accessed by unauthorized
persons and whenever required pursuant to the agreement with the health information custodian or
organization, the Privacy Officer sends written notification to the heath information custodians or
organization who provided the information at the first reasonable opportunity in order that they may
notify individuals whose privacy was breached as per section 12(2) of the Personal Health Information
Protection Act, 2004. As a prescribed registry, BORN Ontario does not directly notify individuals whose
information has been breached.
This notification from BORN Ontario to the health information custodian includes:
• Date of the privacy breach
• A general description of the extent of the breach
• Nature of the Personal Health Information that was the subject of the privacy breach
• Date that the privacy breach was contained and the nature of the containment measures
• Steps that have been taken to reduce the possibility of future breaches
• Steps the individual can take to further mitigate the risk of harm (where applicable)
• Notice that the Information and Privacy Commissioner has been contacted
• Name and phone number of contact person within BORN Ontario who can answer questions
• That individuals have a right to complain to the Information and Privacy Commissioner and the
contact information for the Commissioner.
After consultation with the Executive Director, the Privacy Officer sends a written notification to the
Ministry of Health and Long-Term Care setting out:
• Date of the privacy breach
• A general description of the extent of the breach
• Nature of the Personal Health Information that was the subject of the privacy breach
• Date that the privacy breach was contained and the nature of the containment measures
• Steps that have been taken to reduce the possibility of future breaches
• Steps the individual can take to further mitigate the risk of harm (where applicable)
• Notice that the Information and Privacy Commissioner has been contacted
• Name and phone number of BORN Ontario Privacy Officer
Information Breach An information breach is any act or incident in contravention of the security policies and procedures and
practices implemented by BORN Ontario and any act or incident, external or internal, which affects the
confidentiality and integrity of the information in the custody and control of BORN Ontario. Where a
Privacy Officer investigates and determines that both a privacy breach and an information breach
(affected Personal Health Information was encrypted or was de-identified or aggregate) have occurred,
the Privacy Officer follows the process described above.
If the Privacy Officer determines the suspected privacy breach is not a privacy breach but is exclusively
an information breach, the Privacy Officer follows Policy S-17 Security Breach Management.
Compliance Audit and Enforcement BORN Ontario Agents must comply with this Plan. Compliance is audited on an ongoing basis by the
Privacy Officer in accordance with P-27: Privacy Audits and by the Security Officer in accordance with
S-15: Security Audits.
BORN Agents are required to notify the Privacy Officer at the first reasonable opportunity of a breach or
suspected breach in accordance with P-29: Privacy Breach Management or S-17: Security Breach
Management as applicable. Consequences of breach are detailed in HR-11: Discipline and Corrective
Action which clarifies:
The BORN Ontario Confidentiality Agreement states that a breach of the terms of the Confidentially
Agreement, BORN Ontario policies and procedures, and/or the provisions of the Personal Health
Information Protection Act, 2004 may result in disciplinary action which can include termination of
employment or legal action.
Document Retention The Privacy Officer is responsible for the secure retention of:
• All correspondence related to the privacy breach
• Investigative notes and final report on the breach
• The Log of Privacy Breaches
Documents are retained in the privacy folder.
106 | P a g e
P-29A: Breach Management Protocol A privacy breach occurs when there is unauthorized access to, or collection, use, disclosure or disposal
of Personal Health Information whether done deliberately or inadvertently. Such activity is unauthorized
if it occurs in contravention of the Ontario PHIPA (PHIPA) or BORN policies and procedures
Examples of privacy breaches include instances where Personal Health Information is lost, stolen, or
mistakenly provided to the wrong person, such as when a computer is stolen.
Responding to a Privacy Breach • It is important for all BORN staff to respond immediately when faced with a breach or a potential
breach.
• The following steps should be carried out simultaneously or in quick succession:
1. Contain the Breach to the extent possible
As an Agent who discovers a potential breach you should act quickly to limit the breach. You must ensure that no further breaches can occur through the same means (e.g., change
passwords, identification numbers, and or temporarily shut down a system)
You must determine what (if any) Personal Health Information has been stolen, lost or accessed,
used, disclosed, copied, modified or disposed of in an unauthorized manner
You must securely retrieve or destroy as much as possible of the breached information. In other
words, if the information can be retrieved in a secure fashion, do so, otherwise confirm that as
much of the information as is possible has been destroyed, and you have written confirmation of
that action including date, time and method of secure disposal
You must ensure that no copies of the Personal Health Information have been made or retained
by the individual who was not authorized to retrieve or receive the information
You must determine whether the breach or potential breach would allow unauthorized access to
any other data (e.g. passwords being disclosed that could provide access to systems or databases)
and take whatever steps are necessary and appropriate to shut down that access (e.g. disable the
password)
2. Get Help to Evaluate the Situation
As an Agent who discovers a potential breach you are required to support the evaluation of the situation.
You must notify the Privacy Officer at the first reasonable opportunity
You must complete and Breach Reporting Form which includes the following:
o Name and position of the individual who discovered the breach
o Date and time of discovery
o Estimated time and date the breach occurred
107 | P a g e
o Type of breach (loss, theft, inadvertent disclosure)
o Cause of breach, if known
o Description of information involved in the breach
o Actions taken by Agent reporting the breach to contain the breach
o Any other individuals or organizations involved in the breach (or its notification) and
contact information for relevant individuals
The Breach Reporting Form should be completed and forwarded to the Privacy Officer as soon as
reasonably possible.
The Privacy Officer will work with you and other appropriate BORN staff or external resources to
determine the extent of the breach:
o What data elements have been breached?
o Is there a risk of further exposure of the information?
o Is the information encrypted or otherwise non-accessible?
o How many individuals are affected by the breach?
o Who are the individuals affected by the breach?
o What is the cause of the breach?
o What organizations are involved in the breach?
The Privacy Officer, together with you and other appropriate BORN staff or external resources must determine harm that may result from the breach, including:
o Security risk
o Identity theft or fraud
o Hurt, humiliation, damage to individual’s reputation
o Risk to public health
3. Consider Notification
The Privacy Officer will consider broader notification of the breach.
The Privacy Officer must consider the advisability of notifying other organizations such as:
Information and Privacy Commissioner of Ontario
Police
Whenever personal health information is or is believed to be stolen, lost or accessed by
unauthorized persons and whenever required pursuant to the agreement with the health
108 | P a g e
information custodian or organization, the Privacy Officer must send written notification to the
heath information custodians or organization who provided the information at the first
reasonable opportunity in order that they may notify individuals whose privacy was breached.
4. Prevent further breaches
The Privacy Officer is responsible for preventing further breaches.
The Privacy Officer must review existing policy for necessary changes to BORN policies and procedures to avoid any further breaches
The Privacy Officer must undertake any required educational campaign within BORN (and associated organizations as necessary) to educate employees on how to avoid further breaches
The Privacy Officer must review BORN Breach Management Protocol for potential improvements
The Privacy Officer must take appropriate action regarding the individual responsible for the breach
P-29B: Breach Reporting Form
BREACH REPORTING FORM Name and position of the individual who discovered the incident
Date and time of discovery of the incident
Estimated time and date the breach occurred, if known
Type of breach (loss, theft, inadvertent disclosure)
Cause of breach, if known
Description of information involved in the breach
Actions taken by Agent reporting the breach to contain the breach, if applicable
Any other individuals or organizations involved in the breach (or its notification) and contact
information for relevant individuals
109 | P a g e
P-30: Log of Privacy Breaches The Log of Privacy Breaches is saved on the BORN shared drive:
GENERAL\Privacy\Logs Populated\Privacy\P-30 - Log of Privacy Breaches and Incidents
The following fields are captured in the Log of Privacy Breaches:
Date of privacy breach
Date privacy breach was identified or suspected
Internal/external
Nature of Personal Health Information involved
Nature and extent of privacy breach
Date privacy breach contained
Nature of containment measures
Date Personal Health Information custodian notified
Date investigation completed
Agents conducting investigation
Recommendations
Agent responsible for addressing each recommendation
Date each recommendation will be/was addressed
Manner in which each recommendation will be/was addressed
110 | P a g e
P-31: Privacy Complaints
Purpose The purpose of this policy is to ensure that BORN effectively manages privacy complaints.
Policy BORN responds to all privacy complaints including:
Complaints relating to the privacy policies and procedures implemented by BORN
Complaints related to the compliance of BORN to PHIPA and its regulation
Responsibility Privacy Officer
Procedure
Making a Complaint The Privacy Officer works with the Communications Lead to ensure public communications materials
include appropriate reference to BORN privacy and how to make a complaint. Individuals may obtain
information about making a complaint as follows:
BORN Website The Statement of Information Practices webpage in the Privacy section of the BORN website states:
Details of the BORN privacy policies, frequently asked questions, and other information can be found
under Privacy Resources.
Individuals may obtain further information about BORN privacy policies and procedures by calling, e-
mailing or writing to the Privacy Officer.
Complaints or concerns about BORN privacy policies and procedures may also be sent to the Privacy
Officer by e-mail, phone or in writing. Individuals are encouraged to complete a BORN Complaint Form
and submit it to the Privacy Officer, who can be reached as follows:
Privacy Officer
BORN
CHEO Research Institute | Centre for Practice-Changing Research Building
401 Smyth Road, Ottawa, ON | K1H 8L1
613.737.7600 x 6038
111 | P a g e
Individuals may make a complaint regarding compliance to PHIPA and its regulation to the Information
and Privacy Commissioner of Ontario who can be reached as follows:
Information and Privacy Commissioner
2 Bloor Street East | Suite 1400 Toronto | ON | M4W 1A8
Phone: 416.326.3333 or 1.800.387.0073
Email: [email protected] Website: www.ipc.on.ca
BORN Public Communications Where the communication vehicle is very short, such as a brochure, the communication will contain, at
a minimum, standard contact information for BORN (mailing address, website, phone number, general
information e-mail address) as well as the e-mail address for BORN privacy ([email protected]).
The Privacy section of the BORN website is apparent on the BORN homepage and information on
making a complaint can be found within this section.
Where the communications vehicle is longer, the communication will include:
Privacy Officer
BORN
CHEO Research Institute | Centre for Practice-Changing Research Building 401 Smyth Road, Ottawa, ON | K1H 8L1
613.737.7600 x 6038
www.BORNOntario.ca/privacy [email protected]
The Privacy section of the BORN website is apparent on the BORN homepage and information on
making a complaint can be found within this section.
Managing Complaints Where the Privacy Officer is able to assess and satisfactorily address complaints received by phone, the
Privacy Officer enters the complaint in
112 | P a g e
P-32: Log of Privacy Complaints and Privacy Inquiries and sends a follow-up letter to the complainant
detailing the issue and the agreed-upon resolution within 14 days of the phone call.
Where the Privacy Officer receives a written complaint, the Privacy Officer follows up with a telephone
call within two days of receiving the complaint and may arrange for an in-person meeting.
The Privacy Officer maintains a file for each complaint and documents all phone calls and meetings and
any resolution that is achieved. The Privacy Officer also enters all complaints and their resolutions into
the Log of Privacy Complaints.
If the complaint cannot be addressed satisfactorily through a phone discussion or face-to-face meeting,
the Privacy Officer requests that the complainant fill out a Complaint Form (P-32A: Complaint Form)
which is available from the BORN website (www.BORNOntario.ca) or by mail upon request by the
complainant. The complaint form requires:
A detailed description of the complaint
Date and time of occurrence, where applicable
Individual(s) involved in the occurrence
Any other pertinent information
The Privacy Officer is responsible for assessing the complaint and determining whether:
The complaint is a privacy complaint that should be investigated
The complaint relates to a privacy breach and should be addressed as per P-29: Privacy Breach
Management
This determination is completed within seven days of receipt of the signed complaint form.
A complaint is subject to further investigation if the privacy complaint:
Relates to an action on the part of Agents that could constitute a breach of BORN policy or
procedures or the requirements of PHIPA and its regulation
Relates to an activity on the part of Agents that could be contrary to industry best practices or
directives, publications or communications from the Information and Privacy Commissioner
Is well founded for any other reason
The Privacy Officer documents the complaint, the decision on whether to proceed with an investigation,
and the reasons for the decision in the file.
If the Privacy Officer determines that the privacy complaint will not be investigated further, a letter is
sent to the complainant within 14 days of receipt of the complaint form, including the following:
Acknowledging receipt of the privacy complaint
113 | P a g e
Providing a response to the privacy complaint
Advising that an investigation will not be undertaken
Advising that the complainant may make a complaint to the Information and Privacy
Commissioner if there are reasonable grounds to believe that BORN has contravened or is about
to contravene PHIPA or its regulation, and providing contact information for the Information
and Privacy Commissioner
If the Privacy Officer determines that the complaint will be investigated, a letter is sent to the
complainant within 14 days of receipt of the complaint form, including the following:
Acknowledging receipt of the privacy complaint
Advising that an investigation of the privacy complaint will be undertaken
Providing an explanation of the BORN privacy complaint procedures
Indicating that if additional information is required, the complainant will be contacted
Setting out the timeframe for completion of the investigation
Setting out the nature of the documentation that will be provided upon completion of the
investigation
The Privacy Officer sends a copy of the letter and the complaint form to the BORN Privacy and Security
Review Committee and the Communications Lead.
The Privacy Officer informs BORN staff via e-mail of the complaint and the impending investigation.
The Privacy Officer is responsible for conducting the privacy complaint investigation. The Privacy Officer
seeks to substantiate the facts surrounding the complaint by:
Undertaking reviews of relevant documents
Conducting interviews with the complainant, Agents and third parties, health information
custodians, researchers, as appropriate
Carrying out site visits and inspections, as appropriate
Within 30 days of receipt of the complaint form, the Privacy Officer completes the investigation,
documents the findings from the interviews, reviews and site visits, and forwards a report to the
Executive Director, with copy to the Communications Lead. The report includes:
Findings from the investigation
Where Agents, third parties and/or researchers have deviated from BORN policies and
procedures and/or have been non-compliant with PHIPA and its regulation
Any related considerations
114 | P a g e
Recommendations to address the concern identified in the complaint and timelines
A draft response to the complainant
The Executive Director reviews the report and the recommendations contained in the report and any
required changes.
The Privacy Officer is responsible for implementation of the recommendations that have been accepted
by the Executive Director, including:
Assigning Agent(s) to implement recommendations
Establishing timelines
Monitoring and tracking implementation and ensuring timelines are met
In addition, the Privacy Officer
Reviews policies and procedures to ensure that issues identified by the complaint have been
addressed
Undertakes any required educational campaign within BORN (and associated organizations) as
necessary to educate Agents on any changes to policies, procedures and processes arising from
the complaint
Reviews agreements with third parties and researchers for potential improvements, where
applicable
Works with the Communications Lead regarding changes to communications materials, as
appropriate
Takes disciplinary action, as appropriate
Within 45 days of receiving the complaint form, the Privacy Officer notifies the complainant in writing
of:
The nature of the findings of the investigation
Any measures that have been/will be taken in response to the privacy complaint
The complainant’s right to make a complaint to the Information and Privacy Commissioner of
Ontario
Contact information for the Information and Privacy Commissioner
Note: If implementation of recommendations is not complete at the time this letter is sent, the Privacy Officer sends a confirmation letter when all recommendations have been implemented.
The Privacy Officer provides a written status report to the Executive Director, Communications Lead, Leadership Team and BORN staff:
115 | P a g e
On a monthly basis during the implementation of the recommendations, and
Upon completion of the implementation of the recommendations
The Privacy Officer includes a description of the complaints received and actions taken by BORN in:
The quarterly reports to the Privacy and Security Review Committee
The Annual Report on Privacy and Security
Document Retention The Privacy Officer is responsible for the retention of:
Log of Privacy Complaints, including those for which an investigation was not undertaken
Comprehensive files for each privacy complaint including all correspondence (both external and
internal), complaint form and any notes made by the Privacy Officer
Documents are retained in the BORN shared drive.
116 | P a g e
P-32: Log of Privacy Complaints and Privacy Inquiries The Log of Privacy Complaints and Inquiries is saved on the BORN shared drive:
GENERAL\Privacy\Logs Populated\Privacy\ P-32 - Log of Privacy Complaints and Privacy Inquiries
The following fields are captured in the Log of Privacy Complaints and Inquiries:
Date of privacy complaint or inquiry
Nature of complaint or inquiry
Was it resolved to the satisfaction of the complainant prior to investigation
Will complaint be investigated? Y/N
Date determination made
Date complainant was advised complaint would not be investigated
Date Complainant was advised complaint would be investigated
Date Investigation commenced
Date investigation completed
Agent responsible for conducting investigation
Recommendations arising from the investigation
Agent(s) responsible for addressing each recommendation
Date each recommendation is expected to be addressed
Date each recommendation was addressed
Manner each recommendation was addressed
Date complainant advised of findings and measures taken
Date the inquiry was responded to by the Privacy Officer
Nature of the response provided by the Privacy Officer
Any further queries resulting from the initial inquiry
Date the inquiry was completed
117 | P a g e
P-32A: Complaint Form
BORN Complaint Form
Your Information
Full Name: _______________________________________________
Address: _________________________________________________
Daytime Telephone Number: _________
E-mail address*: ___________________________________________
* I consent to being contacted at this e-mail address. I acknowledge that sending e-mail over the
Internet is not secure, in that it can be intercepted and/or manipulated and retransmitted.
Please initial ______
Complaint Information
Please provide a detailed description of your privacy complaint covering the what, when, who, how, where and why of what happened. Please be sure to describe the nature of the occurrence and any subsequent contacts you have had with BORN and the outcomes. (If you need additional space, please attach as many pages as necessary.)
Where to send this form
Mail:
Privacy Officer
CHEO Research Institute, CPCR
401 Smyth Road Ottawa, Ont. K1H 8L1
Fax : (613)737-6504
E-mail*: [email protected]
Signature
Your Signature: ______________________________________
Date: _________________
118 | P a g e
P-33: Privacy Inquiries
Purpose The purpose of this policy is to ensure that BORN effectively manages privacy inquiries.
Policy BORN responds to all privacy inquires, including:
Inquiries relating to the privacy policies and procedures implemented by BORN
Inquiries relating to compliance of BORN with PHIPA and its regulation
Responsibility Privacy Officer
Procedure The Privacy Officer works with the Communications Lead to develop BORN public communications
materials and ensures that all communications materials include the following:
Individuals may direct privacy-related inquiries and may obtain information about BORN privacy
policies, procedures and practices by phoning, e-mailing or writing to:
Privacy Officer
CHEO Research Institute, CPCR 401 Smyth Road
Ottawa ON K1H 8L1
E-mail: [email protected]
Phone: 613-737-7600 x 6038
Fax: 613-737-6504 BORN website: www.BORNOntario.ca
The Privacy Officer receives and reviews all inquiries to determine if the inquiry:
Relates to a privacy breach and should be addressed as per P:29 Privacy Breach Management
Relates to a privacy complaint and should be addressed as per P-31: Privacy Complaints
The Privacy Officer records all inquiries in P-32: Log of Privacy Complaints and Privacy Inquiries
which contains:
Date of the inquiry
Nature of the inquiry
Date the inquiry was responded to by the Privacy Officer
119 | P a g e
Nature of the response provided by the Privacy Officer
Any further queries resulting from the initial inquiry
Date the inquiry was completed
Responses to all inquiries are provided in writing either by e-mail or by mail, as requested by the
individual or organization making the inquiry.
The Privacy Officer forwards a copy P-32: Log of Privacy Complaints and Privacy Inquiries to the Executive Director and the Privacy and Security Review Committee as necessary, and, at a minimum, in
the Quarterly Reports on Privacy and Security.
Document Retention The Privacy Officer is responsible for securely maintaining:
Log of Inquiries
All written responses to inquiries
Documents are retained in the BORN shared drive.
120 | P a g e
PART 2: Security Policies and Procedures
S-01: Information Security Policy The purpose of this policy is to ensure that BORN has in place a security framework to protect the
Personal Health Information that it receives.
BORN securely maintains the Personal Health Information in its custody and protects the information
against theft, loss and unauthorized use or disclosure, and unauthorized copying, modification and
disposal.
Responsibility Information Security Officer
Overview The Information Security Officer is responsible for the oversight of the information security program
which includes the following policies and procedures:
Policies and procedures for the ongoing review of the security policies, procedures and practices
implemented as per S-02: Ongoing Review of Security Policies and Procedures.
Policies and procedures for ensuring physical security of the premises as per S-03: Ensuring
Physical Security of Personal Health Information.
Policies and procedures for the secure retention, transfer and disposal of records of Personal
Health Information as per S-05: Retention of Records of Personal Health Information, S-06:
Retention of Records of Personal Health Information on Mobile Devices, S-07: Secure Transfer
of Records of Personal Health Information, and S-08: Secure Disposal of Records of Personal
Health Information.
Policies and procedures to establish access control and authorization, including business
requirements, user access management, user responsibilities, network access control, operating
system access control and application and information access control as per S-09: Passwords, S-
14: Acceptable Use of Technology, P-08: Agent Data Access, S-03: Ensuring Physical Security of
Personal Health Information, and HR-06: Template Confidentiality Agreement with Agents.
Policies and procedures for monitoring as per S-10: System Control and Audit Logs and S-15:
Security Audits
Policies and procedures for network security management as per S-11: Patch Management and
S-12: Change Management.
Policies and procedures for back-up and recovery as per S-13: Back-Up and Recovery Of Records Of Personal Health Information.
Policies and procedures related to the acceptable use of information technology as per S-14:
Acceptable Use of Technology.
121 | P a g e
122 | P a g e
Policies and procedures for information systems acquisition, development and maintenance
including the security requirements of information systems, correct processing in applications,
cryptographic controls, security of system files, security in development and support procedures
as per the following BORN policies: S-10: System Control and Audit Logs, P-19: Executing
Agreements with Third Party Service Providers in Respect of Personal Health Information, S-
05: Retention of Records of Personal Health Information, S-15: Security Audits, S-11: Patch
Management, S-12: Change Management and S-03: Ensuring Physical Security of Personal
Health Information
Policies and procedures for back-up and recovery as per S-13: Back-Up and Recovery Of
Records Of Personal Health Information.
Policies and procedures for information security breach management as per S-17: Security
Breach Management.
A security governance framework as per O-01 and O-02: Privacy and Security Governance and
Accountability Framework and HR-01 and HR-03: Privacy and Security Training and
Awareness.
Policies and procedures to establish protection against malicious and mobile code as per BORN
policy S-15: Security Audits and BORN policy O-04: Corporate Risk Management Framework
and BORN policy S-14: Acceptable Use of Technology.
The Information Security Officer has responsibility for the implementation of a comprehensive
information security program that includes administrative, physical and technical safeguards consistent
with industry standards.
The administrative safeguards include:
Administering oaths of confidentiality (delegated to the Privacy Officer)
Implementing an Acceptable Use policy for staff
Executing data sharing agreements and Research Agreements (delegated to the Privacy Officer)
Staff training on privacy and security (initial privacy and security orientation is provided by the
Privacy Officer, where the Information Security Officer reviews the security content of the
security orientation periodically)
Security audits, including Threat and Risk Assessments
Security breach management policies
Prohibition of removal by Agents of Personal Health Information off the premises
Procedures that govern granting and revoking access when beginning or ending an Agent’s
employment or changing user access privileges
Annual review of access privileges
The physical safeguards include:
Locked facility with video monitoring of external building
Locked cabinets
Tracked card access with varying levels of access
Standards for disposal of Personal Health Information and requirement for items identified for
disposal to be securely and separately maintained
Requiring visitors to sign in and sign out
The technical safeguards include:
User system access protected by minimum 256-bit secure socket layer encryption
Transmission of Personal Health Information over authenticated, encrypted and secure VPN
connections
Whole disk encryption for laptops
Multi-factor authentication for all Registry users (i.e. CHEO employees and agents)
Hardened servers with regular patching of known vulnerabilities
Firewall with demilitarized zone to house portal web servers
Anti-virus, anti-spam and anti-spyware measures
Retaining third parties to conduct penetration testing, vulnerability assessments and threat-risk
assessments for internal and external systems when required
Daily backup of necessary information
Mandatory password-protected screen savers after a 15-minute timeout period on user devices
and mandatory idle timeout on BORN portal pages.
The Information Security Officer implements a program for continuous assessment and verification of
the effectiveness of the security program as per S-15: Security Audits and O-04: Corporate Risk
Management. The Information Security Officer is supported by the Privacy Officer in both the
implementation and review of the security program.
Independent reviews and assessments shall be performed at least annually, or at planned intervals, to
ensure that the organization addresses any nonconformities of established policies, procedures, and
known contractual, statutory, or regulatory compliance obligations.
123 | P a g e
Compliance Audit and Enforcement BORN Agents must comply with this policy and procedures. Compliance is audited on an ongoing basis
by the Information Security Officer in accordance with S-15: Security Audits.
BORN Agents are required to notify the Privacy Officer and/or the Information Security Officer at the
first reasonable opportunity of a breach or suspected breach in accordance with P-29: Privacy Breach
Management or S-17: Security Breach Management, as applicable. Consequences of breaches are
detailed in each respective breach policy as well as in P-01: Privacy Policy in Respect of CHEO’s Status
as a Prescribed Person and HR-11: Discipline and Corrective Action, which clarifies:
The BORN Ontario Confidentiality Agreement states that a breach of the terms of the
Confidentially Agreement, BORN Ontario policies and procedures, and/or the provisions of the
Personal Health Information Protection Act, 2004 may result in disciplinary action which can
include termination of employment or legal action.
124 | P a g e
S-02: Ongoing Review of Security Policies and Procedures See policy: P-02 and S-02: Triennial Review of Privacy and Security Policies and Procedures.
125 | P a g e
S-03: Ensuring Physical Security of Personal Health Information The purpose of this policy is to ensure that BORN provides appropriate physical security in order to
protect Personal Health Information against theft, loss and unauthorized use, disclosure, copying,
modification or disposal.
The physical safeguards implemented by BORN to protect records of Personal Health Information
include locked doors, locked filing cabinets, alarms and controlled access to the premises where Agents
work and to secure locations within the premises where records of Personal Health Information are
retained.
BORN defines two types of access:
1. The BORN premises where CHEO employees work
o Any secure CHEO building protected by two levels of secure access and/or a BORN
employee’s personal residence (i.e. teleworkers).
i. Policies S-01: Information Security Policy, S-09: Passwords and Multi-Factor
Authentication, S-14: Acceptable Use of Technology, and P-08: Limiting Agent
Access to and Use of Personal Health Information address the physical security
of devices used by teleworkers.
o When not in use, portable computers must be stored in locked cabinets or locked
offices.
o No personal health information is retained on these premises.
2. The Data Centre where records of personal health information in BORN’s custody are retained
(all personal health information is stored in this secure location; there is no personal health
information stored anywhere else). The Data Centre is managed by the Hosting Service Provider.
Responsibility Information Security Officer, Privacy Officer
Procedure Physical access to the premises is controlled by means of employment and or contractual working
arrangements. Access permissions are based upon a documented need to have such access, such that an
Agent is only granted access to the specific premises where they are required to work.
Access to BORN premises where BORN employees work: provision of identification/access cards and office keys The BORN premises are located in a secure research institute on the premises of The Ottawa Hospital
and are protected by two levels of secure access:
Building is protected by HID access cards
Individual offices have locked doors
126 | P a g e
The BORN human resources agent or designate arranges for an access card and office key as follows:
CHEO human resources issues a CHEO Employee Staff Action Notice (ESAN) for all new Agents;
an ESAN identifies the name, start date and status of the employment arrangement (permanent
or temporary, for example)
CHEO Human Resources issues a secure access card (also a CHEO identification badge)
BORN Human Resources retains a copy of the ESAN and records the secure access card number
and serial number of the office key
S-04: Log of Agents with Access to the Premises
Physical access to Data Centre where records of Personal Health Information are retained All Personal Health Information in the custody of BORN is stored on secure servers in a Data Centre that
is managed by the Hosting Service Provider. Only authorized personnel are allowed access.
Hosting Service Provider datacenters are located in non-descript buildings that are physically
constructed, managed, and monitored 24-hours a day to protect data and services from unauthorized
access as well as environmental threats.
All data centers are surrounded by a fence with access restricted through badge controlled
gates.
Hosting Service Provider data centers all receive SSAE16/ISAE 3402 Attestation and are ISO 27001
certified. Microsoft manages access to the Data Centre as follows:
Datacenter entrances are guarded 24x7x365 by security personnel.
Access to all Hosting Service Provider buildings is controlled, and access is restricted to those
with card reader (swiping the card reader with an authorized ID badge) or biometrics for entry
into Data Centers.
Front desk personnel are required to positively identify Full-Time Employees (FTEs) or authorized Contractors without ID cards.
Staff must wear identity badges at all times, and are required to challenge or report individuals
without badges.
All guests are required to wear guest badges and be escorted by authorized Hosting Service
Provider personnel.
Azure Employees and contractors must have a business need to enter a Hosting Service Provider
data center and have received prior approval.
Doors between areas of differing security require authorized badge access, are monitored
through logs and cameras, and audited on a regular basis.
127 | P a g e
Theft, Loss and Misplacement of Identification Cards, Access Cards and Keys Where a BORN Agent notes theft, loss or misplacement of identification card/access card to BORN
offices:
The BORN Agent reports the missing badge to the BORN Human Resources Agent who alerts
CHEO Human Resources and the Ottawa Hospital Photo ID and Parking desk within the Security
department (either by e-mail or in person) and badge de-activation occurs immediately
o The Ottawa Hospital is notified as well as CHEO because BORN rents space from The
Ottawa Hospital, enabling access to the building via their CHEO HR-arranged badge; to
fully de-activate a badge both organizations must be notified
The BORN Human Resources Agent or designate arranges for a new badge to be issued. BORN
does not issue temporary badges.
The BORN Human Resources agent records the date of loss and the ID of the replacement badge
in S-04: Log of Agents with Access to the Premises
Where a BORN Agent notes theft, loss or misplacement of an office key
The BORN Agent reports the missing key to the BORN Human Resources Agent or designate who
arranges for a replacement key to be cut.
The BORN Human Resources Agent or designate records the date of loss and the replacement
key number in S-04: Log of Agents with Access to the Premises
Termination of the Employment, Contractual or Other Relationship BORN Agents and their supervisors must adhere to HR-10 Termination and Cessation of Employment
when a decision is taken to terminate the Agent’s role. Badge and key return are part of HR-10
Termination and Cessation of Employment. The written notification detailed in HR-10 sets out:
Name of the Agent
Termination date
Reasons for termination
Date at which identification card, access card and/or keys will be returned by the Agent to the
Privacy Officer
Notification When Access is No Longer Required BORN Agents and their supervisors must adhere to HR-10 Termination and Cessation of Employment when a
decision is taken to terminate the Agent’s role. Agents and their supervisors are required to notify the
Executive Director and the Privacy Officer of the termination of an employment or contractual relationship
two weeks in advance, if possible. The notification must be via e-mail and contain the following information:
• Name of Agent
128 | P a g e
• Termination date
• Reasons for termination
Access by Visitors Visitors to the BORN premises must be supervised by a BORN Agent at all times, including departure.
Visitors to the BORN Data Centre are required to sign in and record their name, date and time of arrival, time
of departure and the name of the Agent(s) with whom the visitors are meeting. Visitors must be
accompanied by the BORN System Hosting Provider at all times. Visitors must wear identification issued by
the Information Security Officer; the Information Security Officer ensures the identification is returned prior
to departure; and the Information Security Officer ensures that the visitors complete the appropriate
documentation upon arrival and departure.
All documentation related to the identification, screening and supervision of visitors to the Data Centre is
retained by the BORN System Hosting Provider.
The documentation related to visitors is retained for a minimum of one year to allow for audit.
Document Retention The BORN Human Resources Agent or designate is responsible for securely maintaining:
S-04: Log of Agents with Access to the BORN Work Premises
Documents are securely maintained as per S-05: Secure Retention of Records of Personal Health
Information.
129 | P a g e
S-04: Log of Agents with Access to the BORN Work Premises The log of Agents with Access to the BORN Work Premises is saved on the BORN shared drive:
• GENERAL\Privacy\Logs Populated\Security
The following fields are captured in the Log of Agents with Access to the BORN Work Premises:
Name of Agent Granted Approval
Location(S) within the premises to which access is granted
Date access granted
Date ID card, access card and/or keys granted
ID number on ID card and/or keys granted
Date of next audit of access
Date ID card, access card and/or keys granted were returned
Date ID card, access card and/or keys granted were lost, stolen or misplaced
130 | P a g e
S-05: Retention of Records of Personal Health Information The purpose of this policy is to ensure that BORN securely retains records of Personal Health
Information in electronic format.
Agents are required to take steps that are reasonable in the circumstances to ensure that Personal
Health Information is retained securely and is protected against theft, loss and unauthorized use or
disclosure, copying, modification or disposal.
Records of Personal Health Information in electronic format are retained only as long as necessary to
fulfill the purpose for which the Personal Health Information is collected, to a maximum of 28 years, in
order to permit longitudinal analysis for the purposes of improving the provision of care to mothers,
infants and children, as set out in all BORN collection data sharing agreements. BORN prohibits the
retention of records of Personal Health Information for longer than the period set out in the data
sharing agreement.
Records of Personal Health Information held by researchers must not be retained for a period longer
than set out in the research agreements. Disposal is monitored by BORN.
BORN prohibits paper records of Personal Health Information.
Responsibility Information Security Officer, Privacy Officer
Procedure The Privacy Officer has responsibility for the retention of records of Personal Health Information.
BORN Information System The following safeguards are in place for records of Personal Health Information retained in the BORN
Information System:
Personal Health Information is securely collected via VPN connection or SSL-secured portal for
manual data entry as per S-07: Secure Transfer of Records of Personal Health Information and
pursuant to a data sharing agreement as per P-16: Data Sharing Agreements
Access to and use of Personal Health Information through the BORN Information System is role
based as per
131 | P a g e
P-08: Limiting Agent Access to and Use of Personal Health Information
Access to BORN premises is controlled as per S-03: Ensuring Physical Security of Personal
Health Information.
Access to the Data Centre, where the BORN servers reside, is managed by Hosting Service
Provider and is controlled as per S-10: System Control and Audit Logs.
The BORN Information System stores the date, time and name of the user entering, accessing,
using or transferring Personal Health Information within system audit logs as per S-10: System
Control and Audit Logs. The BORN Information System has the capability of ascertaining the
data values which were created, viewed, updated and deleted at any given time
Data on the database servers is protected using native Transparent Data Encryption (TDE). For
all other data at rest, encryption is enabled per-volume for disks, and per-container (or
container) for blob storage. This applies both to data stored on disks/volumes, as well as data
stored in object storage. BLOB storage has server-side encryption implemented.
BORN PHI Drive The following instances of Personal Health Information are retained on the BORN PHI drive:
Record-level data files, where the data may be:
o Collected under a data sharing agreement, as per P-04: Collection of Personal Health Information and P-06: Statements of Purpose for Data Holdings Containing Personal Health Information
o Research and analysis data files including but not limited to internal and external research datasets, analysis related to data quality, BORN Information System testing, data requests and disclosures
Historical datasets pre-dating the BORN Information System
o Collected under a data sharing agreement, as per P-04 & P-06: Collection of Personal Health
Information and Statements of Purpose for Data Holdings Containing Personal Health
Information
The following safeguards are in place for records of Personal Health Information retained on the BORN
PHI drive:
Personal Health Information is collected via secure FTP as per S-07: Secure Transfer of Records
of Personal Health Information and pursuant to a data sharing agreement as per P-16: Data
Sharing Agreements
Access to and use of Personal Health Information is based on the need-to-know principle tied to
the job description of an Agent.
A Data Request and Research Coordinator authorizes access to specific folders on the BORN PHI
drive and the Privacy Officer maintains a log of access to this drive
132 | P a g e
Access to BORN premises is controlled as per S-03: Ensuring Physical Security of Personal
Health Information.
The BORN PHI drive is equipped with audit capabilities that store the date, time and name of the
user accessing Personal Health Information, as well as create and delete functions.
BORN Temporary Storage In order to facilitate the day to day operations of BORN, the use of temporary data storage is required.
Temporary data storage is required for, but not limited to: the collection of Personal Health Information;
testing of Disaster Recovery Procedures; testing of data backups; and migration of data to BORN’s cloud environment. Data residing in temporary locations will only be for the amount of time required to
import the data into the BORN Information System and/or storing the data on the BORN PHI drive after
which time it will be deleted.
Temporary locations are:
The BORN secure FTP server
BORN SQL server file systems (for backup and restore files)
The following instances of Personal Health Information may be temporarily stored in the BORN
temporary locations:
Record-level data files, where the data may be:
o Collected under a data sharing agreement, as per P-04 & P-06: Collection of Personal Health Information and Statements of Purpose for Data Holdings Containing Personal Health Information
o Research and analysis data files including but not limited to internal and external research datasets, analysis related to data quality, BORN Information System testing, data requests and disclosures
Historical datasets pre-dating the BORN Information System
o Collected under a data sharing agreement, as per P-04 & P-06: Collection of Personal Health Information and Statements of Purpose for Data Holdings Containing Personal Health Information
The following safeguards are in place for records of Personal Health Information temporarily stored in
the BORN temporary locations:
Access to and use of Personal Health Information is based on the need-to-know principle tied to
the job description of a BORN Agent.
Access to BORN premises is controlled as per S-03: Ensuring Physical Security of Personal
Health Information.
Access to the Hosting Service Provider Data Centre, where the BORN servers reside, is managed
by the Hosting Service Provider and is controlled as per S-03: Ensuring Physical Security of
Personal Health Information.
133 | P a g e
Access to the CHEO Data Centre, managed by CHEO, is controlled as per S-03: Ensuring Physical
Security of Personal Health Information.
The BORN secure FTP server is equipped with audit capabilities that store the date, time and
name of the user accessing Personal Health Information, as well as create and delete functions.
Agents are trained in the retention of records of Personal Health Information as per HR-01 and HR-03:
Privacy and Security Training and Awareness.
Storage of Personal Health Information in any other location is strictly prohibited.
S-06: Retention of Records of Personal Health Information on Mobile Devices The purpose of this Policy is to ensure that Personal Health Information stored on authorized mobile
computing equipment is maintained securely and is protected against theft or loss and unauthorized
use, access, copying modification, disclosure or disposal.
It is BORN policy that Personal Health Information not be removed from BORN secured premises for use
by Agents. Personal Health Information will not be stored on mobile computing equipment except in
very specific and exceptional circumstances.
Mobile Computing Equipment includes laptops, Universal Serial bus (USB) flash drives, external hard
drives, CDs, DVDs and other mobile and mass storage devices as authorized in writing by the Privacy
Officer.
Responsibility Privacy Officer
Procedure Agents may retain records of Personal Health Information on a mobile device only when the information
is being used for research purposes (as per in
134 | P a g e
P-10: Use of Personal Health Information for Research) or for the purpose of facilitating and improving
the provision of health care and the elements of this policy have been satisfied.
Personal Health Information in the custody and control of BORN may be accessed remotely only where
an Agent is accessing Personal Health Information for the purpose of using the data for registry
purposes.
Agents are prohibited from remotely accessing Personal Health Information if de-identified or aggregate
information will serve the purpose and from remotely accessing more Personal Health Information than
is reasonably necessary for the identified purpose.
Agents must use full disk encryption, removable media encryption and a password-protected
screensaver.
Access to BORN data remotely is described fully in the following policies:
o Access to the BORN Information System (web logon) :
135 | P a g e
o P-08: Limiting Agent Access to and Use of Personal Health Information
o Remote access to the CHEO system: S-14: Acceptable Use of Technology.
In order to retain Personal Health Information on a mobile device or to access Personal Health
Information remotely, the Agent must make a request to the Privacy Officer via e-mail setting out:
The circumstances requiring the retention of Personal Health Information on a mobile device or
remote access of Personal Health Information
Why de-identified and/or aggregate information will not serve the identified purpose
The length of time the information is required to be retained or the length of time remote
access is required to achieve the purpose
In determining whether to approve the request, the Privacy Officer considers the following factors:
Is remote access or use of a mobile device required to achieve the Agent’s functions
Will de-identified and/or aggregate information serve the identified purpose
Is the amount of Personal Health Information requested the minimum required to meet the
identified purpose
Has the Agent’s use of Personal Health Information been approved under
136 | P a g e
P-08: Limiting Agent Access to and Use of Personal Health Information
Is the timeframe the minimum necessary to achieve the purpose
The Privacy Officer enters all approvals in S-06B: Log of Agents Use of Mobile Devices/Remote Access
including:
Name of Agent
Type of mobile device/remote access
Type and amount of information on mobile device/accessed through remote access (sufficient
detail to ensure that if mobile device is lost or stolen, BORN is able to identify the Personal
Health Information)
Date mobile device removed or remote access activated
Date mobile device due to be returned or remote access de-activated
Date mobile device returned or remote access de-activated
The Privacy Officer e-mails the Agent, with copy to the Agent’s supervisor, with the approval indicating
that the mobile device can be removed/and remote access can be initiated when S-06A: Agreement for
Use of Mobile Devices/Remote Access has been signed.
The Agreement includes:
Name of Agent
Type of mobile device/remote access
Type and amount of information on mobile device/accessed through remote access
Date mobile device removed/remote access activated
Date mobile device due to be returned/remote access de-activated
It also includes the requirement to adhere to the following conditions:
Agents are prohibited from retaining Personal Health Information on the mobile device or
remotely accessing Personal Health Information if other information, such as de-identified
and/or aggregate information, will serve the purpose.
Personal Health Information must be de-identified to the fullest extent possible. The code
needed to unlock the Personal Health Information must be stored separately and securely.
Agents are prohibited from retaining more Personal Health Information on the mobile device or
from remotely accessing more Personal Health Information than is reasonably necessary for the
identified purpose.
137 | P a g e
138 | P a g e
Agents are prohibited from retaining Personal Health Information on the mobile device or for
remotely accessing Personal Health Information for longer than necessary to meet the identified
purpose.
Agents must ensure that a strong and complex password is used and that the password for the
mobile device and for remote access is different from the passwords for files containing the
Personal Health Information and that the password is supported by “defense in depth”
measures as per S-09: Passwords and Multi-Factor Authentication.
Agents must securely retain the Personal Health Information on the mobile device or when
accessing remotely as per S-08: Secure Disposal of Records of Personal Health Information.
In relation to mobile devices, once the intended purpose and use is accomplished, the Agent will
securely remove or destroy Personal Health Information within five days of completion of the
work that necessitated its storage on the mobile computing device as per S-08: Secure Disposal
of Records of Personal Health Information.
The Information Security Officer is responsible for:
Training staff to use strong unique passwords that are a mixture of alphabetic characters,
special characters, digits, minimum of six characters in length
Ensuring that remote access can only be achieved through single secure portal logon page
Where mobile devices have display screens or where Personal Health Information is being
accessed remotely, ensuring mandatory password-protected screen savers are enabled after 15
minutes of inactivity
Ensuring mobile devices use full disk encryption are encrypted with a minimum standard of AES-
256
Monitoring staff compliance with the Agreement for the Use of Mobile Devices/Remote Access
If the mobile device is lost, stolen or misplaced, the Agent is required to notify the Privacy Officer
immediately as per S-17: Security Breach Management.
Document Retention The Privacy Officer securely retains:
• Agent e-mail requests
• S-06B: Log of Agent Use of Mobile Devices/Remote Access
• Signed Agreements for the use of Mobile Devices/Remote Access
Documents are retained in the BORN shared drive.
__________________ __________________
S-06A: Agreement for Use of Mobile Devices/Remote Access
BORN AGREEMENT REGARDING USE OF MOBILE DEVICES/REMOTE ACCESS
Name of Agent:
Type of mobile device/remote access:
Type and amount of information on mobile device/accessed through remote access:
Date mobile device removed/remote access activated:
Date mobile device scheduled to be returned/remote access de-activated:
I _________________agree that I will:
Not retain Personal Health Information on the mobile device or remotely access Personal Health
Information if other information, such as de-identified and/or aggregate information, will serve
the purpose;
Not retain more Personal Health Information on the mobile device or remotely access more
Personal Health Information than is reasonably necessary for the identified purpose;
Not retain Personal Health Information on the mobile device or remotely access Personal Health
Information for longer than necessary to meet the identified purpose
Use a strong and complex password and ensure that the password for the mobile device and for
remote access as per S-09: Policy and Procedures Relating to Passwords
Securely retain the Personal Health Information on the mobile device or when accessing
remotely as per S-05: Policy and Procedures for Retention of Records of Personal Health
Information
Securely remove or destroy Personal Health Information within 5 days of completion of the
work that necessitated its storage on the mobile computing device as per S-08: Policy and
Procedures for Secure
Signature
Agent Date
139 | P a g e
S-06B: Log of Agent Use of Mobile Devices/Remote Access The Log of Agent Use of Mobile Device/Remote Access is saved on the BORN shared drive:
GENERAL\Privacy\Logs Populated\Security
The following fields are captured in the Log of Agent Use of Mobile Device/Remote Access:
Name of Agent
Type of mobile device/remote access
Type/amount of information on mobile device/accessed through remote access
Date mobile device removed or remote access activated
Date mobile device due to be returned or remote access de-activated
Date mobile device returned or remote access de-activated
140 | P a g e
S-07: Secure Transfer of Records of Personal Health Information The purpose of this policy is to ensure that BORN securely transfers records of Personal Health
Information regardless of format.
Records of Personal Health Information in electronic format must be transferred in a secure manner.
Agents must use only the approved methods of transferring records of Personal Health Information in
electronic format.
Paper-based transfers of Personal Health Information are not permitted.
Agents are not permitted to transfer Personal Health Information by fax or by e-mail.
Responsibility Information Security Officer
Procedure Secure Transfer Out of BORN
BORN uses a secure FTP server and password protection to transfer Personal Health Information or de-
identified data to recipients. Where the transfer of Personal Health Information or de-identified data is
permitted, the Data Request and Research Coordinator:
Reviews the file containing Personal Health Information or de-identified data to be transferred
to ensure that it is consistent with the approved request for Personal Health Information
Ensures the file is further secured using password protection
Places the information on the secure FTP server
Notifies the recipient via e-mail that the file is available on the secure FTP server
The recipient must call the Data Request and Research Coordinator to confirm receipt of the
data and to obtain the password to de-crypt the data set
The Data Request and Research Coordinator removes the file from the secure FTP server when
the recipient acknowledges receipt of the data
When receipt has been confirmed, the Data Request and Research Coordinator updates P-11A:
Data Tracking Log with the date and time of transfer, nature of the records of Personal Health
Information transferred, mode of transfer, recipient of the records and date receipt of records
was confirmed
Records of Personal Health Information transferred out of BORN are subject to retention and
destruction guidelines in the associated research agreement or data sharing agreement.
141 | P a g e
Secure Transfer Out of BORN: Aggregate Data and Acknowledging Receipt of Data Aggregate data is transferred via e-mail by the Data Request and Research Coordinator. The recipient
contacts the Data Request and Research Coordinator to confirm receipt of the data and to obtain the
password, where applicable. BORN does not mandate that all aggregate data requests be password
protected. All aggregate data sent via e-mail contains the following boiler plate information
This message, including any attachments, contains confidential information and is for the sole
use of the intended recipient(s). Any unauthorized use, disclosure or distribution is prohibited. If
you are not the intended recipient, please notify the sender immediately and destroy the
original message. The intended recipient of this message will not use the information, either
alone or with other information, to attempt to identify or re-identify an individual. This includes
attempting to decrypt information that is encrypted, attempting to identify an individual based
on unencrypted information and attempting to identify an individual based on prior knowledge.
All transfers of aggregate data are documented by the Data Request and Research Coordinator in the
Data Tracking Log.
Secure Transfer in to BORN 1. Personal Health Information collected electronically from Health Information Custodians is
transferred in one of the following ways:
a. Direct connection to the BORN portal by:
i. using a browser with industry standard SSL encryption, or
ii. HL7 feed directly from hospital systems using a secure VPN connection
b. BORN Hosting Provider
2. Secure FTP
3. BORN Secure Web Service
a. Users on the public Internet must establish a SSL connection to the BORN Secure Web Service; this requires token-based dual authentication
4. Ontario Health’s Connected Backbone (Health Information Access Layer or HIAL)
a. Organizations on the public Internet require ONE ID certificate authentication to access the HIAL Health Information Network Provider (HINP) to transfer Personal Health Information to BORN
BORN applications have idle timeouts implemented to safeguard the data.
Transfer Between Prescribed Registry and Prescribed Entity Where Personal Health Information is transferred between BORN and prescribed entities, BORN will use
the secure network provided by the prescribed entity.
Secure Transfer Policy Updates The Privacy Officer ensures that policies and procedures regarding secure transfer are updated on an
on-going basis to reflect:
142 | P a g e
Orders issued by the Information and Privacy Commissioner of Ontario under PHIPA and its
regulation
Guidelines, fact sheets and best practices issued by the Information and Privacy Commissioner
of Ontario, including Privacy Protection Principles for Electronic Mail Systems and Guidelines on
Facsimile Transmission Security; and
Evolving privacy and security standards and best practices
Document Retention The Data Request and Research Coordinator securely maintains the Data Tracking Log in locked
premises.
Documents are retained in the BORN shared drive.
143 | P a g e
S-08: Secure Disposal of Records of Personal Health Information The purpose of this policy is to ensure that BORN securely disposes of records of Personal Health
Information in electronic format.
BORN prohibits records of Personal Health Information in paper format.
Electronic records of Personal Health Information must be disposed of in a secure manner.
Disposed of in a secure manner means that the records are destroyed in such a manner that the
reconstruction of the records is not reasonably foreseeable in the circumstances.
Responsibility Privacy Officer, Information Security Officer
Procedure Paper records of Personal Health Information are prohibited by BORN.
Note: In the event that a paper record of Personal Health Information was discovered, the
Privacy Officer is responsible for ensuring that paper records of Personal Health Information
intended for secure disposal are maintained separately from other records intended for
recycling in a designated and locked bin clearly marked for the retention of records of Personal
Health Information pending their secure disposal. These records are disposed of using a cross-
cutting shredding method and incineration to eliminate the possibility of reconstructing the
documents.
Records of Personal Health Information in electronic format and/or on removable devices such as CDs,
USB keys, and hard drives are disposed of by:
Physically damaging the item to render it useless by snapping into pieces, hammering, drilling
holes into, obliterating, or pulverizing, or
Where re-use is being considered, such as re-using a hard drive or USB key, the device will be
wiped using a secure wiping utility that is specific to the device/media
Records of Personal Health Information may need to be destroyed as a result of, but not limited to:
Data Holdings Committee determines that Personal Health Information collected by BORN is no
longer needed to fulfill its mandate as a prescribed registry and must be destroyed
Agent has been granted approval for a removable device pursuant to S-06: Retention of
Records of Personal Health Information on Mobile Devices and the mobile device is due to be
returned
Retention period as set out in a collection data sharing agreement has been reached
The method of destruction is selected and the actual destruction is performed as follows:
Records of Personal Health Information on a removable device
144 | P a g e
1. An Agent with records of Personal Health Information on a removable device that are to be
destroyed must contact the Privacy Officer regarding appropriate secure destruction of the data
within 10 days of determining that the data is no longer required.
2. The Privacy Officer informs the Agent which method of destruction is to be performed (either
physically destroying the device or secure wiping the device for reuse) and requests that the
Agent:
Perform the secure destruction as per S-08B: Certificate of Destruction;
Note: where a device is to be destroyed, the Privacy Officer is responsible for
ensuring that the removable device intended for destruction is maintained
separately in a designated and locked bin clearly marked for the retention of
records of Personal Health Information, pending their secure disposal.
Complete and return to the Privacy Officer the S-08B: Certificate of Destruction within
one month
Electronic records of Personal Health Information 1. When electronic records of Personal Health Information are to be destroyed the Privacy Officer
selects the appropriate secure destruction of the data within 10 days of determining that the
data is no longer required.
2. The Privacy Officer informs the Information Security Officer which method of destruction is to
be performed (either physically destroying the device or secure wiping the device for reuse) and
requests that the Information Security Officer or designate:
Performs the secure destruction as per S-08B: Certificate of Destruction
Complete and return to the Privacy Officer the S-08B: Certificate of Destruction within
one month
The Information Security Officer and the Privacy Officer review the policies and procedures regarding
secure destruction on an on-going basis to ensure that they remain consistent with:
PHIPA and its regulation
Orders issued by the Information and Privacy Commissioner
Guidelines, fact sheets and best practices issued by the Information and Privacy Commissioner
145 | P a g e
146 | P a g e
S-08B: Certificate of Destruction of Personal Health Information
TECHNICAL GUIDELINES FOR SECURE DESTRUCTION OF CONFIDENTIAL INFORMATION “Destroy in a Secure Manner” means to destroy the Data and all copies in such a manner that
reconstruction of the records is not reasonably foreseeable in the circumstances, and includes physically
damaging the item to render it useless using a crosscut-shredding machine or otherwise snapping into
pieces, hammering, drilling holes into, obliterating, or pulverizing, or, where re-use is being considered,
wiping the device using a secure wiping utility that is specific to the device/media.
The content of the certificate of destruction is outlined below:
CERTIFICATE OF DESTRUCTION
The information described below was destroyed in the normal course of business pursuant to the
organizational retention schedule and destruction policies and procedures.
Organization:
Organization Contact:
Date and time of Destruction:
Authorized By:
List and/or Description of Personal Health Information or De-identified Data or Data Disposed Of/Destroyed:
Inclusive Dates Covered:
METHOD OF DESTRUCTION:
Overwriting
Pulping
Pulverizing
Grinding
Shredding
Degaussing/secure wiping utility (provide details: ______________________________
Other: _________________________________________________________________
Records Destroyed By* (print and sign):
Witnessed By (print and sign):
Department Manager:
*If records destroyed by outside firm, must confirm a contract exists
S-09: Passwords and Multi-Factor Authentication The purpose of this policy is to ensure that BORN maintains system integrity through appropriate
password creation, security and administration. Agents are required to develop and use strong
passwords when accessing information systems, technologies, equipment, resources, applications and
programs containing Personal Health Information, regardless of whether they are leased, owned or
operated by BORN.
Responsibility Information Security Officer
Procedure The Privacy Officer confirms identity of new Agents to the BORN System Administrator, who then
assigns a username and initial password. The BORN System Administrator provides the username and
temporary password in separate e-mails, by telephone or in person. The password is time limited and
must be changed at first sign-on. Specific details of this are set out in policy
147 | P a g e
P-08: Limiting Agent Access to and Use of Personal Health Information.
Authentication systems within the BORN Information System require that passwords contain:
A minimum of eight (8) characters
Both upper case and lower case letters
A minimum of one numeric or non-alphanumeric character(s)
Agents must ensure the privacy of their passwords and must not:
Write down passwords
Display, reveal, hint at, provide, share or otherwise make their password known to any other
individual, including another Agent
BORN users and Agents must change their password immediately if they suspect it has become known
to another individual including another Agent.
Passwords expire automatically every 90 days and cannot be reused for at least five iterations.
After 10 unsuccessful sign-in attempts with the wrong password, the user is locked out for one minute.
Further incorrect sign-in attempts lock out the user for increasing durations of time.
The application automatically logs users out after 15 minutes of inactivity forcing users to re-
authenticate in order to continue.
Creating Temporary Passwords All temporary passwords must:
be randomly generated (e.g. r5TU4QBxP3)
not based on anything somebody else could easily guess or obtain using person related information (e.g. Summer2020, names, telephone numbers, dates of birth, etc.)
not vulnerable to a dictionary attack
still follow password creation rules as indicated above
Multi-Factor Authentication (MFA) is required for all BORN Information System users.
There are currently 2 options for MFA: For users in organizations that cannot have access to a smart
phone or direct phone number (PIN) and for users in organizations that have access to a smart phone
(One-time use code).
For users in organizations that cannot have access to a smart phone or direct phone number The public IP address of the site must be registered in the BIS.
148 | P a g e
Any attempt to access the BIS from an unlisted site by a user who is setup for this option must
result in denied access to the BIS.
A user logging in from a registered site must enter an alphanumeric PIN which is setup during
the user registration process.
The PIN must be 6-8 characters in length and contain at least one number and one letter.
For users in organizations that have access to a smart phone There are currently two methods for this option: Send a one-time use code via a SMS message or
receive a call with a one-time use code over the phone.
A valid phone number must be registered with a user’s account, which is setup during the user
registration process.
The user can select which method they wish to be contacted at the time of login.
The one-time use code must be successfully entered in order to complete authentication.
The Privacy Officer reviews policies and procedures related to passwords on an on-going basis to ensure
that they are consistent with:
Orders issued by the Information and Privacy Commissioner
Guidelines, fact sheets, and best practices issued by the Information and Privacy Commissioner
Evolving privacy and security standards and best practices
The Privacy Officer and Systems Administer follow this policy in association with the following policies:
P-08: Limiting Agent Access to and Use of Personal Health Information
P-08 A: BORN PHI Access Request Form
P-09: Log of Agents Granted Approval to Access/Use/Disclose Personal Health Information
S-10: System Control and Audit Logs The purpose of this policy is to ensure that BORN maintains system integrity through review of system
control.
The access, use, modification and disclosure of Personal Health Information in the custody and control
of BORN are monitored on an on-going basis.
Responsibility Privacy Officer, Information Security Officer
Procedure The BORN Application Service Provider is responsible for system design in order to ensure that audit logs
capture date and time of any operation or action (including screen names and report view names), the
149 | P a g e
name of the user that performed the action or operation and the changes to values, if any. Each of these
events is retained in the audit logs.
System design parameters include the capabilities to undertake a complete ascertainment of the data
values which were created, viewed, updated, and deleted at any given time. The time of view will be
combined with values in the transactional database and the audit database. In the case of the most
complex reports, the timeframe for these reports being generated will be no more than five business
days.
As well, when an encounter record is deleted the record is marked with a status of deleted so that it is
ignored for all reports and the record will remain in the database as inactive. Aggregated records are not
audited but access to the aggregated dated is audited.
The design also ensures that audit logs capture access to aggregated or calculated information in the
reporting database but do not capture the record IDs which were used by the system to generate the
aggregation/calculation. In addition:
Aggregate/calculated information does not expose any personal information (PI)
The parameters used to retrieve the data are captured by the audit log
The BORN Application Service Provider is responsible for the day-to-day maintenance of the information
in the system control and audit logs including:
Date and time that Personal Health Information is accessed
Date and time of user sign off or system automatic disconnect at 15 minutes of inactivity
Name of user accessing Personal Health Information
Network name or identification of computer through which the connection is made
Creation, amendment, deletion or retrieval of Personal Health Information, the date and time of
the action, the name of the user and the changes to values if any
In addition, the Hosting Provider is responsible for ensuring that:
The system does not allow the audit log to be tampered with such that the audit history can be
altered or cleared of any events that have been captured
The audit controls remain operational at all times and cannot be bypassed through any method
Audit history is retained on-line such that it can be reviewed for a period of two years from the
date of the event. After two years, audit history will be retained off-line for an indefinite period
of time
Each event is retained in the logs
The Information Security Officer and the Privacy Officer are responsible for determining the nature and
scope of events to be audited and for monitoring that all audits are logged in the audit logs.
150 | P a g e
The Information Security Officer is responsible for ensuring the audit reports are run on an as-needed
basis and ensuring appropriate supervision of the operation of the system control and audit logs.
Each audit report contains the following common elements:
User ID: user ID of the user
Date Time: Date and time of the audit event
Action: What action has been taken by the user: Create View, Update, etc.?
Event Type: One of the five specific Audit Event Types as follows:
1. Security Audit Events – user authentication and access authorization events such as login
events, unauthorized access events
2. Reporting Audit Events – all audit events that can be captured during user interaction with
the BORN reporting system such as report execution and report event management
3. Data Interaction Events – all audit events that can be captured during user manipulation of
data through interactive user interface (forms) such as creating, viewing, updating or
deleting records
4. Administrative Events – audit events that can be captured during administrative activities in
the system such as organization or user management
5. Integration Queue Management Events – all audit events that can be captured during user
interaction with data integration queues including data normalization, cleansing and linking
and matching
At the request of the Privacy Officer, the Information Security Officer will produce the following ad-hoc
reports (this is undertaken if there is a suspected breach or other system anomaly):
What did a user change during a period of time – report of the records created, modified and
or deleted by a specific user during a specified date range
What is the revision history for a patient during a period of time – report of the complete
revision history of who created, modified and/or deleted details of patient demographics and
encounter details for selected patients and date range
What did a particular user access within the system during a period of time – report of patient
IDs, record details and record IDs accessed by that user during the specified date range
Who looked and/or changed a particular patient during a period of time – report of the
complete access history of who viewed, created, modified and/or deleted details for selected
patient ID and date range
The Information Security Officer is responsible for monitoring the logs on a monthly basis and, should
there be an indication of a privacy or security breach or an attempted privacy or security breach, the
151 | P a g e
Information Security Officer immediately reports to the Privacy Officer as per P-29: Privacy Breach
Management or S-17:Security Breach Management.
The Information Security Officer provides a report regarding the monitoring of the system control and
audit logs to the Privacy Officer on a monthly basis.
Audit and system control logs are retained on-line such that they can be reviewed for a period of two
years from the date of the event. After two years, they are retained off-line for an indefinite period of time.
The Privacy Officer is responsible for addressing the findings arising from the review of system control
and audit logs by:
Assigning Agents to address the findings
Establishing timelines to address the findings
Monitoring and ensuring the findings are addressed within timelines
The Privacy Officer is responsible for reporting to the Privacy and Security Review Committee on a
quarterly basis. The quarterly reporting includes:
Number and type of audits undertaken
Findings of the audits
Efforts undertaken to address findings
Status of these efforts
152 | P a g e
Document Retention The BORN Hosting Provider is responsible for ensuring that all audit and system logs are securely
retained and backed-up.
The Privacy Officer is responsible for securely retaining all audit reports including all monthly and ad-hoc
reports to the Privacy and Security Review Committee and the Executive Director.
The Information Security Officer is responsible for securely retaining all audit reports and related
materials that are produced as part of his/her duties.
Documents are retained in the BORN shared drive.
153 | P a g e
S-11: Patch Management The purpose of this policy is to ensure that there are appropriate policies and procedures in place for
patch management.
Operating system patches and other hosting system upgrades are reviewed on an ongoing basis and
implemented where appropriate in order to ensure that BORN provides a secure operational
environment.
BORN policy is to follow Microsoft recommendations for server platform patches
Patches from Service Providers for the custom-developed solutions follow the change management
policy and procedure
Responsibility Information Security Officer
Procedure Patches are managed by the Hosting Provider as follows:
All Microsoft products used by BORN are supported by Windows Update Service (WSUS) and follow
these steps:
Patches become available automatically on a monthly basis, and as applicable
Notification of patches is available on the WSUS application which is checked weekly by the
Hosting Provider
Due to the high volume of Microsoft patches, it is impracticable that each patch is reviewed
individually; patch recommendations from the vendor are followed. The Hosting Provider has
determined that accepting vendor recommended patches takes into consideration the balance
between ensuring maximal system security and efficiency vs. the potential service disruption
and general risk in applying the patch
Notice of patches:
o Notice of critical patches are sent by the Hosting Provider via e-mail to the BORN System
Administrator and the BORN Application Service Provider for immediate deployment
o All other patches are placed in a queue of approved patches
The BORN Application Service Provider is responsible for applying Microsoft recommended
patches (critical or otherwise) from the queue of approved patches to the BORN User
Acceptance Testing (UAT) environment for testing
Patches undergo soak testing in the UAT environment for a minimum of one week
After successful testing in UAT the patches are approved and the Hosting Provider deploys the
patches to the production servers
154 | P a g e
o Where a patch does not test successfully, the Hosting Provider is responsible for
denying the patch by removing the offending patch from the UAT environment prior to
deploying to the production environment
Hosting Provider Patch Documentation The Hosting Provider can query upon request the WSUS application server log updates for a list of all
patches (approved or denied). Each patch has a unique Microsoft Knowledge Base article that contains:
What product the update is for
When Microsoft released the given update/when the patch became available
Severity of the update (critical or regular)
Type of update (product update, or security update)
Name of the update
Description of the update, including the information system, technology, equipment, resource,
application or program to which the patch relates)
Release date of update
Date the update was approved/declined for use by WSUS
Date a given Microsoft OS based server applied the approved update
Rationale for not implementing
Document Retention The Information Security Officer is responsible for securely maintained as follows:
Microsoft patches are documented per server on the Installed Updates log.
Application Service Provider patches are documented in the change request ticketing system.
The Information Security Officer maintains a patch log documenting the implementation of
patches that contains: the description of the patch; the date that the patch became available;
the severity level and priority of the patch; the information system, technology, equipment,
resource, application or program to which the patch relates; the date that the patch was
implemented; the agent(s) responsible for implementing the patch; the date, if any, when the
patch was tested; the agent(s) responsible for testing; and whether or not the testing was
successful.
Documents are retained in the BORN shared drive.
155 | P a g e
156 | P a g e
S-12: Change Management The purpose of this policy is to ensure BORN has policies and procedures in place for receiving,
reviewing and determining whether to approve or deny a request for a change to its operational
environment (where BORN’s operational environment is the BORN Information System).
Software changes are reviewed on an ongoing basis and implemented where appropriate in order to
ensure that BORN provides a secure operational environment.
Requests for changes to the operational environment are subject to a thorough review and approval
process.
Responsibility BORN System Administrator/Information Security Officer
Procedure
Submitting a Change Request – BORN Information System Change requests can come from users, the Application Service Provider or from the Hosting Provider.
They may be in the form of an optimization, patch, or as part of annual review of system enhancement
requests for the BORN Information System.
All requests for change to the operational environment are submitted and tracked in the Application
Service Provider’s change management system.
Note: Change requests from users of the BORN Information System (hospital data entry clerks, for
example) may be submitted as follows:
Contact a member of BORN’s Provincial Engagement Team to submit a change request and
BORN will formally submit the change request on their behalf
Submit a change request online on the BORN website
BORN formally opens and tracks tickets in the Application Service Provider’s change management
system for all requests. Tickets contain, at a minimum, the following details:
Description of the proposed change
Rationale for the change
Impact of executing or not executing the change
Steps to reproduce the issue and test the resolution of the issue
Tickets that are submitted but not complete are returned to the Requestor for clarification.
Submitting a Change Request – Operational Environment Change requests can come from Application Service Provider, BORN Hosting Provider, or the BORN
Technical Team. They may be in the form of an optimization, patch, system replacement or upgrade.
All requests for change to the operational environment are submitted and tracked in Hosting Provider’s
change management system.
BORN formally opens and tracks tickets in the Hosting Provider’s change management system for all
requests. Tickets contain, at a minimum, the following details:
Description of the proposed change
Rationale for the change
Impact of executing or not executing the change
Steps to reproduce the issue and test the resolution of the issue
Tickets that are submitted but not complete are returned to the requestor for clarification.
Review, Approval or Denial of Change Requests The BORN System Administrator and the Information Security Officer receives, reviews and approves or
denies all requests and considers the following criteria:
Change will prevent system failure
Change will fix a bug
Change solves an identified problem
The importance of the change outweighs anticipated downtime
The balance between maximal system security and the possibility of a privacy or security risk
being introduced
If the decision is made not to approve the change, the BORN System Administrator updates the status of
the change request (cancels the ticket) and the change management system tracks this decision and
triggers an e-mail to relevant stakeholders. Documentation includes:
Change requested
Name of Agent requesting change
Date change requested
Date change denied/closed
Rationale for not implementing the change (stored in the comments field)
157 | P a g e
If a decision is made to approve the change, it is evaluated for any privacy or security considerations.
The Terms of Reference for BORN’s Data Holdings Committee set out the types of changes that require
approval from the Data Holdings Committee. See Appendix A of the Data Holdings Committee Terms of
Reference within policy O-03: Terms of Reference for Committees with Roles with Respect to the
Privacy Program and/or Security Program.
The BORN System Administrator is responsible for determining the timeframe for implementation of all
approved changes. Changes which address existing vulnerabilities are given priority over changes which
improve user experience.
Implementing a Change Request The BORN System Administrator and other technical staff with access to the change management
system enter status updates, including decisions, into the change management system. The change
management system tracks:
Change requested
Name of Agent requesting change
Date change requested
Date change approved
Rationale for approval
The priority assigned to the change
The expected procedure for testing (the change management system notes the procedure for
replicating the problem; once a problem has been fixed the steps to replicate it must be tested,
verified and documented in the change management system)
Approval from the BORN System Administrator (in the Comments field)
The Application Service Provider is responsible for implementation of the change in the BORN
Information System. The Hosting Provider is responsible for implementation of the change in the
operational environment. When the change is implemented, the Application Service Provider or Hosting
Provider (as applicable) updates the change management system to reflect:
Date change tested
Date change was implemented in the test environment
Sets the ticket status to “Resolved” in the change management system
Testing a Change Request When the Application Service Provider or Hosting Provider sets a ticket to “Resolved”:
The change management system sends an automated e-mail to the Requestor of the change
158 | P a g e
The Requestor tests the change, ensuring that the procedure to replicate the problem (as noted
in the change management system) has been addressed
When testing is complete, the Data Requestor sets the ticket to “Ready for Production” in the change management system
Deploying a Change Request to the Live System Decisions regarding deployment of a change to the production (live) environment can only be made by
the Information Security Officer.
The BORN System Administrator together with the Application Service Provider or Hosting Provider
reviews all tickets in the change management system with a status of “Ready for Production” and
considers:
Change will prevent system failure
Change will fix a bug
Change solves an identified problem
The importance of the change outweighs anticipated downtime
The balance between maximal system security and the possibility of a privacy or security risk
being introduced
Where a change is not accepted for deployment the BORN System Administrator updates the ticket to
“Under Review” enters the reason in the “Comments” field, and the ticket remains assigned to the Data
Requestor.
Where a change is accepted for deployment the BORN System Administrator leaves the ticket status as
“Ready for Production” and the change is included in the next scheduled update.
Document Retention The Information Security Officer has designated responsibility of maintaining the change management
system to the Application Service Provider and Hosting Provider. The change management system has
an immutable audit log trail.
Documents are retained in the BORN shared drive.
159 | P a g e
S-13: Back-up and Recovery of Records of Personal Health Information The purpose of this policy is to ensure that BORN has the appropriate systems in place for the backup
and recovery of records of Personal Health Information.
BORN maintains the security of records of Personal Health Information in its custody through the
systematic back up, recovery and testing of Personal Health Information in its custody.
Responsibility Hosting Provider
Procedure The Hosting Provider provides data protection and recovery service. The Application Service Provider is
responsible for testing of the restored data for completeness. Full details of the BORN Backup plan are
contained in the BORN Disaster Recovery Standard Operating Procedure.
All data on the back-up media containing Personal Health Information shall be encrypted using a
minimum AES 256-bit encryption.
Required Documentation Backups: The BORN Disaster Recovery Standard Operating Procedure documents: the schedule for which
data is backed up; the data to be backed up; and the party responsible for performing the backup.
Recovery: Requests for recovery must be provided to the Information Security Officer or their delegate. The
request must contain: the name of the requester; the data to be restored (e.g. file name or database
records); the timestamp/date of the data to be restored; and reason for restoration. The Information
Security Officer will record this information in the Data Recovery Log along with the date of restoration and
agent who performed the restoration.
Secure Storage of Backups Backups are stored on servers hosted by Microsoft in Toronto, Ontario in encrypted format using the Azure
Backup Service. Copies of the backups are also stored at BORN’s disaster recovery site hosted by Microsoft in
Quebec.Storage is compliant to S-05: Retention of Records of Personal Health Information.
Recovery Testing Recovery testing is performed as needed, minimally twice per year. Recovery testing is performed to
ensure that the data protection process remains adequate.
The Hosting Provider performs a data restore from the recent monthly backup
The Application Service Provider loads the data set into BORN test environment and runs
acceptability testing (e.g. running test cases or endurance testing)
The Application Service Provider provides the Hosting Provider and Information Security Officer
with the results of the acceptability testing
160 | P a g e
Any issues encountered during the acceptability testing are rectified by the Application Service Provider.
161 | P a g e
S-14: Acceptable Use of Technology The purpose of this policy is to ensure that Agents understand and abide by the acceptable use of
information systems, technologies, equipment, resources, applications and programs with respect to
BORN data regardless of whether the technology are owned, leased or operated by BORN.
The following uses of information systems, technologies, equipment, resources, applications and
programs by Agents regardless of whether the technology is owned, leased or operated by BORN are
prohibited without exception:
Using unencrypted mobile media such as USB keys
Removing from the premises computers containing Personal Health Information
E-mailing Personal Health Information
Faxing Personal Health Information
Attempting to gain access to BORN data or programs for which written authorization from the
Privacy Officer does not exist
Use of information systems for illegal or unlawful purposes, including copyright infringement,
obscenity, libel, slander, harassment, intimidation, impersonation and computer tampering (e.g.
spreading of computer viruses or other malicious software)
Creating, viewing, copying, altering, or deleting information systems data belonging to BORN
without permission
Sharing BORN information system account passwords with another person or attempting to
obtain another person’s information system account password. Information system accounts
are only to be used by the registered user
Use of information systems in any way that violates BORN policies and procedures
The following uses of information systems, technologies, equipment, resources, applications and
programs regardless of whether they are owned, leased or operated by BORN are permitted only with
prior approval:
Use of encrypted mobile devices containing Personal Health Information as per:
S-06: Retention of Records of Personal Health Information on Mobile Devices
Remote access to applications and resources through Internet access on a computer equipped
with an approved remote access client, as per the CHEO Information Services remote access
control form, which documents and tracks:
Requested applications and resources for which access is being requested
Request date and time
162 | P a g e
Determination that the user’s job requires remote access to CHEO applications
Name of person submitting form
Name and signature of Authorized Person approving the access, where Authorized
Person is defined as the Executive Director or a manager reporting to the Executive
Director
Department to receive the form
Method and format for the approval to be communicated to the employee, and the
department issuing the communication
Agents should have no expectation of privacy when using the BORN Information System as their
activities related to Personal Health Information will be monitored.
Responsibility Privacy Officer, Information Security Officer
Procedure For uses that are permitted only with prior approval, the Privacy Officer will follow procedures set out in
S-06: Retention of Records of Personal Health Information on Mobile Devices.
163 | P a g e
S-15: Security Audits The purpose of this policy is to ensure that BORN conducts regular security audits.
BORN conducts regular security audits to protect the security of the Personal Health Information in its
custody and control.
Responsibility Information Security Officer
Procedure BORN conducts the following types of security audits:
Compliance with security policies and procedures
Threat Risk Assessments
Comprehensive and organization-wide including all information security assets,
including Personal Health Information and project-specific threat and risk assessments
to identify both internal and external risks; may be performed by an external third party
Vulnerability assessments and ethical hacks
on the information processing infrastructure and on targeted external-facing
applications
Penetration testing
On the BORN portal from the Internet
Audit of security controls (implemented and planned) to assess effectiveness
Reviews of system control and audit logs
The Information Security Officer develops an annual plan for security audits in consultation with the
Privacy and Security Review Committee. Audit plans, activities, and operational action items focusing on
data duplication, access, and data boundary limitations shall be designed to minimize the risk of
business process disruption. Audit activities must be planned and agreed upon in advance by
stakeholders.
Annually, BORN performs:
A vulnerability assessment and ethical hack on the information processing infrastructure and on
targeted external-facing applications
Penetration testing of the BORN portal from the Internet
A threat risk assessment to identify all risks, external and internal (using an independent third
party)
164 | P a g e
Assessments are performed at a minimum every three years and on an as needed basis for individual
projects.
In selecting additional subject matters for the audits in the annual review, the Information Security
Officer considers:
Results of most recent threat risk assessment(s)
Previous security incidents
Introduction of new technologies (security audits performed on all new technologies prior to
deployment)
Significant changes to the BORN facility
Recommendations from Agents
For each security audit, the Information Security Officer identifies in the annual plan:
Purpose of the security audit
Nature and scope of the security audit (e.g. interviews, site visits, inspections)
Timeframe for the security audit
Framework for the audit, including questions or areas of concern
Agent responsible for conducting the security audit, where appropriate
Frequency with which each security audit will be conducted
Circumstances in which the security audit will be conducted
Process to be followed in conducting the security audit
Whether notification will be provided, to whom it will be provided and the content of the
notification
The Information Security Officer ensures that an implementation schedule for the identified security audits is included in the annual plan.
The Information Security Officer forwards a written copy of the annual plan for security audits to the Privacy and Security Review Committee for their review and approval. The Privacy and Security Review
Committee ensures appropriate Agents are selected to perform each audit.
Upon approval, the Information Security Officer and/or the Privacy Officer implement the plan/arrange
for the audits to be carried out.
The assigned Agents undertake the security audits and provide a written update in the report to the
Information Security Officer for each audit activity completed. Each report contains the following:
Audit as identified in the annual plan
165 | P a g e
Scope of the audit
Methodology employed
Findings/risk scores, where applicable (for prioritization of remedial action)
Recommendations
Upon receipt of the report, the Information Security Officer assigns Agent(s) to address the
recommendations arising from the security audit, sets out timelines for completion, and enters the
information into S-16: Log of Security Audits and O-07:Consolidated Log of Recommendations.
The Information Security Officer monitors to ensure that recommendations are implemented within
stated timeframes.
The Information Security Officer forwards the Log of Security Audits to the Privacy and Security Review
Committee on a quarterly basis.
The Information Security Officer includes a description of security audits, recommendations and actions
taken in:
Quarterly reports to the Privacy and Security Review Committee and the Executive Director
Annual Report on Privacy and Security
Document Retention The Information Security Officer is responsible for securely maintaining electronic copies of the
following documents:
Log of Security Audits
Log of Consolidated Recommendations
Description of security audits, recommendations and actions taken in BORN Privacy and Security
Reports (quarterly and annual reports)
Audit reports from the Information Security Officer
Where the Information Security Officer maintains hard copies of any of the above, they must be
maintained in a locked cabinet,
Documents are retained in the BORN shared drive.
166 | P a g e
S-16: Log of Security Audits The Log of Security Audits is saved on the BORN shared drive:
• GENERAL\Privacy\Privacy and Security Audits
The following fields are captured in the Log of Security Audits:
• Nature and Type of Security Audit
• Date Audit Completed
• Agents Responsible
• Recommendations arising from the security audit
• Agent Responsible for addressing each recommendation
• Date Recommendation to be addressed
• Date Recommendation implemented successfully
• Manner in which recommendation was addressed
167 | P a g e
S-17: Security Breach Management The purpose of this policy is to ensure that BORN addresses the identification, reporting, containment,
notification, investigation and remediation of security breaches as defined in this policy.
A Security Breach includes:
Any act or incident in contravention of the security policies and procedures and practices
implemented by BORN
Any act or incident, internal or external, that affects the confidentiality and integrity of information in the custody and control of BORN
This policy also applies to suspected information security breaches (where indicated).
BORN requires every Agent to notify the Privacy Officer and the Information Security Officer as soon as
reasonably possible, and to do whatever is reasonably possible to contain a security breach or suspected
security breach, whether internal or external, and to mitigate its effects immediately as per HR-01 and
HR-03: Privacy and Security Training and Awareness.
The Privacy Officer can be reached at:
Privacy Officer
CHEO Research Institute/CPCR 401 Smyth Road
Ottawa ON K1H 8L1
E-mail: [email protected]
Phone: 613-737-7600 x 6038
Fax: 613-737-6504
The BORN Information Security Officer can be reached at:
BORN Information Security Officer
CHEO Research Institute/CPCR
401 Smyth Road Ottawa ON K1H 8L1
E-mail: [email protected] Phone: 613-737-7600 x 6020
Fax: 613-737-6504
BORN website: www.BORNOntario.ca
168 | P a g e
Responsibility Information Security Officer, Privacy Officer
Procedure Agents must notify the Privacy Officer and the Information Security Officer as soon as reasonably
possible of any security breach or suspected security breach. The notification of a security breach may
be made to the Privacy Officer and Information Security Officer verbally, by e-mail, BBM, or any known
appropriate channel and must include:
Type of suspected breach
Location of suspected breach
Any actions taken by the reporting Agent to contain the breach
An Agent who discovers the breach or suspected breach is required to initiate the process of
containment, as appropriate.
There are three mechanisms by which problems with security may be identified:
1. Hosting Provider monitors, identifies risks such as perimeter, firewall and other external
attacks.
2. Application Service Provider monitors, identifies risks to Access to Portal, threats to the BORN
System itself.
3. An individual reporting inappropriate access or use.
The procedures for each are as follows:
1. The Hosting Provider monitors:
Physical environment for the servers and other hardware and reports any breaches of the
security policy for these systems to the Privacy Officer
Network traffic, using anomaly-based algorithms that look for a predetermined threshold of
activity that may signal an attempted attack on the perimeter or firewall. Based on the severity
of the apparent attack, an incident ticket is created and forwarded to the Hosting Provider who
will assess the situation and escalate to BORN or to the Application Service Provider as required
The Hosting Provider may block all traffic if the threat level reaches an agreed-upon threshold, as
approved by the BORN Information Security Officer or Privacy Officer.
2. The Application Service Provider ensures that the system is programmed to:
Identify authentication failures
Detect attempts to access unauthorized material and shut down sessions as necessary
169 | P a g e
In both these cases, identified risks cause the Application Service Provider to notify the Privacy
Officer and the Hosting Provider. The Privacy Officer contacts the user and/or the supervisor to
ensure there is no malicious intent.
The Application Service Provider maintains system logs of all such events.
3. An individual observing a contravention of security policy as soon as reasonably possible reports the
incident to the Privacy Officer.
Oral notification must be followed up as soon as possible by completion of a P-29B: Breach
Reporting Form to be forwarded by the Agent to the Privacy Officer. The completed Breach Reporting Form includes:
Name and position of the individual who discovered the incident
Date and time of discovery of the incident
Estimated time and date the breach occurred, if known
Type of breach (loss, theft, inadvertent disclosure)
Cause of breach, if known
Description of information involved in the breach
Actions taken by Agent reporting the breach to contain the breach, if applicable
Any other individuals or organizations involved in the breach (or its notification) and contact
information for relevant individuals
The Privacy Officer and the Information Security Officer, together with the Hosting Provider and
Application Service Provider (as applicable) works immediately to further contain the breach by:
Determining whether the breach or potential breach would allow unauthorized access to any
other data and takes whatever action is required to ensure that no further breaches can occur
through the same means (e.g. change password, shut down the system) and that the breach is
contained
Determining what (if any) Personal Health Information has been stolen, lost or accessed, used,
disclosed, copied, modified or disposed of in an unauthorized manner
If the Privacy Officer determines that the breach involves theft or impacts personal safety, the Privacy
Officer alerts the Executive Director of BORN and the CEO of CHEO and informs them that the police will
be notified. The Privacy Officer then notifies the police.
If the Privacy Officer determines that the information security breach involves the unauthorized
collection, use, disclosure, retention, or disposal of Personal Health Information in violation of PHIPA
and its regulation or in violation of any of the BORN privacy policies and procedures, then P-29: Privacy
Breach Management applies.
170 | P a g e
Notification of Executive Director If the Privacy Officer determines that a security breach has occurred, the Privacy Officer as soon as
reasonably possible sends an e-mail to the Executive Director indicating that:
A security breach or potential security breach has occurred and whether it is internal or external
A brief description of the nature and extent of the breach, including what information has been
breached
Actions taken by Agent reporting the breach, the Privacy Officer, and the Information Security
Officer, Hosting Provider, Application Service Provider (as applicable) to contain the breach
The police have been notified and why, if applicable.
The Executive Director, in consultation with the Privacy Officer, the Information Security Officer, and the
relevant Agent, reviews the containment measures implemented to determine that the security breach
has been effectively contained. Where further measures are required, the Executive Director works with
the Privacy Officer, Information Security Officer, Hosting Provider and Application Service Provider (as
applicable) to ensure secure containment.
The Executive Director forwards the Privacy Officer ’s notification e-mail and a description of any further
efforts at containment to the CEO as soon as is reasonably possible.
When the breach has been contained and the Executive Director informed, the Privacy Officer enters
the information into the S-18: Log of Information Security Breaches.
The Privacy Officer, in consultation with the Executive Director considers whether to report the breach
to the Information and Privacy Commissioner, taking into account:
The sensitivity of the information disclosed
Whether the disclosed information could be used to commit identity theft
Whether there is a reasonable chance of harm from the disclosure
The number of people affected by the breach
Whether the information was fully recovered without further disclosure
Any legal requirements to provide notification under PHIPA (e.g., Ontario Regulation 329/04 under
the Personal Health Information Protection Act, section 6.3)
Any guidance’s issued by the Information and Privacy Commissioner (e.g., see Guidelines for the
Health Sector – Reporting a Privacy Breach to the IPC, dated September 2019)
Once the decision has been made to inform the Information and Privacy Commissioner, the Privacy
Officer sends an e-mail to the Office of the Information and Privacy Commissioner indicating that:
A security breach has occurred
171 | P a g e
A brief description of the nature and extent of the security breach, including what information
has been breached
Actions taken by the Agent reporting the security breach and the Privacy Officer to contain the
breach
The police have been notified and why (if applicable)
The Privacy Officer informs the Leadership Team and the Communications Lead, in writing, of the
breach, actions taken to date and notification of the Information and Privacy Commissioner (where
applicable).
The Privacy Officer and/or the Information Security Officer enters the information into S-18: Log of
Information Security Breaches.
Notification of Health Information Custodians and Others Whenever personal health information is or is believed to be stolen, lost or accessed by unauthorized
persons and whenever required pursuant to the agreement with the health information custodian or
other organization, the Privacy Officer sends a written notification to the heath information custodians
or organization who provided the information at the first reasonable opportunity in order that they may
notify individuals whose privacy was breached as per section 12(2) of PHIPA. As a prescribed registry,
BORN does not directly notify individuals whose information has been breached.
The written notification will include:
Date of the security breach
A general description of the extent of the breach
Nature of the information that was the subject of the security breach
Date that the security breach was contained and the nature of the containment measures
Steps that have been taken to reduce the possibility of future breaches
Steps the individual can take to further mitigate the risk of harm (where applicable)
Notice that the Information and Privacy Commissioner has been contacted
Name and phone number of contact person within BORN who can answer questions
A statement that individuals have a right to complain to the Information and Privacy
Commission and the contact information for the Commissioner.
The Privacy Officer in consultation with the Executive Director considers sending, at the first reasonable
opportunity, a written notification to the Ministry of Health and Long-Term Care setting out:
Date of the security breach
A general description of the extent of the security breach
172 | P a g e
Nature of the information that was the subject of the security breach
Date that the security breach was contained and the nature of the containment measures
Steps that have been taken to reduce the possibility of future security breaches
Informing Staff The Privacy Officer and/or Information Security Officer meet with BORN staff to inform them of the
nature and extent of the breach, and keeps them informed as the investigation and remediation
proceeds.
For all security breaches, the Privacy Officer e-mails updates to the CHEO Chief Privacy Officer. The
Information Security Officer updates the Privacy and Security Review Committee and the Executive
Director and the CHEO VP of Provincial Programs on a regular basis.
Investigation When the breach has been contained and the Executive Director informed, the Privacy Officer and/or
the Information Security Officer together with the appropriate Agents initiates a comprehensive
investigation, including interviews, document reviews, site visits and inspections. The review will
determine:
Organizations involved in the breach
Cause of the breach
Data elements involved
Number of individuals affected by the breach
Identification of individuals affected by the breach
Any harm that may result from the breach, including:
o Security risk
o Identity theft or fraud
o Hurt, humiliation, damage to reputation
Actions required to prevent future breaches
The Information Security Officer and/or the Privacy Officer completes the comprehensive investigation
within four weeks of the time the breach was reported and prepares a comprehensive report for the
Executive Director, including:
Date of the security breach
Date that the security breach was identified or suspected
173 | P a g e
Nature of the security breach, that is, whether it was determined to be a security breach and
whether it was internal or external
Nature of the information that was the subject matter of the security breach
Facts or events relevant to the security breach
Date that the security breach was contained and the nature of the containment measures
Date that the health information custodian or other organization that disclosed the Personal
Health Information to BORN was notified
Date that the investigation of the security breach was completed
Agent(s) responsible for conducting the investigation
Recommendations for corrective measures arising from the investigation
Agent(s) assigned to address each recommendation and the date each recommendation is
expected to be addressed
The Privacy Officer updates S-18: Log of Information Security Breaches.
The Executive Director reviews the report and assigns Agents to proceed with implementation of the
recommendations approved of by the Executive Director.
Preventing Further Breaches Upon the written approval of the Executive Director, the Agents assigned by the Executive Director:
Establishes and monitors timelines for implementation
Monitors and tracks these activities to ensure that recommendations are implemented within
the stated timelines
The Privacy Officer
Undertakes any required educational campaign within BORN (and associated organizations) as
necessary to educate Agents on any changes to policies and procedures and how to avoid
further breaches
Reviews BORN Breach Management Protocol for potential improvements
Reviews Agreements with Third Parties and Researchers for potential improvements
Takes appropriate action, which may include termination, regarding the individual responsible
for the breach, as per the BORN Confidentiality Agreement. Human resources and accreditation
bodies may be involved, as appropriate
The Information Security Officer provides a written status update and a copy of S-18: Log of Information
Security Breaches to the Privacy and Security Review Committee on a quarterly basis.
174 | P a g e
The Information Security Officer includes a description of the nature and extent of security breaches,
the causes, recommendations and status of the implementation of those recommendations in:
The quarterly report to the Privacy and Security Review Committee
Document Retention The Privacy Officer, maintains
All correspondence related to the security breach
Investigative Report on the Security Breach
Log of Information Security Breaches
Documents are retained in the BORN shared drive.
175 | P a g e
176 | P a g e
S-18: Log of Information Security Breaches The Log of Information Security Breaches is saved in the privacy folder:
GENERAL\Privacy\Logs Populated\Security\S-18 - Log of Security Breaches and Incidents
The following fields are captured in the Log of Information Security Breaches:
Date of information security breach
Date information security breach identified or suspected
Nature of the information security breach
Nature of the Personal Health Information, if any, that was affected and the nature and extent
of the information security breach
Date information security breach contained
Nature of containment methods
Date that health information custodian or other organization that disclosed the information was
notified, if applicable
Date investigation completed
Agent conducting investigation
Recommendations resulting from investigation
Agent responsible for addressing each recommendation
Date each recommendation was or is expected to be addressed
Manner in which each recommendation was or is expected to be addressed
S-19: Application Security The purpose of this policy is to ensure that there are appropriate policies and procedures in place for
application security.
Applications are subject to security assessments based on the following criteria:
New or Major Application Release – will be subject to a full assessment prior to approval and/or release into the production environment.
Third Party or Acquired Web Application – will be subject to full assessment after which it will be bound to policy requirements.
Point Releases – will be subject to an appropriate assessment level based on the risk of the changes in the application functionality and/or architecture.
Patch Releases – will be subject to an appropriate assessment level based on the risk of the changes to the application functionality and/or architecture.
Emergency Releases – An emergency release will be allowed to forgo security assessments and carry the assumed risk until such time that a proper assessment can be carried out. Emergency releases will be designated as such by the Information Security Officer or their designate.
All security issues that are discovered during assessments must be mitigated based upon the following
risk levels. The Risk Levels are based on the OWASP Risk Rating.
Methodology. Remediation validation testing will be required to validate fix and/or mitigation strategies
for any discovered issues of Medium risk level or greater.
High – Any high risk issue must be fixed immediately or other mitigation strategies must be put in place to limit exposure before deployment. Applications with high risk issues are subject to being taken off-line or denied release into the production environment.
Medium – Medium risk issues should be reviewed to determine what is required to mitigate and scheduled accordingly. Applications with medium risk issues may be taken off-line or denied release into the production environment based on the number of issues and if multiple issues increase the risk to an unacceptable level. Issues should be fixed in a patch/point release unless other mitigation strategies will limit exposure.
Low – Issue should be reviewed to determine what is required to correct the issue and scheduled accordingly.
All development must adhere to an industry standard framework of security requirements and controls
that focus on normalizing the functional and non-functional security controls required when designing,
developing and testing modern web applications. An example of such a framework is “The Open Web
Application Security Project (OWASP)” (https://www.owasp.org)
All development must include steps to check for the following vulnerabilities during the development of
any Deliverables:
Injection vulnerability prevention
Cross-Site Scripting (XSS)
177 | P a g e
Broken Authentication and Session Management
Insecure Direct Object References
Cross-Site Request Forgery (CSRF)
Security Misconfiguration
Insecure Cryptographic Storage
Failure to Restrict URL Access
Insufficient Transport Layer Protection
Un-validated Redirects and Forwards
Security administration of web applications must include, but not limited to, the following requirements:
User input data must first be validated before it is processed by the application.
User input validation must include string length and meta character control.
Verify user supplied data does not contain commands or queries.
Application interfaces must be coded to prevent buffer overflows.
Applications must prevent users from directly accessing internal objects, API’s, files, and databases. The application must interact on behalf of the user.
Account credentials and session tokens must be adequately secured.
Application leakage of information, such as configurations, logs, internal working, etc., must be avoided.
Responsibility Information Security Officer, Senior Technical Architect
Procedure Procedures are found in the corresponding individual policies as above.
178 | P a g e
S-20: Encryption & Key Management The purpose of this policy is to support business processes and technical measures implemented, for the
management of BORN’s cryptographic keys.
Key management procedures must ensure that authorized users can access and decrypt all encrypted data
using controls that meet operational needs and comply with data retention requirements. BORN key
management systems are characterized by the following security precautions:
BORN uses procedural controls to enforce the concepts of least privilege and separation of duties
for personnel (per NIST SP800-53 guidelines). These controls apply to persons involved in
encryption key management or who have access to security-relevant encryption key facilities and
processes, including Certificate Authority (CA) and Registration Authority (RA), and/or contractor
personnel.
The Information Security Officer will verify backup storage for Key passwords, Files, and related
backup configuration data to avoid single point of failure and ensure access to encrypted data.
To ensure separation of duties and two person control, the Information Security Officer is
responsible for encryption key management functions.
o Key management roles are only to be held by BORN Agents and are subject to BORN
policy P-08: Limiting Agent Access to and Use of Personal Health Information
o The Information Security Officer or their delegate will verify the subject’s identity.
o Background checks and clearance procedures required for BORN agents holding a Key
Management role
o Complete regular annual training on key management requirements and procedures
o Sanctions against personnel for unauthorized actions, unauthorized use of authority,
and unauthorized use of BORN systems, may be up to and including termination of
employment. A violation of this policy by a temporary worker, contractor or vendor may
result in the termination of their contract or assignment with BORN. Actions are further
detailed in BORN policy HR-11: Discipline and Corrective Action
Keys in storage and transit must be encrypted
Private keys must be kept confidential
The Information Security Officer conducts regular quarterly audit trail reviews
The Information Security Officer or their delegate shall ensure:
• Decryption keys are not associated with user accounts
• Documentation and procedures exist to protect keys used to secure stored Confidential
Information or PHI against disclosure and misuse
179 | P a g e
• Restrict access to cryptographic keys to the fewest number of custodians necessary.
• Cryptographic keys are stored in the Azure Key Vault
• Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as
deemed necessary when the integrity of the key has been weakened or keys are suspected of
being compromised
Note: If retired or replaced cryptographic keys need to be retained, these keys must be securely
archived. Archived cryptographic keys should only be used for decryption/verification purposes.
Key Generation BORN must be able to manage its own cryptographic keys. Keys must be rotated every 90 days.
BORN must be able to perform the following in the Azure environment:
Create or import a key or secret
Revoke or delete a key or secret
Authorize users or applications to manage or use keys and secrets
Configure key usage (for example, sign or encrypt)
Monitor key usage
Key Management Roles This section defines the enterprise Key Management roles required for deploying, operating, and
maintaining the BORN encryption keys.
Key Management Governing Body The Key Management Governing Body is responsible for reviewing and authorizing the Key Owner role.
This governing body is made up of the BORN Privacy and Security committee which reviews the assigned
Key Owner roles and authorized users.
Key Owner The Key Owner is responsible for the overall security of the encryption keys. This role is responsible for
authorizing Key Managers and is held by the BORN Information Security Officer. The Key Owner is also
responsible for working with the data owners during such events as key compromises or other sensitive
situations which may impact the integrity or security of the sensitive data. The Key Owner’s duties
include:
• Authorization and creation the Key Manager role
• Authorize key generation and revocation events
• Liaise and communicate with Data Owners during key compromises or other sensitive events
which may jeopardize the security and/or integrity of data or systems.
180 | P a g e
Key Manager The Key Manager oversees the security, access, usage and handling of any encryption keys or
cryptographic device during its entire life cycle and to ensure that all such activities are in compliance
with the BORN Encryption and Key Management Policy. The Key Manager’s responsibilities include but
are not limited:
• Create the user login and password
• Create tokens
• Write device keys
• Create key sets and keys
• Import keys
• Export keys
• Key creation
Key Auditor The Key Auditor plays a security role to ensure that the Encryption and Key Management Policy is being
upheld. This includes the review of all administrative functions related to the creation and maintenance
of all users of the Key Management solution. It all also includes any user or system usage of
cryptographic keys.
Note: There cannot be a ranking relationship between Key Mangers, Key Owner or Key Auditors.
Key Storage Secrets and keys must be safeguarded using industry-standard algorithms, key lengths, and hardware
security modules (HSMs). The HSMs used must be Federal Information Processing Standards (FIPS) 140-
2 Level 2 validated.
Access to a key vault requires proper authentication and authorization before a caller (user or
application) can get access. Authentication establishes the identity of the caller, while authorization
determines the operations that they are allowed to perform.
Authentication is done via Azure Active Directory. Authorization may be done via role-based access
control (RBAC) or Key Vault access policy. RBAC is used when dealing with the management of the vaults
and key vault access policy is used when attempting to access data stored in a vault.
Azure Key Vaults may be either software- or hardware-HSM protected.
Auditing The Key management system shall be audited on a regular basis to ensure that the practices continue to
effectively support the Encryption and Key Management Policy.
The actions of the personnel that use, operate and maintain the key management systems are reviewed
by the Key Auditor to verify that they continue to follow established security procedures.
Unless otherwise noted, audits occur on a quarterly basis.
181 | P a g e
182 | P a g e
Replacement of Known or Suspected Compromised Keys If a key is compromised, or is known by unauthorized parties the Key Owner must be immediately
informed.
Unauthorized access to system keys may occur when:
• Audit logs reveal inappropriate use, such as exporting of system keys without proper
authorization (which may be tracked through audit logs and change request tickets)
• Evidence of physical tampering with the system
• Security issues prompt an audit due to physical compromise of a key component (e.g. a key
component is missing) by an internal or external third party
The Key Owner must then document the incident and perform the following tasks:
• Document the incident including; date and time of compromise, means of compromise, as well
as data, systems, and users affected,
• Follow the appropriate procedures to revoke the compromised key(s)
• Inform the BORN Privacy Officer of the incident
• Authorize the Key Manager(s) to securely issue the new keys
Responsibility Information Security Officer
Procedure Specific procedures for managing encryption keys in Azure are found in the Microsoft Azure
documentation (https://docs.microsoft.com/en-us/azure/storage/common/storage-encryption-keys-
portal).
S-21: Roles Based Access Controls for the Azure Environment Role-based access control (RBAC) restricts access to the Azure environment based on a person's role
within BORN. RBAC refer to the levels of access that employees/agents have to the Azure environment.
BORN employees/agents are only allowed to access the information and systems necessary to
effectively perform their job duties. Access is based on several factors, such as authority, responsibility,
and job competency. In addition, access to resources can be limited to specific tasks such as the ability
to view, create, or modify user accounts.
Azure Roles The following Azure roles will be utilized in the managing of the BORN Azure environment: Contributor;
Owner; VM Contributor; Reader; and Global Administrator.
Owner - Has full access to all resources including the right to delegate access to others
Contributor - Can create and manage all types of Azure resources but cannot grant access to others
Reader - Can view existing Azure resources
Virtual Machine Contributor - Can manage virtual machines, but not access them or the virtual network
or storage account they are connected to
Administrator - Can manage user access to Azure resources
Other roles may be added as BORN expands its functionality.
Segregation of Duties In general, the following duties are considered incompatible and should be performed by separate
individuals. No one person should:
Provide development services to BORN
Have read and write access to BORN’s databases that store PHI
Manage the Azure Key Vault
Manage BORN’s encryption keys
Administer/manage the BORN Azure environment
Administer/manage BORN assets in the Azure environment
Staff/Contractor Onboarding All Agents with access to the BORN Azure environment must:
Undergo a criminal background check
Sign a non-disclosure/confidentiality agreement to comply with the privacy and security policies,
practices and procedures
183 | P a g e
Encryption Key Managers In addition to the requirements in policy S-20: Encryption & Key Management, all key managers must
be BORN agents.
Staff/Contractor Termination BORN must be immediately notified when an Authorized Person no longer requires or is no longer
authorized to have access to or use of the BORN Azure environment.
Responsibility Information Security Officer
Procedure Procedures are found in the corresponding individual policies as above.
184 | P a g e
PART 3: Human Resources Policies and Procedures
HR-01 and HR-03: Privacy and Security Training and Awareness The purpose of this policy is to ensure that Agents are provided with initial privacy and security
orientation as well as ongoing privacy and security training.
Agents accessing Personal Health Information must complete an initial privacy and security orientation
prior to being given access to Personal Health Information.
All Agents must attend annual privacy and security training and additional training as required by the
Privacy Officer.
Responsibility Privacy Officer
Procedure
Initial Privacy and Security Orientation Hiring managers are required to inform Human Resources and the Privacy Officer via e-mail one week in
advance of the starting date of new employees and contractors. The e-mail must contain the name of
the new Agent or contractor, start date and copy of the job description, contract, or job responsibilities.
The Human Resources agent arranges for an intake meeting to review anticipated access and training
needs for all new Agents. The Human Resources agent also arranges the initial privacy and security
orientation with the Privacy Officer.
The Privacy Officer prepares the training materials and delivers the initial privacy and security
orientation. The Privacy Officer works closely with the Information Security Officer in the development
of the training materials and in delivery of the training.
The content of the initial privacy and security awareness training includes:
A description of the status of BORN as a prescribed registry under PHIPA and the duties and
responsibilities that arise as a result of this status to protect the privacy and security of Personal
Health Information
A description of the nature of the Personal Health Information collected as determined by the
Data Holdings Committee, and the health information custodians from whom this information is
typically collected
An explanation of the purposes for which Personal Health Information is collected and used and
how this collection and use is permitted by PHIPA and its regulation
Limitations placed on access to and use of Personal Health Information based on the “need to
know” principle
185 | P a g e
A description of the procedure that must be followed in the event that an Agent is requested to
disclose Personal Health Information
An overview of BORN privacy and security policies and procedures and the obligations for
Agents arising from these policies and procedures
The consequences for Agents of breaching BORN privacy or security policies and procedures
An explanation of the privacy and security program, including the key activities of the program
and the role of the Privacy Officer
The administrative, technical and physical safeguards implemented by BORN to protect Personal
Health Information against theft, loss and unauthorized use or disclosure and to protect records
of Personal Health Information against unauthorized copying, modification or disposal
The duties and responsibilities of Agents in implementing the administrative, technical and
physical safeguards put in place by BORN, including the Information Security Officer, the Data
Request and Research Coordinator, the System Administrator, the Hosting Provider, and the
Privacy and Security Review Committee
An explanation of the P-29: Privacy Breach Management and S-17 Security Breach
Management and the duties and responsibilities imposed on Agents to identify, report, contain,
and participate in the investigation and remediation of information privacy and security
breaches
A discussion of the nature and purpose of the Confidentiality Agreement that Agents must
execute, and the key provisions of the Confidentiality Agreement
Ongoing Privacy and Security Training Ongoing privacy and security training is formalized and standardized and includes:
Role-based training (within two weeks of start date) to ensure that Agents understand how to
apply the privacy and security policies and procedures in their day-to-day employment,
contractual or other responsibilities
New privacy and security policies and procedures and significant amendments to existing
privacy and security policies and procedures
Privacy/security training updates resulting from privacy impact assessments, investigations of
breaches and complaints, and privacy/security audits including threat and risk assessments,
security reviews or assessments, vulnerability assessments, penetration testing, ethical hacks
and reviews of system control and audit logs.
Agent attendance at ongoing privacy and security training is tracked by BORN Human Resources and
entered by the Privacy Officer into HR-02 and HR-04: Log of Attendance at Privacy and Security
Training.
186 | P a g e
187 | P a g e
The Privacy Officer maintains the Log of Privacy and Security Training which includes:
Name of the Agent
Date the Agent attended the initial privacy and security orientation
Dates that the Agent attended ongoing privacy and security training
The Privacy Officer:
Informs the Agent’s supervisor via e-mail when the initial/annual training has been completed
Monitors the Log of Privacy and Security Training on a monthly basis to ensure that all Agents
receive required training within timeframes
Sends a reminder to Agents, contractors, and their supervisors two weeks prior to the renewal
date for annual training (and for the annual signing of the Confidentiality Agreement which is
completed at the annual training session)
Informs the supervisor via e-mail if the Agent or contractor has not attended annual or required
training sessions by the renewal date
Informs the supervisor, with a copy to the Executive Director, if the annual or required training
has not been completed within one month of the renewal date
Removes Agent(s) name(s) from the Log of Privacy and Security Training upon receiving notice
of termination, as per
P-08: Limiting Agent Access to and Use of Personal Health Information
The Privacy Officer and the Information Security Officer are each required to attend a minimum of one
external privacy/security training session each year, as approved by the Executive Director of BORN
Ontario. Their attendance is entered into the Log of Privacy and Security Training by the Privacy Officer
and signed off by the Executive Director.
All Agents are required to attend an annual BORN-hosted Privacy and Security workshop.
At the Privacy and Security workshop, the Privacy Officer raises awareness of the privacy and security
program and actively fosters a culture of privacy by:
Promoting open lines of communication with the Leadership Team and with Agents
Posting to the BORN shared drive site all policies and procedures, directives, changes to PHIPA
and its regulation, orders or guidelines issued by the Information and Privacy Commissioner, and
upcoming privacy and security conferences
Providing notice of the schedule of internal privacy and security training sessions, and highlights,
recommendations and status updates on privacy and security audits, privacy or security
breaches and/or complaints
Providing quarterly reports to the Privacy and Security Review Committee and the Leadership
Team
Building strong relationships with other prescribed registries and prescribed entities in the
province
Document Retention The Privacy Officer is responsible for securely maintaining:
Log of Attendance at Privacy and Security Training
Attendance sheets from training sessions
Correspondence with Agents and supervisors
Training materials
Documents are retained in the BORN shared drive.
188 | P a g e
HR-02 and HR-04: Log of Attendance at Privacy and Security Training The Log of Attendance at Privacy and Security Training is saved on the BORN shared drive:
GENERAL\Privacy\Logs Populated\Human Resources
The following fields are captured in the Log of Attendance at Privacy and Security Training:
Last name
First name
Date attended initial privacy orientation
Dates of privacy and security training sessions
Comments
189 | P a g e
HR-05: Execution of Confidentiality Agreement by Agents The purpose of this policy is to ensure that BORN has all Agents sign a Confidentiality Agreement to
protect the privacy, security and confidentiality of the information for which BORN is responsible.
BORN undertakes to ensure all Agents are aware of and confirm their obligations to protect the privacy
and confidentiality of the Personal Health Information for which BORN is responsible.
To this end, Agents execute Confidentiality Agreements at the commencement of their employment,
contractual or other relationship with BORN and prior to being given access to Personal Health
Information.
Confidentiality Agreements are renewed annually on completion of annual privacy and security
training.
Responsibility Privacy Officer
Procedure Each BORN supervisor or designate is required to inform the Privacy Officer via e-mail one week in
advance of the starting date for new employees and contractors. The e-mail must contain the name of
the new Agent or contractor, start date and copy of the job description, contract, or job responsibilities.
The Privacy Officer e-mails the following information to the supervisor:
Date of the initial training
HR-06: Template Confidentiality Agreement will be signed on that date
Reminder that Agent access to Personal Health Information is not permitted until initial training
is completed and the Confidentiality Agreement has been signed
The Privacy Officer informs the supervisor via e-mail when the training has been completed and the
Confidentiality Agreement signed.
The Privacy Officer maintains HR-07: Log of Executed Confidentiality Agreements with Agents which
contains:
Name of Agent
Date of commencement of employment, contractual or other relationship with BORN
Date that Confidentiality Agreement was initially executed
Date(s) on which Confidentiality Agreement was renewed
The Privacy Officer monitors the log and sends reminders to Agents, contractors and their supervisors as
follows:
190 | P a g e
For the initial Confidentiality Agreement: immediately upon becoming aware of a new
employee who does not have a signed Confidentiality Agreement
For the annual re-acknowledgement of the Confidentiality Agreement: two weeks prior to the
renewal date for the annual signing or re-acknowledgement of the Confidentiality Agreement
and for annual training.
If the Agent or contractor has not renewed the Confidentiality Agreement (or attended training
sessions) by the renewal date, the Privacy Officer informs the supervisor. If the Confidentiality
Agreement and annual training have not been completed within one month of the renewal date, the
Privacy Officer informs the supervisor, with a copy to the Executive Director.
Document Retention The Privacy Officer securely maintains:
Signed Confidentiality Agreements
Log of Confidentiality Agreements
Correspondence with Agents and supervisors
Documents are retained in the BORN shared drive.
191 | P a g e
HR-06: Template Confidentiality Agreement with Agents The approved Confidentiality Agreement template is saved in the privacy folder:
• GENERAL\Privacy\Agreements\Confidentiality Agreement\Template
192 | P a g e
HR-07: Log of Executed Confidentiality Agreements with Agents The Log of Executed Confidentiality Agreements with Agents is saved on the BORN shared drive:
GENERAL\Privacy\Logs Populated\Human Resources
The following fields are captured in the Log of Executed Confidentiality Agreements with Agents:
Agent last name
Agent first name
Date of commencement of employment or contractual or other relationship
Date Confidentiality Agreement initially executed
Dates Confidentiality Agreement renewed
193 | P a g e
HR-08 and HR-09: Job Description for Position(s) Delegated Day-to-Day Authority to Manage the Privacy and Security Programs
See P-1: Privacy Policy in Respect of CHEO’s Status as a Prescribed Person – Additional Roles and
Responsibilities. Specific job descriptions are maintained by BORN separate from this Plan.
194 | P a g e
HR-10: Termination or Cessation of the Employment or Contractual Relationship To identify the BORN policy and procedures related to termination or cessation of employment or
contractual relationship.
All BORN policies for voluntary and involuntary termination or cessation of the employment or
contractual relationship are in alignment with Children’s Hospital of Eastern Ontario (CHEO) Human
Resources policies and requirements, and are in full compliance with current employment legislation.
Agents must securely return all property on or before the date of termination of employment. Property
includes records of Personal Health Information, identification cards, access cards, credit cards,
computer equipment, books, materials, cell phones and mobile devices, keys and any other CHEO or
BORN owned items as identified
Responsibility Privacy Officer
Procedure Agents and their supervisors are required to notify the Executive Director and the Privacy Officer of the
termination of an employment or contractual relationship two weeks in advance, if possible. The
notification must be via e-mail and contain the following information:
Name of Agent
Termination date
Reasons for termination
Within three days, the Executive Director, or delegate, forwards the name of the Agent and the
termination date to:
CHEO Human Resources who processes termination in payroll system
Security for termination of access to the building
Information Security Officer who arranges for the withdrawal of access to Personal Health
Information on termination date and updates P-09: Log of Agents Granted Approval to
Access/Use/Disclose Personal Health Information
Within three days, the Executive Director, or delegate, e-mails to the Agent (with copy to the supervisor)
a request for the secure return to the Executive Director all property on or before the termination date.
The Executive Director, or delegate, includes a list of property to be returned and indicates that payroll
will be withheld if the specified property is not returned on or before termination date. As well, the
Executive Director, or delegate, reminds the Agent of the confidentiality requirements contained in the
signed Confidentiality Agreement.
195 | P a g e
When the Agent returns the property, the Executive Director, or delegate, checks the list of property
and both the Agent and the Executive Director, or delegate, sign the list to acknowledge receipt. The
Executive Director retains the signed list in the Agent’s employee file.
Secure return of physical property (as defined in the policy to this procedure):
Done in person by the Agent to the Executive Director or delegate
Secure return of records of Personal Health Information:
Agents are not expected to have any Personal Health Information in their possession. Personal
Health Information, as per the Agent Confidentiality Agreement and policy S-05: Retention of
Records of Personal Health Information is retained only on the CHEO network. BORN does not
permit paper records of Personal Health Information. The Executive Director or delegate verifies
verbally with the Agent that they do not have any Personal Health Information to return and
that they have abided by the obligations of an Agent with respect to Personal Health
Information.
If the Agent does not return the property on or before termination date, the Executive Director, or
delegate, sends an e-mail to the Agent requesting return of the property.
If the property is not returned within one month from the date of the e-mail the Executive Director e-
mails a registered letter to the Agent requesting the return of the property and indicating the potential
for legal action if the property is not returned within one month. If the property has not been returned
within one month from the date the registered letter was mailed, a second registered letter will be
mailed. If within one month there has been no response, the Executive Director consults with the CHEO
Human Resources regarding legal action.
Where an employee is terminated for cause:
The Executive Director notifies the System Administrator to ensure access to Personal Health
Information is removed immediately
The Executive Director ensures the immediate return of any sensitive assets
Document Retention The Privacy Officer securely retains all correspondence and the employee’s file is securely maintained by
the Executive Director.
The Information Security Officer securely retains
196 | P a g e
P-09: Log of Agents Granted Approval to Access/Use/Disclose Personal Health Information.
Documents are retained in the BORN shared drive.
197 | P a g e
HR-11: Discipline and Corrective Action To purpose of this policy is to identify the policy and procedures for employee disciplinary and
corrective action in respect of Personal Health Information.
Agents must execute a BORN Confidentiality Agreement in accordance with HR-06: Template
Confidentiality Agreement with Agents at the commencement of their employment, contractual or
other relationship with BORN and prior to being given access to Personal Health Information.
The BORN Confidentiality Agreement states that a breach of the terms of the Confidentially Agreement,
BORN policies and procedures, and/or the provisions of PHIPA may result in disciplinary action which
can include termination of employment and/or legal action.
Whistle Blower Protection Agents are protected from actions taken against them simply for reporting breaches or suspected
breaches unless those reports are made in a frivolous or vexatious manner.
Responsibility Privacy Officer
Procedure The Privacy Officer investigates all privacy and security related disciplinary matters.
In undertaking the investigation to ascertain the facts, the Privacy Officer:
Interviews all individuals who have knowledge of the breach incident
Interviews the Agent involved and his/her supervisor jointly
Reviews applicable documentation and records
Based on an assessment of the facts, the Privacy Officer meets with the Agent and his supervisor jointly
to report on findings and to indicate that disciplinary action is being applied. As soon as reasonably
possible after this meeting the Privacy Officer sends a written letter to the Agent (with copy to the
supervisor) documenting the date and time of the follow-up meeting, a brief statement of the issue, the
salient facts of the discussion, and the conclusion reached in the meeting regarding disciplinary action.
The Privacy Officer, in consultation with the Executive Director and CHEO Human Resources where
applicable, determines the type of disciplinary action appropriate to the issue:
Oral Warning and/or additional privacy and security training as appropriate for minor first
offences. It should be made clear to the Agent that an oral warning is the first step in a
progressive disciplinary process.
Written Warning and/or additional privacy and security training, as appropriate for a more
serious offence or after an employee has received an oral warning. The written warning:
o Identifies that the letter is a disciplinary warning
198 | P a g e
o Describes the situation which prompted the warning
o Indicates why the behavior merits a warning
o States that should there be a repetition of the behavior, additional corrective action will
be taken which could result in termination
Suspension without pay and/or additional privacy and security training, as appropriate for
serious offences or after an employee has received an oral and written warning. The Agent is
notified in writing and the letter outlines the reasons for the suspension, and the dates of the
suspension.
Termination of employment as a penalty for a very serious offence or the culmination of the
progressive discipline process. The Privacy Officer and the supervisor hold a pre-termination
meeting with the Agent to review the past record and/or the circumstances leading to the
termination.
The Privacy Officer documents in the Agent’s file:
Date and time of meeting(s) with the Agent
Description of the issue
Salient facts related to any discussions with the Agent
Disciplinary action taken
The Privacy Officer forwards a copy of the Agent’s file to CHEO Human Resources where applicable.
Document Retention The Privacy Officer securely retains:
All correspondence with Agent and supervisor
All notes related to the investigation of the issue
Documents are retained in the BORN shared drive.
199 | P a g e
PART 4: Organizational and Other Policies and Procedures
O-01 and O-02: Privacy and Security Governance and Accountability Framework BORN Ontario is a Provincial Program, funded through the Children’s Hospital of Eastern Ontario (CHEO)
and as such, has direct accountability through CHEO’s accountability structure.
CHEO’s CEO is ultimately accountable for ensuring that BORN and its Agents complies with PHIPA and its
regulation, as well as its privacy policies, procedures and practices implemented.
As illustrated in Figure 1 of P-01: Privacy Policy in Respect of CHEO’s Status as a Prescribed Person, the
CEO delegates responsibility for ensuring compliance with PHIPA and its regulation to the Vice President
of Provincial Programs and the CIO. The Vice President of Provincial Programs and the CIO delegates day
to day responsibility for ensuring compliance with PHIPA and its regulation to BORN’s Executive
Director.
Each year the Vice President ((i.e., the person responsible for Provincial Programs -- CHEO VP Child
Development and Community Services)) of Provincial Programs and the CIO will be supplied with a
written report by the Executive Director addressing the initiatives undertaken by the privacy and
security programs including training, development of policies, procedures, audits undertaken, privacy
impact assessments, threat risk assessments, privacy and security breaches, privacy complaints that
were investigated, and the status of any recommendations that were made from the investigations. The
Vice President of Provincial Programs and the CIO will present such findings to a committee of the CHEO
Board of Directors. The Audit and Finance Committee is also briefed in regard to data security matters.
The governance and accountability framework will be communicated to agents of BORN each year by
the Privacy Officer at the annual training session.
200 | P a g e
201 | P a g e
O-03: Terms of Reference for Committees with Roles with Respect to the Privacy Program and/or Security Program As illustrated in Figure 1 of P-01: Privacy Policy in Respect of CHEO’s Status as a Prescribed Person,
there are a number of committees that have been established to provide guidance and advice to BORN’s
Executive Director on matters of privacy, security and the collection, quality and disclosure of data. The
Executive Director also receives guidance from two management teams – the BORN Executive Team and
the BORN Leadership Team.
Privacy and Security Review Committee (PSRC) BORN’s Executive Director receives guidance in managing privacy and security program from the PSRC
which has the mandate to review and approve the necessary elements of BORN’s privacy and security
frameworks that are required for compliance with the Personal Health Information Protection Act, 2004
and its regulation as well as with guidelines for registries issued by the Information and Privacy
Commissioner (IPC). The PSRC is the escalation authority for significant privacy and security risks faced
by BORN. In carrying out this mandate, the PSRC has the following responsibilities:
Developing, reviewing and approving BORN policies and procedures related to privacy and
security. Conducting the annual review of privacy and security policies and procedures in
accordance with the IPC requirements of a registry
Reviewing and approving BORN’s Privacy Audit Plan
Developing a plan for meeting requirements of tri-annual and other IPC reviews
Receiving and validating Privacy Impact Assessments and any other privacy or security audits
Monitor implementation of recommendations from assessments and audits to the extent
appropriate
Reviewing quarterly reports on privacy and security
Reviewing and refining the privacy and security elements of a corporate risk management
framework
Assessing significant privacy and security risks faced by BORN and develop the appropriate risk
management plans
Reviewing and approving BORN’s approach and plan for business continuity and disaster
recovery
Receiving and reviewing reports on penetration testing and security vulnerabilities.
Serving as BORN’s planning and decision-making group in the event of a significant business
continuity issue or disaster.
Receiving reports on privacy and security breaches and privacy complaints, provide guidance on
the appropriate response(s) and monitor
Providing guidance on issues or initiatives that have organization-wide privacy implications
Performing such other duties assigned to it by the Executive Director
Data Holdings Committee (DHC) BORN’s Executive Director receives advice on BORN’s data holdings from the DHC to ensure that the
data that BORN collects is aligned with BORN’s purposes, that BORN collects only the Personal Health
Information (PHI) than is reasonably necessary to meet those purposes and that a current listing and
brief description of BORN’s data holdings is developed and maintained.
PHI Disclosure Committee (PDC) The PDC is responsible for reviewing all requests for record level disclosure of PHI. It also reviews record
level de-identified data disclosure requests. The PHI Disclosure Committee is also responsible for
reviewing any changes to the methods used to de-identify personal health information.
Research Review Committee (RRC) RRC as responsible for reviewing, approving and/or denying requests for the use of Personal Health
Information for Research purposes. It is also responsible for reviewing requests for the disclosure of
Personal Health Information for Research purposes. In cases involving disclosure of Personal Health
Information for Research that has not undergone De-identification (including De-identification through
aggregation) prior to proposed disclosure (if any), the RRC will refer the matter to the PHI Disclosure
Committee with its recommendations.
Data Quality Committee (DQC) BORN is an authoritative source of accurate, trusted, and timely data used to monitor, evaluate, and
plan for the best possible beginnings for lifelong health. The purpose of the DQC is to facilitate the
implementation and refinement of BORN’s data quality framework, including overseeing and assessing
the quality of BORN’s data and developing and implementing plans, processes and tools to enhance data
quality.
BORN Executive Team BORN’s Executive Team carries out the following functions in providing guidance to BORN’s Executive Director:
Guidance on the longer-term strategic direction of BORN, including the development of BORN’s strategic plan
Input and guidance on BORN’s annual plan and budget as well as any Ministry submissions for
funding and ensures sufficient alignment and integration with CHEO’s annual plan and budget
Identification of emerging issues and opportunities for growth
Provides advice to ensure that BORN’s plans and activities are aligned with developments in
Health Care and the direction of the broader public sector including the interests of BORN
stakeholders
Guidance on BORN’s research agenda and how to best use BORN data to facilitate and improve
quality health care
202 | P a g e
Identifies, builds, monitors, and maintain positive and productive relationships with key
organizations and individuals (ambassador role) and support the efforts of the organization to
do so, including any joint work planning
Provide guidance on responding to risks or significant privacy, security or data integrity issues
BORN’s Leadership Team: The Leadership Team oversees BORN projects and cross-BORN initiatives to ensure operational
alignment and the management of project interdependencies, effective risk management, information
sharing, and appropriate staff and stakeholder communication and engagement. In addition to other
duties assigned to it by the Executive Director, the Leadership Team carries the following
responsibilities:
Project Oversight This involves reviewing and approving the initiation of projects (SBARs, project charters), receiving
updates on BORN projects, discussing risks, approving adjustments to the scope, timing, and
deliverables of projects. This also includes allocating resources to the projects – resource management,
providing guidance on staff and stakeholder communication regarding projects, and reviewing and
approving BORN’s project management infrastructure and tools.
Risk Management This involves identifying emerging organizational risks, discussing potential solutions and responses to
risks, identifying corporate risks that need to be elevated to BORN’s Executive Team including any
significant privacy and security risks faced by BORN that are identified by BORN’s Privacy and Security Committee.
Operational Alignment This involves (i) identifying and prioritizing operational areas of risk or gaps in policy, procedure or
process; (ii) reviewing and approving organizational-wide policies, standard operating procedures (SOPs)
and processes not otherwise specifically addressed by other BORH Committees.
Information Sharing This involves sharing relevant information on BORN operations. It also involves identifying opportunities,
challenges and risks and problem solve solutions or approaches.
Staff and Stakeholder Communication and Engagement This involves identifying potential agenda items for BORN staff meetings, contributing to the
development and delivery of agenda material for BORN staff meetings, sharing key messages with BORN
staff as directed by the Leadership Team, and providing guidance and input into the development of
BORN’s Annual Report.
There are Terms of Reference for each of the following:
BORN Privacy and Security Review Committee
BORN Data Holdings Committee
203 | P a g e
BORN PHI Disclosure Committee
Research Review Committee
Data Quality Committee
Master copies of each terms of reference are saved at V:\BORN\~GENERAL\General\Governance\BORN
Committees. Each sets out the membership of the committee, the chair, the mandate and responsibility,
frequency of meeting, whom the committee reports to, the formats of any reports and to whom they
are presented, and the frequency of these reports.
204 | P a g e
O-04: Corporate Risk Management Framework The purpose of this policy is to ensure that BORN has a comprehensive and integrated corporate risk
management framework in place.
BORN implements a corporate risk management framework to identify, assess, mitigate and monitor
risks, including risks that may negatively affect its ability to protect the privacy of individuals whose
Personal Health Information is received and to maintain the confidentiality of that information.
All risks identified through the BORN Privacy & Security policies and procedures will be assessed using
the framework including those identified through audits, PIA’s and breach incidents.
Responsibility Privacy and Security Review Committee
Procedure On an annual basis, the Privacy Officer and the Information Security Officer undertake a process to
identify risks related to BORN’s ability to protect the privacy and confidentiality of the Personal Health
Information in its custody and control.
In identifying risks, the Privacy Officer and the Information Security Officer:
Reviews the security audit reports, including threat risk assessments, vulnerability assessments,
penetration assessments and other security audits
Reviews the privacy audit reports, privacy impact assessments, reports on breach incidents and
complaints
Consults with the Hosting Provider and the Data Request and Research Coordinator and other
Agents and stakeholders, as appropriate
The Privacy Officer and the Information Security Officer reviews risks in the following areas:
Power loss (loss of electrical power supply to the information system)
Communication loss (inability to transfer information to and from the organization)
Data integrity loss (alteration of the data)
Data loss (incomplete restore; system error resulting in data loss; computer virus)
Accidental errors (improper use of information technology resulting in data loss or alteration)
Abuse of access privilege by employees
Natural disasters
Unauthorized system access by outsider
Theft or destruction of computing assets
205 | P a g e
System failure (maintenance or component failure or system crash resulting in down time)
The Privacy Officer and the Information Security Officer develop the corporate risk management
framework which includes:
A description of the review process
Assessment of identified risks
Ranking of identified risks
Rationale for the assessment and ranking
Strategies to address identified risks and rationale for the choice
Rankings are based on
a) Probability of occurrence, and
b) Impact on ability to maintain the security of records of Personal Health Information
A weighted point rating system is used to measure potential risks. Each level of probability and each
impact rating is assigned probability points: high (10), medium (5) or low (1). The weighted risk factor is
level of probability X impact rating.
The Privacy Officer and the Information Security Officer work with subject matter experts as appropriate
in identifying the risks and the strategies to address the risks (risk reduction, risk avoidance, risk coping).
The Privacy Officer forwards the corporate risk management plan to the Privacy and Security Review
Committee for their review and approval.
When the Privacy Officer and the Information Security Officer receives written approval to proceed, the
Leadership Team and/or Executive Director:
Assigns Agents responsibility for implementing risk strategies
Establishes timelines
Monitors implementation
Reports monthly to the Privacy and Security Review Committee on progress
The Privacy Officer monitors the Corporate Risk Register on an on-going basis and as per the Corporate
Risk Register (different risks are subject to different monitoring timelines). Amendments to the
Corporate Risk Register require prior approval of the Privacy and Security Review Committee. The
Corporate Risk Register is a standing item at the monthly meetings of the Privacy and Security Review
Committee.
206 | P a g e
Prior to the commencement of a new project, the Privacy Officer works with the project manager to
develop a risk management plan to identify, document and manage the risks inherent in the project. The
plan must set out:
The risks involved in the project
The costing of the risks as set out in the budget for the project
Who is responsible for what aspects of risk mitigation
Who will report risk status to the Privacy Officer and how often
Recommended Actions for Grades of Risk
Grade Risk Mitigation Actions
10-20 Acceptable risk – no action necessary.
21-40 Acceptable risk – no action necessary but monitor the outcomes.
41-50 Mitigation actions to reduce likelihood and/or impact to a 20. If not possible, eliminate the
risk or identify organizational tolerance for acceptable risk and monitor outcomes closely.
51-80 Mitigation actions to reduce likelihood and/or impact to a grade of at most 30 at a cost up
to the equivalent of a high impact. If not possible, eliminate the risk.
81+ Immediate mitigation actions to reduce grade to at most 80 (consider eliminating risk until
then) with follow-up actions to reduce grade to at most 50. If not possible, eliminate risk.
Document Retention
The Privacy Officer securely maintains the Corporate Risk Register.
Documents are retained in the BORN shared drive.
207 | P a g e
O-05: Corporate Risk Register The Corporate Risk Register is saved on the BORN shared drive:
GENERAL\Privacy\Logs Populated\Organization
The following fields are captured in the Corporate Risk Register:
What is the risk?
o Risk #
o Risk Description
o Identified By
How important is this risk and why
o Risk Likelihood (A) (1-10)
o Risk Severity (B) (1-10)
o Risk Impact (A*B)
How will this risk be addressed? Select one and describe response. Where risk is to be mitigated,
record risk grade as per Recommended Actions for Grades of Risk
o Avoid, Mitigate, Transfer, Accept, Response Description
Date Mitigation Strategy Will be Implemented
Date Mitigation Strategy was Implemented
Agent Assigned to Mitigation Strategy
o Frequency with which agent will report risk status to Privacy Officer or Security Officer
When will this risk be monitored by Privacy Officer or Security Officer?
o Define frequency of monitoring and next monitoring date.
208 | P a g e
O-06: Maintaining a Consolidated Log of Recommendations The purpose of this policy is to ensure that BORN maintains a consolidated log of recommendations.
BORN maintains a consolidated and centralized log of all privacy and security related recommendations.
The log will be updated within a week of recommendations being received, and will be reviewed as
required, at a minimum monthly.
Procedure The Consolidated Log of Recommendations (see O-07: Consolidated Log of Recommendations) contains
recommendations arising from:
Privacy impact assessments
Privacy audits
Security audits, including Threat and Risk Assessments
Investigation of privacy and security breaches and privacy complaints
Investigation of privacy and security issues raised by BORN staff
Recommendations made by the Information and Privacy Commissioner of Ontario that must
be addressed by BORN prior to the next review of its practices and procedures
The Privacy Officer and the Information Security Officer are responsible for the creation and
maintenance of the Consolidated Log of Recommendations.
The Privacy Officer and the Information Security Officer inputs all recommendations from privacy impact
assessments, privacy audits, security audits, investigations of privacy and security breaches and privacy
complaints, concerns raised by staff, and recommendations made by the Information and Privacy
Commissioner.
The Privacy Officer and the Information Security Officer reviews the Consolidated Log of
Recommendations on an on-going basis to ensure that all recommendations are addressed in a timely
manner.
The Privacy Officer and the Information Security Officer forwards the Consolidated Log of
Recommendations to the Privacy and Security Review Committee on a quarterly basis along with the
quarterly report.
Document Retention The Privacy Officer and the Information Security Officer securely maintains the Consolidated Log of
Recommendations as per S-05: Retention of Records of Personal Health Information.
209 | P a g e
O-07: Consolidated Log of Recommendations The Consolidated Log of Recommendations is saved on the BORN shared drive:
GENERAL\Privacy\Logs Populated\Organization
The following fields are captured in the Consolidated Log of Recommendations:
Recommendation
Name and date of document, investigation, audit, review
Manner in which the recommendation is to be addressed
Responsible Agent
Proposed completion date
Actual completion date
Comments
210 | P a g e
O-08: Business Continuity and Disaster Recovery Plan The purpose of this is to ensure the continued availability of the BORN information technology
environment in the event of short and long-term business interruptions and in the event of threats to
the operating capabilities including natural, human, environmental and technical interruptions and
threats.
A consistent unified framework for business continuity planning and plan development shall be
established, documented and adopted to ensure all business continuity plans are consistent in
addressing priorities for testing, maintenance, and information security requirements. Requirements for
business continuity plans include the following:
Defined purpose and scope, aligned with relevant dependencies
Accessible to and understood by those who will use them
Owned by a named person(s) who is responsible for their review, update, and approval
Defined lines of communication, roles, and responsibilities
Detailed recovery procedures, manual work-around, and reference information
Method for plan invocation
Business continuity and security incident response plans shall be subject to testing at planned intervals
or upon significant organizational or environmental changes. Incident response plans shall involve
impacted customers (tenant) and other business relationships that represent critical intra-supply chain
business process dependencies.
Datacenter utilities services and environmental conditions (e.g., water, power, temperature and
humidity controls, telecommunications, and internet connectivity) shall be secured, monitored,
maintained, and tested for continual effectiveness at planned intervals to ensure protection from
unauthorized interception or damage, and designed with automated fail-over or other redundancies in
the event of planned or unplanned disruptions.
The policy is to protect and ensure the continued availability of the BORN information technology
environment in the event of short and long-term business interruptions and in the event of threats to
the operating capabilities including natural, human, environmental and technical interruptions and
threats. Specific policies can be found below in this policy. See also O-08A: Business Continuity Incident
The BORN business continuity and disaster recovery responsibilities and procedures are supported
jointly by the Application Service Provider, CHEO IT, and BORN staff. BORN’s Business Continuity and Disaster Recovery Plan procedures are documented as follows:
1. BORN Disaster Recovery Plan
2. BORN: Downtime Standard Operating Procedure
3. BORN Emergency Phone Tree Process
4. BORN Emergency Contact log
211 | P a g e
Business continuity and disaster recovery includes the following steps:
1. Notification of the interruption or threat.
2. Assessment of the severity of the interruption or threat.
3. Activation of the business continuity and disaster recovery plan.
4. Recovery of personal health information or access to personal health information.
Documentation of steps 1 -4 in a BORN Business Continuity Incident Summary Report
Responsibility Information Security Officer
Procedure Note: The BORN Information System is not a critical system to end users and as such, BORN has a
reasonable tolerance for down time.
Notification of an interruption or threat:
o Notification and timeframe of notification from BORN to staff, stakeholders and end
users of the BORN Information System is documented in the BORN Downtime SOP
(Scheduled Outage section, Unscheduled Outage section, Notification e-mail section)
which sets out the communication requirements from the BORN System Administrator.
o Contact lists to support notification from the BORN System Administrator to all
stakeholders including BORN staff and end users of the BORN Information System are
documented in the BORN Downtime SOP (Appendix Contact Information), maintained
by the BORN System Administrator, and the BORN Emergency Contact log, maintained
by the BORN Administrative Assistant.
o Notification and timeframe of notification from the BORN Hosting Provider to BORN is
documented in the BORN Disaster Recovery Plan (Communication Procedure for
Unscheduled Downtime) that sets out the communication link between the Hosting
Provider and BORN (roles and contact information).
o Contact lists to support notification from the BORN Hosting Provider to BORN are
documented in the BORN Disaster Recovery Plan
Documentation of the interruption or threat is outlined as follows:
o Documentation of the outage itself is mandated in the BORN Disaster Recovery Plan
where all outages are ultimately documented by the BORN Hosting Provider in a root
cause analysis SBAR (situation, background, assessment, recommendation) and in a
report used for assessment, review and risk mitigation planning
o On-going documentation of the outage is documented in the BORN Downtime SOP
which includes mandatory e-mail fields/contents.
212 | P a g e
Assessment of the severity of the interruption or threat is set out in the BORN Disaster
Recovery Plan (Assess Phase section) which includes:
o The department responsible for assessment
o The criteria on which an assessment is based
o The time frame by which the assessment must be completed (one hour)
o Any applicable initial and detailed damage assessment exercises and documentation of
these exercises, which includes technical and physical infrastructure and business
processes
o The persons or organizations that must be consulted
Activation of the business continuity and disaster recovery work for the BORN Hosting Provider
is set out in the BORN Disaster Recovery Plan (Contain Phase section)
Recovery of Personal Health Information or access to the personal health information is the
responsibility of the BORN Hosting Provider and is set out in the BORN Disaster Recovery Plan
(Recovery Phase section)
o Communication of the recovery from the BORN Hosting Provider to BORN is the
responsibility of the BORN Hosting Provider and set out in the BORN Disaster Recovery
Plan.
o Communication of the recovery from BORN to staff, stakeholders and end users is the
responsibility of BORN (BORN System Administrator) and is included in the BORN
Downtime SOP (Completed Outage section; involves an e-mail from the BORN System
Administrator confirming that all functionality has been restored).
o In support of the recovery operations, the BORN System Administrator and BORN
Hosting Provider maintain detailed inventory of all critical applications and business
functions and of all hardware and software, software licenses, recovery media,
equipment, system network diagrams, hardware configurations, software configuration
settings, configuration settings for database systems and network settings for firewalls,
routers, domain name servers, email servers and the like. The BORN System
Administrator works with the BORN Hosting Provider and the vendor of the BORN
Information System to ensure the inventory is up-to-date. Each is responsible for
maintaining their own list and providing updates to the BORN System Administrator as
required.
Testing, maintenance and assessment of this policy and procedure with respect to personal health
information
213 | P a g e
The BORN Information Security Officer / Technical Lead is responsible for ensuring all business
continuity and disaster recovery planning is tested, maintained and assessed, and that any amendments
needed as a result of testing are forwarded to the BORN Privacy Officer. The BORN Information Security
Officer /Technical Lead is supported in this work by the BORN Hosting Provider.
Testing, maintenance and assessment is performed as follows:
Restoring records of Personal Health Information: testing and maintenance of the ability to restore
records of personal health information is documented in BORN policy S-17: Back-up and Recovery of
Records of Personal Health Information, which outlines a mandatory bi-annual recovery test to ensure
data protection remains adequate.
• Testing of BORN policy O-08: Business Continuity and Disaster Recovery Plan: testing and maintenance of the policy is performed via annual policy review as set out in BORN Policy P-02 and S-02: Triennial Review of Privacy and Security Policies and Procedures
Amending the plan based on testing, maintenance and assessment is performed as follows:
• Amendments and associated approvals resulting from the testing, maintenance and assessment of the plan are forwarded by the BORN Technical Lead to the BORN Privacy Officer. Approval of amendments proceed as per BORN Policy P-02 and S-02: Triennial Review of Privacy and Security Policies and Procedures where the Privacy Officer obtains final approval from the BORN Privacy and Security Review Committee
Agent Awareness Agents are required to read this policy as part of their initial privacy training. All BORN Agents are
required to review this policy, including any amendments, as part of the annual acknowledgement of
the BORN Confidentiality Agreement.
Document Retention The following list sets out required documentation, responsible BORN Agent, and storage location:
Document name Responsible Agent Location
BORN Disaster Recovery
Plan
BORN Technical
Lead
Source file:
V:\BORN\~GENERAL\General\Standard Operating
Procedure (SOP)
BORN Managed Service
Agreement
Information
Security Officer
V:\Financial and Contracts\Contracts and
Agreements\4- CHEO Agreements\CHEO –
Hosting -“BORN Hosting Services Agreement
(2015-18 Renewal) FINAL - Fully Signed”
214 | P a g e
BORN: Downtime SOP Information
Security Officer
V:\BORN\~GENERAL\General\Standard Operating
Procedure (SOP)
BORN Emergency Phone
Tree Process
BORN Senior
Administrative
Assistant
V:\BORN\Admin - Confidential\Emergency
BORN Emergency
Contact log
BORN Senior
Administrative
Assistant
V:\BORN\Admin - Confidential\Emergency
BORN Business
Continuity Incident
Summary Report
Information
Security Officer
All summary reports stored at
V:\BORN\~GENERAL\Privacy\BORN Disaster
Recovery and Business Continuity\BORN Business
Continuity Incident Summary Report
O-08A: Business Continuity Incident Summary Report BORN business continuity and disaster recovery incident summary reports are saved on the BORN
shared drive:
GENERAL\Privacy\BORN Disaster Recovery and Business Continuity\BORN Business Continuity Incident Summary Reports
Business continuity and disaster recovery incident summary reports contain the following fields:
1. Notification of the interruption or threat
2. Assessment of the severity of the interruption or threat
3. Activation of the business continuity and disaster recovery plan
4. Recovery of personal health information or access to personal health information
215 | P a g e
