Clinic Privacy & Security
Tips for keeping your Ocean products secure within your clinic, including tablet security and accessing audit reports.
- Enforcing Two-Factor Authentication for All Users on your Ocean Site
- How should my HINP validate that a health service directory listing can safely receive secure electronic messages sent by other providers?
- Securing Your Tablets
- Tracking Two-Factor Authentication Compliance
- URLs, and IPs That Need to be Allowlisted for Ocean
- Guide for Reviewing Your Site's Audit Logs
- Documentation for Ocean Audit Log Entries
How should my HINP validate that a health service directory listing can safely receive secure electronic messages sent by other providers?
Ocean's health service directory helps providers locate other health service providers who can provide services for their patients.
Each provider has a corresponding listing in the health service directory (OceanHealthMap.ca) that lists the provider's contact information, along with various options for inter-provider communication.
The primary channels of communication used by these providers include the following mediums:
- Physical Address
- Secure electronic communication using Ocean (for eReferrals, eConsults, Website Forms etc.)
Since the communication between providers typically involves the exchange of a patient's personal health information (PHI) for the purpose of providing care, from a privacy perspective, it is crucial that these listings provide accurate contact information and a secure means of communication.
As an electronic service provider, CognisantMD follows a number of strategies to ensure the integrity of listings in Ocean's health service directory.
Health Information Network Providers (HINPs) may assist in the validation and maintenance of listings under their jurisdiction. HINPs are encouraged to use the following strategies, along with their own best practices, to protect patient privacy.
Validating Basic Listing Contact Information
As a HINP facilitating this communication for a specific set of providers using Ocean, you are assuming responsibility to reasonably ensure that the providers in the directory have accurate, up-to-date, contact information.
It is very important to keep the listings' information current. Otherwise, providers may use incorrect or outdated information for sending personal health information (PHI), such as an old fax number used for a patient referral, potentially leading to a privacy breach.
Your HINP must develop and implement a dedicated and ongoing process to safely maintain the accuracy and currency of this contact information. For tips on developing this process, please see this article:
When the listing contact information is validated successfully, it may be used as a reasonably reliable reference for traditional means of communication (phone, fax, mail etc.).
However, the endorsement to use listings for electronic communication (such as eReferral), entails some additional privacy considerations. Additional steps are required for completely validating providers who provide these electronic services.
Validating Listings for Receiving Electronic Communication Using Ocean
Prior to permitting providers to participate in the secure exchange of PHI using Ocean, it is important for the HINP to ensure that these providers not only have up-to-date contact information in the listing, but that it also:
- Ensures that the providers are truly represented in the real world by the Ocean user accounts and the Ocean site that they are claiming acts on behalf of in the listing (through the process of identity validation)
- Ensures that these providers have provided informed consent to participate as care providers within the Ocean network, along with the commitment to process electronic communications sent through Ocean in a safe, secure, and timely manner. This consent is typically provided with a signed HINP-specific participant agreement.
1. Identity Validation
It is important to be aware that any malicious user on the Internet could attempt to sign up for an Ocean account and impersonate a real-world healthcare provider by claiming a listing in the directory. Unlike a public phone, a published fax number or a physical mailing address, this user could directly receive personal health information (for example, in the form of an eReferral sent by an unwitting referrer), unless appropriate safeguards are in place.
This initial sign-up and claiming process is permitted by Ocean (for the sake of ease-of-use when onboarding on new clinicians), despite the possibility of an illegitimate claimant. To alert referrers and other healthcare providers to this risk, these listings are considered "unvalidated" and are marked with a warning in the directory:
A HINP is able to validate that the user's listing claim is legitimate. To be confident in this validation step, at a minimum, the HINP must first:
- Speak with an individual in person or on the phone and verified their recent intent to claim this listing in Ocean.
- Have objective evidence that this individual has the authority to act on behalf of the clinic (e.g., by calling them using the clinic's public phone number)
- Validate the listing's contact information using an external source such as a public Internet page or the CPSO directory (in the aforementioned article)
- Ensure that the Ocean username and the Ocean site claiming this listing within Ocean matches this individual's information as it was conveyed outside of Ocean (i.e., to ensure it matches the same information that was conveyed over the phone or in-person).
2. Provider Consent and Commitment
Prior to validating a listing claim, the HINP should have a standard agreement in place with the provider. The agreement should include, at a minimum:
- Roles and responsibilities of the provider acting as an Ocean message recipient.
- A review of how the services may affect the privacy of the individuals who are subject of the information (e.g., a Privacy Impact Assessment).
- An agreement to comply with the restrictions and conditions in accordance with PIPEDA and/or local provincial privacy law.
- A review of their responsibility to monitor for Ocean messages and respond to these messages in a reasonably timely manner (similar to the standard of care for specialists with regard to responding to faxed referrals within mandated deadlines)
If the above criteria are met in accordance with your own organization's policy (as determined by your privacy officer), you may proceed to validate the listing's claim.
Validating Listing Claims in Ocean for Electronic Communication
Once the above requirements have been reviewed and approved, a representative of the HINP may proceed to validate the listing (once the representative's Ocean user account has been granted this privilege by CognisantMD).
To validate the listing, go to the Ocean site managing the listing, update the relevant information, and click Save Changes. If the listing has not already been validated to receive eReferrals, you will see a prompt asking you to verify that the site is valid (along with a link to this article). Once you confirm, the listing will be considered valid and the warning shown in the Ocean health map will no longer be visible.
CognisantMD recommends the following to ensure secure use of your Ocean-enabled tablets. Implementation of each recommendation may be dependent on the tablet or other hardware manufacturer.
Configure your tablets to use your guest Wi-Fi network.
The Ocean software only needs access to the internet. It does not need access to any internal clinic computers, so we strongly recommend configuring your clinic Wi-Fi router to have a guest network that separates the tablets from your internal clinic systems. Configuration of this network is dependent on your Wi-Fi router model.
Ensure any Google (or other) accounts are removed from each tablet before patient use.
These accounts are not necessary for configuration or operation of the Ocean software and may allow installation of apps from the Google Play Store, or access to other services. They may be temporarily necessary for installing other security apps while configuring the tablet (e.g. for remote wipe), but should be removed immediately afterward. To do this, go into tablet settings, locate the "Accounts" section and remove each account found there.
Enable Screen Pinning
If you are running Android 5.0 or higher, pinning the Patient Tablet application will inhibit patients from navigating away from Ocean while using the the tablet. Pinning disables the physical buttons on the device, as well as the notification area that can normally be accessed by swiping down from the very top of the screen.
It is recommended that prior to enabling screen pinning you set a PIN or password for your tablet's lock screen. This will ensure if the device is powered off or rebooted, patients will not be able to access other applications prior to staff re-opening the Ocean Tablet application.
To do this, open the Android Settings application and navigate to "Lock Screen and Security" > "Screen Lock Type" and choose either the PIN or Password option.
To disable screen pinning, simply return to the Administrative menu and select "Disable Screen Pinning."
Please note: If your tablet is powered off or rebooted, you will be prompted to re-enable screen pinning when the Ocean Tablet app is next relaunched.
Avoid keyboards from tablet manufacturers.
Some of these keyboards include "predictive text" features that can show text suggestions that may have been learned from previous patient responses. While we don't believe this can expose PHI since the suggestions are not linked to a particular patient, it could cause alarm and is unnecessary. CognisantMD recommends using the stock Google keyboard ("Gboard"), which can be downloaded from the Google Play Store, or disabling any predictive text features. Samsung tablets are known to ship with the Samsung keyboard that has this feature enabled by default (learn how to disable predictive text on Samsung keyboards).
Install "remote wipe" software on each tablet.
Remote wipe software packages allow you to track tablets through a web application and remotely reset them to factory state if they connect to the internet, thus removing access to any Ocean services. If a tablet goes missing, it can be deregistered easily using the Ocean Portal to avoid access to any patient data and unnecessary charges.
Enable Ocean's birth date validation.
In the Tablets tab of the Ocean Portal, enter into the tablet settings and ensure that, on the introduction screen, "Always Show Introduction Screen" and "Use Birthday Validation" are both enabled. This will require a patient to provide their birthday (month and day) before proceeding.
If you are concerned about patients installing additional apps to your tablets, you can optionally use a restricted account for the Ocean software. Restricted accounts are available as a feature on some tablet models and can be configured to prevent installation of apps, changes to tablet settings, etc. without a password. There are some downsides to this, however:
- The Patient Tablet software will no longer be able to auto-update itself. Each tablet will have to be manually updated periodically using the tablet administrator account.
- There will be additional configuration steps for each tablet and the administrator password will need to be remembered. If the administrator password is forgotten, it will be necessary to do a factory reset and reconfiguration of the tablet.
Ocean offers Two-Factor Authentication (2FA) as an optional feature to provide an additional level of security for Ocean users. The feature can be enabled by users by following the steps outlined in How To Enable and Disable Two-Factor Authentication.
Two-Factor Authentication Compliance Report
Site Administrators can access a 2FA compliance report to assist in tracking user compliance an organization's 2FA policy.
- Log into the Ocean Portal, select the "Menu" button in the top left corner, and selecti "Admin".
Enforcing Two-Factor Authentication
For additional information on how you can enforce 2FA compliance for all users on your Ocean site, please refer to Enforcing Two-Factor Authentication for All Users on your Ocean Site.
We understand that our customers need to be confident that they are communicating with the Ocean platform in a secure environment. One of the ways of ensuring this is to only permit traffic to enter a customer network from trusted IPs owned by CognisantMD.
NOTE: This information is subject to change. Please subscribe to this support article to be notified about any changes made to it.
Production Ocean IPs and URLs
Inbound Firewall Changes Required (Allow traffic from Ocean to your network)
Receive Webhook events from Ocean for patient engagement or eReferral updates:
Integrate CloudConnect with an OscarPro EMR:
Outbound Firewall Changes Required (Allow traffic from your network to Ocean)
NOTE: Most customers don't have outbound IP or URL restrictions in place so these changes may not be necessary. Check with your network administrator if you're unsure.
Access the Ocean portal and / or Ocean APIs:
Requests to Ocean transit through Cloudflare. See an up to date list of IPs for the Cloudflare network here. Any of these IPs may be used to communicate with the Ocean platform.
If you have a firewall configured to only permit access to certain allowlisted URLs, you will need to add the following URLs to your allowlist in order to take advantage of all Ocean features.
Development Ocean IPs and URLs
The following IPs must be added to inbound and outbound allowlists during development and testing of new API integrations against our pre-production environments:
If you have a firewall configured to only permit access to certain allowlisted URLs, you will need to add the following URL to your allowlist to be able to access our staging and/or test environments:
This information is subject to change. Please subscribe to this support article to be notified about any changes made to it.
|July 14, 2022||
Updated Ocean URL allow list, removed obsolete links
|June 20, 2022||
Removed production Ocean IPs :
|May 4, 2022||
Added 2 new Production Ocean IPs (inbound) to be allowlisted as necessary.
This guide is intended to assist health information custodians and Ocean site administrators with the review and interpretation of your site's Ocean audit log for PHIPA compliance related to auditing and monitoring.
Under the guidance of Canadian PIPEDA / PHIPA Law, health information custodians (HIC’s), including physicians and nurse practitioners, have a duty to ensure that platforms with PHI are audited and that the audit logs are reviewed on a periodic and random basis to help protect personal health information (PHI) against unauthorized use or disclosure.
According to the Information and Privacy Commissioner of Ontario:
"The logging, auditing and monitoring of all accesses to electronic records of personal health information is important to ensure the privacy of individuals and the confidentiality of their personal health information. The capacity to log all instances where personal health information is collected, used and disclosed by agents will enable custodians to respond to requests for information and complaints about the collection, use or disclosure of an individual’s personal health information; to audit and monitor all collections, uses and disclosures of personal health information by all of their agents; and to investigate actual or suspected privacy breaches including cases of unauthorized access. Logging, auditing and monitoring can be an effective deterrent to unauthorized access if all agents are made aware that all of their activities in relation to electronic records of personal health information will be logged ...
The policy and procedures should require the custodian to conduct ongoing, targeted (reactive) and random (proactive) auditing and monitoring of the logs"
Audit Logging in Ocean
Ocean, as a system that provides access for users to PHI, should be included in the HIC’s regular auditing activities (in addition to the site's EMR and other platforms with PHI).
To assist with this task, Ocean captures all user activity related to the storage, retrieval, and presentation of PHI both from the underlying EMR as well as Ocean itself. The full audit data for a specific Ocean site is available for download at any time.
Ocean's logging and exports only provides access to activity within the specific Ocean site. Other activity, such as interactions with an underlying EMR or subsequent disclosure activity (such as printing / emailing of PHI),is not captured by Ocean. To review this activity, it is recommended that site administrators also refer to EMR audit logs as well as specific computer terminal usage logs according to internal audit policy.
Exporting the Audit Data
To export the audit log, go to the Reports section of your Ocean site administration page. Choose the relevant start and end date, and choose User "All" for a site-wide audit.
The report is then downloaded as a CSV file, which may be opened and presented by any mainstream spreadsheet application such as Excel or Google Sheets.
Although the audit report itself does not contain any PHI, it should nonetheless be treated as sensitive documentation, with appropriate safeguards in place for the encrypted transmission, storage and deletion of this information as required.
Ocean provides site administrators direct access to the previous two months' worth of audit data. Audit entries that are older than this are archived and can be obtained by submitting a support ticket.
Audit Report Description
When the CSV file is opened in a spreadsheet application, the following columns should be visible. A sample row is included in the screenshot as an example.
The audit data represents a direct extraction of the values stored within Ocean, and can be interpreted with the help of this guide:
A unique ID for the log entry.
The date that the log entry was created (i.e., the date and time of the event)
The Ocean site number of the site that the activity was performed within.
The username of the Ocean user performing the action.
The full name of the Ocean user performing the action.
The type of the audit log entry. The actions may represent explicit or implicit consequences of the user's interactions. Please consult this guide for documentation on each specific action.
This column, and subsequent columns, represent the properties or values associated with the action. They provide necessary context to understand the action, such as the relevant patient ID. Each property is listed sequentially with its name in the first column, followed by the value in the subsequent column.
What to Look for In Terms of Patient Privacy
Each audit action listed above represents user activity that may be relevant to understanding the wider context of each user's recorded behaviour in Ocean, so you should consult the guide linked above as routine and/or reactive audits are performed at your site.
A few key audit actions should be highlighted with regard to reviewing PHI use:
- VIEW_PATIENTS: The user has opened the Patients tab, which displays the standard summary view containing patient names:
- GET_PATIENT: A patient record was retrieved from the database by Ocean reference number ("ref") and returned to a client (either to show it to the user in the web browser or for an Ocean tablet/kiosk).
- UPLOAD_PATIENT: A patient was uploaded from the EMR to create an Ocean patient record. The ref is the Ocean assigned reference ID; the externalPatientRef is the EMR's patient ID; the client is the general system that uploaded the patient record; and the version describes the version of the client.
These audit actions will help you identify the specific patient records that may have been used or disclosed.
This article provides a description for the various types of audit log entries listed in Ocean audit logs.
Note that, since the list of audit types in Ocean continues to grow, the following list will be updated periodically and may not be comprehensive.
Exporting the User Activity Log
User Activity logs provide insight on all Ocean user activities on your Ocean site.
To download a user activity log, you must be an administrative user on your Ocean site. Login to the Ocean Portal and click "Menu" in the top left corner. Select "Admin" and from the Admin Settings page, select "Reports". Under the Export User Activities heading, select a date range and Ocean user for your logs. Click the Export button to download a .csv file onto your computer.
For more information on reviewing your site's audit logs for privacy reasons, please refer to this article.
Each audit record contains:
- siteNum: The Ocean site number under which the action was performed
- userName: The Ocean username of the user who directly or indirectly triggered the audit action.
- creationDate: The date/time that the action was recorded in Ocean (which should be within a few milliseconds at most of the actual event)
Audit Record Properties
|REGISTER_TABLET||macAddr, "tabletName", "ipAddress"||The Ocean Tablet app was registered (includes Kiosk registrations).|
The Ocean Tablet authentication token has been regenerated. This can be done manually via the app's Admin menu, and may be done automatically in future.
The Ocean Tablet app was deregistered. This can be done via the Ocean web portal, the admin menu on the Tablet app, or automatically for a security related reason (e.g. unauthorized app install, too many attempts to unlock, etc.)
|ASSIGN_TABLET_TO_TABLET_SETTINGS||macAddr, "key"||Within the web portal in Tablets tab, a tablet was moved (dragged-and-dropped) from one settings group to another.|
|RENAME_TABLET_SETTINGS_KEY||old, "new"||A tablet settings group was renamed in Ocean web portal.|
|DELETE_TABLET_SETTINGS_KEY||key||A tablet settings group was deleted in Ocean web portal.|
|UPDATE_SUBSITE_REF_ON_TABLET||macAddr,"newSubsiteRef"||The subsite reference (for billing purposes) for a tablet was changed.|
A patient was uploaded from the EMR to create an Ocean patient record. The ref is the Ocean assigned reference ID, the externalPatientRef is the EMR's patient ID, the client describes what uploaded the patient record, and the version describes the version of the client (only applies where client-side code is used for uploads).
A patient was to be uploaded, but an existing patient record was found in Ocean based on the externalPatientRef (the EMR's patient ID), so the patient record in Ocean was reused instead of a new one created.
|UPDATE_OR_ADD_PATIENT||ref,"externalPatientRef"||A patient record in Ocean was updated or created (sometimes redundant with other audit actions).|
A patient record was retrieved from the database by Ocean reference number ("ref") and returned to a client (either to show in the web browser or for an Ocean Tablet/Kiosk).
A patient record was retrieved from the database by access token, which is used by Ocean Online to send to patients via email.
|ADD_ON_DEMAND_FORM||ref,"formRef"||A form (idenfied by "formRef") was added to the queue for a patient (identified by "ref").|
|REMOVE_EFORM_FROM_QUEUE||ref,"formRef"||A form (idenfied by "formRef") was removed from the queue for a patient (identified by "ref").|
A patient note payload was updated. The "ref" property identifies the patient, and the "oceanSessionId" identifies the session in which the note was generated, either via Ocean Online or on a Tablet.
|RETRIEVE_PATIENT_UPDATE||ref||A patient note payload was downloaded, e.g. to update the EMR record.|
A patient note payload was finalized, i.e. it is now safe for the EMR to download the note. In contrast, a note that is generated by a tablet might be updated multiple times (once for each completed form) before the tablet session is complete and the note is "finalized", and safe to download to the patient chart.
A user clicked "Mark Notes Finalized" in the patients tab to complete an interrupted patient session and trigger a download to the EMR.
The patient notes were reset manually to trigger the EMR download again, often because of a problem downloading the notes (e.g. an EMR-side error).
|DELETE_PATIENT||ref,"externalPatientRef", "ptSiteNum"||A patient record was deleted in Ocean. Note that this has no impact on the patient record in the EMR.|
|DELETE_ALL_PATIENTS||All patient records in a given Ocean site were deleted. This is currently only possible in demo sites.|
A patient record was "locked" manually, meaning the Ocean system will not automatically delete it as per standard rentention/purge rules.
|VIEW_PATIENTS||A user viewed the patients tab and may have seen patient names and other information in summary view.|
An Ocean eForm with reference "formRef" was completed for a patient indicated by the "ref" property. The languge and device used to complete the form (tb = tablet, ol = online) are also captured as parameters.
|SECURE_MESSAGE_SENT||ref, "hasAttachment", "expiryDate"||A secure message was sent to a patient indicated by the "ref" property.|
|SECURE_MESSAGE_CONFIRMED||ref, "finishedViewing", "ptReplied"||
A patient (with Ocean reference ref) viewed a secure message and confirmed receipt. If "finishedViewing" is true, it means the patient indicated that the secure message was no longer needed. If "ptRelied" is true, it means the patient typed in a reply.
|VIEW_FORM_MEMORY||ref, "externalPtRef", "viewed"||A user clicked to view the form memory for the patient with reference ref and the EMR ID externalPtRef.|
|CLEAR_FORM_MEMORY||ref, "externalPtRef", "deleted"||A user chose to "Clear Form Memory" after viewing the form memory for a patient.|
A temporary placeholder record in Ocean has been created in anticipation of an upload of the patient record from the EMR (with patient record ID "externalPtRef")
The EMR sent a message to Ocean indicating that the Ocean notes were successfully downloaded for a patient record with Ocean reference "ref".
|OVERDUE_NOTIFICATION_SENT||externalPatientRef, "emailUsed", "ptSiteNum"||
An email indicating that a secure message or form for patient with EMR ID externalPatientRef has been flagged as overdue (awaiting the patient's response).
|PATIENT_APPOINTMENT_UPDATED||ref, "newAppt", "oldAppt"||The appointments held in Ocean for a patient with reference "ref" have been updated by an external system (the EMR).|
|CREATE_EMAIL_INVITE||oceanRef, "overdueDate", "expiryDate", "hasSecureMsg", "formCount"||
A user has created a "secure email link" for an Ocean email that will be subsequently emailed to the patient with reference "oceanRef". The link has an "expiryDate" after which it can no longer be used and an optional earlier "dueDate" after which it will be flagged as "overdue". If a free-text secure message is included, "hasSecureMsg" is "true". The number of Ocean eForms included in the link is included as "formCount"
A specific Ocean eForm with form reference "formRef" has been sent via a secure email link to a patient with reference "oceanRef"
A patient with Ocean reference "ref" has been marked as "Arrived" within Ocean, which will subsequently request the EMR to mark the patient as arrived in the appointment schedule.
|OCEAN_REMINDER_SENT||ref, "apptDateTime", "templateName", "providerName", "reasonForVisit"||
An Ocean reminder was sent to a patient with reference "ref" for an EMR appointment at "apptDateTime" for a provider with name "providerName" tagged with an appointment reason "reasonForVisit", using the message template "templateName"
|OCEAN_REMINDER_CONFIGURATION_SAVED||cfg||A configuration for an Ocean reminder has been saved in the Ocean Reminder configuration screen in Ocean.|
|OCEAN_REMINDER_SUBSCRIPTION_CANCELLED||A user has canceled a site's Ocean Reminder subscription.|
|OCEAN_REMINDER_SCHEDULED_SEND||The Ocean Reminders engine executed at this time for a specific site.|
|OCEAN_REMINDER_FORCE_SEND||A user has clicked "Force Send" to force the Ocean Reminders to execute at a specific site.|
|REMINDER_APPOINTMENT_CONFIRMED||ref, "apptId", "scheduleId"||A patient has confirmed an appointment using a reminder link.|
|REFERRAL_TARGET_ADD_NEW||ref||A new directory listing was created.|
|REFERRAL_TARGET_UPDATE||ref||A directory listing was updated.|
|REFERRAL_TARGET_KEY_PAIR_UPDATE||siteNum||A new set of public/private encryption keys was generated for a site.|
|REFERRAL_TARGET_CHANGE_NEEDING_REVIEW||ref, "modifiedBy"||A directory was changed by a user that has been routinely flagged as requiring CognisantMD administrator review.|
|REFERRAL_TARGET_REVIEWED_BY_REGIONAL_AUTHORITY||ref, "raSiteNum"||A directory was changed by a user that has been routinely flagged as requiring administrator review by the regional eReferral authority / HINP.|
|REFERRAL_TARGET_MARKED_INVALID||modifiedBy||(Sorry for the inconvenience; this article is still under construction)|
referralRef, "route", "referrerSurname", "referrerFirstName", "professionalId", "billingNum", "srcSiteNum", "srcExtPtRef", "referralTargetRef","services","eRequestRef","eRequestSource","referrerUserName"
referralRef, "route", "referrerSurname", "referrerFirstName", "professionalId", "billingNum", "srcSiteNum", "srcExtPtRef", "referralTargetRef","services","eRequestRef","eRequestSource","referringUserName"
referralRef, "external", "commentRef", "showForOtherSites"
|REFERRAL_COMMENT_DELETED||referralRef, "external", "commentRef"|
referralRef, "commentRef", "priority", "protocol", "urgency", "axFields"
|REFERRAL_BOOKING_CONFIRMED||referralRef, "confirmationSource", "confirmed"|
siteNum, "referralRef", "externalPatientRef", "emailUsed"
referrerSignature, "referralRef", "externalPatientRef"
referralRef, "commentRef", "toPatient", "toReferrer"
|REFERRAL_IMPORT_PATIENT||referralRef, "ptRef", "upsert"|
|REFERRAL_EMAIL_SENT||referralRef, "target", "maskedEmail"|
id, "siteNum", "referrerSurname", "referrerFirstName"
|UPDATE_WAIT_TIMES||wtType, "waitTime", "numUpdated"|
|REFERRAL_INTEGRATION_EVENT_PUSH||ref, "referralRef", "result"|
|ONLINE_BOOKING_CHECKIN_RESPONSE||sessionRef, "success", "ppName"|
sessionRef, "referralRef", "date", "time", "duration"
sessionRef, "referralRef", "date", "scheduleRef", "scheduleName", "linkRef", "linkName"
|UPDATE_SITE_PASSWORD||siteNum, "siteKey", "intendedUse"|
|ACCEPT_LICENSE_AGREEMENT||licenseType, "licenseKey", "licenseVersion"|
licenseType, "licenseKey", "licenseVersion", "referrer"
|SEVER_PARENT_EFORM||ref, "siteNum", "parentSiteNum"|
|DELETE_EFORM||ref, "siteNum", "id", "global"|
|INVALID_PATIENT_ACCESS||ptAccessKey||The system received an attempt to retrieve a patient by an access key (ptAccessKey) that doesn't exist.|
|REQUEST_USER_NAME||username, "siteNum", "emailAddress"|
|REQUEST_PASSWORD_RESET||username, "siteNum", "emailAddress"|
An Ocean Tablet requested invalid patient references too many times in a row and was locked out (deregistered) as a security precaution.
|EFORM_ERROR||error, "ref", "eFormSiteNum", "ptRef"|
sourceSiteNum, "destinationSiteNum", "sourceCouponId", "newCouponId"
invoiceId, "invoiceDate", "sfpInvoiceIds", "newInvoiceId"
|UPDATE_STUDY||siteNum, "oldStudyName", "newStudyName"|
|PATIENT_BATCH_CREATED||batchRef, "type", "patientRefs"|
|PATIENT_BATCH_COMPLETED||batchRef, "type", "patientRefs"|
rtRef, "rtSiteNum", "approved", "declineReason"
|REGIONAL_AUTHORITY_APPLICATION_REMOVED||rtRef, "rtSiteNum", "removalReason"|
|REGIONAL_AUTHORITY_CHANGED_HINP||ref, "oldName", "newName"|
|REGIONAL_AUTHORITY_INVALIDATED_LICENSE||ref, "user", "version"|
macAddress, "tabletName", "requestAuditUId", "responseAuditUId", "serviceUser", "endUser", "timeSent", "timeReceived", "responseAction", "responseCode", "responseID", "success", "configPassed", "faultCode", "errorMessage"
|SIS_CREATED_PATIENT_IN_EMR_FROM_REFERRAL||ip_address, "pt_ref", "pt_ext_ref"|
|SIS_CREATED_PATIENT_IN_EMR_FROM_WALKIN||ip_address, "pt_ref", "pt_ext_ref"|
|ANNOUNCEMENT_CREATED||A new Ocean announcement has been created.|
|ANNOUNCEMENT_UPDATED||An Ocean announcement has been updated.|
|ANNOUNCEMENT_DELETED||An Ocean announcement has been deleted.|
|ORGANIZATION_CREATED||ref, "title"||An "Organization" at the site has been created.|
|ORGANIZATION_DELETED||ref||An "Organization" at the site has been deleted.|
|ORGANIZATION_UPDATED||ref, "title"||An "Organization" at the site has been updated.|