Posted by Dr. Wael Hassan on

PHIPA Compliance Meets Innovation

Ontario’s Personal Health Information Protection Act (PHIPA) governs healthcare providers including general practitioners and group practices, long-term care facilities and community care access centres, hospitals, psychiatric facilities, and independent health facilities. PHIPA regulates the collection, use and disclosure of personal health information, and sets out individual rights with regard to personal health information (e.g., consent, access). Healthcare providers are responsible to demonstrate compliance with PHIPA, particularly in the context of new initiatives involving personal health information.

PHIPA was most recently revised in 2016, with changes aiming to:

  • Increase accountability and transparency by making it mandatory to report privacy breaches to the Information and Privacy Commissioner and, in certain cases, to relevant regulatory colleges
  • Strengthen the process for prosecuting offenses under PHIPA by removing the requirement that prosecutions must be commenced within six months of the alleged privacy breach
  • Further discourage “snooping” into patient records by doubling the fines for offenses under PHIPA from $50,000 to $100,000 for individuals and from $250,000 to $500,000 for the organization
  • Clarify the authority under which healthcare providers may collect, use and disclose personal health information in electronic health records

Besides penalties, PHIPA violations including privacy breaches entail serious costs related to discovery and containment, investigation, remediation expenses, legal fees, and loss of public confidence. It is essential that patients feel that they can trust their healthcare providers to protect their privacy. Ensuring legal compliance is both an important responsibility and wise investment for healthcare providers.

The drive to unlock new insights from health data through research and analysis can sometimes push the boundaries of privacy regulations. A KI Design privacy review can help you understand and manage the privacy risks arising from secondary uses of data.

Our healthcare privacy compliance services assess organizational practices, with a particular focus on the effectiveness of de-identification and anonymization strategies used to protect data. We are able to identify the strengths and weaknesses of your current approaches and define the level of privacy risk to which your organization is exposed. We can then design solutions to support immediate compliance with key security regulations and standards by mitigating security vulnerabilities, measuring and managing overall security exposure and risk, and ensuring compliance with internal and external privacy policies.

Learn more about our privacy products and services at kidesign.io or contact us to see how we can help you.

Posted by Dr. Wael Hassan on

“HIPAA Compliant” Applications

Canadian healthcare providers have often asked, do health applications advertised as “HIPAA-compliant” offer some legal assurance? Often, the answer is no. The Health Insurance Portability and Accountability Act, the main US law governing privacy and information security in healthcare, does not apply to technological applications as such. Rather, it governs personal health information managed by covered entities such as hospitals, physicians, pharmacies, and health insurance companies. Health applications managed by covered entities are subject to HIPAA rules. Consumer health applications managed by private businesses or independent developers are not.

What developers of health applications likely mean, when they advertise themselves as “HIPAA-compliant,” is that their solution aligns with HIPAA standards, and that they are willing to sign Business Associate Agreements (BAA) with healthcare organizations.  A BAA makes a service provider to a healthcare organization directly liable under HIPAA rules. Canadian healthcare organizations can obtain some legal protection by signing a BAA with a U.S.-based information service provider.

HIPAA definitely does not apply to consumer health applications, such as mobile apps and wearable devices that collect health information for an individual’s use (e.g., monitoring one’s exercise habits or diet), but do not share this information with a healthcare provider. Healthcare providers who wish to recommend these applications to patients should be aware that Canadians have few legal avenues to enforce their privacy rights with respect to consumer applications.

Posted by Dr. Wael Hassan on

Canadian Healthcare and U.S. Cloud Services: Is HIPAA Compliance Good Enough for Canadian Health Data?

Many Canadian healthcare organizations are asking questions about using U.S.-based cloud service providers to manage services such as email and databases. Cloud service providers in the U.S. and public organizations in Canada often ask whether compliance with the Health Insurance Portability and Accountability Act (HIPAA), or with Federal Trade Commission (FTC) recommendations, is relevant in evaluating compliance with Canadian privacy laws. In other words, does legal compliance translate, in full or in part, from the U.S. to Canada?

