Privacy Impact Assessment Amendment

Template

Usage and Disclosure

This document is for the explicit use of dr2dr Secure Messaging customers, for use in developing their Privacy Impact Assessment amendment. It may not be distributed outside of the clinic, clinic staff, PIA consultants, and the OIPC without express written consent from Microquest Inc., Dave Brochu and Ingrid Ruys.

Introduction

Hello, and welcome to dr2dr Secure Messaging! We’d like to thank you for your interest in using dr2dr within your clinic and for taking the appropriate step of updating your Privacy Impact Assessment (PIA) with the Office of the Information and Privacy Commissioner (OIPC). Please follow the instructions below to get started.

Instructions

Questionnaire

To make the process as easy as possible we’ve collected all of the relevant information into a brief questionnaire. Simply complete this questionnaire and the PIA Amendment will be modified for your own clinic. We do encourage you to read and review the PIA Amendment and make any changes that you feel are necessary. If you have any questions or concerns, please do not hesitate to contact us at privacy@dr2dr.ca.

Documents

Your PIA Amendment submission to the OIPC consists of the following four documents:

The Amendment itself

Clinic Risk Assessment

Microquest Client and Security Policies

Microquest Software Development Policies

The completed questionnaire will modify these documents to suit your clinic. All four documents must be submitted to the OIPC together as a package.

Submission

To submit to the OIPC, complete the questionnaire on the following pages and print a hard copy. This hard copy must then be couriered or mailed to the closest OIPC office. It is highly recommended that a courier be used to ensure the documents are not lost in the mail.

Office of the Information and Privacy Commissioner (Edmonton) #410, 9925 109 Street Edmonton, Alberta T5K 2J8	Office of the Information and Privacy Commissioner (Calgary) Suite 2460, 801 6 Avenue SW Calgary, Alberta T2P 3W2

Questionnaire

Please complete the questionnaire below to fill out your PIA Amendment for submission to the OIPC.

