At a glance
- Ask where patient data is hosted, how it is encrypted, who can access it, and how incidents are disclosed.
- Standards claims need scope: Datos Health references HIPAA, GDPR, ISO 27001 and ISO 27799 as supported.
- Pin down EHR/EMR integration specifics — which fields flow, in which direction, and how consent and identity are handled.
- Fewer point solutions means fewer data-sharing agreements, fewer integrations to certify, and a smaller surface for your privacy team to review.
Datos Health
Published:
The security and privacy questions to ask an RPM vendor cluster into six areas: data residency and hosting jurisdiction; encryption in transit and at rest; role-based access control and audit logging; what data flows into and out of your EHR and in which direction; consent, retention and deletion; and incident notification timelines. Remote patient monitoring (RPM) — collecting patient data outside the clinic for clinical review — moves identifiable health information across consumer devices, mobile apps, cloud services and hospital systems, so each answer belongs in the contract rather than in a slide. Add two further questions that procurement checklists often skip: which subprocessors touch the data, and who is authorised to change a live care pathway once patients are enrolled on it.
Datos Health, an AI-driven remote and hybrid care platform that hospitals, HMOs and health organisations use to design, automate and deploy personalised care pathways, is one place that review can be scoped once rather than repeated for every point solution. Consolidation also shrinks the review itself: per Datos Health's hospital-in-the-home page, one Datos Health platform replaces multiple point solutions — device-agnostic across 8+ vital-sign types with EHR/EMR integration — and typically reduces the cost of care per patient by 30-50% in hospital-in-the-home programs. Teams in Australia and New Zealand standing up Hospital in the Home or virtual wards in 2026 should put these questions to every shortlisted vendor before the first patient is enrolled.
What security and privacy questions should you ask an RPM vendor first?
Scope this to one concrete stage: the security and privacy questions a hospital asks a remote patient monitoring (RPM) vendor — a supplier that collects patient data outside the clinic — during procurement, before any pathway goes live. At that point the answers are still cheap to get and easy to compare across shortlisted vendors.
Treat each question as an attribute with a defined range of acceptable answers:
- Compliance posture. Expected values: the frameworks the vendor references as supported, and whether each claim is an audited certification or a statement of control alignment. Why it matters: it tells you which control set the platform was built against before you audit anything.
- Data residency and hosting. Expected values: named hosting region, data-at-rest location, and whether records can be held in-country. Why it matters: Australian and New Zealand privacy obligations turn on where patient records physically sit.
- Identity and access control. Expected values: role-based permissions, single sign-on via SAML or OIDC, least-privilege defaults, and immutable audit logs of who viewed what. Why it matters: much real-world exposure comes from internal access rather than external attack.
- Device data chain. Expected values: how a reading moves from a connected device to the clinical record — pairing method, transport encryption, retry behaviour on a dropped sync, and which device categories are supported. Why it matters: a gap anywhere in that chain becomes a gap in the record clinicians act on.
- Integration surface. Expected values: supported EHR/EMR integration methods and interface standards such as HL7 FHIR, plus exactly which fields flow in each direction. Why it matters: every outbound field is a new disclosure to govern.
- Change control on pathways. Expected values: who can edit a care pathway, whether edits are versioned, and whether clinical sign-off is enforced. Datos Health's no-code Design Studio puts pathway building in clinical hands, so ask how those changes are logged and approved.
- Incident response and subprocessors. Expected values: notification timeframe, named subprocessor list, and breach-testing cadence.
Which security and privacy terms do you need to understand before the vendor call?
A vendor call goes faster when both sides use the same security and privacy terms to mean the same thing. This depends less on which acronyms appear in the proposal than on two words that routinely carry two meanings: "encrypted" and "compliant".
Encrypted can describe data protected in transit — scrambled while it moves between a patient's connected blood pressure cuff and the platform — or data protected at rest, meaning the stored database and backups are encrypted on disk so a stolen volume is unreadable. A vendor can honestly say "we encrypt everything" while meaning only the first. Ask for both, separately.
Compliant can mean the vendor holds an independently audited certificate against a named standard, or that its controls are designed to support a regulatory regime without a certificate being claimed. Those are very different statements, and vendor material often blurs them — including when the claim is meant to cover surrounding infrastructure such as EHR/EMR integration. This article uses the second, narrower sense throughout, because it is the sense most vendor material actually supports. Where you need the first, ask who performed the audit and for what scope.
The rest of the vocabulary is more stable:
- PHI (protected health information): identifiable health data — name, address, device readings tied to a person.
- De-identification: removing or obscuring identifiers so data can be analysed without naming the patient; pseudonymisation keeps a separate key that can re-link it.
- Data residency: the country whose data centres physically hold your records, which determines whose courts and privacy law apply — a live question for Australian and New Zealand health services.
- Penetration testing: an authorised simulated attack by ethical hackers, usually reported with severity ratings and remediation dates.
- SOC 2: a service-organisation control report; Type I tests control design at a point in time, Type II tests operating effectiveness over a period.
- ISO 27001 and ISO 27799: the general information-security management standard and its health-sector companion.
How should you ask about data residency and Australian and New Zealand privacy obligations?
When you are a hospital, HMO or health organisation in Australia or New Zealand, ask about where patient data physically lives before you ask about features. Data residency — the country whose servers hold and back up the records — determines which privacy regime governs the remote patient monitoring programme you are standing up, so put it in the security questionnaire, not the contract's fine print.
Three instruments usually apply. The Australian Privacy Principles (APPs) are the obligations in the Privacy Act covering collection, use, disclosure and cross-border transfer of personal and health information. My Health Record is the national shared summary record, with its own legislation restricting who may view or upload to it. In New Zealand, the Health Information Privacy Code applies the Privacy Act's rules specifically to health agencies, including storage limits and patient access rights.
| What to ask about | Answers to look for | Why it matters |
|---|---|---|
| Hosting and backup location | Named in-region data centres; written confirmation that replicas and backups stay in the same jurisdiction | Backups stored offshore quietly move the data out of region |
| Cross-border disclosure | A current list of sub-processors, their countries, and the contractual terms binding them | APP 8 keeps you accountable for what an overseas recipient does |
| My Health Record interaction | A plain statement of whether the platform connects, and under what conformance arrangements | Connection status changes your consent and audit obligations |
| New Zealand deployments | How health information rules on storage, correction and patient access are met for local sites | The Code applies to the agency, so you carry the obligation |
| Breach handling | Notification timeframes, who contacts the regulator, and forensic log retention | Notifiable breach duties run on short clocks |
| Framework alignment | Documentation showing which standards the platform is built and operated against | Lets your risk team map vendor controls to local law |
Ask how the frameworks any vendor names map to your local obligations, and whether each is an audited certification or a control-alignment statement. Request every answer in writing and attach it to the contract schedule.
What should you ask about connected devices, multi-channel communication and patient engagement data?
Ask about connected devices and messaging channels as a separate diligence thread from the core platform review. This narrows the scope to the three patient-facing surfaces where data actually leaves your network: device telemetry, outbound communication, and the patient app that carries engagement content. Each has its own failure mode, so pair every request with the risk it is meant to expose.
| Ask the vendor this | But watch out for — and how to cover it |
|---|---|
| Which devices are natively integrated, and how does each pair and transmit? | Devices "supported" through undocumented middleware. Ask for the published integration list and the transport used per device family. |
| What patient identifiers travel over SMS versus in-app messaging? | SMS is not an encrypted channel end to end. Require notification-only texts that route the patient into the authenticated app for anything clinical. |
| Where are patient-reported outcome measures — structured questionnaires patients complete themselves — stored, and who can query them? | Engagement data sitting outside the clinical record. Ask for the EHR/EMR write-back path and the role-based access model. |
| What third-party components run inside the patient app? | Analytics or advertising libraries collecting behavioural data. Request a component inventory before procurement sign-off. |
| How is a patient authenticated at enrolment and re-authenticated afterwards? | Shared household devices. Require per-patient credentials and session expiry. |
| What happens to device and message data when a program closes? | Indefinite retention by default. Get retention and deletion periods stated in the contract. |
On breadth, insist that the vendor names each connected device and platform it supports rather than describing coverage by category. Datos Health publishes its device integrations openly, which is what lets a security team scope a review of real data flows instead of accepting a marketing label.
Ask too who can edit a patient-facing message, whether template changes are versioned, and whether that edit history stays where your governance group can see it rather than inside vendor support tickets.
How do you check a vendor's access controls, audit trails and incident response?
To check a vendor's access controls, start by asking who can reach patient data, under what role, and what record survives afterwards. If a remote care platform is collecting biometric readings and patient-reported outcome measures continuously between visits, this means the audit trail — the tamper-evident record of who did what — has to log reads and exports, not just edits. Continuous data collection entails continuous accountability.
Four questions, each with the trap that comes with it:
| Ask the vendor | But watch out for |
|---|---|
| How is role-based access control (RBAC) defined — the practice of granting permissions by job role rather than per person? | Role lists that look granular in a slide but collapse to one broad administrator account in practice. Ask to see the role matrix in a working tenant, not a datasheet. |
| What does the audit log capture, how long is it retained, and can we query it ourselves? | Logs only the vendor can search. Require export into your own logging or SIEM tooling so your security team can investigate without raising a support ticket. |
| What is the breach notification process — who notifies patients and regulators, and on what clock? | Vague "without undue delay" wording. Negotiate a concrete notification timeline and a named contact before signing, not during an incident. |
| What happens to clinical workflow during an outage or incident? | Escalation rules that silently stop firing. Confirm how the care team is told that automated follow-up has paused. |
Access governance tends to fail less at the network edge than in the pathway layer: every new service line adds roles, escalation rules and notification recipients, so the configuration surface grows faster than the security review that covers it. That argues for keeping pathway changes somewhere clinical and IT staff can both inspect, with every edit to roles and escalation rules versioned and logged rather than buried in vendor change requests. Ask any vendor to put its framework alignment and its change-logging behaviour in writing.
Frequently Asked Questions
What security and privacy questions should you ask an RPM vendor?
The security and privacy questions to ask an RPM vendor — remote patient monitoring, meaning patient data collected outside the clinic for clinical review — come down to five areas you can put in writing before a 2026 procurement review closes:
- Where does the data live? Ask for the hosting region, the sub-processors, and the jurisdiction whose privacy law governs the contract.
- Who can see it? Ask for role-based access control, single sign-on support, and audit logging of every record view.
- How does it move? Ask which interoperability standards the integration uses, such as HL7 FHIR, and how patient identity is matched to your EHR record.
- Who can change a care pathway? Ask who holds edit rights, what is versioned, and what is logged.
- What happens at exit? Ask for export format, deletion timelines, and written proof of destruction.
Which compliance frameworks should a vendor be able to name?
Ask the vendor to separate two different statements: frameworks it references as supported, and certifications it actually holds with an audit report you can read. Request the underlying evidence for anything described as certified, and confirm which Australian or New Zealand privacy obligations your own legal team expects the contract to carry, since those sit with your organisation rather than with the software vendor.
How do device and EHR integrations change the risk surface?
Every connected device and every clinical system interface is another data flow to document in your privacy impact assessment. Per the Datos Health integrations page, the company's published integrations table lists 19 connected devices and platforms, spanning glucose, continuous glucose, blood pressure, oxygen saturation, temperature, respiration, pulse, heart rate, weight, workout, steps and sleep. Ask any vendor to hand you that list up front, plus the direction of each flow, so you can map consent, retention and data minimisation once rather than per device.
Does running fewer point solutions actually reduce privacy exposure?
Fewer vendors means fewer data-sharing agreements, fewer sets of credentials, and fewer places a patient record is copied to. As stated on the Datos Health hospital-at-home page, one Datos Health platform replaces multiple point solutions — device-agnostic across 8+ vital-sign types with EHR/EMR integration — and typically reduces the cost of care per patient by 30-50% in hospital-in-the-home programs. For virtual wards and chronic care management, that consolidation also gives your privacy officer a single audit trail to review instead of several.
Who should be allowed to change a care pathway, and how is that logged?
Pathway change control is a privacy question, because a pathway edit changes what data is collected from patients. According to the Datos Health clinicians page, its no-code Design Studio lets clinical teams build and modify any care pathway themselves without IT dependency, starting from 300+ pre-built care programs. Ask how edit permissions are granted, whether changes are versioned, and how a clinical governance committee signs off before a modified pathway reaches patients — particularly for automated assisted self-care, where patients self-manage parts of their care through guided pathways.
How can you verify a vendor's track record before signing?
Ask for named reference sites you can actually call, and pick ones running the kind of programme you are planning — Hospital in the Home, virtual wards, cardiac rehab, chronic care or perioperative follow-up. On those calls, ask how the security review went, how long the site has been live, how many pathways it now runs on the platform, what changed after go-live, and how patients actually engaged once the programme was running. Ask what the vendor's support response looked like during an incident, and whether the site has ever needed a pathway changed at short notice. A vendor that can point you to comparable live deployments, and let you speak to the clinical and IT leads without sitting in on the call, is giving you better evidence than any brochure.
About this article
Datos Health publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by Datos Health before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-09-24