Among Canadian organizations, public healthcare providers have particularly complex information technology needs. They store large volumes of personal data that need to be easily accessible, yet also protected by strong privacy safeguards. They need private and secure means for communication and data sharing. In addition, they often de-identify or anonymize data for use in research and system planning. Cloud services appear to be a promising option to meet some of these needs. They offer to eliminate the expense of maintaining secure servers, and deliver easy but secure data access and improved features. Cloud services are also typically more interoperable than local systems. It seems a cost-effective and convenient solution.

Numerous Canadian healthcare organizations are, in fact, choosing to make use of cloud services to manage email, databases, and other systems. This is a decision that needs to be examined carefully from the perspective of privacy and security. Most cloud service providers are based in the U.S. It can be difficult to assess whether these companies are in compliance with Canadian privacy laws and standards. Organizations often ask whether compliance with the U.S. Health Insurance Portability and Accountability Act (HIPAA), or with Federal Trade Commission (FTC) recommendations, is relevant in evaluating compliance with Canadian privacy laws. In other words, does legal compliance translate, in full or in part, from one jurisdiction to another?

HIPAA vs. PHIPA

Both in Canada and in the U.S., healthcare is recognized as a sector that requires specific privacy legislation. In the U.S., healthcare privacy is regulated by the Health Insurance Portability and Accountability Act (HIPAA). In Canada, most provinces have dedicated healthcare privacy legislation.

Does HIPAA compliance have any relevance to Canadian healthcare organizations? It is difficult to compare HIPAA with Canadian healthcare privacy laws such as Ontario’s Personal Health Information Protection Act (PHIPA) and Alberta’s Health Information Act (HIA) because they are written in different language. Canadian privacy laws generally focus on objectives rather than methods, and use general terms: for example, Ontario’s PHIPA states that Health Information Custodians (HICs) must take “reasonable steps” to protect personal health information against theft, loss, and unauthorized use and disclosure, as well as unauthorized copying, modification, or disposal. HIPAA, on the other hand, describes specific required physical and electronic safeguards for health information, such as facility access controls, workstation security, electronic information access control and authentication, and transmission security.

HIPAA compliance does indicate alignment with certain industry standards for privacy and security, but HIPAA differs from Canadian healthcare privacy laws on a number of specific points. For example, Ontario’s PHIPA has several requirements that are not included in HIPAA:

1. Information technology service providers to HICs must “notify the custodian of any breach of the restrictions on its use and disclosure of personal health information or unauthorized access.”

This means that email or cloud storage providers serving healthcare organizations in Ontario are obligated to notify them of any security breaches or other instances of unauthorized access or disclosure. HIPAA does not require IT service providers to notify healthcare clients of breaches. While a notification requirement could be included in a contract with an American service provider, many U.S. service providers are reluctant to agree to notify their clients of breaches because of fears of liability and loss of reputation.

2. Information technology service providers to HICS must “make available to the public, information about the services provided to the custodian; any directives, guidelines and policies of the provider that apply to the services provided; and a general description of the safeguards that have been implemented.”

IT service providers to Ontario healthcare organizations should provide a plain language description to be published online and in print about the services they will be providing, the privacy and security directives, guidelines, and policies to which they have agreed, and the information safeguards they employ.

3. Information technology service providers to HICs must agree to comply with PHIPA.

This point is problematic when it comes to large U.S.-based IT service providers. It is doubtful whether American companies would agree to assess and monitor compliance with Canadian laws. The possibility of having to maintain compliance with multiple sets of laws from different jurisdictions is a liability which many companies are not willing to take on.

The U.S. National Security Caveat

The state of privacy in the U.S. cannot be understood apart from its national security legislation. Many Canadians hold privacy concerns about U.S. national security agencies’ broad access to data held by major internet companies. The USA PATRIOT Act and the U.S. National Security Agency’s PRISM project are frequently cited as privacy violations. It is often noted that this legislation permits more extensive surveillance of foreign citizens than of U.S. citizens. Yet the U.S. Cybersecurity Information Sharing Act (CISA), passed in 2015, may be even more problematic. CISA’s stated goal is to develop procedures for the federal government to share classified and declassified information on cybersecurity threats with private companies, lower levels of government, and the public. In practice, this could legally justify the existence of a catch-all database recording internet traffic, accessible to multiple levels of government and corporations. Several privacy provisions included in the draft bill were removed shortly before the bill was passed.

