Security & Encryption FAQ

Yes, Ocean automatically scans inbound attachments for viruses/malware before being encrypted using industry standard tools. Files containing viruses/malware are automatically blocked by Ocean.

Article Link

Article Link

As a privacy and security best practice, inactive Ocean Users will be automatically logged out of their session if there is no activity on their user account.

Article Link

In some cases, a clinic may want to remove a patient's data from Ocean. This can happen when a patient has concerns about the privacy and safety of their patient health information. It's important to note that Ocean encrypts all patient data using a clinic-specific private encryption key. This means that no agent outside of the clinic can ever decrypt or read private patient information (including Ocean staff).  

Additionally, Ocean is not designed to be a long term repository of that encrypted patient health information. As a result, the platform regularly purges any encrypted patient data once it has been synced to the primary patient record. You can learn more about this approach, including data retention periods here.

Despite this, there may be times when a clinic is asked by a patient to ensure that no encrypted patient data is (even temporarily) in Ocean. Furthermore, patients may ask to "opt out" (or ensure that they do not receive communication via Ocean in the future.

In this case, the clinic should follow the following steps:

1. Purge the patient from the Ocean Portal (instructions below).
2. Ensure that there is no email address in the email field in the EMR Patient Record.
3. If your clinic uses text reminders, advise the patient to follow the standard opt-out process in the text message (described here) 

How to Purge a Patient from the Ocean Portal

• Log in to the Ocean Portal and locate the patient within the "Patients" page. Select the patient by clicking their name.
• 
• Press the "Remove Patient" button from the list of actions on the right hand side.
• You will be reminded that any data that has not yet been downloaded to the EMR will be lost, and be prompted to confirm the removal of the patient.
• 
• Click "Yes - Remove Patient" to purge the patient from Ocean.

Article Link

The Ocean Network Flow Diagram can be viewed or downloaded using the link below.

Article Link

All personal health information is encrypted prior to storage within Ocean using an encryption password known only to the patient's care providers (not Ocean / OceanMD). This "client-side encryption" goes beyond the protections provided even by the banking industry, since it ensures that even system administrators and third parties cannot view it.

The Ocean kiosks, tablets, questionnaires, secure messages and referrals require the use of personal health information to ensure they can provide a functional and convenient user interface for its users.

Use Cases Requiring Personal Health Information

• Reviewing contact information on a kiosk or tablet
• Automatically triggering questionnaires to display based on patient-specific clinical criteria (such as a flu shot that only shows for patients over 18 who have not yet had one)
• Pre-populating questionnaire and referral forms with lab values and health indicators
• Storing and uploading questionnaire answers into the electronic medical record
• Obtaining email consent using a patient's current email address
• Assisting with the collection of block fee payments
• Displaying a patient's medication list for medication reconciliation
• Sending and receiving textual clinical messages and attachments to the patient via a secure email link
• Sending electronic referrals containing relevant clinical and contact information for patients and their providers

Field List

To successfully provide these use cases for Ocean users, Ocean must temporarily store the following fields in an encrypted format:

• Electronic medical records ID
• Source site / clinic
• Demographics including birthdate, sex / gender, spoken language, associated comments
• Patient's family doctor, clinic-specific doctor, and primary provider/clinician
• Patient roster status
• Clinic block fee payment status
• Contact information including address, email, phone, emergency contact, email consent status, preferred pharmacy
• Health number, health number province, health number version code, health number expiry date
• Cumulative patient profile fields including health problems, past medical history, family health history, social history, allergies, active treatments, immunizations
• Pertinent lab values: Cr, eGFR, Hb A1C, ACR, FBS, RBS, OGTT, TG, HDL, LDL, Chol:HDL, Ketones, Na, K, CO2
• Vitals: Latest height, weight, blood pressure
• Upcoming appointments: date, time, reason, type, location
• Patient-specific Ocean form/questionnaire queue
• For Ocean Online Messaging: Secure messages, associated attachments, and patient responses to questionnaires
• For referrals: referral note, referral source and destination, requested health services, booking information, associated notification emails, associated clinical notes and attachments, associated messages

In accordance with our privacy policy and PHIPA / PIPEDA, even though the information is in an unidentifiable encrypted format, the personal health information is scrubbed from Ocean servers as soon as the associated use case(s) are considered complete.

For more information on OceanMD's commitment to protecting privacy, please refer to: "How does OceanMD adhere to the 10 Privacy Principles of PHIPA?".

Article Link

All patient health information is encrypted using a shared encryption key, providing an extra level of protection for PHI stored in Ocean. This key is not accessible to OceanMD employees and is never transmitted to third parties.

As a result, even OceanMD employees are unable to see PHI, providing additional security beyond the usual minimum standard of server-side encryption-at-rest.

Article Link

All Ocean data, including client-side encrypted PHI, is stored in our primary storage facility located in Montreal (AWS Canada Availability Zone 1) with additional copies of the data kept in a warm failover disaster recovery facility also in Montreal. (AWS Canada Availability Zone 2)

Our data centers are SSAE 16 certified - this means they are locked, guarded, and monitored through closed-circuit television systems, with on-site security teams, military-grade pass card access, and biometric finger scan units to provide additional security. You can read about the security measures in place at our data storage facilities in this SSAE 16 Overview.

Article Link

Ocean uses email to alert patients about new Ocean forms, messages and automated referral notifications.  In order to protect personal health information, Ocean takes a few precautions.

Patient Messages 

When a patient receives a patient message, they are provided a link that takes them to a secure site to view their messages, attachments, and any Ocean forms.  Before accessing the full content of the message, the patient is required to enter one or more security validators as selected by the sender. This can include:

• a password (given to the patient in advance)
• the patient’s birthdate (pre-populated using data from your EMR)
• the patient’s health number (pre-populated from your EMR)
• the patient’s chart ID number in your EMR (pre-populated from your EMR)

By default, Ocean uses the patient’s birthdate as a minimum requirement to access a Patient message.

Ocean eReferral Notifications

In Ocean eReferrals notifications, the following precautions are taken:

• The email used is one either explicitly entered in the Send Referral dialog or on the EMR file;
• The referrer must confirm that the patient has provided informed consent for email prior to sending the referral; if the patient feels no consent was given, this issue should be discussed with the health information custodian (the referring clinician);
• Access to the referral information and personal health information is not available with the email beyond its basic content: patient's first name, referral health service offering, appointment date, time, and location;
• The email only provides a link for the patient to confirm (and possibly cancel in the future), not a link to the actual referral with the personal health information.

Article Link

PHIPA is the Ontario provincial legislation that protects personal information, including health information. It outlines out ten principles that organizations, individuals, associations, partnerships and trade unions must follow when collecting, using and disclosing personal information in the course of a commercial activity.

To learn more about how OceanMD adheres to these principles, please refer to our Privacy Policy.

Article Link

The shared encryption key (SEK) is used by Ocean to encrypt a patient's personal health information (PHI) prior to leaving the circle of care. Beyond the standard strong security precautions implemented by Ocean, the privacy of the shared encryption key effectively prevents third parties (including OceanMD) from eavesdropping on patient information. Without the shared encryption key, the patient's data cannot be decrypted and consequently cannot be viewed.

As a result (in the spirit of PIPEDA and our privacy policy), it is important for health information custodians (HICs) to take precautions to ensure the shared encryption key and its associated password remain private.

These precautions sometimes make it more difficult for clinicians to locate the shared encryption key when it is needed for legitimate clinical purposes. It could lead to a very unfortunate situation when the shared encryption key is lost completely, because it prevents health service providers from viewing potentially important clinical information about patients in Ocean. For tips on recovering your site's shared encryption key, please refer to: "Recovering a Lost / Forgotten Shared Encryption Key".

General Precautions for Protecting the Shared Encryption Key

Ocean provides some automated mechanisms to protect the privacy of the shared encryption key:

• Ocean does not send the SEK across the network for any reason except when configuring your Ocean site and Cloud Connect. The SEK is protected from access by OceanMD staff by a number of controls.
• All requested viewings of the SEK in the Ocean Portal are logged.
• The SEK cannot be viewed in an electronic medical record without prior authorization as a clinical administrator.
  • e.g. in PS Suite, the user is prompted to enter their Ocean username and password and is subsequently validated as an Ocean site administrator prior to the key's presentation

Best Practices for Clinical Administrators

• Follow standard "strong password" security guidelines when choosing a shared encryption key
• Keep the "hint" for your shared encryption key sufficiently vague such that a hacker could not easily use it to guess the key, find the key's physical location, or use social engineering to obtain it
• Do not write down the shared encryption key in a public location
• Do not choose a hint that is merely a shortened or transformed version of the actual shared encryption key (e.g. using "P@ssw0rd" to describe password)
• Do not enter the shared encryption key in browsers on publicly-accessible terminals
• Do not email the shared encryption key.
• Do not store the shared encryption key on an external drive or cloud server without appropriate privacy and security protocols to restrict access.
• If you print the shared encryption key, keep a known, limited number of copies of the printout and store them in a secure, locked location.
• Do not re-use a personal password for the key
• Do not re-use a clinic-wide password for the key
• Do not re-use a shared encryption key that has been used by any other clinic.
• Change the key if it has been publicly disclosed or compromised by an untrusted individual.
• Consider using a trusted secure password manager such as 1Password to store the shared encryption key.

Article Link

Ocean incorporates the crucial concept of Trustees/Custodians within the Ocean Provider Network. It is essential for healthcare providers to identify whether a referral site qualifies as a Trustee/Custodian of Health Information before sharing any Personal Health Information (PHI). This is especially true in Ontario, where healthcare providers are required to follow specific legislation.

Who is a Health Information Trustee/Custodian?

According to Canada Health Infoway, the term Trustee/Custodian is defined as "an individual or an organization who has custody and control of health records, and is accountable for the protection of PHI." The usage of terms 'Trustee' and ‘Custodian’ may vary by region; however, both terms describe entities with significant responsibilities over PHI.

Legislation and Regional Variations

In Ontario, the Personal Health Information Protection Act (PHIPA) identifies a Health Information Custodian (HIC) as responsible for collecting, using, and disclosing PHI. While this legislative framework is specific to Ontario, the principles of managing PHI responsibly are best practices that apply broadly, ensuring patient privacy and data protection.

Ocean Platform Implementation

Within the Ocean Platform, every clinic or provider that receives eRequests (e.g., eReferrals and eConsults) through the Ocean Healthmap is required to declare if they are a Trustee/Custodian during their Ocean Site configuration. If a healthcare provider does not identify themselves as a Trustee/Custodian, an orange notice will appear on their Directory Listing to alert referring providers of this status, ensuring transparency and compliance in the handling of PHI.

Examples of Health Information Trustees/Custodians

• Healthcare practitioners and clinics
• Hospitals and psychiatric facilities
• Long-term care homes and pharmacies
• Community care access corporations
• Laboratories and ambulance services
• Public health officials and certain governmental bodies

Who is Not a Health Information Trustee/Custodian?

Not all individuals or organizations fall under the category of Trustee/Custodian. Examples of such exceptions include:

• Faith healers or traditional aboriginal healers
• Agents or employees of a health information custodian, where the agent does not provide healthcare
• Providers of non-health related services like fitness or weight management

Conclusion

When sending a referral to an entity not recognized as a Trustee/Custodian, providers should obtain explicit consent from the patient and minimize the PHI disclosed. This ensures compliance with regional regulations and upholds best practices in patient data protection.

Article Link

When receiving any referral, electronic or otherwise, healthcare organizations are responsible for taking reasonable precautions to verify the legitimacy of the source. These precautions include adherence to procedures such as avoiding personal health record disclosure without reasonable assurances that the referrer is trustworthy and is acting with patient consent.

All users must formally commit to following appropriate privacy practices prior to using Ocean by agreeing to Ocean's mandatory end-user license agreement (EULA).

Ocean Features that Help Facilitate the Validation and Accuracy of Referrer Contact Information

Although the responsibility for referrer validation ultimately lies with the referral recipient, Ocean has several features that assist healthcare organizations with identifying and validating a referrer's contact information. Unlike traditional fax or eFax which do not facilitate any checks on the validity of the sender, Ocean provides the following safeguards to help prevent referrals with inaccurate sender information:

• Confirmation of referrer contact information required with each referral
  • Referrers are prompted to review and correct their contact information prior to submitting each referral.
• Mandatory referrer information required with referrals
  • Referrers must enter their professional ID and billing number when applicable prior to sending. This is generally private information typically only known only by legitimate providers.
• Live updates of referrer contact information
  • Referrers may update their Ocean account's contact information at any time, which will be used for future communications, even for previously-submitted referrals
• Optional federated identity provider account linkage
  • Ocean can support a link between a user's Ocean accounts and a regional federated identity provider. 
• Region-specific agreement enforcement
  • Regional programs can specify a customized referral user agreement outlining privacy policies and usage terms, requiring referrers to agree prior to sending referrals
• Limit listings to only receive referrals from specific user categories
  • Individual listings can add a restriction to ensure that only physician or Nurse Practitioner Ocean user accounts are eligible to send.

Access Restrictions for Referrers

Most referral recipients require senders/referrers to sign in with a valid Ocean account prior to sending referrals. This account is also required to view the status of the referral and any updates.

If a referral is sent without logging into an Ocean account or federated ID, access to the referral is protected and restricted under applicable privacy legislation and cannot be viewed after sending. In this case, the sender is encouraged to print or download a pdf copy of the referral. 

Note: As part of our commitment to patient privacy, OceanMD reserves the right to remove an offending provider from the directory without warning and/or report breaches of patient privacy to the relevant custodian(s). This is stipulated in our End User Licence Agreement (EULA).

Article Link

Introduction

The Ocean eReferral Network provides a convenient and secure mechanism for health service providers to send electronic referrals containing personal health information for patients to trusted health information custodians, in accordance with PHIPA / PIPEDA privacy laws.

In this context, OceanMD acts as a electronic service provider (ESP) that interacts with a designated health information network provider (HINP) to transfer the personal health information necessary for the referral.

It is important for the HINP to ensure that the referrers interacting with its network are legitimate health service providers (HSPs) with accurate, up-to-date contact information. Otherwise, the risk of unintentional disclosure of personal health information is increased during the natural back-and-forth communication regarding a referral.

Specific risk scenarios related to invalid referrers include:

• Malicious users masquerading as real-world HSPs who send eReferrals in Ocean with false patient or referrer contact information.
• Referrers with out-of-date contact information, including email addresses, phone, and fax numbers.

In the event that the referrer's contact information is faulty, there is a risk that the referral recipient may inadvertently disclose personal health information to an untrusted third party as part of the follow-up communication. For example, the recipient may call or fax back information to this third party indicating that the patient has "been seen here recently", presuming that the source is a valid HIC for the patient. This information disclosure would constitute a privacy breach of the patient's personal health information.

Responsibilities for the Receiving Health Information Custodian

It is important to keep in mind that the risks related to untrustworthy referrers are not unique to electronic referrals. In theory a malicious individual may masquerade as a referrer using a faxed referral to create the same risk scenario.

Consequently, referral recipients are responsible for taking the same reasonable precautions with electronic referrals as they do with faxed and phone referrals today. These precautions include adherence to simple procedures, such as the general avoidance of any personal health record disclosure without reasonable assurances that the referrer is trustworthy and is acting under the patient's consent. When these precautions are used, the risk of serious personal health information disclosures is relatively low.

HICs must formally commit to following these precautions prior to using Ocean by agreeing to Ocean's mandatory end-user license agreement (EULA).

Ocean Features that Facilitate the Validation and Accuracy of Referrer Contact Information

Although the responsibility for the referrer validation ultimately lies with the referral recipient, Ocean has several features available (now or in the near future) that can assist HINPs and HICs with the identification and validation of a referrer's contact information:

• Confirmation of referrer contact information with each referral
  • Referrers are prompted to review for accuracy (and correct if necessary) their contact information prior to submitting each referral.
• Mandatory referrer information required with referrals
  • Referrers must enter their professional ID and billing number when applicable. These fields are relatively private pieces of information often known only by the referrer.
• Ocean account linkage
  • Referrers may sign in with an Ocean account prior to sending an eReferral. The Ocean account provides a mechanism for basic user identification including a valid email address.
• Live updates of referrer contact information
• Referrers may update their Ocean account's contact information (such as their email) at any time. Ocean will use the updated email for future referral notification and communication, even for previously-submitted referrals.
• Federated identity provider account linkage
  • Where available, Ocean users can link their accounts to regional federated identity providers. Referral recipients may subsequently review the referrer's information and gauge its trustworthiness based on the presence of the federated identity.
• Referrer account enforcement by the HINP
  • HINPs will be able to restrict the sending of referrals to only users with accounts provided by a federated identity provider or Ocean
• Referrer account enforcement by the referral recipient HIC
  • HICs will be able to restrict the acceptance of referrals at their site to only users with accounts provided by a federated identity provider or Ocean
• HINP-specific agreement enforcement
  • HINPs can specify a customized referral user agreement outlining its privacy policy and usage terms and force referrers to agree prior to sending referrals.

Access Restrictions for Referrers

Most referral recipients require senders/referrers to sign in with a valid Ocean account prior to sending referrals. This account is also required to view the status of the referral and any updates.

If a referral is sent without logging into an Ocean account or federated ID, access to the referral is protected and restricted under applicable privacy legislation and cannot be viewed after sending. In this case, the sender is encouraged to print or download a pdf copy of the referral. 

Note: As part of our commitment to patient privacy, OceanMD reserves the right to remove an offending provider from the directory without warning and/or report breaches of patient privacy to the relevant custodian(s). This is stipulated in our End User Licence Agreement (EULA).

Article Link

Introduction

The Ocean Healthmap consists of listings that represent health service providers (HSPs) and health information custodians (HICs) as described under PHIPA law.

It is very important that the listings in the directory be accurate and up-to-date to prevent accidental or malicious leakage of personal health information to untrusted third parties by unwitting referrers to the listed services.

Consequently, safeguards must be in place to prevent individuals from masquerading as health service providers, so that referrers do not inadvertently send them their patient's personal health information. Policies should also exist to ensure listings have up-to-date contact information to prevent patient faxes and phone calls from sending to the wrong location.

Maintaining accurate and up-to-date information in a comprehensive health service directory is an ongoing challenge. To minimize the risks involved, OceanMD's policies are outlined below.

Prioritized Use of Official Sources

When possible, the directory listings in Ocean are directly pulled from "Official Sources", which contains a comprehensive list of physicians and other health service providers in the province. These registry services have their own well-developed and publicly-trusted mechanisms for validating listings.

Consequently, the information within these listings are transitively trusted by Ocean to be up-to-date and representative of a trustworthy real-world health information custodian. For example, the phone and fax numbers for physicians from the eHealth Ontario Provider Registry are presented in the directory as accurate information.

Information from these official sources is refreshed in Ocean on a regular basis to ensure the information remains up-to-date.

Official Sources as of May 2018:

Third Party HINPs Using Ocean

OceanMD also allows select not-for-profit organizations to act as their own Health Information Network Providers (HINPs). These organizations have their own policies for validating health information. An example of a HINP using Ocean is the CFFM Care Innovations organization based in the Waterloo Wellington LHIN in Ontario.

These third-party HINPs may validate and submit their own listings as a subset within the wider Ocean Health Service directory. OceanMD regularly reviews the policies of these HINPs as it pertains to Ocean and provides support to the HINPs to ensure they adhere to the company's own privacy policy.

Current 3rd Party HINPs as of May 2018:

Listing Creation and Listing Claims

Listings representing Health Information Custodians (HICs) may be entered or updated in Ocean by either the HINP or the HIC itself:

1. An authenticated user acting on behalf of an Ocean-affiliated HINP may manually enter a new health listing in Ocean under their own directory subset at any time. This process facilitates HINPs in creating their own comprehensive directory of trusted health services. When a HINP creates a listing, it assumes the responsibility for validating this listing using their own policies and procedures.
2. Central Intake users, designated and validated as trustworthy by OceanMD, may manually enter a new health listing in Ocean, or update an unclaimed listing, at any time. The Central Intake user assumes the responsibility for validating this listing using their own policies and procedures. This will commonly be done at the time of transcribing inbound referrals, when importing and updating the referring provider’s information from the Healthmap.
3. Alternatively, HICs may choose to independently create and claim their own listing within the OceanMD directory, or "claim" a listing as their own. These listings contain both identifying information and contact information for the HIC. Since these individuals in this circumstance are not yet validated by a HINP as trustworthy, the listing is flagged as such in the directory to warn referrers of a potential privacy breach if personal information were to be sent. HINPs may proceed to validate these claimed listings, after which the warning is removed and replaced with an appropriate indicator of the HINP's approval.

OceanMD's Listing Validation When Acting as HINP

In circumstances where OceanMD is acting as the HINP, the company directly assumes the responsibility of validating listings.

OceanMD's steps for validating listings are as follows:

1. Listings that are flagged as requiring validation are reviewed on a daily basis by a designated HINP administrator.
2. For each listing requiring validation:
   • The administrator reviews the listing for any obvious initial inaccuracies or inappropriate information.
   • In the event that the listing is considered unreliable or deemed to be "spam", it is deleted immediately.
   • If the listing is felt to belong to another HINP, such as a regionally-funded program, the HINP's support representative is contacted and instructed to apply to the alternate HINP instead of OceanMD.
   • An Internet search is also performed with two separate services (e.g. Google and Microsoft's Bing) to locate any publicly-accessible information regarding the listing to ensure consistency with the claimed information.
   • If a website is found that aligns with the listing, it should be cross-referenced for consistency with the listing's information.
   • The listing's contact information, including the phone, fax, website and email, is cross-listed with an official source. Official sources include:
     • The official health profession's directory, e.g. CPSO for Ontario physicians
     • An official regional directory for social services (such as centralhealthline.ca)
     • An established vendor partner, such as TELUS, QHR, or WELL, who can vouch for the claim
     • If an official source is not available: the validation must be escalated to management and/or the privacy officer to consider alternative means of validation as a special case, being mindful of the risk of a social engineering attack.

3. If the information passes this initial screening test, the administrator calls the phone number provided on the official source. During the phone call, the administrator identifies OceanMD and explains the purpose of the call, then proceeds to clearly enumerate all of the listing's information as submitted to confirm accuracy.

   The administrator confirms with the clinic representative which user is claiming this listing and which Ocean site. To avoid affirmative miscommunication, the administrator shall confirm that the clinic representative is independently aware that the listing is being claimed by this particular Ocean user at this particular Ocean site.

   • • Up to two voicemails are left on separate days.
4. If 7 days pass without the administrator successfully manually confirming the accuracy of this information, the listing is deleted.
5. If the listing however is successfully confirmed, the validation is completed by the administrator and tagged in the directory accordingly. The time, date, administrator that approved the listing, and validation steps taken by the administrator are logged.

Reporting and Correction of Invalid or Out-of-Date Listing Information

All individuals interacting with Ocean should flag and report health service listings found to contain inaccurate information in a timely manner. Any user of the directory can quickly and easily alert OceanMD of the concern by clicking on a hyperlink contextually located next to the listing's information.

Once a listing has been flagged as potentially inaccurate, the listing is flagged for all users along with the user's suggested correction. OceanMD manually reviews such reports on a daily basis. In the event that a listing is managed by a separate HINP, OceanMD notifies the HINP of these reports so that the HINP may take appropriate action. If not, OceanMD follows the same validation steps as those used by initial listing validation to ensure the new information is accurate.

Article Link

OceanMD generally acts as a Electronic Service Provider (ESP) under PHIPA, particularly in the capacity of providing hosted software to facilitate patient engagement technology. We do not handle PHI, which is protected by client-side encryption.

In some cases, we act as a Health Information Network Provider (HINP), specifically in the context of Ocean eReferrals, which allow Health Information Custodians (HICs) to share Personal Health Information (PHI) with other HICs. 

A special case exists for the System Coordinated Access Program in Ontario. In this eReferral project, Ocean's role is as an ESP with HINP responsibilities residing with the CFFM Care Innovations, a not-for-profit organization.

Article Link

Ocean is not an EMR/EHR and not a long term repository of health information for a patient. All patient records are eventually deleted from Ocean. Ocean only holds patient records in an encrypted format for a limited time to support the various ways clinics use the system.  After this time has passed, the patient record is permanently deleted from the Ocean database, although it will be available in database backups for a year.

For example, when a patient is scheduled for an appointment, the patient record is encrypted and uploaded into Ocean a day or two before the appointment time. It is deleted after the EMR downloads the generated note. The total time in Ocean may be 3-4 days.

For a contrasting example, if a newly pregnant patient registers for a new baby pediatric appointment, the patient might be sent an Ocean Online web questionnaire months prior to the birth and be asked to complete the form upon delivery. In this case, the patient record might be stored in Ocean for 5 months.

Ocean's behaviour is guided by the PIPEDA privacy principle of "Limiting Use, Disclosure and Retention". Privacy guidelines recommend that PHI be kept in as few places as possible for as short a time as possible. The principal record of personal health information for clinics is the EMR/EHR. Furthermore, the patients in Ocean are "snapshots" of a patient at a point in time (when the patient was uploaded). Although the patients can be updated by the EMR/EHR easily, having multiple copies of patient records is generally problematic due to the potential for stale data.

Caveats:

• You can "lock" a patient in Ocean to request that Ocean leave the record alone and stored within Ocean, although this should be reserved for special situations only.
• Ocean Study data captured for a patient is kept indefinitely (until it is deleted by the owning Ocean site).
• The audit trail maintained by Ocean lives indefinitely, which allows you to map the EMR ID of the patient to an Ocean reference number to tablet access, web questionnaire access, form completion audit records, etc for audit purposes.
• Encrypted PHI will be maintained in Ocean database backups for up to one year. Ocean backups are maintained at a secure facility with all access logged.  Access is limited to OceanMD operations staff.

Detailed time frames in patients are kept within Ocean:

• For patients with forms pending: 30 days or until the secure hyperlink to access the form expires
  • The patient will be kept in Ocean for the longer of the two durations.
• For patients with notes that haven't been downloaded: 90 days (if you have patients in this situation, the following will occur: "What do I do if I see 'Warning from Ocean: Notes Require Download?'")
• For patients that have all notes downloaded and no forms pending: 14 days
• For patients that have unopened secure messages and no forms pending: 14 days or until the secure hyperlink to access the message expires
  • The patient will be kept in Ocean for the longer of the two durations.
• For patients with an appointment scheduled in an integrated EMR with no forms or updates pending: 14 days after their scheduled appointment date
• For patients with associated eReferral, eConsult, Website Forms, Patient Authenticated Website Form, or Online Booking submissions: until all associated submissions are purged from the Ocean Site
  • Submissions are associated with existing patients via a matching health number/alternate ID. In the case of new patient creation (e.g., accepting a submission, creating a new submission), the patient is explicitly tied to the submission using a unique patient reference value.

eConsults/eReferrals

By default, eConsults/eReferrals that are sent through Ocean or transcribed into Ocean are stored for a minimum of 1 year before they are purged. However, certain actions in Ocean can extend the purge deadline beyond the default. Detailed information about eReferral storage can be found in: How long are eConsults/eReferrals stored after they are sent through Ocean?

eConsult/eReferral analytic data captured by Ocean is kept indefinitely. For additional information, please see Supporting Analytics in eConsults and/or eReferral eForms.

When an eConsult/eReferral is approaching it's purge deadline, it will automatically move into the 'Deletion Warnings' status folder 14 days before being purged from Ocean. A Deletion Warning email notification will also be automatically sent to all Ocean Sites with access to the eConsult/eReferral.

Website Form/Patient Authenticated Website Form Submissions

• Website Form Submissions in the 'New', 'Accepted', or 'Completed' status folder are kept for 180 days from the date of submission.
• If appointment information is added into the website form submission, it is retained until the appointment date + 30 days.
• If an 'Anticipated Time to Appointment' is entered in the website form submission, it is retained until the end of the estimated date range + 60 days.
• If review is requested by another user at the site, the submission will be stored for 12 months after the date the review was requested.
• When a Website Form Submission is scheduled for deletion, it moves to the "Deletion Warnings" status folder, which appears in red. A user can "extend" the retention time for additional blocks of 60 days.
• As above, Ocean will notify you with an alert if you have deletion warnings.

Online Booking Submissions

• If the appointment date is within 180 days of the date that the booking occurred, the submission will be retained in Ocean for 180 days after the date that the booking occurred.
• If the appointment date is beyond 180 days of the date that the booking occurred, the submission will be retained in Ocean for 30 days after the booked appointment date.
• If review of the submission is requested by another user at the site using the 'Needs Review' feature, the submission will be stored for 12 months after the date the review was requested.
• When an Online Booking submission is scheduled for deletion, it moves to the "Deletion Warnings" status folder 14 days before being deleted. A user can "extend" the retention time for additional blocks of 60 days.

Unused File Attachments

Ocean supports the ability to include files and/or notes from integrated EMRs as an attachment in a Patient Message, or as an attachment in an eReferral/eConsult.

This process typically involves 1) taking steps within the EMR to first upload the file into Ocean, and then 2) subsequently sending the Patient Message/eReferral/eConsult. During the time between these two actions taking place, the uploaded file attachment exists within Ocean and is associated with the relevant patient, but it is not yet associated with a specific Message/eReferral/eConsult.

