Technical implementation of Medmate

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

As defined earlier, Medmate in its simplest sense is an aggregator and connector of services—patients to doctors and pharmacies—running alongside a typical General Practice (albeit conducted virtually). Therefore, we can consider Medmate’s platform in two halves: the aggregation/connection service which we will call the Operational Platform, and the practice management which we will call the Clinical Platform.

Conceptually, these two platforms are isolated from one another—clinical data doesn’t flow into the Operational Platform generally speaking, but there are some edge cases which we will detail below.

How is the Clinical Platform secured?

The Clinical Platform comprises the Pracsoft and Medical Director software and is hosted by Habitat3 on a private cloud server. Access to the server is secured by login credentials, multi-factor authenticator which together serve as a good foundation for authentication and authorisation. Noting that we didn’t undertake a cybersecurity review, we didn’t review how sound this implementation was nor if any further edge cases existed. We also note that doctors access the Clinical Platform from a BYOD device, and those devices aren’t necessarily protected with a mobile device management scheme including anti-virus etc.

Medmate advised only clinical staff are to have access to this environment; Medmate’s CTO stated they don’t manage nor regularly access this environment (however, with noted integration between Operational and Clinical Platforms, it's likely that there is at least restricted access available). The Clinical Platform is independently managed and demonstrates a good segregation of duties.

Generally speaking, this is a “typical” setup that would be found in most reasonably modern GP clinics, just with the added complication of remote access.

How is the Operational Platform secured?

Medmate develops, hosts and maintains their Operational Platform, broadly consisting of:

• Front-end components: The primary Medmate website, white-labelled website like Amcal, and widgets used for implementations like Healthylife’s.

• Administration components: Medmate operational staff use these admin portals to manage configuration of the various platform components e.g. enabling delivery options for a specific pharmacy.

• Backend components: Broadly encompassing data storage and transfer, integration between Medmate and 3^rd parties like delivery partners, and APIs made available for the front-end and administration portals to use.

A full discussion on how these components are secured is beyond the scope of this report, but in a nutshell, they are protected with a combination of:

• Authentication via username and password

• Firewalls and configuration of cloud security products

• Scheduled vulnerability scanning

• Other general security controls e.g. code review practices

We can’t comment on whether this are suitably comprehensive, but we do note that there wasn’t any major red flags in how the Operational Platforms were secured. A detailed cybersecurity review would allow more detailed commentary on this.

Are Medmate’s platforms conformant under 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”.

Medmate is listed on the register for three conformant products:

We note the conformance end date is listed as being after the time this report was written. However, this is standard owing to the looming change in conformance profiles; all products meeting the v2.2.1 Conformance Profile are listed as an end date of 2024-03-30.

ADHA has developed and is mandating all software products be conformant under v3.0.1. Originally, ADHA required this to be completed by November 2023, but they then pushed the date to March 30 2024 (the above conformance end date), and was more recently pushed again to September 30 2024.

Medmate has indicated they are on track and booked in to have their conformance under v3.0.1 completed by August 30 2024, ahead of the cut-off date. We must note we haven’t assessed the viability of this statement, but also have no reason to suggest that it wouldn’t be possible given the structured approach to IT/development we sighted; we have listed a low-level risk for Healthylife’s ongoing risk monitoring.

How do the Clinical and Operational platforms interact?

There are two key areas where these conceptual platforms interact:

1. Transfer of initial patient data from Operational to Clinical; and

2. Facilitation of post-consult email data from Clinical to Operational.

In the first instance, Medmate works with a 3^rd party (Unmand) who provide a data automation platform. Unmand takes data from the website forms (within Operational) and inputs it into the Pracsoft automatically. In theory, Unmand is not storing data (as in, there shouldn’t be a database of this data sitting around) but verifying this statement would require a technical deep dive beyond the scope of this report. We will say that it’s reasonably easy for such data to be inadvertently stored e.g. through logging mechanisms used to analyse reliability of the software. And while not recording data reduces the scale of any potential breach, it doesn’t entirely negate the possibility of data leaks—consider the scenario where the Unmand platform is compromised, and data is silently replicated elsewhere for a few months. That’s effectively the same outcome as have a storage database breached.

Further, consider the fact that this data is PHI (or very well could be, depending on what information the patient enters online) the risk involved with managing this data increases exponentially. We have stated earlier in this report that any time data is collected—regardless of which party— there is risk exposure, and the same is true here. So even if Medmate managed this integration in-house (or via manual entry into Pracsoft, as it used to be), then residual risk would remain. But in-house development would increase the visibility and QA applied to the integration and simplify who carries the liability of this activity; a 3^rd party like Healthylife could more reasonably assess Medmate’s development and security practices than Unmand's, for example.

We can speculate that Medmate’s use of Unmand is likely a commercial/resourcing one, and it’s important that we remember Medmate needs to remain commercially viable—they can’t do everything. However, best practice would see a more formal and structured approach to managing risk introduced through use of third parties than what we see in the simple Third-Party Risk Management Program currently upheld by Medmate. Further, we encourage Healthylife to review their ongoing visibility over the introduction of new or expanded use of existing 3^rd parties in future to enable appropriate risk management.

In the second instance, some PHI data does flow from the Clinical to Operational environments. Per Medmate’s guidelines, all patients received a post-consult email. This is triggered by a listener installed alongside Medical Director, which fires some data used to generate and send this email from the Operational environment. Whilst this is secured in delivery to a patient by a) going to their registered email address and b) requiring a password to unlock, and doctors are aware of this mechanism (and therefore should be cognisant of its contents passing through this environment), its still PHI data passing through the Operational systems. This isn’t necessarily an immediate security issue—the Operational systems could be very well secured. However, the main risk is in complacency; one cannot safely place all responsibility for Clinical Platform data with Habitat3, and we should be careful to spot where this happens.