It is largely because of concerns about surveillance that two Canadian provinces, British Columbia and Nova Scotia, have passed laws prohibiting public bodies, such healthcare and educational institutions, from storing personal information outside of Canada. While other provinces do not explicitly prohibit this practice, it is clear that from a privacy perspective it is not ideal for Canadians’ personal information to be managed by U.S. companies.

The current reality is that U.S.-based cloud service providers are generally not in compliance with Canadian legal requirements and have no plans to achieve compliance. Canadian organizations considering using American cloud services should carefully consider how to ensure legal compliance and enforce contracts. If Canadian organizations choose to utilize U.S.-based service providers, they will need to retain enough power and control to monitor legal compliance and effect changes needed to bring systems into alignment with Canadian laws.

How to Protect Canadian Health Data

For healthcare organizations in provinces that permit the use of U.S.-based cloud services, contractual and technical safeguards can mitigate some of the privacy risks.

1. Sign a Business Associate Agreement

The HIPAA Privacy Rule recognizes that most healthcare providers employ third party service providers, including information service providers. HIPAA allows healthcare providers to disclose protected health information to these “business associates” if the providers “obtain satisfactory assurances that the business associate will use the information only for the purposes for which it was engaged by the covered entity, will safeguard the information from misuse, and will help the covered entity comply with some of the covered entity’s duties under the Privacy Rule.”[1] These assurances are to be documented in a contract or agreement, commonly known as a Business Associate Agreement (BAA). Business associates that have signed a BAA are directly liable under HIPAA rules.

The U.S. Department of Health and Human Services website lists requirements for a BAA, and offers a list of sample provisions. Ki Design’s experts in international privacy law can help your organization to draft a specialized BAA to protect Canadian health information managed by U.S.-based cloud service providers.

2. Segregate data assets and support

Whether your organization chooses to procure cloud application services (software as a service – SaaS), cloud platform services (PaaS), or cloud infrastructure services (IaaS), personal health data need to be segregated from other cloud customers’ data at all three levels: application, platform, and infrastructure. Healthcare organizations should also choose cloud service providers with support services located in Canada or the U.S., and support technicians’ access to health data should be segregated.

3. Choose database-level encryption

When healthcare organizations employ cloud services, it is essential that health data be encrypted at the database level, before data leave the source computer. Database-level encryption tools may be built into the original database, or may function as a separate engine, producing an encrypted version of the database.

Using cloud services, and especially cloud services based in another country, to manage personal health data brings certain technical and legal risks. However, legal agreements and strong technical safeguards can mitigate some of the most significant risks. Contact Ki Design for a consultation on how your organization can use cloud services safely.

[1] http://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/

Posted by Dr. Wael Hassan on

Canadian Mobile Health Initiatives: Lessons Learned

Recent Canadian initiatives suggest that mobile health applications can help integrate healthcare into individuals’ daily lives, by enabling remote communication between healthcare providers and patients. These first initiatives have revealed significant opportunities for healthcare, as well as important challenges to be addressed. What lessons do we need to learn from these experiences in order to expand the scope of mobile health?

In the last few years, mobile health applications have been launched by several Canadian hospitals and healthcare organizations. Mobile health applications extend healthcare beyond traditional settings by making it possible to monitor patients’ health remotely. Mobile phones and tablets have been adapted to monitor heart rate, blood glucose levels, and other health indicators and upload results to online portals accessible to patients’ healthcare providers. Mobile applications can also be used to educate and inform patients and to enable more frequent communication between patients and healthcare providers. To offer a couple of examples, these capabilities are being used to help patients prepare for surgery and to monitor patients just released from hospital. As for future possibilities, mobile applications are especially well-suited to supporting patients with complex and chronic health conditions that need to be monitored continuously.