At that point in time, the attachment is considered to be "unused". Once the attachment is included in a sent Message/eReferral/eConsult, it is considered to be "used" and inherits the purge timeline of the associated eReferral/eConsult or patient record outlined above.

When the attachment is in the "unused" state, it can be included in a Message/eReferral/eConsult by any user within the Ocean Site who is interacting with the associated patient. For example, if User A performs the steps within the EMR to first upload the file into Ocean but does not proceed to send the Message/eReferral/eConsult, User B could subsequently skip those initial steps and "use" the attachment when sending a Message/eReferral/eConsult for that patient.

Every night at approximately 2:00 AM EST, Ocean automatically purges any "unused" file attachments that are older than 24 hours. This means that an "unused" file attachment could be kept in Ocean up to a maximum of 48 hours before it is automatically purged.

Article Link

Article Link

The only patient data (i.e. patient health information) held in the Ocean tablet app is that belonging to the current patient. Once a patient is done completing their form(s) (specifically, when the finish/reset button is pressed), the patient data is deleted from the tablet.

In other words, at most one patient's data is on the device at any point in time.

Article Link

OceanMD employees (including system administrators) do not have access to our customers' encryption keys without the direct immediate authorization of the health information custodian. Therefore, employees are unable to see or disclose any PHI.

Article Link

