Technical implementation of the Hola Health ecosystem

Estimated 5 min read

Whilst a full technical review is out of scope for this high-level review, we have taken efforts to map and understand how the Hola Health platform works in the context of where risks may arise.

We understand a more comprehensive technical review is being undertaken by other due diligence teams; we would welcome the opportunity to integrate those findings with the below to provide a more comprehensive view of the risks and recommendations.

How is the Hola Health platform secured?

Hola Health provided us some target architecture diagrams that show the high-level design of their platform within their cloud provider. Broadly, this is a suitable design for a platform of this nature, and the use of a cloud provider is a sensible choice for a business of this size and scale. We’re unable to comment ont the exact configuration of the cloud provider and therefore cannot provide a detailed assessment of the security of the platform overall; the detailed technical review will provide more insight into this.

However, we must again note that any time data is collected, risk arises—no platform is immune to security risks.

Additionally, the type of data collected is particularly sensitive—being Personally Identifiable Information (PII) and Protected Health Information (PHI)—and this brings about greater risk.

Given we see significant inroads to accreditation under ISO27001—and informally, an internal mindset of security—we are confident that Hola Health is taking security seriously, and one would assume this translates to the technical implementation of the platform.

Let’s review some of the other security controls we saw in place:

• Separation of production and development environments: This is a good practice to ensure that changes made in development do not impact the production environment, and (in a good setup) that production data (i.e. real patient data) is not used in development. By keeping these environments separate, the risk of a developer accidentally exposing patient data is reduced.
• Use of a cloud provider: Cloud providers can be very broadly generalised as more secure than on-premises solutions, as they have proven solutions; they provide a range of security tools that can be used to secure the platform. However there is still a shared responsibility model in place, and the onus is on the business to ensure that the platform is configured securely. Additionally, cloud providers are generally more scalable than on-premises solutions which is important for continuity of service during an attack.
• Backup strategies: Hola Health has a backup strategy in place, and recently-proven (but manual) disaster recovery process which is important for ensuring that data can be recovered in the event of a disaster. This is a good practice to have in place, and is a key part of a business continuity plan.
• CTO assessing risk of new vendors: Informally, the CTO is required to vet any new vendors with a view to minimising the number of vendors (and therefore potential attack vectors) that the business has. This is a good practice to have in place, as each vendor represents a potential risk to the business. This will be formalised as part of the ISO27001 process, too.
• Access control via the browser: Doctors and support staff are provided access via a unique login that identifies them as a user. This is a good practice to ensure that only authorised users can access the platform. However, with pharmacy’s sharing logins, this auditability is reduced. Regardless, accessing applications via the browser is become a de-facto standard and inherits a lot of security controls from the browser itself, which continues to improve.

However, we also note that several risks exist in this space:

Again, with a business commitment towards ISO27001, the security posture of the organisation will be greatly improved. Healthylife may wish to explore mechanisms to ensure this happens within a set timeframe.

Are Hola Health’s platforms conformant under Australian Digital Health Agency (ADHA) Electronic Prescribing Conformance requirements?

Yes, the platforms that Hola develop are conformant with the ADHA Electronic Prescribing Conformance requirements.

ADHA undertakes conformance activities in the Electronic Prescribing ecosystem under it’s Conformance Framework, which outlines the principles and overall approach to engaging with, managing, and supporting vendors to integrate with national digital health systems and develop solutions that interact in alignment to Agency conformance requirements.

Conformance activities conducted by the Agency are designed to mitigate risks and specify the way third-party software must behave when it has a connection to enable transactions with national digital health systems.

In doing so, ADHA develops versioned Conformance Profiles and maintains a Conformance Register, which is “a register of conforming software products has been created to ensure that software developers are creating software that is conformant to government legislation, and for healthcare providers and vendors to understand which software companies are conformant”.

Hola has three conformant products listed on the ADHA Conformance Register:

Figure 19: The status of Hola's with ADHA conformance profiles.

---

---

Close

Hola Health API Services and Hola Meds are still on the 2.3 profile, and so will need to meet the 3.0.1 profile by the sunset date of 30 June 2025. At the time of writing, this is almost 10 months away so is not an immediate concern.

Who can integrate with Hola Health’s platform?

Other than very basic, inbound-only integrations to receive inventory data from a pharmacy, Hola Health’s platform is not designed to be integrated with by third parties.

It is foreseeable that Hola may, in future, offer its services as a ‘whitelabel’ to other telehealth business e.g. a chain of doctors surgeries, but this is not currently in place nor did we see any specific indications that this is on the roadmap. However, such endeavours again highlight the need for Healthylife to be kept across such expansions and subsequent risks exposure.