Mobile health initiatives have begun to take healthcare into new domains, uncovering new opportunities and challenges. Creators and managers of mobile health applications have had to learn as they go, and adapt to unforeseen obstacles. What can we learn from these initial experiences? We offer a few points of interest to organizations considering the potential of mobile health.

Mobile health lessons learned

Mobile app purchasing is different from software or hardware purchasing.

When healthcare organizations seek to purchase computer hardware, there are usually about ten major vendors to consider. With software, there are perhaps fifty established companies to choose from. There are thousands of mobile application creators. Organizations need support from people with experience in mobile health to formulate clear requirements and priorities and help narrow down an extremely wide field of vendors.

Mobile health apps need to work on more than one kind of phone.

Mobile health applications are often intended to be installed on patients’ own phones. Even where healthcare organizations choose to provide phones to patients, the Canadian Radio-Television Telecommunications Commission (CRTC) requires that they be given the option of switching telecommunications service providers, which may mean switching phones. In either case, mobile health applications have to work on different types of phones (e.g., iPhone, Android, Blackberry). Compared to software, mobile applications rely more heavily on a device’s operating system, with the result that the same app is likely to behave quite differently on different phones. Mobile applications need to be written and tested for different phone operating systems. Since applications are often intended for a large number of users who have different kinds of phones and may lack technological proficiency, considerable technical support is needed to address the variety of problems that may arise.

Calculate costs per capita.

Because different versions of mobile applications need to be designed for different phones, applications usually have higher operating costs than software. Costs of ongoing development and support are also considerable; for instance, the application will need to be updated every time a phone operating system is updated. Before launching an application, organizations need to consider the cost per patient for the patient population they expect to serve. Because of relatively high ongoing costs, it makes most sense to design applications relevant to large populations in order to benefit from economies of scale.

Don’t forget about backend support.

Mobile health apps used by patients or health professionals need to be supported by backend databases and systems (e.g., hospital servers) that manage data collection and storage, user identification, security, and privacy, among other functions. Data collection and access systems need to be designed to protect patient privacy. For example, before the application is launched, it needs to be decided whether incoming data streams will be linked to identifiable individuals or not. Applications will also need to integrate patients’ previously stated privacy and confidentiality preferences regarding who can view their health information. While telecommunications systems can generally assure secure data transmission, backend security systems need be configured to ensure that telecommunications providers do not have access to patients’ personal health information.

Backend support infrastructure requires considerable resources, and is a much better investment if it is capable of supporting future updates and applications. If possible, backend support systems should be aligned with Canada Health Infoway architectural standards, which will allow them to be adapted more easily to future needs and integrate better with other systems.

Plan ahead for operating support.

When healthcare organizations purchase a mobile application from outside IT service providers, they cannot simply turn over responsibility for access, privacy, and security to the provider. If outside service providers are going to provide operating support, healthcare organizations need very well-written agreements to ensure that the service providers comply with the organization’s privacy policies and legal obligations. Mobile health applications cannot be managed in isolation from the organization’s regular operations, but need to be integrated with existing business processes, such as patients’ privacy and confidentiality directives. Deciding how the healthcare organization and IT service provider will work together to manage an application takes careful planning in terms of both policy and operations.

Thinking ahead

Mobile health applications to date have generally been designed along unique lines for specific contexts. Now that they are becoming more common, it makes sense for healthcare organizations to consolidate what they have learned and begin to develop common standards. Comparing notes with other organizations on their application designs and launch experiences would help developers to establish broadly applicable standards, such as a common nomenclature for mobile health applications or a common interpretation of Infoway architecture as it applies to mobile health. Common standards would make it possible for developers’ experience and knowledge to be transferred from one context to another, rather than each new application being designed from scratch.

Common standards would also make it possible to create cornerstone solutions that could be integrated into multiple applications. In particular, designing backend support infrastructure to support a variety of applications would greatly reduce the cost of new applications and enable more complex features, such as linking data collected through different applications. More fully developed privacy and security infrastructure would support the collection of more complex data, and make it possible for users to access some applications anonymously by integrating de-identification or anonymization into data collection.