OceanMD is committed to accessibility for all public website content, which we consider to be all patient-facing interfaces.

• For Ocean Tablets, Kiosks, Website Forms and Online Booking, Ocean uses large, simple fonts with high contrast (dark on white) using standard HTML5 elements. Fonts can be enlarged in web browsers. Some tablets (e.g. Samsung Tab E and Tab A) allow for larger text sizes.
• Throughout all patient interfaces, Ocean uses large buttons and elements, designed to make user interaction as simple as possible.
• On some tablet models, you can use colour inversion (specifically Samsung tablets), so text can be white on black.
• The tab order and keyboard navigation of Ocean forms is sequential, allowing standard browser key control for form completion.
• Ocean does not rely on video or images to convey information to patients. Note that some clinics may build forms using images or videos, in which case the accessibility compliance may be compromised.

Article Link

OceanMD maintains a continuous build process in its Toronto office, where a build / autotest cycle runs continuously.

No "live data" (i.e. patient health information) is ever included in the test environment - only demo data is used for testing.

Article Link

System maintenance is normally done Thursday nights between 9pm and 11pm ET.

The system maintenance does not compromise patient privacy, since all PHI is kept encrypted during the maintenance period using private encryption keys that are not accessible to OceanMD staff.

Article Link

Yes, OceanMD has completed or participated in the following privacy/security audits for Ocean:

1. OceanMD Privacy Impact Assessment (PIA), audited by MNP (revised July 2023; see attached)
2. Threat Risk Assessment (TRA) by Cycura Data Protection Corporation (October 2021).
3. Privacy/Security Assessment by Shoppers Drug Mart (April 2018)
4. Privacy/Security Assessment by TELUS (Sept 2016)
5. Threat Risk Assessment (TRA) by MNP (May 2016; summary available by request).
6. Assessment by Sunnybrook Health Sciences Centre (April 2014)
7. Assessment by St. Michael's Hospital (July 2013)

Note that this is not an exhaustive list; other healthcare organizations have done assessments in which we have either not been be directly involved or have been asked not to disclose.

* As per industry best practice, we do not publish or send full TRA documents electronically. Stakeholders who have a legitimate need to review the full TRA document may do so on site in our Toronto office after signing a non-disclosure agreement.

Article Link