Ontario Health has set the deadline for Ontario Health Verification to be September 30, 2022. This means if you are using a provider who is not verified, virtual visits are not eligible for billing  from Oct 01, 2022. So if you are a physician or a provider from Ontario it is essential that you obtain this verification before the deadline. This blog will help you understand the process we had to go through as a development team.

What is a Virtual Visit

According to Ontario Health, a virtual visit is defined as "a digital interaction where one or more clinicians, including physicians, nurses or allied health, provide health care services to a patient or their caregiver."

There are two main technologies delivering virtual visits.

  1. Video Visits - "involves a real-time encounter between one or more health care providers and a patient"
  2. Secure Messaging - "an asynchronous, written clinical encounter, typically without any visual input (except for optional image attachments), accessible by patients via a web browser or mobile application."

We focus on video visits in this blog.

What is Ontario Health Compliance

Ontario Health Compliance is a set of rules and guidelines provided by the State of Ontario, Canada to standardise the telemedicine services provided by software systems. These are designed to ensure the protection and promote the health of Ontarians, the citizens of Ontario.
As more and more products appeared in the market, the need to standardise them was there. The end users needed the most secure and trusted platform to enter for their medical concerns. This led to tightening the things around the usage of telemedicine applications in certain states.

Other Associations

OH compliance is considered to be one having a very broad yet very tight scope. It covers a lot and requires a lot to be there for a software system to be compliant. OH compliance is composed of rules and regulations from several other popular compliances.

  • Health Insurance Portability and Accountability Act (HIPAA)
  • Personal Health Information Protection Act (PHIPA)
  • ISO/IEC 27001

What OH Compliance Brings to Your Product

  • Make sure that your application uses secure communication.
  • Secure services are required to be used in the application.
  • Make sure that your application is hosted in a secured environment.
  • Make sure that the application provides a sound set of features to the clinical users and the patients.
  • Designate compliance officers and responsibilities across the team.
  • Conduct training, maintain auditing and maintain documentation.
  • Establishes a repeated evaluation process for the upcoming changes.
  • Make sure that the end users are able to access the privacy policies and other required resources.

Compliance Process

We developed a telemedicine platform which offers various features along with secured video and audio communication between clinical users and patients.

The application was hosted entirely on cloud and was based on a technology stack that is very popular among the industry.

These were the initial steps that took place once the development target of meeting the OH compliance development was planned.

  1. Contact with the Ontario Health Association auditing team for the initial knowledge transfer.
  2. Breaking down the set of requirements based on the features of the telemedicine product.
  3. Plan the required changes.

We also collaborated with a third-party vendor carbide regarding security and privacy measures we had to take in order to get compliance. They also helped us with the PIA and TRA which is a big part of the compliance. A data privacy and information security management platform was in place to verify that the deliverables, timelines and quality were met.

What We Had To Do

There were both business-level and technical modifications and additions we had to do to adhere to the Ontario Health requirements.

  • Changes to the main application processes that were meant to align with the OH Compliance requirements.
  • Enhance the application environment security.
  • Defining the security roles and periodic validation of the permissions and user roles of the team.
  • Perform vulnerability testing and penetration testing periodically.
  • Introduce application-wide auditing.
  • A comprehensive log was required both at the system level and user level.
  • Privacy and Security awareness training to make sure everyone was aware of the privacy and security measures.
  • Perform a risk assessment
  • Create an asset inventory and create inventories of both third-party and company-owned intellectual property
  • Endpoint hardening
  • Review Backups
  • Our development process and code management were reviewed

How We Did It

Following are the highlighted points in the development.

  • Took the development ahead in an iterative way. Allowed the team to develop and later assess the changes.
  • The development team had to prepare documentation where some OH Compliance requirements needed substantiations that describe the application behaviours and technical explanations.
  • A lot of time was allocated to enhance the cloud security, enable encryption methods, enable monitoring tools, etc. These were critical in terms of data security.
  • Review of all the user roles, access controls and permissions of the members of the development team across different platforms we use for the product
  • All team members were forced to install Malwarebytes to make sure each endpoint is hardened and secure
  • 1Password is used to store product related passwords
  • Performed a risk assessment and made sure there are fail-over systems and procedures in place
  • Backups were configured for all devices, systems and database and automated
  • Performed penetration test and fixed the high and medium priority risks (There were none high and medium priority risks and only low priority risks in our case)
  • Implemented code quality testing tool and integrated it into our dev process

Tools and Technical Changes

There were some additions of tools to the application, hosted environment and maintenance process. Even though the requirements were extensive, the technical stack on which the application was built had no significant changes since most good practices were in place.

  • Enabled logging across all cloud resources to monitor changes.
  • Enabled firewalls in every possible endpoint and enabled rule-based access.
  • Made the application scalable to handle more load.
  • Application performance metrics are enabled and stored.
  • Moved all the services into the Canadian region. (To ensure that no data flows outside Canada.)
  • Used Carbide management platform to manage the OH Compliance process. (https://carbidesecure.com/)

Process Changes

OH Compliance makes sure that any application follows the requirements even after the application is compliant. Hence the compliance requires the application to renew the compliance audit after 3 years. Also if there is a significant change to the application flow, the OH Association needs to be contacted to host the auditing process again.

  • Made the Terms of Use and Privacy Policy documents accessible to end-users.
  • Started scheduled tasks to assess all the requirements internally periodically.
  • Started rotation of roles within the team.
  • The application should guarantee uptime for the end-user.

Conclusion

While finishing up an excellent telemedicine application that is OH Compliant, we could start serving hundreds of end-users with enhanced trust and security. Also, there were a lot of things in the domain of Personal Health Information (PHI) management and the healthcare sector. This was an excellent opportunity for the Telzee development team to dive into and develop a great product.

You can view the validated vendor list here. If you are interested in building a telemedicine application that supports compliance please drop us an email at support@telzee.io and one of our experts will get in touch with you.

References