Mobile health initiatives have opened up a number of new possibilities for healthcare. A variety of applications are beginning to enable more frequent communication between patients and healthcare providers, increase patients’ involvement in managing their own health, and generate high quality information for health research. Learning from early initiatives can help healthcare organizations to begin to take advantage of the full potential of mobile health by designing better applications, integrating them more smoothly into existing infrastructure, and managing them more efficiently and economically.

Posted by Dr. Wael Hassan on

Extending the Reach of Healthcare: Mobile Health Devices, Privacy and CRTC Compliance

Mobile health devices have extended the reach of healthcare by making it possible for clinicians to monitor patients’ health on a day-to-day basis, regardless of their physical location. These technologies have a great potential to improve care for patients who are not well-served by the traditional healthcare system, including people in remote areas and those with complex and chronic health conditions, especially seniors. Canadian healthcare providers do, however, need to consider several important regulatory and privacy concerns as they adopt mobile health devices.

Mobile health devices are an exciting new development in global healthcare. In Rwanda, lab-on-a-chip technologies are being used to provide highly accurate HIV tests and automatically send results to patients’ electronic health records via cell phone networks. Closer to home, mobile phones and tablets are being adapted to monitor heart rate, blood glucose levels, and other health indicators and upload results to online portals accessible to patients’ healthcare providers. These technologies are particularly well suited to supporting patients who find it difficult to travel to a doctor, such as people in remote areas and housebound seniors. They are also extremely useful for monitoring complex and chronic health conditions. Mobile health devices have the potential greatly to improve care for patients who are not well-served by the traditional healthcare system. Canadian healthcare providers do, however, need to consider several important regulatory and privacy concerns as they adopt mobile health devices.

CRTC Requirements for Mobile Health

Healthcare providers that give patients mobile devices which use cell phone networks are considered by the Canadian Radio-Television Telecommunications Commission (CRTC) to be telecommunications resellers. While the CRTC does not directly regulate resellers, these are none the less obligated to meet certain compliance requirements:

  • Any mobile devices that have voice communications capabilities have to have 911 service capabilities. If devices can be used for phone calls (even if this is not their intended purpose), the CRTC requires that providers test the devices to ensure that they can make 911 calls. If devices are not capable of voice calls, patients need to be explicitly informed of this, and the devices should not look like cell phones (i.e. have features such as keypads).
  • Resellers must report user complaints about mobile devices within five days to the Commissioner for Complaints for Telecommunications Services. Ideally, users’ issues will already be resolved by the time complaints are reported.
  • Devices must be adapted, as needed, for people with visual disabilities. This is both a CRTC requirement and a requirement of the Accessibility for Ontarians with Disabilities Act (2005).
  • Resellers must follow CRTC guidelines of transparency, innovation, clarity and competitive neutrality. This means that they must clearly explain services to users and make information about their business practices available to the public. Competitive neutrality means that users must have the option to switch telecommunications service providers. This means that healthcare providers managing mobile health devices need to have agreements with all national telecommunications carriers. While most urban patients will not be concerned with which carrier serves them, remote areas may not be served by all carriers, and healthcare providers need to be able to switch patients to a carrier that serves their home.

It is also highly advisable for telecommunications resellers to monitor their compliance with CRTC requirements, follow CRTC rulings, and participate in relevant meetings and boards.

Privacy in Mobile Health

Mobile health devices take patients’ personal health information outside of secure healthcare settings into the community. This raises a couple of important privacy issues:

  • Mobile service providers to health devices will have records of patients’ names, addresses, and type of device, and will know that they are participating in a mobile healthcare program. Any employee in the telecommunications company serving a mobile health program will potentially be able to access this information. The worst case scenario is that an employee could steal contact information for vulnerable patients, such as seniors, and sell it to fraud artists. Patients need to be told who will have access to their personal information and what risks this may pose.
  • If a mobile health device is lost, this should be considered a privacy breach, as the SIM card in the device will contain personal information. The healthcare provider will need to be able to respond in 5 days, for example, by disabling the SIM card or tracking the device’s location. Patients need to know that there is personal information on the SIM card and that they should contact the healthcare provider if they lose the device.