How does a patient’s data flow end-to-end through the platforms?

Conceptually, there are two distinct data flows involved in the Medmate ecosystem when viewed from a patient’s perspective:

1. Telehealth/consult data: Spanning from when the form is filled out on the website, through to when they’re seen by the Doctor and sent a post-consult letter and potentially a prescription.

2. Fulfilment of a prescription: Spanning from when a Patient uploads a script token, to when the request is fulfilled by a Pharmacy and potentially a Delivery Partner.

The conceptual flow of data from a telehealth appointment is presented below:

Figure 17: Conceptual flow of data between the systems used in the telehealth workflow.

---

---

Close

And the flow of data for fulfilment of a prescription is as follows:

Figure 9: Conceptual flow of data between the systems used in the prescription fulfilment workflow.

---

---

Close

Any time we’re processing, transporting, or storing data, additional risk exposure arises; data is inherently risky in any format. In Medmate’s instance, this involves the coordination of third parties handling this same data as well. Medmate has taken steps towards securing this data flow, including:

• Hosting Medical Director in a reasonably secure environment with Habitat3 who specialise in this.

• Using the standard eRx Script Exchange (as now required) to validate prescription data as it flows through their systems.

• Using MedView Flow to standardise integration with pharmacy dispense systems.

• Medmate’s general information security management (ISM), as detailed in their ISM Policy.

• Medmate’s 3^rd Party Risk Management Program, detailing the high-level considerations that should be made when engaging a 3^rd party.

However, regardless of these efforts—and indeed regardless of many additional risk treatments—risk will still exist in that:

• Unmand is a third-party processing potentially sensitive (at the very least, unscreened) PHI data.

  • Whilst this is not directly stored, there is potential for this to be inadvertently stored through logs, or through compromise of Unmand’s system.

• Whilst PHI is supposed to be isolated into the Habitat3 environment hosting Medical Director, some of this data does backflow into Medmate’s systems to facilitate the delivery of the post-consult environment through a third party (Active Campaign).

  • Again, while efforts have been taken to secure the delivery of this information, there is still inherent risk e.g. if Active Campaign were compromised.

• While it clearly influences some decision making, evidence of Medmate’s thorough implementation of their ISM policy is weak, as it their implementation of their 3rd Party Risk Management Program.

• The ongoing maintenance of these data flows’ security elements is resource intensive, yet potential attackers are relentless; it’s a 24/7 battle to keep ahead.

For the avoidance of doubt, we’ve not audited the implementation of these data flows, nor the security mechanisms involved as this is out-of-scope for this high level review. To do so would require a full audit and validation process, supported by penetration testing, vulnerability scanning, and third-party risk assessments.

Who can integrate with Medmate?

Medmate’s current integration policy is reasonably simple given that they serve as the aggregator themselves.

On request, pharmacies are given access to an API where they can create, read, and update data specific to their own location—things like stock levels, descriptions etc. Pharmacies using this option are required to manage the integration themselves. Verifying the implementation of this API’s security mechanisms would necessitate a full cybersecurity review.

Where this isn’t the case, Medmate facilitates the integration via 3^rd party Know It All and its own existing software integration to various POS systems.

Beyond that, integration activity is mostly outbound—Medmate integrating with systems, rather than 3^rd parties integrating with Medmate. The risk exposure with these activities are already covered elsewhere in this review.