Question/Field	Response
Clinic Information
Clinic Name	Click here to enter text.
Clinic Address	Click here to enter text.
Clinic City	Click here to enter text.
Clinic Postal Code	Click here to enter text.
Year the clinic began operation	Click here to enter text.
Clinic PIA Number (H#xxxxx)	Click here to enter text.
Clinic PIA Acceptance Date	Click here to enter a date.
Clinic EMR	Choose an item.
Type of Clinic	Choose an item.
Are Hospital services provided by clinic physicians?	Choose an item.
If Yes, please specify (please list, comma separate)	Click here to enter text.
Primary Care Network	Choose an item.
Number of clinic staff	Click here to enter text.
Number of clinic administrators	Click here to enter text.
Clinic Phone Number	Click here to enter text.
Clinic Fax Number	Click here to enter text.
Clinic Email Address	Click here to enter text.
Physician Information
Lead Physician	Click here to enter text.
Physicians participating in dr2dr (please list, comma separate)	Click here to enter text.
Number of physicians	Click here to enter text.
PIA Amendment Information
dr2dr Implementation Date	Click here to enter a date.
Privacy Officer	Click here to enter text.
Legal Name of Lead Custodian or Organization (Clinic or Lead Physician’s legal name, e.g. Professional Corporation)	Click here to enter text.
Lead physician is:	Choose an item.
Job Title responsible for clinic administration	Click here to enter text.

Your submission starts after this page! Please do not include the preceding pages when submitting to the OIPC.

January 4, 2018

Ms. Jill Clayton, Commissioner

Office of the Information and Privacy Commissioner

# 410, 9925 – 109th Street

Edmonton, Alberta

T5K 2J8

RE:	Privacy Impact Assessment

dr2dr Secure Messaging System PIA Amendment

Click here to enter text.

Dear Ms. Clayton:

Please accept our Organizational Privacy Management Privacy Impact Assessment (PIA) amendment for your review. I am submitting the enclosed documents in compliance with section 64 of Alberta’s Health Information Act (HIA).

I am submitting the PIA Amendment for Click here to enter text. to include the dr2dr Secure Messaging System information. We are currently utilizing Click here to enter text. EMR solution, with a previously accepted PIA and PIA Amendments (latest being Click here to enter text. in Click here to enter a date.).

Our participation includes access to Alberta Netcare and I am aware of and bound by the following:

Alberta Health ‐ Alberta Netcare Portal (ANP) PIA (H3879);

Alberta Health Services (AHS) ‐ Netcare Clinical Repositories (NCR) PIA ‐ Provincial Health Information Exchange (pHIE) Addendum (H5172);

Alberta Health’s “An Overview of Alberta’s Electronic Health Record Information System”;

Alberta Health’s summary sheet, “Your System Integration with Alberta Netcare” and;

“An Alberta Netcare Guide for Authorized Custodians and / or their Authorized Affiliates”

EMR: Click here to enter text.

dr2dr Secure Messaging System implementation date: Click here to enter a date.

Privacy consultant resources, Ingrid Ruys and Dave Brochu, have assisted in the preparation of this PIA submission.

Microquest Inc. has provided our clinic with training specific to the application and functionality related to its technical safeguards including audit trails, backup, etc.

Click here to enter text. has been operating as a Click here to enter text. since Click here to enter text. and is located at Click here to enter text. in Click here to enter text., AB.

Physicians participating in this dr2dr Secure Messaging System include:

Click here to enter text.

This new dr2dr Secure Messaging System allows the sharing of identifying health information in a secure environment, a capability currently not provided by regular email programs and protocols. The disclosure of identifying health information to other custodians for the purposes of continuing care and provision of health services, are covered under the collection, use, and disclosure provisions of the HIA. But because this collection, use, and disclosure through communications is carried out in a new manner for our clinic, using new information handling tools, we are submitting this update PIA, as required by the HIA, for review and feedback by the OIPC to ensure best practices are being followed and potential risks involved have been properly considered.

I trust that this will be satisfactory.

Sincerely,

Click here to enter text.

Lead Custodian

Click here to enter text.

Enclosures:	Privacy Impact Assessment

Risk Assessment Table

Microquest Client and Security Policies

Microquest Software Development Policies

PRIVACY IMPACT ASSESSMENT

Organization Management
and
Organization Medical Information Communications

(dr2dr Secure Messaging System)

Click here to enter text.

Click here to enter text.

Clinical Director / Lead Physician

Click here to enter text.

Privacy Officer

Clinic Name: Click here to enter text.

Legal Name of Lead Custodian or Organization: Click here to enter text.

Contact Information:

Click here to enter text., Clinic Privacy Officer

Click here to enter text.

Click here to enter text.

Click here to enter text., Alberta

Click here to enter text.

Canada

Phone: Click here to enter text.

Fax: Click here to enter text.

Email: Click here to enter text.

PIA Submission Date: January 4, 2018

Previous PIA Submission:

Click here to enter text.	Acceptance date: Click here to enter a date.

Changes since previous PIA submission:

Implementation of dr2dr Secure Messaging System for communicating sensitive information and documents with other custodians, staff, and patients.

Version Control:

Date	Version	Author of changes	Description
Click here to enter a date.	1.0	Click here to enter text.	Organizational management and EMR implementation
January 4, 2018	1.1	Click here to enter text.	Implementation of dr2dr Secure Messaging System

Table of Contents

Usage and Disclosure	2

Introduction	3

Instructions	3

Questionnaire	3

Documents	3

Submission	3

Questionnaire	4

Section A: Project Summary	9

Project Background	9

dr2dr Secure Messaging System	9

Clinic Profile	11

Section B: Organizational Privacy Management	13

Management Structure	13

Policy Management	13

Microquest Inc.	14

Privacy Management Structure	15

Agent of the Custodian	16

Change Management Process	16

Training and Awareness	17

Privacy Officer	17

Microquest	17

Alberta Netcare training and awareness	18

dr2dr Secure Messaging System Privacy Training and Awareness	18

Incident Response	19

Privacy Breach Management	19

Material Breach	20

Access and Correction Requests	20

Section C: Project Privacy Analysis	22

Project Health Information Listing	22

Figure 1 – Patient Demographic Capture Within dr2dr	23

Project Information Flow Analysis	24

Dr2dr Secure Messaging Technical Information Flow Diagram	24

Legal Authority and Purposes Table	25

Data Transfer	26

Notice	26

Project Consent and Expressed Wishes	26

Project Data Matching	26

Contracts and Agreements	27

Use of Health Information Outside of Alberta	27

Section D: Project Privacy Risks and Mitigation	28

Access Controls	28

Available Permissions	28

Figure 2 – User Permissions within an Inbox	29

System Administrators	29

Access Control Safeguards	29

ISO 13485:2003 Development Process	30

Privacy Risk Assessment and Mitigation Plans	30

Data Retention	31

Data Export	31

Monitoring	31

PIA Compliance	32

Section E - Policy and Procedure Attachments	33

General Privacy Policies	33

Attachment 1:	Microquest dr2dr Secure Messaging System Risk Assessment Table	1

Click here to enter text. – Risk Assessment Table for dr2dr Secure Messaging System	1

Attachment 2:	Microquest Client Security and Privacy Policy	1

Microquest Security & Privacy Policy	1

Introduction	1

1. Roles & Responsibilities	2

Title: Privacy Officer	2

Title: IT Manager	3

Title: Software Support Technician	3

Title: Client Services / Training	4

Title: Software Programmer	5

Type: Electronic	6

Type: Portable	6

Type: Hardcopy	7

3. Collection, Use and Disclosure of Information	8

Collection	8

Storage & Security	8

Use and Disclosure	8

4. Third Parties	9

5. Disposing of Client Data	10

Type: Electronic	10

Type: Portable	10

Type: Hardcopy	10

Attachment 3:	Microquest Software Development Policy	1

Quality System Procedure	1

Software Development	1

QSP 7.3-1 r9	1

1. General	4

1.1. Purpose	4

1.2. Scope	4

1.3. Definitions	4

2. Overview	5

2.1. Phases	5

2.1.1. Design Documentation	6

2.1.2. Phase - Planning	6

2.1.3. Phase - Requirements	6

2.1.4. Phase – Implementation/Design & Verification	7

2.1.5. Phase – Validation	7

2.1.6. Phase – Design Transfer (Release)	7

2.1.7. Phase – Maintenance	7

2.1.8. Source Code Management	7

2.2. Related Documents and References	8

2.3. Required Approvals	8

3. Responsibilities	8

4. Procedure	8

4.1. Overall Process	8

4.2. Pre-design Activities	8

4.2.1. Project Initialization	8

4.2.2. Design Concept	9

4.2.3. Legacy Software	9

5. Planning Phase	10

5.1. Project Plans	10

5.2. Project Reviews	10

5.3. Approval of Project Plans	11

5.4. Updates to the Project Plan	11

5.5. Legacy Software	11

5.6. Deliverables	11

6. Hazard & Risk Analysis	12

6.1. Hazard & Risk Analysis	12

6.2. Legacy Software	12

6.3. Deliverables	12

7. Requirements Phase	13

7.1. Requirements Capture	13

7.2. Requirements Verification, Identification & Traceability	14

7.3. Architectural Design and Detailed Design	15

7.3.1. Architectural Design [§5.3]	15

7.3.2. Architectural Design Verification [§5.3.6]	15

7.3.3. Detailed Design	15

7.3.4. Detailed Design Verification	16

7.4. Legacy Software	16

7.5. Deliverables	16

8. Implementation & Verification Phase	17

8.1. Implementation (Coding)	17

8.1.1. Coding/Debugging	17

8.2. Legacy Software	17

8.3. Deliverables	17

8.4. Integration	17

8.5. Verification	17

8.5.1. Testing Procedures	18

8.6. Legacy Software	18

8.7. Code Review	18

8.8. Deliverables	19

9. Validation Phase	19

9.1. Validation	19

9.2. Validation Test Procedures	19

9.3. Legacy Software	20

9.4. Deliverables	20

10. SW Problem Resolution	20

11. Transfer Phase (SW Release)	20

11.1. Legacy Software	21

11.2. Deliverables	21

12. Documentation	21

13. Source Code Configuration Management	22

14. Off-The-Shelf (OTS) Software	22

14.1. Legacy Software	22

14.2. Deliverables	22

Appendix A: IEC62304:2006 Compliance Check	23

Section A: Project Summary

Click here to enter text. has been operating as a Click here to enter text. medical practice since Click here to enter text., providing medical services to patients in our local area as reported in our existing PIA The clinic is located at Click here to enter text. in Click here to enter text.. In order to provide care, the clinic must collect, use and disclose health information.

Project Background

Click here to enter text. is filing this update Privacy Impact Assessment (PIA) to remain in compliance with Section 64 of the Alberta Health Information Act (HIA). All custodians are required to report on updates to their information safety and security practices when it comes to personal health information they have in their care and custody. This is a key step in demonstrating willful compliance with the provisions of the HIA and related legislation.

Further to this, participating in the PIA process and having the organization update PIA accepted by the Office of the Information and Privacy Commissioner (OIPC) demonstrates that our custodian(s) follow good information safety and security practices, including having an active program to improve these practices as we become aware of new trends and ideas going forward. This demonstration of good practices in turn opens the door to partnering with organizations and applying for services that require some form of proof that the clinic has such measures in place.

dr2dr Secure Messaging System

For this update PIA, we are initiating the d2dr Secure Messaging System service provided by Microquest. This service is aimed to improve communications between custodians providing health services including referrals / consults as permitted by Section 35 of the HIA, eventually including as well as limited communications between patients and custodians. Further, this capability is being initiated to both improve timeliness of contact and exchange of information and security of same.

Clinics and custodians are expected to use the most secure means possible to communicate with patients and other custodians in their role as health care providers when discussing case management, setting up appointments, and for other related communications involving the patient’s identifiable health information. While the OIPC has provided guidance for general e-mail use in managing patient appointments in the same manner as voicemail might be used (OIPC HIA Practice Note #5, dated August 2012), this communication is limited to appointment related information only. Where more detailed patient health information needs to be exchanged, a higher bar of expectation is set for health information safety and security for such exchanges, and regular email is generally acknowledged as not providing enough security for such.

In the same vein, faxing of information carries risks similar to voice mail and general email where successful receipt in a secure and private manner is heavily dependent on the accuracy of fax phone number information provided by the receiving agency directly or by the patient. There is further risk from the fact that faxed copies of information can also be of varying quality, risking loss or limiting the usefulness of the information for provision of health care services or other allowable purposes as identified by applicable legislation.

The d2dr Secure Messaging System is a web based, secure server system that enables the exchange of sensitive data, beyond the clinic borders, in a secure fashion, while ensuring that it is compliant with industry regulations. The system is designed to:

provide secure, seamless, timely sharing of medical information between health care providers

reduce wait times for access to specialists and requests for consultation

maximize the coordination of care for Albertans

Secure messaging is not the same as secure e-mail. Secure messaging has several important advantages:

No data resides outside of the central server so there is no ability to hack into the information during transport

Confidential and authenticated exchanges can be started immediately. There is no need to install special software or security access devices (e.g. key fobs or fingerprint readers)

It provides a high degree of ‘non-repudiation’, which is proof of the integrity and origin of the data as well as highly assured authentication of the identity of the user

With the above considerations in mind, we are undertaking to employ the d2dr Secure Messaging System, provided by Microquest that includes a secure messaging and secure document delivery component (attachments) through an encrypted Web portal. This portal is compatible with all modern browsers including on smart phones. Accounts exist for primary custodians (and their staff) as a paid service, with a long term plan to make it available to other providers, such as pharmacists and nurse practitioners, and ultimately to patients.

Secure messaging can be used for many clinical purposes, but there are three primary functions:

Rapid exchange of clinical information functions

Requesting clinical advice quickly and efficiently

Facilitating electronic consultation and referral

The dr2dr system maintains all of the messaging in a single location, with no messaging information residing outside of the system. The data is encrypted both in transit and while at rest on the dr2dr servers. The system also provides for a common directory of system user physicians, including their location, services provided, referral information and clinic contacts.

When a physician signs up for the dr2dr Secure Messaging System, they are authenticated to ensure that they are a member of the College of Physicians and Surgeons of Alberta (CPSA) in good standing. Once authenticated, the user must sign and Information Manager Agreement (IMA) and an End User License Agreements and a verification code is sent to them. This provides the basis for a common directory of system-user physicians, including their location, services provided, referral information and clinic contacts.

Users access the secure messaging system via 2-factor authentication. dr2dr generates a secret key in the form of a QR code which is sent to the user via e-mail of text. The user then scans the code using the Google authenticator application for verification. Messages sent are only visible and accessible to the message generator and the authorized receiver(s).

If users have a Microquest Healthquest EMR, dr2dr Secure Messaging solution is integrated into the EMR. If they are using a different EMR vendor, there is a straightforward Application Program Interface (API) is available to integrate with their EMR, but this is subject to the EMR vendor agreeing to do that.

The system is hosted offsite by Microquest in Edmonton, Alberta with a secondary failover site in Calgary, Alberta. All of the data is stored on the servers, with no information residing on outside devices (phones, tablets, computers, etc.). The data is transferred using 256-bit SSL encryption, and all data (messages and attachments) at rest on the servers is also encrypted. Microquest has undertaken to ensure significant layers of fail-over redundancy are built into the system equipment and support involved through the data centre. Microquest has appropriate security in place for hardware, software, and data safety and security management. System security will be verified through a third-party security audit.

The clinic physicians, as individual custodians of health information, have undertaken reasonable steps to maintain administrative, technical, and physical safeguards to protect the confidentiality of the information under our custody and control including when used for health service provider education. As custodians under the HIA, physicians are required to protect the health information in their custody or control against reasonably anticipated threats or hazards that could result in loss, unauthorized disclosure or use, modification or inaccuracy.

This update PIA submission is documentation of the reasonably anticipated threats or hazards, and (of the suitable) safeguards put in place by Click here to enter text., as Lead Physician for the organization, to manage those threats and hazards in the organization’s use of this new capability.

Clinic Profile

Clinic Opened:	Click here to enter text.
Clinic Address:	Click here to enter text. Click here to enter text., Alberta Click here to enter text.
Clinic Legal Structure:	Click here to enter text. is a professional corporation formed in Click here to enter text..
Clinic Privacy Officer:	Click here to enter text.
Type of Clinic:	Click here to enter text. Click here to enter text. Click here to enter text.
Clinic Staffing:	Click here to enter text.
Primary Care Network:	Click here to enter text.
EMR:	Click here to enter text.

Please see Section A or equivalent of our existing PIA for more details on the clinic organization and related existing information systems.

Section B: Organizational Privacy Management

Please see our existing PIA for details on our clinic organization including management structure, policy management, training and awareness, and incident response.

Under the HIA, each physician in our clinic is a custodian of health information. When physicians in a clinic share an EMR and follow the same privacy and security policies & procedures, the Office of the Information and Privacy Commissioner (OIPC) has agreed to the submission of one PIA for the clinic. The PIA submission must be made by the clinic’s lead physician / custodian who is responsible to inform the other clinic physicians of the privacy risks and mitigation strategies, implemented policies & procedures and other PIA contents.

Management Structure

Click here to enter text. is a professional corporation formed in Click here to enter text.. Click here to enter text. is the Click here to enter text..

Click here to enter text. is identified as the current Clinic Privacy Officer. The Clinic Privacy Officer reports to the custodian, Click here to enter text.. The Click here to enter text. oversees administration in the clinic.

The physicians participating in the dr2dr Secure Messaging System include:

Click here to enter text.

Policy Management

Our clinic has developed a Health Information Privacy and Security Manual that specifically addresses privacy protection and includes a Privacy Charter. Our Privacy Charter is the overarching policy that guides the revision or development of all other information privacy and security policies & procedures.

The Click here to enter text. has:

Identified information sensitive systems and data;

Developed privacy and security policies and procedures;

Assessed the privacy and confidentiality implications of our daily administrative processes, to ensure the protection of the information of our patients and those providing information. These considerations are at the forefront of our clinic’s operating policies and procedures;

Initiated an awareness and training program relevant to the protection and confidentiality of health information.

Our physician(s), office administrator(s), medical support staff, administrative assistant(s), and receptionist(s) have participated in the development, review, and identification of potential privacy and security issues. Click here to enter text. authorizes new policies and changes to policies. The clinic manager authorizes procedures.

The following policies and procedures, per our initial Privacy Impact Assessment, apply to all health information collected, used, and disclosed by our clinic:

Privacy Charter

Health Information Privacy Practices

Policy #1	Right of Access

Procedure:	Release of Information & Disclosure Log

Policy #2	Correction or Amendment of Health Information

Policy #3	Collection, Use, and Disclosure of Health Information

Policy #4	Information Handling

Policy #5	Information Security in Contracting

Policy #6	Wireless Networking and Remote Access

Policy #7	Privacy and Security Risks and Mitigation

Policy #8	Information Flow Diagram and Legal Authority Table, Workflow diagram

Procedure:	Privacy Breach Management

Attachment:	Employee Confidentiality and Security Checklist

Attachment:	Password Guidelines

Attachment:	Facsimile Transmission Guidelines

These policies are reviewed on a regular basis, and any changes are communicated to our clinic physicians and staff by the Clinic Privacy Officer. Our clinic staff also review the policies during their orientation and annually thereafter.

Microquest Inc.

Microquest Inc. (“Microquest”) is a professional corporation formed in Edmonton, Alberta, Canada. Mike Barth is the president and CEO of this corporation. Kim Brown is identified as the current Privacy Officer and also oversees administration in the company.

All staff members are Microquest employees:

Staff Position	Job Responsibility	Reports to	Number of Individuals
President/CEO	Overall guidance of the corporation	N/A	1
Vice President	Assisting the President; day-to-day operations	President	1
General Manager/CFO	Financial items (e.g. budgeting/projections), day-to-day operations	President	1
Development Manager	Overall responsibility for the development team	Vice President	1
Technical Support Manager	Overall responsibility for the technical support team	Vice President	1
Client Services Manager/CMO	Overall responsibility for the client services team; marketing duties	Vice President	1
Software Developers	Development of various Microquest products	Development Manager	9
Quality Assurance Representatives	Testing various Microquest products	Development Manager	3
Technical Support Representatives	Providing technical support to Microquest clients	Technical Support Manager	5
Client Services Representatives	Assisting existing Microquest clients; new sales	Client Services Manager/CMO	4
Office Manager	Book keeping; running the office	General Manager	1

Privacy Management Structure

The Microquest Privacy Officer role is held by the General Manager. The Privacy Officer is responsible for information privacy and security, including ensuring that appropriate administrative, technical, and physical security features are in place to protect personal and health information. The Privacy Officer reports directly to the President / CEO.

In addition, key personnel in other areas have privacy responsibilities:

The Vice President holds the role of Security Administrator, and is responsible for privacy obligations around Support and IT Operations:

All staff are responsible to report security problems to the Security Administrator and their manager, immediately upon detection of the problem;

The Security Administrator will investigate and escalate to the appropriate manager or, as required, to the President, within one business day of being notified;

Security incident reports will be completed and submitted to management within 24 hours of an incident; and

The Security Administrator will initiate and ensure completion of an incidence report for each breach of security and all staff and contractors will be required to contribute as requested.

The Development Manager:

Is actively involved in dr2dr product development pertaining to security & privacy obligations (e.g. auditing, password management, etc.)

The Technical Support Manager:

Implements technical security controls (e.g. firewalls, intrusion prevention)

Development, Technical Support and Client Services Managers:

Identify the electronic information resources within areas under their control;

Establish acceptable levels of security risk for resources by assessing factors such as data sensitivity, importance to continuing operations, operations affected by unavailability, or reduced availability, etc.; and

Ensure that appropriate security measures are implemented for the resources.

Software Developers:

Analyze potential threats and the feasibility of various security measures in order to provide recommendations to the Development Manager; and

Implement security measures that mitigate threats, consistent with the level of acceptable risk established by the Development Manager.

Users (individuals who access and use dr2dr):

Protect the resources under their control, such as access passwords, computers, and data they download.

Agent of the Custodian

Per the Agreement between Microquest and the Custodian, Microquest is an Agent of the Custodian, providing contracted services, and as such must enter into an IMA, which aids the Custodian in mitigating the associated risks.

The Custodian has the right to monitor the compliance of Microquest in fulfilling their obligations of this Agreement. Copies of Employee Privacy Agreements, log entries to modifications of the Custodians’ health Information, and site visits to observe compliance should be available on request.

Change Management Process

Revisions to Microquest’s Policies and Procedures, or technical setup, are primarily performed by the Vice President, and must be approved by the President/CEO prior to coming into effect. Policy revisions are initiated when:

There is a change to contractual or statutory obligations;

There is a material change to organizational structure or technology; and

An annual review identifies areas for improvement.

When these changes occur, they are discussed amongst Microquest’s management team and are then communicated to the appropriate people / departments. The information is then updated in the Microquest Policies and Procedures documentation. If the change is significant enough, an addendum to the vendor’s PIA is sent to the OIPC.

Change management processes are also aided by our company having separate development, test / staging, demonstration, and production environments for our software products. This allows for our developers to produce code and extensively test it prior to it being introduced to the “real world”.

All of Microquest’s affiliates are notified of the change(s) and their effect(s), and what specifically may be required of the affiliates to enact those changes. In addition, if the change(s) may affect the Custodians whose data Microquest maintains, they are notified of the change(s) and the potential effect(s).

Training and Awareness

Privacy Officer

To acquire and maintain privacy expertise needed for the role of Privacy Officer, access to the following privacy resources are available:

Privacy training program – completed upon appointment as Privacy Officer and annually thereafter;

HIA help desk (780.427.8089) and the AH’s HIA Guidelines and Practices Manual;

Privacy Resource – to assist in preparing and / or updating our PIA and privacy policies & procedures;

OIPC assistance to respond to a suspected or real privacy or security breach;

Other HIA training sessions as offered by AH, AHS or the OIPC.

General privacy awareness and training practices:

Confidentiality and security of information are addressed as part of the conditions of employment for all of our staff, beginning with the recruitment stage and included as part of job descriptions and contracts.

Each employee will review our information privacy and security policy and procedures with our Privacy Officer, including a review of relevant sections of HIA Guidelines and Practices by AH, at time of hire, annually, if they change to a job position involving greater health information access or responsibility, or after an incident / breach at the clinic. Other relevant resources and in-services will be made available.

All staff that collect, use or disclose information as part of the performance of their duties for the clinic are required to sign a confidentiality agreement at time of hire.

Staff members are made aware that their performance is monitored to reduce the risk of error, fraud, or misuse of information and that all violations or suspected violations of privacy and security must be reported to the clinic’s Privacy Officer immediately.

Microquest

Microquest staff members are initially provided privacy, confidentiality and security training as part of recruitment and orientation, and on an annually recurring basis must indicate that they have "reviewed and understand the policies outlined in this document and agree to adhere to policy in all aspects of protecting private clinic and patient data". This training is also emphasized when new products are developed and launched.

Training is mainly the responsibility of the management team in a classroom setting, with staff members also being required to do independent study. Microquest staff members are made aware that their activities are monitored to aid in the reduction of errors, fraud, or misuse of information and that all violations or suspected violations of privacy and security must be reported to the Microquest’s Privacy Officer immediately.

Alberta Netcare training and awareness

In preparation for Netcare access implementation each authorized clinic physician and staff member (affiliate) is given Netcare training tailored to their Netcare permission level and job role at the clinic. Netcare users are informed about the confidentiality of the information in the following ways:

During Netcare training, users are advised that they are to limit their Netcare access to only pertinent information to a specific patient’s care (e.g. lab results, diagnostic imaging text reports and images, transcribed clinical reports, patient hospital admission and discharge history logs, pharmaceutical information, etc.). They are advised that they are not to be looking up their own information or that of anyone they know;

The Netcare home page has a large print message that states that the Netcare portal is being monitored and audited on a regular basis. Examples of past breaches and physician / employee consequences are discussed;

Alberta Netcare Portal Learning Centre has a section dealing strictly with Privacy, Security and Confidentiality. The information is written in plain language to make it easier for users to understand their roles and responsibilities as a custodian or affiliate. It also includes the ‘Test Your Knowledge’ quiz with 10 questions and real-life scenarios related to privacy, security and confidentiality in the Alberta Netcare workplace; and

The Clinic’s Confidentiality Oath includes access to Netcare and informs staff the Netcare monitors access on a regular basis.

dr2dr Secure Messaging System Privacy Training and Awareness

The dr2dr Secure Messaging System vendor, Microquest, undertakes privacy and security training with staff with a focus on health information handling best practices and maintains this training on an annual basis. Further, employees are expected to sign confidentiality oaths with the vendor that includes references to protection of client information.

Custodians are able to view information on privacy policies and statements and related health information safety and security measures as provided by the vendor through the vendor website and system user interface to meet a reasonable bar of disclosure and transparency expectations and adequately demonstrate that the company has good policies in place and company staff are appropriately trained in privacy and security for managing the system on behalf of customers using the service.

User training on safe use of the service for secure messaging to health care providers and their affiliates is carried out through a combination of two measures. One is in-clinic measures (in compliance with best practices such as OIPC HIA Practice Note #5 and clinic internal policies and procedures as reported in our original PIA submission) to ensure user awareness of policies and procedures in accordance with HIA Reg Section 8(6) requirements. This is also available on-line (privacy training). The second is in-system user training and reminder prompts provided by the system as described in this PIA submission. The custodians regard this as a suitable level of user training and awareness for use of the secure messaging system by staff signing up for the system.

Reference: Section E - Attachment 1: Health Information Privacy and Security Manual

Incident Response

Privacy Breach Management

Click here to enter text.

The Clinic Privacy Officer is responsible for information privacy and security, including ensuring that appropriate administrative, technical, and physical security features are in place to protect health information.

Click here to enter text. is designated as our clinic’s Privacy Officer and all violations or suspected violations of privacy and security must be reported to the Privacy Officer immediately. The Clinic Privacy Officer will respond immediately by following the clinic’s “Privacy Breach Management” starting with limiting the breach, initiating a Privacy Breach Report and determine which authorities or organization need to be informed. Affected physicians will be involved and consulted with.

The Clinic Privacy Officer must report any breach involving Alberta Netcare to the Information Access and Privacy Office (Manager, Information Policy and Compliance Unit, Alberta Health). A custodian can also request a copy of the Netcare user or patient audit trail by calling the HIA help desk.

The Clinic Privacy Officer must report the breach to the Office of the Information and Privacy Commissioner (OIPC) of Alberta and will receive support in responding to the breach.

We follow up on breach incidents as outlined in our clinic policy, to ensure that steps are taken to prevent future occurrence. This includes a communication plan to persons involved, staff, public, etc. and an audit plan to ensure implementation of preventative or correction steps are achieved including revision to policies and procedures.

Microquest Inc.

Microquest IMAs have a privacy breach reporting mechanism (see Policy #6: Information Security in Contracting). Microquest has a Privacy Officer who is responsible for information privacy and security, including ensuring that appropriate administrative, technical, and physical security features are in place to protect health information.

Microquest minimizes security / privacy breaches at their chosen data centre from occurring through the use of an Intrusion Detection System (IDS), and Intrusion Prevention System (IPS).

All systems are protected by monitored firewalls and passwords and all unnecessary ports disabled, in addition to the other provisions of this policy document. The infrastructure offers multiple levels of secured managed firewalls and host-based protection.

Each server is monitored by an Intrusion Detection System. Servers are monitored in real-time by the IDS.

Microquest minimizes the damage from a security / privacy breach at their chosen data centre by:

Regular monitoring of firewalls and systems for unauthorized access attempts;

All employees are responsible to report to the Security Administrator and Privacy Officer suspected security breaches;

The Security Administrator and Privacy Officer will promptly mitigate and investigate all breaches. All alerts from IPS and IDS are routed to a centralized monitoring system and dispatched to security administrators;

Security & privacy problems are investigated and escalated;

All staff members are trained in, and responsible to, report security & privacy problems to the Security Administrator, Privacy Officer, and their manager, immediately upon detection of the problem;

The Security Administrator and Privacy Officer will investigate and escalate to the appropriate manager or, as required, to the President, within 24 hours;

Security & privacy incident reports will be completed and submitted to management within 24 hours of an incident;

The Security Administrator will initiate and ensure completion of an incidence report for each breach of security and all staff and contractors will be required to contribute as requested; and

All breaches are reported to the clinic involved, and to the OIPC and will include the following information:

the nature of the of the non-permitted or violating use or disclosure;

the health information used or disclosed;

identify, if possible, who made the non-permitting or violating use or received the non-permitted or violating disclosure;

any corrective action that has been taken or will be taken to prevent further disclosure;

any actions that have been taken or will be taken to mitigate any deleterious effect of the non-permitted or violating use or disclosure; and

provide any other information that may be reasonably requested

Material Breach

Upon knowledge of a material breach of this Agreement by an Agent, Microquest shall provide written notice to the Custodian and the Agent identifying the breach. Microquest shall conduct a formal investigation, and take such remedial actions against the Agent including suspensions or termination for cause as deemed appropriate.

Access and Correction Requests

Microquest Inc.

In the event of any requests for access to, or correction of information, Microquest will do the following:

Record the specifics of the request (what, who, when, etc.), required to be in written form, and will be directed to the Microquest Privacy Officer;

Per the IMA, the Privacy Officer will refer the request to the appropriate Custodian of the data; and

The Microquest Privacy Officer will inform the applicant in writing of the final decision pertaining to the request for access / correction.

Other than as expressly permitted under the Agreement with the Custodian, Microquest will not disclose, allow access to, or use of, Health Information by any Person unless compelled pursuant to an order of a court in Alberta of competent jurisdiction in accordance with Section 6 (Disclosure Compelled by Law).

Alberta Netcare

If a clinic physician or staff member suspects an error in the demographic data or inaccurate clinic record (e.g. lab test) for a patient in Netcare, they can report that record:

To Netcare by selecting the Data Inquiry button within Netcare. A pop up window will appear and the user is asked to complete the various fields - include a description of the suspected problem in the Message box, and the user’s e-mail address if a response is required. The Request a read receipt check box can be selected for confirmation that someone has looked at the data inquiry request;

To the HIA help desk by calling (780) 427-8089 (or toll free 310-0000) or emailing to hiahelpdesk@gov.ab.ca; or

To Alberta Health Services, Patient Concerns: 1 (866) 561-7578 or locally
(780) 735-0333.

The Netcare Data Integrity team will investigate and work to resolve any possible errors with the source system. It is critical that demographic information be kept up-to-date, and that clinical records are accurate in Netcare.

If a patient makes a request for correction or amendment of other information in Netcare and the clinic physician or staff member feels that request is valid, then the physician or staff member can make a request for change as indicated above. The custodian who entered the information into Netcare is the one that has to make the correction or amendment. They must make the determination in each individual case whether or not the correction is warranted, as per the Health Information Act.

Reference: Section E: Attachment 1: Health Information Privacy and Security Manual - Privacy Breach Reporting Procedure

Section C: Project Privacy Analysis

Project Health Information Listing

The Click here to enter text. collects data from numerous sources including but not limited to participating physicians / clinics, Click here to enter text., AHS, Research Groups, Pharmacies and individuals in the community searching for physicians.

Data collected may include, but not be limited to, personal demographics, diagnostic and treatment information, pharmaceutical information and program information.

The contents available in the dr2dr Secure Messaging System can include any and all information that is potentially contained in a patient chart with due regard for expressed wishes and other related restrictions for patient confidentiality, privacy, and safety purposes as allowed under professional standards for health professions and applicable privacy legislation. The dr2dr Secure Messaging System users will determine what data other users will see as part of the messaging process.

Communications using the system may include the following personal health information:

Registration information

Personal demographics of patient as provided to the originating health service provider from any or all of the following sources:

Patient; and

Referral providers

The communications will usually need to identify the patient involved when said communications is between health care providers and needs to reference the patient for context purposes.

Patient identity information can include name, address, contact information, personal health number, and any other such registration information relevant to facilitating the communication’s conversation between health care providers or between a health care provider and patient.

Diagnostic, treatment, and care information

As provided by the originating health service provider.

Medical history or diagnostics / care information may be included as part of targeted communications between health care providers over the secure messaging system such as detailed in this PIA. The type of information included will depend entirely upon the nature of the communications just the same as a phone conversation or fax conversation between providers or provider and patient will vary with nature of the communications involved (i.e. contacting patient with medical history question, referral/consult related communications between providers, etc.).

In summary based on the above information, a secure message may include:

Registration	Diagnostic, Treatment and Care Information
Patient name** Address Phone number (home) Phone number (work) Additional contact numbers (cell, pager) Sex Date of birth Personal Health Number** Contact name Contact relationship Contact Address Contact phone numbers (home, work) Alerts Pharmacy Chart Number**	Family and social history Past medical history Immunization history Medications Allergies Lab orders and results Problem list Vital Stats Progress notes Consults Diagnostic imaging reports Health service provider information (physician name, provider ID**; referring physician name, referring Dr. ID**)

** Unique identifier

Figure 1 – Patient Demographic Capture Within dr2dr

Project Information Flow Analysis

Dr2dr Secure Messaging Technical Information Flow Diagram

General Technical Information Flow

User logs into Microquest Secure Web Portal linking user to server over a 256-bit encrypted SSL 3.0/TLS 1.2 connection using minimum 8 character strong password with at least one upper case and one number character in it for single factor authentication.

User creates message to send using contact list or new contact invite dialogue to designate the receiver, filling in secure and unsecure component fields with message parts as appropriate as well as attaching documents for secure viewing if they are part of the message.

Upon hitting send, the server generates a message-waiting alert and sends it along with any unsecure message component to the receiver’s regular email account (or initiates a new user invite to the same regular email account if message is sent to a non-user).

The receiver, upon receipt of the message-waiting alert, either initiates the new user dialogue to establish a new account (with birth date as identity verification tool for patients invited to establish an account), or the receiver as an existing user logs into the Microquest Secure Web Portal to link to the server.

Once either of the above steps are completed (new user or existing user), the receiver is able to view new messages and their secure contents (message and documents), manage messages, and send responses in the same manner if desired.

**See Section D: Project Privacy Risks and Mitigation for detailed risk assessment and related security/safety measure

Legal Authority and Purposes Table

The HIA permits health care providers to collect, use, and disclose health information with consent, and in specific cases, without consent of the patient whose information is involved (Sections 22, 27, 34, and 35).

Below is our information flow diagram and related authorities for collecting, using, and disclosing information in accordance with the provisions of the HIA.

Click here to enter text. Microquest Secure Messaging System Medical Information Flow
IT Service Provider	Account support
Other Health Service Providers	Send / receive messages
2 3
Secure Messaging System
1
Custodian / Affiliate	Send / receive messages

Info Flow	Description	Type of Information	Purpose	Legal Authority
1 and 2	Custodian to Custodian (possibly sent or received by representative affiliate for either) – clinic care conversations Patient information shared with or without consent as appropriate to purpose of conversation	Patient Registration, Scheduling, and Diagnostic, Treatment and Care information	COLLECTION Providing health services to the patient and related purposes in accordance with HIA USE Providing health services to the patient and related purposes in accordance with HIA DISCLOSURE Providing health services to the patient and related purposes in accordance with HIA	HIA sections. 20, 22, 24, 27, 28, 34, 35, 36, 43
3	Custodian to System Service Provider Support and Help Desk	User account registration information – user identity/name and email address	USE Technical support to user accounts	HIA section 60

Data Transfer

Data retained within the dr2dr system can be exported / saved in the Portable Document Format (.PDF) for incorporation into other areas / systems that the User deems applicable. The User is presented with notice that this data, once saved to a .PDF document, is no longer secure and must be treated as such.

It is anticipated that the saved data be used to retain a record of the secure messages within the User’s EMR system. Once the .PDF is incorporated into the EMR system, it should be deleted from the User’s computer. Alternatively, the .PDF file can be printed and added to a patient’s paper record.

Notice

Our clinic Privacy Practices - Section 3, states: “Every time the clinic collects individually identifying health information from the individual, the individual must be informed of the purpose for which the information is collected, the legal authority for the collection, and the title, business address, and telephone number of the Clinic Privacy Officer (or a staff member) who can answer questions about the collection”. Our Clinic provides this notification by means of a sign or verbally as appropriate.

Project Consent and Expressed Wishes

Health information shall only be used and disclosed for the purpose for which it was collected, unless alternate use or disclosure is authorized or required by law, or with the knowledge and consent of the subject individual. When requesting release of their health information usually the patient has signed a third party consent form (e.g. lawyer, insurance company).

Under the HIA, patients may make an express wish to limit access to their health information. Custodians must consider an individual’s expressed wishes when accessing, using or disclosing their health information. The dr2dr system has the ability to handle expressed wishes by restricting who can access a record within the dr2dr system by controlling access to the Inbox in which the messages regarding the patient are retained. For example, a physician could choose to use their own personal Inbox rather than the clinic Inbox so that clinical staff does not have access to the patient messages. All mailboxes being used are strictly internal to the dr2dr application. NO outside mailboxes are allowed.

Project Data Matching

Data matching is defined under HIA [s.1(1)(g) as meaning “the creation of individually identifying information by combining individually identifying or non-identifying health information or other information from 2 or more electronic databases, without the consent of the individuals who are the subject of the information.”

Data matching is not done in the dr2dr system. All patient data that is added to the dr2dr system is done independently and not linked to any pre-existing data within the system.

Contracts and Agreements

Microquest has entered into an agreement with the Custodian. In particular, Microquest is an Information Manager in relation to the Custodian. The relationship between the Custodian and Microquest has been established through an End User License Agreement (EULA), which meets the requirements of section 7.2 of the Health Information Requlations. This agreement has been accepted by the Custodian upon registration / account creation with the dr2dr system.

Within Microquest, confidentiality and security of information are addressed as part of the conditions of employment for staff, and staff are made aware of and appropriately trained with regard to, policies and procedures for safeguarding information. These are policy requirements per our Health Information Privacy Practices and Policy #5: Information Handling.

All Microquest staff, including volunteers and contracted personnel, that collect, use, or disclose confidential information as part of the performance of their duties for the clinic are required to sign a confidentiality agreement.

Use of Health Information Outside of Alberta

The dr2dr system will not involve use of health information outside of Alberta. The application software, server, data, etc. will be hosted offsite by Microquest in Edmonton, Alberta with a secondary failover site in Calgary, Alberta. The Microquest help desk is located in Edmonton, Alberta. The help desk does not retain (save, print, store, etc.) the individually identifying information after a problem is resolved. Our IMA addresses inter-provincial transmission of health information, and requirement that it not be transmitted out of Canada.

Section D: Project Privacy Risks and Mitigation

Access Controls

User access / permissions within the dr2dr Secure Messaging System can be modified on a per inbox basis. This allows users to have differing access depending on which inbox (e.g. clinic or physician) that they are currently working under. For example, it is plausible for a user to have Modify/Create permissions on the clinic inbox, but only View access to a physician inbox.

System access is achieved via a User ID and Password, along with two-factor authentication in the form of temporary 6-digit codes delivered via either SMS / text message, email, or the Google Authenticator application. Passwords must contain at least 8 characters, at least one upper and one lower case character, at least one number, and at least one special character.

Role based Access to Health Information by clinic staff:

Position & Job Title	User Role	# indivs in this role	Type of access (Read, Write, Edit)	Description of information this user can access
Clinic Staff	User	Click here to enter text.	Read/View/Move - all messages	E-mail communications
Clinic Administrator (only assignable by physician)	Administration	Click here to enter text.	Read/View/Move - all messages Create/Write/Edit – all messages Add/Edit/Delete - users	E-mail communications
Physicians	Doctor	Click here to enter text.	Read/View/Move - all messages Create/Write/Edit – all messages Add/Edit/Delete - users	E-mail communications

Available Permissions

User accounts can be given access to the following options on a per-user, per-inbox basis:

View Secure Messages

Move Secure Messages (e.g. to a different folder/filter)

Modify Secure Messages (i.e. reply/respond)

Create Secure Messages

Add a User Account to the inbox

Edit User Permissions within the inbox

Edit User Info within the inbox

Delete a User Account from the inbox

Figure 2 – User Permissions within an Inbox

Within an inbox, there must always be an Administrator account that has full User Control permissions. This account is either the physician custodian or the delegate and this is enforced during the sign up process. The Administrator account can then add / remove users and their associated permissions as needed.

System Administrators

System Administrators exist within dr2dr Secure Messaging System and are limited to a small number of Microquest staff. These accounts have full access to the system including individual inboxes.

Access Control Safeguards

Once a physician has access to dr2dr, access for other users (e.g. clinic managers, staff, etc.) is done on an invite-only basis through the physician's account.

Users must be invited to dr2dr through a physician or clinic administrator.

Clinic Administrators can only be assigned by a physician. They can, in turn, invite other users to the system.

Access for Microquest employees’ access to the dr2dr data / information is limited to those employees that require it. Currently this includes the development manager, senior developer, and vice president. Once access is granted, the Microquest employee will have permissions that are relevant to his / her tasks.

To help control access to the system, there are numerous safeguards in place:

All activity within dr2dr is full tracked and auditable. Every piece of data that is accessed is retained along with the account information and date/time of the access. This information can be retrieved in case of a breach.

System Administrators also have a standard administrator account for performing administrative tasks and a limited privilege account for non-administrative tasks.

Passwords are to be kept confidential at all times and should not be written down, posted publicly, or shared with other staff except for security purposes. Unique passwords or other authentication controls are required for dr2dr. A strong password standard is used.

When a clinic employee or physician leaves the clinic, their dr2dr access is cancelled or inactivated. dr2dr user rights and accounts are assigned and maintained by the inbox Administrator and / or the System Administrator.

When a Microquest employee leaves the company, all of their accounts are suspended / locked out, including their dr2dr accounts. This includes domain and email accounts, server access, etc. their dr2dr access is cancelled or inactivated.

ISO 13485:2003 Development Process

Microquest Inc. is an ISO 13485:2003 (Medical devices - Quality management systems) certified company. As part of the certification process, a quality management system was developed and put in place within the company and is applied to all of our development processes, including dr2dr. This quality management system was also developed following the guidance of IEC/TR 80002-1, Guidance on the application of ISO 14971 to medical device software. As such, during the development process, a full risk analysis is performed and the results recorded.

Privacy Risk Assessment and Mitigation Plans

Risk can be mitigated through the deployment of controls which will lessen either the likelihood or consequence of a privacy breach. In addition to mitigating risk, an organization can choose to avoid the risk by not undertaking the activity, transfer the risk to another entity or accept the risk.

The Risk Assessment Table included in our PIA submission identifies risks associated with both privacy and security. Privacy risks cover areas such as health information collection, use, disclosure, retention, access, accuracy and governance. Security risks cover areas such as confidentiality, integrity and availability. The risk assessment product score reflects the risk level without any mitigation measures.

The risks are grouped into six causes:

People - internal Privacy/security not well understood; information accidentally or otherwise disclosed to unauthorized individuals; inappropriate network access/usage; an act of sabotage (disgruntled current or former staff member); unauthorized internal access (staff see information they are not authorized to see); access is not limited; information accidentally or otherwise disclosed to unauthorized individuals (terminated employee whose access to information systems was not removed); unauthorized use of information by an authorized user (vendor staff); unauthorized access (user shares his login and password with another user).	People - external unauthorized access by a contractor; loss of information availability / information control (data held by contracted service provider – data centre); contracted service provider breaches confidentiality; access to information by contracted third parties; disclosure of information (risk of loss / theft of data from contracted service provider); excessive collection of information by vendor when providing contracted services physical damage / theft (fire, flood, malicious action, equipment failure); unauthorized/unintended loss of data by vendors; unauthorized external access due to lack of implementation of planned administrative, technical and physical controls.
Technology - internal information is accidentally or otherwise disclosed to unauthorized individuals (use of malicious software such as spyware; passwords are intercepted in transmission; etc.); unauthorized internal access (individual downloads information they do not need to know); physical damage/theft, unauthorized/ unintended loss of data (loss of a portable device that is not encrypted); unauthorized use of health information by an authorized user.	Technology - external unauthorized/unintended loss of data (system crash); information is unavailable when needed (loss of internet service or power at data centre, etc.); unauthorized internal access (passwords not regularly changed and become known) data modification; disclosure of information (unauthorized access to electronic information by an external hack); unauthorized/unintended loss/theft of data (interception of transmission of data);
Physical Security - internal physical damage/theft (use of doors alarms and motion detectors to prevent or minimize unauthorized access to the office to protect computer equipment); unauthorized / unintended loss of data (public access to sensitive areas of the office, unlocked shred bins).	Physical Security - external unauthorized/unintended loss of data (accidental harm in data centre to servers); loss of information availability/loss of information control (loss of timely availability to network due to fire).

Data Retention

All data entered into the dr2dr Secure Messaging System is retained for a minimum of 10 years following the date it was created, or in the case of a minor patient, when the patient reaches 20 years of age (two years past the age of majority) if that is longer than 10 years. There is no mechanism to remove data from the system; it is always available, although it can be categorized as “Archived”. If / when a physician chooses to leave the system (e.g. retires, account cancelation, etc.), read-only access to their account will be provided for a nominal fee.

Data Export

Physicians have the option to export their data from dr2dr in Portable Document Format (PDF). This option will be available at no charge to the physician and will contain the contents of all secure conversations that the physician’s account has access to within the dr2dr system. This information can then be placed in their EMR.

Monitoring

The Microquest Privacy Officer is responsible for information privacy and security, including ensuring that appropriate administrative, technical, and physical security features are in place to protect health information.

All violations or suspected violations of privacy and security must be reported to the Microquest Privacy Officer immediately. Affected users will be involved and consulted with as necessary depending on the level of gravity of the breach / violation.

To detect unauthorized access and prevent modification or misuse of user data in applications:

Use of the dr2dr system will be monitored by the Microquest System Administrator. All users and occasions of use are logged by time and date. Audit and access logs will be checked by the Microquest System Administrator on a quarterly basis, if a complaint is made, or breach of security or privacy is suspected.

Individual users do not have access to the application logs. Should a user have an issue and require an investigation, they have the right to request the access logs that are pertinent to that individual. This request is made by the user to Microquest’s Privacy Officer who will obtain the relevant logs.

Use of the Microquest internal network will be monitored by the Network Administrator for security incidents (e.g. automated account lockouts due to invalid password attempts, etc.)

Microquest will monitor firewalls and systems regularly for unauthorized access attempts. All alerts from IPS and IDS are routed to a centralized monitoring system and dispatched to the Network Administrator. In addition, all employees are responsible to report suspected security breaches to the Privacy Officer.

PIA Compliance

Microquest has appointed a Privacy Officer who is responsible for information privacy and security, including ensuring that appropriate administrative, technical, and physical security features are in place in Microquest offices and dr2dr data centre to protect health information.

The HIA section 62(1) requires custodians to identify a contact person who is responsible for ensuring compliance with the Act. The Microquest Privacy Officer shares the responsibility and is designated as the responsible affiliate for the purposes of the HIA.

The responsibilities of the Microquest Privacy Officer are outlined in our clinic Health Information Manual, Health Information Privacy Practices, point #6. Specific PIA compliance duties include:

Promptly investigating all instances of privacy complaints and breaches using Microquest’s Privacy Breach Management Procedure, and taking appropriate remedial measures for substantiated complaints, including where appropriate, amending existing policies and practices, or staff disciplinary action;

Ensuring the dr2dr PIA is updated periodically to reflect any physical, technical, or administrative changes that may affect the collection, use or disclosure of health information in the Physician’s care or control per HIA;

Ensuring that privacy and security policies and procedures are developed, regularly reviewed, and maintained as necessary;

Ensuring that Microquest staff and contractors are aware of their responsibilities and duties under HIA;

Ensuring the overall security and protection of health information in the custody or control of Microquest per HIA s.60; and

Representing Microquest in dealings with the OIPC of Alberta.

Section E - Policy and Procedure Attachments

General Privacy Policies

Our organization’s general privacy policies are as outlined in our existing PIA submission.

Attachment 1:	Microquest dr2dr Secure Messaging System Risk Assessment Table

Click here to enter text. – Risk Assessment Table for dr2dr Secure Messaging System

RISK	PROB.	SEVER.	DISCUSSION & MITIGATION STRATEGIES
Unauthorized Internal Access Unauthorized access to patient information by internal personnel, from within facility or through intentional remote terminals.	Low	Med	One of the inherent risks to medical information is that its access and exposure can be highly revealing. Whereas de-identification might otherwise be a mitigating strategy, patient identification is often embedded directly in records or files, as a precaution against medical mistakes or through the nature of the medical condition and treatment resulting. In the secure messaging system case, identification embedding has the added dimension of potentially being included in both the addressing and body of the message being sent. The primary risk of unauthorized access by internal personnel is focused on access to user accounts. If a user grants another person access to their user account or accidentally leaves it logged in so another user can come in behind them to use the account or view information within the account, this can be considered to constitute a breach of patient health information. Risks of unauthorized internal access are mitigated by the clinic by first ensuring each person authorized to send or manage communications as custodians or responsible affiliates of same have their own user account. The risk is further mitigated by ensuring proper clinic-wide training to users on appropriate safeguard measures including password protection, password change, user account logout upon completion of task, and similar steps. The risks are further mitigated by vendor system measures limiting pathways to how accounts can be established, the fact that other users including custodians can see who has user accounts within their organizational group through the contact list, system timeout, proper use guidelines and reminders, Microquest limiting internal access to the development manager, senior developer, and vice president, and other such steps.
Unauthorized External Access Unauthorized access or disclosure to external party (on or off premises).	Low	Med	Exposure of personal information from outside the clinic is limited to risk routes through user account compromise, physical compromise of data centre / system security measures, and miss-sending of information to the wrong recipient. User account misuse can result from poor account identity and password protection, leaving the account logged on or logging on in a non-secure network or usage environment (i.e. laptop used on open network and / or left unattended in coffee shop), or sharing of account information with non-clinic persons. This risk is mitigated through clinic privacy and security policies and user training on same. Data centre / system security measures can be compromised by hacking attempts to the system if the hacking entity is determined enough and has tools and approaches not anticipated by and able to get around current security and safety measures as employed by the vendor and data centre. This risk is reasonably mitigated by both the vendor and data centre maintaining an ongoing program of reviewing developing risk / threat vectors and scenarios and regularly updating security and safety measures to account for same in accordance with IT industry security best practices. All activity in dr2dr is logged and monitored on a regular basis, looking for hacking attempts. Additionally, dr2dr regularly undergoes a complete third party security audit, including intrusion attempts and penetration testing. The miss-sending of communications (and thus potentially health information) to the wrong recipient can occur in the same manner as fax messages can go to the wrong recipient. Measures to mitigate this risk include in-system reminders to verify addresses before sending messages, and regular re-confirming of addresses with health service providers and patients in accordance with clinic privacy and security policies. The vendor has policies and procedures in place that prohibit the help desk from retaining information after a problem resolved; that address security of information communicated between service environment and clinics; regarding the use of technical controls to secure information in transit; and or the monitoring, detection, analysis, and correction of intrusions. All data stored in the database can only be modified by the database software itself. Other data retained on the hard drive is encrypted and protected by active virus / malware scans. dr2dr itself is primarily a data entry system with no mechanism to modify data (e.g. conversations, attachments, etc.).
Unauthorized Use of Information Risk of improper use of patient information that has been otherwise legitimately collected and retained.	Low	Med	This risk is a secondary concern as it flows out from the preceding two risks (unauthorized internal or external access / disclosure). As such, it is mitigated by the same measures. One additional concern is misuse of information by the same persons in the above risk scenarios if they are not complying with expectations of proper use of health information as outlined in their obligations to the custodian. This risk is mitigated for internal staff and contractors by in-clinic training on privacy and security including related policies and procedures and signing of a confidentiality oath with custodians. This risk is mitigated for external persons such as vendor staff through appropriate service agreements and vendor privacy and security training and policies.
Data Modification Risk of unauthorized modification of patient health information.	Low	Low	There is minimal risk of data modification as messages sent are recorded by user accounts and audit logs accordingly. Users can only delete, archive to folders, or reply to messages, not modify their contents once sent. This risk does not account for deliberate modification of data outside the system’s borders including failure to input information accurately into the messaging system or failure to copy information accurately from the messaging system to external records. Those risks are the responsibility of the clinic and custodians and lie outside the scope of this project to mitigate. All files uploaded to dr2dr undergo a virus / malware scan on the server through ClamAV. If a virus / malware is detected, the file is not uploaded. All data stored in the database can only be modified by the database software itself. Other data, retained on the hard drive, is encrypted and protected by active virus/malware scans. dr2dr itself is primarily a data entry system with no mechanism to modify data (e.g. conversations, attachments, etc.).
Unauthorized Destruction, Unintended Loss, & Unavailability of Data Interruption to normal operation (e.g., infrastructure failure, system error) can mean that information is not available. More drastic are the risks of permanent damage to data integrity and outright loss.	Low	Low	There are two primary risk vectors for this category, improper deletion of messages by users before information has been properly transferred to a more permanent record set (i.e. chart) or loss of access to systems due to data centre accident / incident including hacking, physical threats, and technical threats. This risk is mitigated through system and data centre protection and redundancy measures including redundant servers, drives, and power supplies, data centre physical and technical security and safety steps, onsite and offsite data and system backup steps, and vendor disaster recovery plans. All data stored in the database can only be modified by the database software itself. All uploaded are scanned by antivirus software and will not be uploaded if any is detected. dr2dr itself is primarily a data entry system with no mechanism to modify data (e.g. conversations, attachments, etc.).
Physical Damage / Theft Risk to system infrastructure due to man-made or natural hazards such as, flood, power outage and sabotage.	Low	Low	Physical theft and damage risks are isolated to in-office equipment and data centre equipment. Theft of in-clinic equipment used to access user accounts and possibly download health information from messages to the same are the responsibility of the clinic as covered in the clinic’s existing PIA submission and are outside the scope of this project PIA. Physical theft of vendor office equipment used to manage the system presents minimal risk to custodians and health information as vendor system administrators have no direct access to health information in user accounts. Physical theft or damage to data centre equipment is of limited risk due to the large array of measures in-place including physical security barriers, video surveillance, biometric and card ID access controls, hardware locks, and audit logs monitoring these measures. Physical damage risk due to accident/incident is limited by similar measures, fire detection and suppression measures, backup power supplies, and adequate ventilation. Technical damage risks from hackers and intrusion are limited by robust and regularly updated technical security measures including intrusion prevention devices, firewalls, malware detection and protection software, etc. Impacts of damage or theft are further mitigated by ensuring redundant hardware and onsite and offsite system and data backup services are in-place.
Retention and Disposition of Data Retained and archived information is at risk for unauthorized access, disclosure and loss, including inappropriate asset handling at redeployment, sale or destruction.	Low	Low	Risks associated include loss of user accounts through technical or physical damage, deletion of accounts or information within them, and improper disposal of information deleted on hardware storage devices. Mitigating measures to ensure retention include redundant drives as part of the overall system configuration and onsite and offsite data backups with a 10 year retention of backed up information (or until such time as custodian / vendor relationship is terminated). Deleted information is able to be recovered by system administrators through the backups as well by restoring a user account to a previous save point with system administrator controls to ensure newer data since the restoration point isn’t lost in the process (i.e. data merger). Improper information destruction is prevented by vendor and data centre policies and procedures governing steps to be followed in deleting accounts and information post-relationship including offering the customer copies of data to be destroyed before any such permanent action takes place. These same policies and procedures also govern proper disposal of storage media that is retired or replaced due to failure of same.
Contracted Third Parties Risks associated with access and disclosures to contracted third parties.	Low	High	Associated risks include improper collection, use, storage, and disclosure of information in the hands of contracted third parties involved in the secure messaging system including vendor staff and contracted data centre staff. Improper conduct of vendor staff risks are mitigated by company privacy and security policies and procedures, related training, and audit trails to actions taken. This is further mitigated by the fact that system administrators have no access to user account data and user accounts have audit log trails tracking actions within the accounts. Access by company database developers presents a greater risk due to their ability to access raw user data within the database. This risk is mitigated by the limited number of people acting in this role and the fact that developer access to the database is tracked by an independent audit log system that the developer has no access to; only management does. Data centre personnel wrongful activity risks are mitigated as detailed in previous risk categories concerning data centre administrative, technical, and physical safety and security measures including appropriate agreements with obligations spelt out between data centre and vendor for same. This risk is further mitigated by the fact that the database is encrypted at rest, and communications between the database and user Web browsers is encrypted in motion.
Privacy Not Well Understood Privacy and security is not well understood by physicians / affiliates.	Low	High	Users are provided initial training in the use of the system, online training and a user handbook that includes privacy training. Each clinic has policies and procedures in place that include specific information pertaining to privacy and security. Physicians and affiliates who have access to the dr2dr system are able to refer to their clinics’ Privacy Officer for guidance and information pertaining to privacy and security in regards to using the system.

Attachment 2:	Microquest Client Security and Privacy Policy

Microquest Security & Privacy Policy

Introduction

As a provider of services to the healthcare industry, Microquest Inc. has a responsibility to ensure that the privacy of our clients and their patients is maintained at all times. This responsibility extends beyond the standard vendor-client privacy issues. Through the course of our duties, we have access to not only client information, but also confidential patient records. Extra care must be taken to ensure that patient information is protected, and that only the Microquest personnel that require it, get access to this data.

This policy will detail the roles and responsibilities of who gets access to client and patient data, how the data is to be protected, handling procedures, and disposal methods for any storage media that may contain client or patient data.

1. Roles & Responsibilities

By definition, all roles listed here will ensure that client and patient data is protected from unauthorized access, damage or destruction, and client/patient privacy will be maintained at all times. Only data that must be accessed will be accessed, and no unnecessary copies of client or patient information may be taken.

All Microquest employees and contractors are required to sign a non-disclosure agreement, which includes protecting any client information they may be exposed to during the course of their duties.

Microquest uses the same user ID and password requirements as those implemented in the dr2dr program.

The following Job descriptions are also the roles defined for our internal network security.

Title: Privacy Officer

Role: To create, oversee and maintain the privacy policies within Microquest Inc.

Responsibilities:

To address all privacy concerns within Microquest as they apply to client and patient data being handled by Microquest personnel and ensure that privacy regulations and requirements are adhered to.

Educate Microquest staff as to their responsibilities in the handling and security of client and patient data.

Maintain the Microquest Privacy Policy and update it as required

Regularly review all security logs on Microquest systems.

Regular review of all copies of client data in possession of Microquest and the related logs. Any data no longer in use should be deleted from any Microquest computers.

Maintain Microquest’s internal network and application security.

Regularly review all user and role based security settings on the Microquest network, ensuring any client data may only be accessed by the users who “need to know”.

Title: IT Manager

Role: To maintain the security and operation of the Microquest internal network.

Responsibilities:

Update and maintain all hardware aspects of the Microquest internal network including servers, workstation and all peripheral devices (such as printers) attached to the network.

Update and maintain the software systems used on the Microquest internal network.

Update and maintain all security aspects of the Microquest internal network including firewall hardware and anti-malware software.

Update and maintain user access to the Microquest internal network ensuring that only authorized personnel are allowed access to the system.

Ensure a risk assessment is performed before updating any hardware or software systems.

Title: Software Support Technician

Role: To troubleshoot and resolve any problems clients may be having with operation or understanding of dr2dr.

Responsibilities:

Ensure that any client or patient information they may be exposed to as part of their duties remains confidential.

To ensure that when accessing a client system, the integrity of the client’s data is maintained and that all accesses are logged.

To ensure that the client personnel being helped has the required access to be viewing or working with that information.

Title: Client Services / Training

Role: To market and sell dr2dr to new clients, and train the end users on the proper use of dr2drin the clinic.

Responsibilities:

Ensure that any client or patient information they may be exposed to as part of their duties remains confidential.

All training will be done with the end-user logged into the dr2dr software, ensuring each user has only the access granted by the Clinic Privacy Officer.

Training should be performed with fictional patient records (when possible) to ensure privacy of actual patient information.

Title: Software Programmer

Role: Maintaining and updating the dr2dr software.

Responsibilities:

Ensure that any dr2dr modifications do not affect personal privacy.

Ensure that any modifications that may potential affect personal privacy should:

Increase the security of the information; Or

Be a “switchable” function, disabled by default until the clinic has revised their PIA

2. Information Handling and Security

Client data may be in electronic, portable or hardcopy format. No matter what the format of the data is, it must be handled and protected. The following policies will describe the procedures to be followed.

Type: Electronic

Description: Electronic data is considered to be any data that resides on servers or computer hard drives used by, or in possession of Microquest Inc., and can be transmitted or moved via networks or Internet systems.

Handling Procedures:

Electronic client data must not be exposed to unprotected networks or transmitted in an unencrypted format. Due to the nature of the systems involved, care must be taken to ensure that client data is not changed, corrupted or deleted from its original format.

Anti-virus systems will be updated regularly to protect client data from infection and/or corruption. Client disks must be scanned for viruses or other malware before moving to an electronic format (i.e. copying a database for conversion) and again after writing to disk for transport.

When the task requiring Microquest to have copies of client data is completed, all client data will be deleted from Microquest computers.

Type: Portable

Description: Portable data is considered to be any floppy disk, CD, DVD, tape, external hard disk, and flash ram or any other means of storing data for the purpose of transporting, backup or storage.

Handling Procedures:

Disk and tape based data storage are vulnerable to a variety of damaging forces. Static electricity, magnetic fields, heat and cold are a fact of everyday life and are all around us. Care must be taken that when handling and transporting these media to use proper containers, and not leave them in areas where they may be exposed to these dangers.

Due to the convenience and portability of these media, keeping them secure is essential. This means they must be protected, not left unattended, and disposed of properly when no longer required.

Portable media will be scanned for viruses and other malware before use in Microquest systems, and again before being returned to clients. All such scans will be logged.

Type: Hardcopy

Description: Hardcopy data is any client data that is printed to a non-erasable media such as paper.

Handling Procedures:

All hardcopy data will be protected the same as portable media, and disposed of properly when no longer required. Due to the ease of creating hardcopy, care must be taken to account for all copies that may be produced.

No hardcopy data will be taken from a client site without the expressed consent of the client and will be returned when no longer required. No copies of client papers will be made without their expressed consent.

3. Collection, Use and Disclosure of Information

Microquest employees may only collect client and patient data, when required and as part their job roles as specified in section (1). Any data collected may only be used for the required task and must be stored securely. Any data collected may not be disclosed to any outside parties without the expressed written consent of the client. No data will be collected before a valid Information Manager Agreement has been signed with the client.

Collection

Data can be collected in a variety of methods such ad CD-R, flash drive or external hard disk. All media to be used in the collection of client data will be scanned for viruses and other malware before connecting to a client’s system. The amount of data to be collected and the availability will determine the type of media to be used. All removable media will be scanned for viruses and other malware before using it on any Microquest system. All data collected will be encrypted using an approved 128 bit standard.

Hardcopy (paper) data may only be collected with the expressed consent of the client. A log will be kept of client data collected noting the date, time, place and person doing the collecting, the reason for the collection, and a description of the data collected.

Storage & Security

Client data collected on removable media must be stored in a secure fireproof container that is rated for computer media, when not in use. Such containers must be kept in a secure area. Hardcopy data must also be stored securely when not being used. A log will be kept noting access to client data from secure storage.

Use and Disclosure

All client and patient data is confidential and will only be accessed on a need to know basis. Client data is never to be disclosed to outside parties without the expressed written consent of the client. All use and disclosure including, in-house, will be logged.

4. Third Parties

Where equipment maintenance requires the release of components that may contain personal health information, these components shall not be released to a third party unless the personal health information has been permanently erased or encrypted. If it is not possible to erase or encrypt the data, the third party must be bonded. Except for rare exceptions, client and healthcare data is never to be disclosed to parties outside of the Province of Alberta. In these rare exceptions, and Information Manager Agreement will be signed with the Third Party.

The Information Manager Agreement used will comply with Health Information Regulation 8(4) by including the following:

a. A statement that the Custodian will retain control over the Health Information being transferred.

b. Any risks associated with the storage use or disclosure will be addressed as listed in Part 4 of this document.

c. A statement that the third party to whom the Health Information is to be transferred to must implement and maintain security safeguards.

d. A statement that the Custodian may monitor all terms of the agreement to ensure compliance.

e. Remedies for non-compliance, or breach of contractual obligations.

5. Disposing of Client Data

When client data is no longer required, and does not need to be returned to the client, it must be disposed of properly. The format of the data will determine the proper disposal procedure.

Type: Electronic

Disposal Procedure:

Electronic data can be deleted from the hard drive as long as the system the hard drive is in is still in use. Other media such as flash drives and external hard drives may be reformatted if they will be reused. If the media is ever to be disposed of, it must be physically destroyed by crushing or other mechanical means that will ensure it can never be read again. No hard drive or other electronic media that has ever contained client data will ever be sold or thrown away. It must be physically destroyed.

Type: Portable

Disposal Procedure

Portable media that contains or had contained client data and is no longer required must be physically destroyed by crushing. Backup tapes may be reused in the same system, but must be destroyed by crushing when their usefulness has ended.

Type: Hardcopy

Disposal Procedure:

All hardcopy data that contains any client information will be destroyed by shredding and then disposed of by a bonded recycling company. It may be included with other documents to be shredded. No paper that has client or patient information will be disposed of at home or any other location.

Special Note: Due to the ease that hardcopy can be created by printing or even just writing on a scrap of paper, ALL waste paper at Microquest must go into the special bin setup for the purpose of shredding and disposal. At no time will ANY paper be disposed of in the regular garbage.

Last review and/or revision: April 2016 by Kim Brown

Attachment 3:	Microquest Software Development Policy

Quality System Procedure

Software Development

QSP 7.3-1 r9

Change History:

rev	change	minor/ major	by	Effective Date
r1	Initial release	major	Kim Brown	2010/07/29
r2	Clarification of Verification and Validation; added deliverable 6.2.4 Risk Management Report; modified deliverables to reference Serena Business Mashups	minor	Brandon Blanck	2010/09/13
r3	Regression testing moved to validation; Clarification of Traceability Matrix (reference to SCR); Clarified risk control measure and written test procedure; Re-order code review items; Reference to VSS for DHF	minor	Brandon Blanck	2010/09/27
r4	Added reference to QSF 7.3-1C Test Report; update to Test Procedures naming scheme	minor	Brandon Blanck	2010/09/28
r5	Test Reports only contain a record of failed procedures in order to provide a summary; Full pass/fail data is stored in Visual Source Safe.	minor	Brandon Blanck	2010/10/14
r6	Test procedures electronically signed and filed	minor	Brandon Blanck	2012/11/09
r7	Fix numbering for section 6	minor	Brandon Blanck	2014/06/11
r8	Removed traceability matrix	minor	Brandon Blanck	2015/02/02
r9	Added Design Review Record; Signature approvals	minor	Brandon Blanck	2015/02/24

Table of Contents

Introduction	2

Instructions	3

Questionnaire	3

Documents	3

Submission	3

Questionnaire	4

General

Purpose

The purpose of this procedure is to ensure that Microquest Inc. (“Microquest”) software and all off-the-shelf (“OTS”) software included in Microquest software are developed in a controlled manner, are under proper configuration management, and follow a defined maintenance program according to the requirements of IEC62304:2006 Medical device software - Software life cycle processes (the “SW Standard”).

Scope

This procedure applies to the design and development of all software products at Microquest:

This procedure also applies to the validation of commercial off-the-shelf [COTS] software and software of Unknown Provenance [SOUP].

Microquest’ Software Developers must be conversant with the following standards:

IEC 62304:2006: “Medical Device Software – Software Life Cycle Processes”

This QSP does not apply to software used for feasibility (pre-Design Control) SW or non-medical SW developed by Microquest under contract. The structure of this procedure can be considered for these types of software, but it is not a requirement that this procedure is fully implemented.

Definitions

Throughout this procedure ‘SW’ means software

The definitions of IEC62304:2006 apply.

Legacy Software: Software that was designed and developed at Microquest before the effective date of this procedure.

Verification: Confirmation by examination and provision of objective evidence that specified requirements have been fulfilled. [IEC62304:2006]

Software Item: Any identifiable part of a software product. [IEC62304:2006]

Software Module: A collection of logically related Software Items. In the context of SW at Microquest this means a file containing Software Items.

Software System: Integrated collection of software modules organized to accomplish a specific function. [IEC62304:2006]

Software Validation: Confirmation by examination and objective evidence that software specifications conform to user needs and to the intended uses of the medical device, and that the particular medical device requirements implemented through software can be consistently fulfilled. [IEC62304:2006]

Source Code Management: The process of identifying and defining the software items in the system, controlling the change of these items throughout their lifecycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items. [IEC62304:2006]

Microquest distributes only one identical configuration of a SW product to all customers

Software Classification: Classification of SW product or SW Item per IEC 62304 §4.3 Software Classification

Device Classification: Classification of SW product per Canadian Medical Devices Regulation [CMDR]

Code Review: The systematic examination of source code intended to find implementation errors and to ascertain that the code is properly documented and meets internal coding standards.

Code Review must not be performed by the SW Developer/Coder alone. Ideally is undertaken by a pairing of the SW Developer/Coder and an ‘arms length’ reviewer

Overview

This procedure addresses the design and development of medical software products

SW maintenance activities are covered by QSP 7.3-2 SW Maintenance

In the overall design & development process there are a number of distinct phases that are followed more or less sequentially.

If the software is being designed as part of a larger project incorporating hardware and software element, then there is only one project plan. If the software is a stand-alone project, then the project plan will focus solely on the software.

In the overall design & development process there are a number of distinct phases that are followed more or less sequentially. At the end of each phase there is an optional review that determines if the work is in an appropriate state to progress to the next phase.

Phases

A SW project roughly follows the following phases:

Phase 1 – Planning

Phase 2 – Requirements

Phase 3 – Implementation (Coding) & Verification

Phase 4 – Validation

Phase 5 – Design Transfer (Release)

After the design transfer the SW enters the Maintenance Phase. The Maintenance Phase deals with problem resolution and minor changes. If further functionality is added to existing software it must be done under a project following this procedure.

The purpose of phases is to break down a project into a logical sequence of tasks and events. Optional phase reviews typically have both backward looking and forward looking objectives. They ask whether the project phase in question has achieved its key goals, and whether the project is ready to proceed with the next phase.

Phase reviews can be held in conjunction with project reviews at the appropriate phase of the project.

Design Documentation

Throughout the design lifecycle, the design efforts must be fully documented.

The design documentation serves as a reference for later modifications and changes.

The design documentation will be the sole source of objective evidence that the design has been conducted according to written procedures, and fulfills the regulatory requirements. The documentation will be closely examined during any regulatory audits.

GOOD DESIGN DOCUMENTATION = COLLECTIVE MEMORY!

Phase - Planning

The basic purpose of planning is to ensure that there is a clear understanding of the tasks to be undertaken and that essential resources are available when they are needed.

To arrive at a realistic plan, the three basic variables of time, resources and scope often have to be traded off against each other.

Phase - Requirements

Establishing the requirements is one of the most critical phases in the design process. It needs to be done with care and deliberation to gain the maximum benefit from design control. It is not unusual that the Requirements phase takes up to 30% of the total project time.

Depending on the scope and complexity of the design, the requirements are established in several stages. For new products the user and market requirements need to be documented as part of the Design Concept.

It is important that all requirements are uniquely identifiable and traceable to verification and validation testing. It is important that low-level (sub-system) requirements trace, directly or indirectly, to user requirements.

As part of the Requirements Phase a Hazard Analysis must be conducted following the process identified in QSP 7.3-3 SW Risk Management. Through early identification of risks and application of mitigations during early development phases, expensive design changes can be avoided and the time to successful market introduction clearly shortened. However, a complete Hazard & Risk Analysis is not a “one shot affair”, but the risks must be managed throughout the product life cycle and must be reviewed regularly. In particular, hazards and associated risks must be reconsidered every time a design change is undertaken.

During this phase the software requirements are mapped to a software design. With the exception of very small software systems, the design is performed at more than one level; Architectural Design & Detailed Design.

Software Architectural Design defines the software in terms of its major subsystems, documents the allocation of SW System requirements to subsystems (SW items) and defines the interfaces between these subsystems.

Software Detailed Design describes the design of individual SW Items or SW Units and their structure and behavior (functionality).

Phase – Implementation/Design & Verification

This phase includes coding and testing of the SW, where the software developers translate the SW requirements into code and perform the initial debugging of the software to ensure that the code is correct and consistent. Some very “local” design can take place and is documented as in-line comments.

Verification Testing is defined as the confirmation by examination and provision of objective evidence that specified requirements have been fulfilled. Verification can take place at several levels (SW Item, SW Unit, partially integrated product) but always according to written protocols.

Some high level verification may have to be left for after full system integration.

Verification should not be used for debugging purposes, that is, the primary purpose of verification is not to find errors, faults and deficiencies but rather to demonstrate that the requirements have been implemented correctly. Failed verification tests should be the exception. When verification tests fail multiple times then this is a strong indication that the design is not yet sufficiently mature and ready for testing.

Phase – Validation

Validation testing is conducted on the software after it has been compiled and integrated. The Validation Testing will involve, at a minimum, bench testing to ensure that the device meets the user’s needs and the intended use(s) is met.

Validation Testing is defined as the confirmation by examination and objective evidence that software specifications conform to user needs and to the intended uses of the medical SW Product.

Phase – Design Transfer (Release)

The Transfer/Release Phase is the final step in a project. For this phase the software developers are releasing the software and associated documentation, which is then transferred in a controlled and limited access repository from which the product is distributed.

Phase – Maintenance

The Maintenance Phase is not part of the design and development rather it is a stand-alone process whereby the software team performs maintenances activities (software upgrades, post-release bug fixes, etc.).

Source Code Management

Source Code Management is employed throughout the development cycle and continued into the Maintenance Phase to ensure that only validated and released versions of the software are distributed and that all changes are evaluated and approved prior to releasing upgrades or bug fixes

Related Documents and References

QSP 7.3-2	SW Maintenance

QSP 7.3-3	SW Risk Management

QSP 7.3-4	Source Code Management

QSP 4.2-3	Change Control

Required Approvals

Changes to this SOP and related forms must be approved by those listed under the “Approvals” section.

Responsibilities

President: The President is responsible to provide sufficient resources to ensure that the required software processes are implemented and followed

Quality Manager: The Quality Manager owns the “Software Process”, and thus is responsible to ensure this procedure is followed and all software products conform to the appropriate regulations.

Quality Manager: The Quality Manager is responsible to audit all software design projects to ensure that they comply with this procedure, and all appropriate regulations and applicable standards, including the release of project documents in the Design History File.

The SW Developers are responsible to develop maintain, and document SW products following this procedure and to release SW under Source Code control as per QSP 7.3-2 Source Code Management.

Procedure

Overall Process

This process primarily describes the required activities for the design and development of new software. Not all activities are applicable to Legacy SW and alternate or abbreviated actives are described where so warranted.

Pre-design Activities

Project Initialization

Before new projects can be initiated a summary review of what is planned, including budgets and timelines, should be prepared and approved by Senior Management and QA Manager.

The summary review and approval are documented with a QSF 7.3-1A Project Initialization.

Once the project has been approved a Project (DHF) Log is initiated. This can also be done by creating a new project in Visual Source Safe.

Design Concept

IEC 62304 §4.3 Software Classification

The Design Concept is a documented high level vision of the product, its uses, and market and user driven top-level requirements.

Before any design effort is undertaken a Design Concept is established.

The Design Concept document includes:

General Information about the product, how it fits into the existing product line and/or how it may compare against current competitors’ products

Indications for use and intended use

Software Classification

Device name including various models and options

The system concept from a construction and functional point of view

Principle of operation, its core functions and how they might be achieved

Design constraints, if any

Preliminary system requirements, based on marketing, regulatory and user inputs

The Design Concept will serve as a starting point to derive concise and verifiable SW product requirements

Legacy Software

For Legacy SW a comprehensive Design Concept is written that fully describes the product including a SW description and system specifications.

Planning Phase

IEC62304 §5.1 Software development planning

ISO13485 §7.3.1 Design and development planning

IEC62304 §4.3 Software Classification

Project Plans

A Software Project Plan is prepared for any new software project

The software development planning must include and address the following items:

SW Classification as per SW Standard §4.3 Software Safety Classification

the processes, techniques and methodologies to be used in the development

SW languages to be used for the development

actions to be taken (activities to be completed),

the deliverables of all the activities and tasks;

software configuration and change management, including SOUP configuration items and software used to support development, including programming language(s) and their compilers;

software problem resolution for handling problems detected in the software products,

deliverables (includes documentation) and activities at each stage of the life cycle;

list of development team members and their responsibilities

The plan must also include or reference planning of the following activities:

SW Requirements approach and methods

SW development standards, methods and tools (coding)

SW Integration and Integration Testing

SW Verification

SW Validation

SW Risk Management

Design and SW Documentation

SW Configuration Management

SW Release

any other items that could affect the performance or safety of the SW product

The Project Plan also includes a project timeline estimate which will be updated on a regular basis based on Project Reviews (planned and otherwise).

The Project Plan shall include all activities and tasks necessary to manage any OTS SW and SOUPs.

Project Reviews

Software projects are divided phases as outlined in Section 2.1 above. Project review meetings must be held to determine if the required activities per the Project Plan and this procedure have been met, and the project can proceed to the next phase.

Project review meetings will be conducted as per the Project Plan.

The following representatives are required to attend all Project Review Meetings:

SW Team, and

Quality Assurance

Project Review Minutes are recorded including any action items.

Approval of Project Plans

Project Plans are approved by:

President,

Project Leader(s) and

Quality Assurance

Updates to the Project Plan

The project plan must be updated as the project evolves, in particular due to project changes:

Change	How to Document
Change of project scope	Update Project Plan (release new revision)
Addition or deletion of resources	Amendment
Addition or deletion of activities	Amendment
Addition or deletion of functionality	Update Project Plan (release new revision)
Minor change(s) in milestones	Include updates in project meeting minutes or amendment to Project Plan.
Significant change(s) in milestones	Update Project Plan (release new revision)
When the following occurs approvals are required:
New Revisions	All approvers of the initial Project Plan
Amendments	Project Leader and Quality Assurance

Legacy Software

For Legacy SW a comprehensive Project Plan is written that defines and describes the activities to ensure that the SW complies with the applicable regulations and standards, and that the SW is fully documented and validated.

The Project Plan outlines the activities to be undertaken to ensure that the Legacy SW still meets the intent of the design control requirements of ISO13485:2003 §7.3 Design and Development

Deliverables

A Project Plan [P###-nnn-PP]

A Design Review Record [P###-nnn-DR]

An initial Project (DHF) Log

Hazard & Risk Analysis

IEC62304 §7.3 Software Risk Management Process

ISO13485 §7.1 Planning of product realization (Risk Management)

Hazard & Risk Analysis

As part of the SW Hazard & Risk Analysis conducted, the process must address all hazards that are associated with the software, including COTS software and SOUPs

A Hazard & Risk Analysis is performed and completed, as per QSP 7.3-3 SW Risk Management, before the SW Requirements are approved.

A Risk File is established that includes or references:

The product under consideration

SW Classification as per §4.3 Software Safety Classification.

The Risk Management Team and the designated Risk Team Leader

Risk Management Plan

If the SW contains modules (based on the architectural design) of different SW safety classifications then all modules and their respective SW safety classification are listed in the Risk File.

As per QSP7.3-3 SW Risk Management, a final review of the risk analysis is conducted after the conclusion of SW Validation and filed in the Design History File.

All Risk Management Records are added to the Risk File as they occur.

Legacy Software

For Legacy SW a complete Risk Management as above is undertaken and documented.

Deliverables

If not included in the Project Plan, a separate Risk Management Plan [P###-nnn-RM] per QSP 7.3-3 SW Risk Management

A set of Hazard Records [P###-Hnnn]

A Hazard Log

A Risk Management Report [P###-nnn-RR]

Requirements Phase

IEC 62304 §5.2 Software requirements analysis

Requirements Capture

Using methods and techniques as outlined in the project plan, all requirements for the SW product are documented.

The selection and application of appropriate methods and techniques for the acquisition and evaluation of requirements is at the discretion of the project leader.

Requirements include, as applicable:

software system inputs and outputs

interfaces between the software system and other systems

software-driven alarms, warnings, and operator messages

security requirements including risk control measures (from Risk Management and other sources)

data definition and database requirements

installation and acceptance requirements of the delivered software product at the operation and maintenance site or sites

requirements related to methods of operation and maintenance

user documentation to be developed

user maintenance requirements

For further details and notes relating to the above refer to the standard §5.2.2

functional and capability requirements, including performance

environmental conditions under which the software is to perform (these could be design constraints);

interfaces to physical components;

security requirements, including those related to compromise of sensitive information;

human factors engineering requirements (including those related to support for manual operations, human-equipment interactions,) that are sensitive to human errors and training;

the minimum system hardware and software specifications to support the proper operation of the software (these could be design constraints)

any required national or international standards or regulations.

For SOUPs and COTS SW the requirements include, as appropriate:

title and manufacturer of the software component to be used;

version level, release date, patch number, and upgrade designation to be installed and tested as part of the SW product;

functional and performance requirements to support the risk management process

functional and performance requirements that are necessary for its intended use [§5.3.3];

interfaces to the software component; and

safety-related, safety-critical, and risk control measure functions dependent on this OTS software component

the system hardware and software necessary to support the proper operation of the software component (e.g., processor type and speed, memory type and size, system software type, communication and display software requirements) [§5.3.2];

At the conclusion of the requirements capture the SW system requirements must be reviewed and updated as appropriate

At the conclusion of the requirements capture the SW Classification must be reviewed and updated as appropriate

Sometimes it may be difficult to distinguish between a requirement and a design constraint such as a mandated OS or DB engines. The distinction in itself is less important than a clear and complete documentation.

Requirements Verification, Identification & Traceability

IEC62304 §5.2.6 Verify software requirements

Each requirement is identified with a unique requirements identifier of the form Rxxx, e.g., requirement number 1 would be identified as R001.

For easier updating, the requirements can be assigned in blocks such that system requirement would be R001 to R099, hardware requirements R100 to R199, etc.

Requirement must be expressed as documented in the project plan.

It is permissible to employ different modes of documentation for different types of requirements

Requirements must be indivisible (i.e. avoid compound statements)

Requirement must not contradict each other.

Each requirement must be expressed such that it is unambiguous.

Each requirement must be verifiable.

Each requirement must be traceable to system requirements or other sources.

Each requirement must be traceable to verification & validation testing.

Architectural Design and Detailed Design

IEC62304 §5.3 Software Architectural Design

IEC62304 §5.4 Software Detailed Design

Architectural Design [§5.3]

The Architectural Design is a high-level design task that deals with the conceptual partitioning of the SW product into functional subsystems.

The Software Architectural Design must describe the software’s structure and identify the software items [§5.3.1]

The software architecture must describe the interfaces between the software items and components external to the software items (software and hardware) and the interfaces between the different software items [§5.3.2]

This may include diagrams such as:

context diagrams;

data flow diagrams;

state transition diagrams;

control and sequence diagrams;

interface/program diagrams;

data and control element definitions;

module definitions;

module interaction diagrams; and

conceptual graphical user interfaces (screens).

The software architecture design must also describe any constraints placed on the design (e.g., memory limitations) and list any assumptions upon which the design is based.

Where appropriate the AD must identify any segregation necessary for risk control including means to ensure that such segregation is effective [§5.3.5]

Where the SW classification of a SW Unit is higher than the overall classification it must be documented in the AD

Architectural Design Verification [§5.3.6]

The AD is reviewed and approved to ensure that:

the architecture of the software implements system and software requirements including those relating to risk control;

the architecture is able to support interfaces between software items and between software items and hardware; and

the architecture supports proper operation of any SOUP items.

Detailed Design

During Detailed Design the SW Architecture is partitioned and refined until it is represented by SW Items and all requirements are assigned to specific SW Items

If a given SW Items is of SW Class is B or C as determined under item 5.1.2 above, a Detailed Design must be completed.

The Software Detailed Design, if completed, must define the design of individual components or software modules and the interaction between the components/modules and the interactions between the software components/modules and external components (hardware or software).

The SW Detailed Design may be documented as plain prose, pseudo-code or with suitable diagrams. Diagrams may include the following:

context diagrams;

data flow diagrams;

state transition diagrams;

control and sequence diagrams;

interface/program diagrams;

data and control element definitions;

module definitions; and

module interaction diagrams.

The software detailed design also describes any constraints placed on the design (e.g., memory limitations) and list any assumptions upon which the design is based.

Detailed Design Verification

The Detailed Design is reviewed and approved to ensure that it:

implements the assigned requirements and the software architecture; and

is free from contradiction with the software architecture.

Legacy Software

For Legacy SW an Architectural Design, a Detailed Design (if required per 7.3.3.2 above) is completed.

Deliverables

A Requirements Document [P###-nnn-DI]

Note: Review and Approval of the Requirements Document(s) assure and document that the requirements have been verified.

An Architectural Design [P###-nnn-AD]

Note: Approval of the Architectural Design assure and document that the AD has been verified.

A Detailed Design [P###-nnn-DD], if required per 6.2.3.2 above

Note: Approval of the Detailed Design assure and document that the DD has been verified.

Implementation & Verification Phase

IEC 62304 §5.5 SOFTWARE UNIT implementation and verification

During the Implementation phase the software code is created from Requirements and Detailed Design. The programmers begin with creating the code and debugging the code.

Implementation (Coding)

Before coding commences, the SW unit is identified and checked into the Source Code Management System.

The SW units are identified by a filename consistent with the AD and consecutive revisions assigned by the source code management system (MSVSS = Microsoft Visual Source Safe)

Coding/Debugging

SW coding is the task of translating the detailed design into source code.

The SW Team employs the methods and SW languages documented in the project plan

Software testing at this phase is essentially debugging which is completed informally and continuously throughout the coding phase.

Software code created during Feasibility (research) stages can only be included in the final software code if the feasibility code has been fully documented and tested. Feasibility code must undergo the same processes as new code.

Legacy Software

All Legacy SW is put under Source Code Management and a corresponding Release Report is generated (Baseline)

Deliverables

Output from the Implementation/Design Phase is the source code. The source code is entered into the Source Code Management System as per QSP 7-3-4 Source Code Management

Integration

Current and reviewed SW Units are integrated and compiled into a executable suitable for verification and validation, as described in the Project Plan

The SW units included in the integration and their revisions are documented in the QSF 7.3-2A SW Release Report (SRR)

Verification

Since formal verification is conducted with fully integrated SW it also covers Software System Testing as required by ISO62304 §5.7

Verification is performed using strategies, methods and procedures as documented in the Project Plan.

SW Items must pass successful verification before they can be considered for validation.

Testing Procedures

When SW Units implement risk control measures (e.g. for hazard/risk management) they must be verified according to written Test Procedures.

SW Units not implementing risk control measures (e.g. standard SW Units) can be verified either through written Test Procedures or standard debugging undertaken in the SCR/Business Mashups issue.

Where SW units are verified according to written Test Procedures they include acceptance (pass/fail criteria).

The Test Procedures include, for each software requirement, procedures for conducting the testing, the expected outcome(s) of the test, and an optional set of Test Cases with inputs to achieve the desired outcome.

Each Test Case is identified with a unique identifier (TCxxx or numeric) and traceable to a requirement. A Test Case should document a single pass/fail criterion for a requirement. In cases where one test is not sufficient to test a requirement, multiple Test Cases should be used.

Test Procedures include provisions to consistently record the test results.

Such provisions may include checklists, tables, forms or may be integrated with the Test Procedure in form action and result

Required Test Procedures are reviewed and approved before execution.

For further details and notes relating to additional acceptance criteria refer to the standard §5.5.4

Test Reports are electronically signed and dated by the person executing the protocol and reviewed by the project leader.

Legacy Software

All Legacy SW undergoes Code Review, and is further tested and verified as required and documented in the Project Plan

All Legacy SW is completely verified as described above.

Code Review

The Code Review of each SW Item is documented with either a QSF 7.3-1B Code Review Record (CRR) or within the SCR.

Code Review is the minimal testing that must be performed on each SW Unit before Validation and Release

Whenever possible, code review is completed using a two-person team consisting of the SW developer/coder and an arms-length reviewer

Code Review includes the following:

Proper file naming

Consistency with the overall program design

Adherence to coding standards and style guides

Detection of flaws or potential flaws.

Sufficient documentation (in-line comments)

SW Modules must pass successful Code Review before they can be considered for Validation and Release.

Deliverables

Code Reviews [P###-nnn-CR] for each affected SW Unit. These can also be provided through Serena Business Mashups or the SCRs.

Test Procedures [P###-nnn-TP] and resulting Test Reports [P###-nnn-TRxx]. These can also be provided through Serena Business Mashups or the SCRs.

Validation Phase

Validation

The SW Validation is performed on the fully integrated, verified and compiled SW product.

Regression Testing is undertaken as part of SW Validation.

Validation Test Procedures

Validation Test Procedure for software validation is developed to ensure that the software meets the user’s needs (intended use).

See also §8.5 above for the writing of Test Procedures and test reports.

Validation Test Procedures can utilize the same document(s) as Verification Test Procedures. Validation Test Procedures are a superset of Verification Test Procedures.

The Test Procedures include the approach, responsibilities, and sequence of testing. As applicable, validation of OTS SW components is addressed.

The test requirements, test cases and test specifications must reflect the particular requirements of the intended use and the range of actual operating conditions.

Integration testing should include test cases that expose software behaviour not only in response to the normal case, but also in response to exceptional, stress, and worst-case conditions

The results of the SW Validation are documented with Test Reports using QSF 7.3-1C Test Report (TR). Only failed test procedures will be documented in the test report, providing a summary of the test results.

A complete record of the software validation test procedures, including all pass/fails, is stored electronically in Visual Source Safe.

The test report must include the software version tested, relevant hardware and software test configurations, relevant test tools, the date of the testing and the identification of the tester.

Legacy Software

All Legacy SW is completely validated as described above.

Deliverables

Output from the Validation is the installable executable (binary code).

Validation Test Procedures [P###-nnn-TP] (or optional naming scheme [TPnnn-<SW Unit>])

Validation Test Reports [P###-nnn-TRxx]

SW Problem Resolution

IS62304 §9 Software problem resolution

Errors and issues detected during SW Verification and Validation must be logged under the Serena Business Mashups tracking system and are resolved as per QSP 7.3-4 Source Code Management and QSP 4.2-3 Change Control.

Transfer Phase (SW Release)

§5.8 Software Release

All software testing must be completed and test reports reviewed and approved before the software can be formally released.

A QSF 7.3-2A SW Release Report (SRR) is generated, which includes:

a current description and version of the software;

a list of software compilers used in the creation of the software;

a list of the name and version of all software units included;

a list of the name and version of all software deleted since the last release;

an overview of the source codes and executables, including where they are maintained;

regression testing results or a link to the results; and

a summary of all changes from previous the release (as applicable), and an explanation for the changes.

A Software Bug/Defect Report is generated, which lists any remaining software anomalies (bugs/defects), along with an explanation of the impact these bugs/defects have on the safety or effectiveness of the SW product, including the operator usage and human factors.

A Software Bug/Defect Report is appended to or referenced by the SRR

The Software Bug/Defect Report may either be a separate report (preferred) or included as part of the Validation Test Report (less preferred).

A master copy of software and source code is archived on the server

The SW source and binary code is maintained and archived under in the Source Code Management System.

All related OTS software is maintained and archived under in the Source Code Management System with originals and/or back-up copies in the Device Master Record.

Legacy Software

A SW Release Report is generated for each released SW product.

Deliverables

Completed SRR

Documentation

All documents resulting from SW development are filed in the Design History File [DHF] under their respective project number. The DHF Log can be maintained and retrieved electronically by Visual Source Safe.

For each Project a DHF Log is maintained that records:

the document identifier per 12.3 below

the document title

the revision and the effective date

Each document is uniquely identified as follows:

P###-nnn-AA, where “P###” is the number of the project, “nnn” is the sequential integer for the document, and “AA” designates the document type. For more verbose naming, or P###-nnn-<Document Type> is also acceptable.

“AA”	Document Type
PP	Project Plan
RM	Risk Management Plan
RR	Risk Management Report
DI	Design Input
AD	Architectural Design
DD	Detailed Design
DO	Design Output
CR	Code Review
TP	Test Procedure
TR	Test Report
DH	Design History
DR	Design Review

All documents get assigned a unique integer (nnn), except for Test Reports which have the same number as the TP that generated them but receive a postfix TRxx, where “TR” is the abbreviation for “Test Report” and xx is a sequential integer for each execution of the protocol.

For example, the first execution of P003-017-TP will generate P003-017-TR01, while the next execution would generate P003-017-TR02, and so forth

Test Procedures can optionally be named in the format TPnnn-<SW Unit> for easier reference, where nnn is a sequential integer for the document. In this case, Test Procedures should be stored in a sub-directory of the project to prevent confusion.

Source Code Configuration Management

All SW units, related manual text and OTS SW are under SW Configuration management as described in QSP 7.3-4 SW Configuration Management

Off-The-Shelf (OTS) Software

All OTS SW that is incorporated into the SW product is documented and validated.

Generally, the OTS SW is implicitly validated during the overall SW validation.

For all OTS SW, including “open source” software, the software license must be reviewed and deemed acceptable prior to being incorporated into the product.

Legacy Software

OTS SW included in the current SW product is validated and documented.

Deliverables

A reviewed (signed & dated) copy of each applicable OTS software license

An OTS SW Description as part of the overall SW Description

Appendix A: IEC62304:2006 Compliance Check

Clause of IEC62304:2006	Related clause of ISO 13485:2003	Reference within this Procedure or QMS
§4.3 Software Classification	4.5.3. SW Classification
§5.1 Software development planning	§7.3.1 Design and development planning	4.2. Planning Phase
§5.2 Software requirements analysis	§7.3.2 Design and development inputs	7. Requirements Phase
§5.3 Software Architectural Design	7.3.1. Architectural Design
§5.4 Software Detailed Design	7.3.3 Detailed Design
§5.5 Software Unit Implementation and Verification	§7.3.5 Design and development verification	8. Implementation and Verification Phase
§5.6 Software Integration and Integration Testing	§7.3.6 Design and development validation	8. Implementation and Verification Phase
§5.7 Software System Testing	§7.3.5 Design and development verification §7.3.6 Design and development validation	8. Implementation and Verification Phase
§5.8 Software release	§7.3.3 Design and development outputs §7.3.4 Design and development review	11 Transfer Phase
6.1 Establish software maintenance plan	§7.3.7 Control of design and development changes	QSP 7.3-2 SW Maintenance
§6.2 Problem and modification analysis	§7.3.7 Control of design and development changes	QSP 4.2-3 Change Control
§6.3 Modification implementation	§7.3.5 Design and development verification §7.3.6 Design and development validation	QSP 4.2-3 Change Control QSP 7.3-4 Source Code Mgt
§7. Software Risk Management	§7.1 Planning of product realization	QSP 7.3-3 SW Risk Management
§8. Software configuration management	§7.5.3 Identification and traceability	QSP 4.2-4 Source Code Mgt
§8.2 Change Control	§7.5.3 Identification and traceability	QSP 4.2-3 Change Control
§9. Software Problem Resolution	§8.5.2 Corrective action	QSP 4.2-3 Change Control QSP 7.3-4 Source Code Mgt QSP 8.5-1 CAPA