Mobile health devices have a great potential for extending healthcare services beyond traditional settings, and in particular, helping patients with complex health needs better to manage their conditions. In adopting these devices, healthcare providers need to take into account the needs of patients with differing abilities in diverse geographical locations. They also need to ensure that patients are thoroughly informed of how their personal information will be managed and whom to contact for help with the device. By planning ahead to fulfill mobile device users’ rights, as set out by CRTC requirements and privacy laws, healthcare providers can offer sensitive and responsible support to patients in need of innovative healthcare approaches.

Posted by Dr. Wael Hassan on

Where do we start? Privacy first steps for community health providers

Individual health practitioners and community health organizations usually have some awareness of privacy regulations and have developed a privacy policy, but may struggle to integrate privacy principles into their daily operations. Here are our answers to the question, “Where do we start?”

Most community health providers are aware that they are governed by privacy legislation, and have made some effort to familiarize themselves with the provincial or federal laws that apply to them. Most have developed a privacy policy based on guidelines from federal or provincial privacy commissioners. The challenge usually is knowing how to implement it. Small to midsize health organizations serving local communities generally do not have the resources to build a privacy program with expert staff. They may seek consultations such as organizational reviews or privacy impact assessments, but these are intended for contexts where privacy practices are already being integrated into daily operations. So, where should community health providers start with privacy?

We suggest that the first steps for community health providers seeking to improve privacy are the following:

1. Create a privacy officer role

Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA) affirms that every organization should have a designated privacy officer. This does not only mean appointing an individual, but defining a role: Who will the privacy officer need to consult with? Which committees will he or she sit on? What actions or changes will need to be approved by the privacy officer? While the privacy officer’s role will be unique to your context, it is helpful to keep in mind that privacy connects multiple areas, including policy, communications, information technology, service delivery, and staff training.

2. Review communications

You probably has a privacy policy, but do your clients know about it? One of the privacy officer’s first tasks is to make sure that clients are informed about the privacy policy through channels such as your website, information sheets, and most importantly, frontline healthcare delivery. Clients’ personal information should only be collected with their informed consent, which means that they should know what kinds of information will be collected, how it will be used and stored, who may have access to it, and how long it will be kept. Clients should also know whom to contact about privacy concerns.

Of course, the privacy officer will also need to make sure that what clients are told about how their personal information is managed is true – that your privacy policy is actually being implemented. As clients are invited to raise concerns about privacy, the privacy officer should have a plan for handling questions and complaints.

3. Investigate information management

How do you collect, use, store, and dispose of personal information? How long is it kept, and how is it destroyed? Who manages the data and who has access to it? In particular, what outside service providers do you depend on to manage client information? These could include email and cell phone service providers; cloud data storage providers such as Dropbox or Google Drive; and IT installation and support for software (e.g., appointment booking and client record-keeping systems) and hardware (e.g., internal server, desktop computers and laptops). What client information could they access, and what are their privacy policies and practices? The privacy officer needs to know the answers to these questions, make sure that they are in line with your privacy policy, and ensure that clients are informed of these practices.

4. Develop breach response protocols

What will be done if there is a privacy breach – for instance, if your website or record-keeping system is hacked? Do you have the ability to block access from a hacked account, or are you dependent on service providers to manage access? What if a USB, laptop, or smartphone containing personal information is lost or stolen? Are these devices password protected? How much information could be compromised by a breach? Who needs to be notified in the event of breach? At this stage, the privacy officer will need to consult with IT staff to reduce security risks and develop breach response protocols.

These initial steps are the foundation for implementing privacy policy in regular operations. Once this is done, you will be in a better position to benefit from an organizational review or consultation, which documents privacy policies and practices and identifies any gaps. From there, an important next step is to develop privacy awareness and training for all staff. Later, privacy impact assessments or maturity assessments may be used to refine privacy risk management. Each of these steps aims not just to identify risks and develop policies, but to ensure that privacy considerations are integrated into every aspect of your daily operations that involves individuals’ personal information.

For healthcare organizations and health professionals in Ontario, we recommend consulting:

A Guide to the Personal Health Information Protection Act (PHIPA). Information and Privacy Commissioner of Ontario. http://www.ipc.on.ca/images/resources/hguide-e.pdf

Posted by Dr. Wael Hassan on

Our Privacy Impact Assessment Approach

Privacy Impact Assessments (PIAs) are a key tool for demonstrating compliance with privacy laws. We outline our approach to basic institutional PIAs, as well as PIAs for multi-institutional or multi-jurisdictional data initiatives.

The KI Design approach to a single institutional privacy impact assessment falls in line with the provincial and federal requirements in Ontario and Alberta. The basic purpose of a PIA is to assess the impact of the collection, use, and disclosure of personal information on privacy and to justify this impact. Our approach begins with an analysis guided by the four-part test for necessity and proportionality established in R. v. Oakes (based on the Office of the Privacy Commissioner of Canada guideline):

  1. Is the measure demonstrably necessary to meet a specific need?
  2. Is it likely to be effective in meeting that need?
  3. Is the loss of privacy proportional to the need?
  4. Is there a less privacy-invasive way of achieving the same end?

In addition to answering the above questions, we help to collect documentation to demonstrate compliance with the ten principles that form the core of PIPEDA:

Accountability – Governance structure, PIA protocols, auditing, training, legal consultation

Identifying Purposes – Purposes of data collection, legislative authority for collection, description of data collected

Consent – Notification process or exceptions to consent

Limiting Collection – Justification for each data element collected, and indication that data taken from other departments are purged of all but essential data elements

Limiting Use, Disclosure, and Retention – Use cases, proposed disclosures, data sharing agreements, retention and disposition policies

Accuracy – Processes for correcting data and monitoring changes to records

Safeguards – Physical and electronic safeguards, Threat Risk Analysis, encryption practices, access policies

Openness – Public communications regarding privacy practices

Individual Access – Processes for individual access to or correction of personal information

Challenging Compliance – Privacy complaint procedures, compliance audits

Once privacy risks have been identified and mitigating measures proposed, we help to develop an Action Plan that provides a timeline and assigns responsibilities for the implementation of these measures. We will also help to set up processes for ongoing updates of assessments, auditing and monitoring compliance with privacy policies, and retention and disposition of data.

Multi-Jurisdictional Privacy Impact Assessments

An increase in information sharing initiatives, such as Electronic Health Records (EHR), has led to a growing need for multi-institutional and multi-jurisdictional PIAs. Guidelines from the Office of the Privacy Commissioner recommend that such PIAs include a clear business case for information sharing, a common communications strategy to inform the public of information sharing, and a set of expected privacy practices shared by all institutions participating in the data sharing initiative.

Our unique approach builds on these basic requirements to define a clear, seven-step process that we use both to guide our clients as they develop privacy policy prior to EHR adoption, and to conduct PIAs in an EHR context.

  1. Purpose: We begin by defining the reasons for which health information custodians collect, use, retain and disclose personal health information.
  2. Custodianship: A key next step to ensuring privacy protective information sharing is the definition of a custodianship model. In the context of an EHR initiative, a steward will be designated to review and revise policies, processes, and procedures and to ensure the proper operation of shared records.
  3. Liability: In order to establish liability, we help to define the roles, responsibilities, and accountabilities of EHR participants. We define different EHR participants’ right and ability to manage (collect, retain, disclose, and correct) personal health information.
  4. Data Management: We define policies for management of data quality, records management, assurance of accuracy, retention and archiving, and secondary use of data.
  5. Controls: We define policies for the application of legislative requirements, including management of information safeguards, compliance auditing, identity validation and management, implementation of consent rules, breach management, and proactive and reactive monitoring of technology assets. Controls also include frameworks such as provider agreements, patient disclaimers, and mandatory and discretionary requirements that define the roles of EHR participants.
  6. Process: We apply privacy policy to workflows and interactions throughout care delivery processes, including service model, delivery model, management of consent, reporting procedures, circle of care management, and incident management.
  7. Adoption: In this final step we develop instruments for the implementation of privacy policy during the adoption and ongoing development of EHR, such as provider agreements, patient disclaimers, mandatory and discretionary requirements, and system feedback.