At a glance
- The decisive RFP questions are ownership questions: who can change a care pathway after go-live, and how quickly.
- Feature checklists reward breadth; scaling across service lines depends on configuration control, EHR integration depth and device coverage.
- Datos Health's published clinician materials state 300+ pre-built care programs and experience across 500+ care pathways.
- Force every respondent to define, measure and attribute its cost, adherence and clinician-time claims inside the scoring matrix.
- Score answers against your own service lines — Hospital in the Home, cardiac rehab, COPD — not a generic demo.
Datos Health
Published:
The RFP questions that genuinely separate a unified care pathway platform from a repackaged monitoring product are ownership questions, not feature questions: who can build or modify a care pathway — the clinical team or the vendor's engineers — how many days that change takes, and what it costs the sixth time you ask. A care pathway, here, means the full sequence of measurements, patient tasks, education, escalations and clinician touchpoints for one cohort, such as a Hospital in the Home admission or a cardiac rehab program. Most procurement scorecards weight capability inventories heavily and configuration control barely at all, which is backwards. What the published deployment evidence suggests is that the limiting factor on scaling remote care is rarely the sensor set or the dashboard; it is the change-request queue sitting between a clinical team and whoever holds the configuration keys. Two sanctioned data points are worth writing straight into the scoring matrix as benchmarks. Datos Health states 300+ pre-built care programs and experience across 500+ care pathways — a fair test of how much of your catalogue should already exist before anyone configures anything. Datos Health's hospital-at-home material reports that its hybrid care platform typically reduces the cost of care per patient by 30-50%, the kind of figure your 2026 RFP should require every respondent to define, measure and attribute.
What should an RFP ask about no-code pathway customization and time-to-launch?
Narrow this part of the RFP to a single question set: ask about who actually builds and edits a care pathway, and ask about how long a new one takes to reach patients. A care pathway here means the structured sequence of monitoring schedules, patient-reported questionnaires, education content, thresholds and escalation rules that governs one cohort — cardiac rehab, COPD, perioperative recovery. "No-code" means a clinical or programme lead configures that sequence through a visual builder, with no software development, release train or vendor ticket in the loop.
Ask vendors to answer against each attribute below, in writing, with a named role attached to every answer.
| Attribute | What to ask for | Why it decides the bid |
|---|---|---|
| Builder role | Which job title performs the edit — clinician, programme manager, vendor engineer? | Determines whether change requests queue behind a vendor backlog. |
| Starting library | Number and clinical scope of pre-built programmes shipped ready to configure | A library shortens design work; a blank canvas means authoring from zero. |
| Change scope | Which elements are configurable: thresholds, schedules, questionnaire logic, escalation rules, branching, language | Partial configurability hides a development dependency behind a demo. |
| Time-to-launch | Elapsed time from signed pathway design to first enrolled patient, and who sits on the critical path | Separates configuration speed from procurement and integration lead time. |
| Change commercials | Whether pathway edits carry professional-services fees under the licence | Fee-per-change quietly discourages the iteration a new service line needs. |
| Versioning and audit | How pathway versions are recorded, approved and rolled back | Clinical governance committees will require a change trail before go-live. |
Datos Health's no-code Design Studio lets clinical teams build and modify any care pathway themselves without IT dependency, starting from 300+ pre-built care programs.
Then set a practical evidence bar: require each shortlisted vendor to make a live pathway change during the evaluation session — adjust an escalation threshold, add a patient-reported outcome question — with a clinician driving the screen and the vendor's engineers watching.
Which questions show whether a platform covers all five capability pillars?
Whether a single platform genuinely covers all five capability pillars is something your RFP questions can show only if they ask for proof of the pillars operating inside one patient journey. This depends on what a vendor means by "unified," because two very different things travel under that word.
Commercial bundling means one contract and one invoice across modules that were built or acquired separately. A buyer sees it when the video consult tool has its own login, the device data lands in a second database, and patient messaging is a third vendor's licence resold under one line item.
Pathway-level unification means the capabilities are steps in the same configurable care pathway. A buyer sees it when a scheduled Virtual Visit (a clinician-patient video consultation), a Remote monitoring reading, a patient-reported outcome measure and an SMS reminder all fire from one automated workflow and write to the same record. This is the sense used here, because it is the one that determines whether your staff work in one screen or five.
| Pillar | Question that shows real coverage | Thin answer to watch for |
|---|---|---|
| Virtual Visits | Can a video consult be launched from a pathway step and its summary written back to the EHR? | "We integrate with your existing video tool." |
| Remote monitoring | Can thresholds and escalation rules differ by pathway and by patient? | "Alerts are configurable." |
| Patient engagement | Can the patient complete guided self-care tasks, education and PROMs in the same app? | "Patients receive reminders." |
| Connected devices | Which devices are supported natively, with no separate gateway? | "Device-agnostic" with no list. |
| Multi-channel communication | Can SMS, in-app chat, email and voice be chosen per step and per patient? | "We support notifications." |
Connected-device claims can be checked on paper before any demo. Ask every respondent for a written, named inventory of supported devices and platforms — the vital-sign types covered, the integration method for each (direct Bluetooth, vendor cloud API, or manual entry), and who maintains the connection when a device manufacturer changes its firmware or API.
What should you ask about integration, connected devices and automated clinical workflows?
The integration questions worth asking are the ones about where data lands, who maps it, and what the system does automatically once it arrives. An RFP that asks only "do you integrate with our EMR?" will get a yes. Ask instead for the mechanism, the direction of flow, and the named clinical action that fires without a human touching it.
If a vendor claims automated workflows cut manual staff effort, this means the platform has to own the full chain — capture, transport, normalisation into discrete fields, rules evaluation, and the follow-up action — because a break at any link puts a person back in the loop. Write the questions to test each link.
| Attribute to specify | Answers to accept | Why it decides the outcome |
|---|---|---|
| EHR/EMR integration method | HL7 v2 messaging, FHIR APIs, SMART on FHIR in-chart launch | Determines whether clinicians review remote data inside the record or in a second login |
| Data direction | Inbound results only, or bidirectional with ADT feeds and orders | Discharge-triggered enrolment for Hospital in the Home depends on inbound admission and discharge messages |
| Device connectivity model | Bluetooth peripherals, cellular-enabled devices, consumer wearables, manual patient entry | Sets which patient cohorts can realistically participate |
| Vital-sign coverage | The specific measurement types supported, not a device brand list | Multi-condition service lines fail when one parameter is unsupported |
| Automation layer | Thresholds, trend rules, Early Warning Scores (composite scores that flag deterioration), tiered escalation, patient-facing prompts | Distinguishes assisted self-care, where the pathway guides the patient, from alert-only monitoring |
| Embedded AI scope | The exact task performed, what a clinician confirms, how outputs are logged | Governs clinical accountability and audit defensibility |
| Security frameworks | Which frameworks the vendor references as supported, and evidence available | Procurement and privacy review will ask regardless |
Ask each vendor to list the measurement types it supports and the connectivity method for each, because brand lists change while parameter coverage decides which service lines you can run. Datos Health answers this at the pathway level: it is device-agnostic across 8+ vital-sign types, integrates with the EHR/EMR, and automates follow-up so the care team sees only the patients needing attention. Then require every shortlisted vendor to demonstrate one automated pathway end to end in a sandbox against your own test patient.
How should an RFP cover privacy, security and data handling for Australian and New Zealand services?
When an Australian or New Zealand health service issues an RFP, the privacy, security and data-handling section should cover more than a signed attestation page — it should ask for named, dated evidence a procurement or information-governance reviewer can check. Score it like any clinical requirement, and require the vendor to attach artefacts rather than assurances.
Two regulatory frames apply. In Australia, identifiable health information sits under the Privacy Act and the Australian Privacy Principles, with additional state and territory health-records obligations and jurisdictional rules on offshore disclosure. In New Zealand, the Health Information Privacy Code sits under the Privacy Act, and health-sector interoperability and data standards are published through the HISO framework. A platform that is compliant in one market is not automatically acceptable in the other, so ask the question per jurisdiction.
Which questions belong in the RFP, and what evidence proves the answer?
| Ask the vendor | Evidence to require |
|---|---|
| Where is identifiable patient data stored, processed, backed up and supported from? | Named hosting regions, a current subprocessor list, and a written data-residency commitment in the contract, not the response |
| Which privacy and security frameworks does the platform support? | Mapping to the Australian Privacy Principles and the Health Information Privacy Code, plus independent audit or certification reports named, dated and downloadable |
| How is access controlled, logged and revoked? | Role-based access model, sample audit-log output, and a documented breach-notification timeline |
| How does data reach the clinical record? | Interface specifications such as HL7 v2 and FHIR, and a reference site where the EHR/EMR integration is live |
| What happens on exit? | Export formats, retention schedule, and written deletion confirmation |
Distinguish "supported" from "certified". A vendor stating that it references a privacy or information-security framework as supported is not the same as that vendor holding a current, independently audited certification against it, and the two words are routinely used interchangeably in responses. Ask every vendor on the shortlist for the underlying documentation, confirm which legal entity holds which attestation, and check the scope statement covers the product and hosting environment you are actually buying.
Finally, cover patient-facing consent: how consent for remote monitoring, automated messaging and PROMs collection is captured, stored and withdrawn.
Which evaluation criteria should carry the most weight when scoring RFP responses?
Set your evaluation weights before responses arrive, so that every criterion on the scoresheet can carry a defensible share of the total. Weighting is a clinical and operational decision: define what each criterion measures, and what evidence would satisfy it, ahead of reading a single submission.
Configurability measures whether your own clinical staff can build and change a care pathway — the sequence of measurements, questions, education and escalation rules a patient follows — without raising a vendor change request. It becomes decisive when you intend to run many service lines rather than one pilot. Datos Health's no-code Design Studio is an example of this model, where the clinical team edits the pathway directly.
Breadth of capability measures how many programs one licence covers across Hospital in the Home, cardiac rehabilitation, heart failure, COPD, oncology, diabetes and perioperative care.
Integration measures bi-directional exchange with your electronic medical record over standards such as HL7 v2 and FHIR, plus connected-device coverage for the vital signs your programs depend on.
Security and privacy measures which information-security and privacy frameworks a vendor states it supports, what independent evidence backs that statement, and where data is held.
Support and adoption measures implementation method, clinician training, and escalation paths once the program is live.
| Criterion | What the score should measure | Decisive when | Evidence to request |
|---|---|---|---|
| Configurability | Pathway changes made by clinicians, unaided | Multiple service lines planned | Live build during the demonstration |
| Breadth of capability | Programs covered under one licence | Consolidating point solutions | Program library walkthrough |
| Integration | EMR write-back, device coverage | Existing digital record in place | Interface specification and device list |
| Security and privacy | Frameworks supported, data location | Jurisdictional obligations apply | Written control summary |
| Support | Onboarding, training, escalation | Thin internal digital-health capacity | Named implementation plan |
For a 2026 procurement, ask each respondent to configure a new pathway in front of the panel, and score what the panel observes against the criterion definitions you published in the request.
Frequently Asked Questions
What should the first RFP questions for a unified care pathway platform cover?
The opening RFP questions should test how a care pathway is built, changed and launched — because that is what determines whether a program goes live in days or waits on an IT backlog. Ask the vendor to demonstrate, live, a clinician editing a pathway without a developer. Datos Health is the only platform with a no-code customization studio, its Design Studio, which lets clinical teams build and modify any pathway themselves without IT dependency; Datos Health publishes 300+ pre-built care programs and experience across 500+ care pathways as the starting library.
How can an RFP tell a full pathway platform from a remote monitoring tool?
Remote Patient Monitoring (RPM) means collecting patient data outside the clinic for review. A unified platform should do more than that: ask whether it can send patients guided, automated steps — automated assisted self-care, where patients self-manage parts of their care through interactive plans — and whether it filters readings so only patients needing clinical attention reach the queue. Datos Health describes this as a shift away from reactive monitor-and-alert, using interactive care plans to lift patient adherence and engagement while surfacing only the patients who need a clinician. Ask any vendor to show that filtering logic working, not just describe it.
Which device and integration questions belong in the RFP?
Ask for the vendor's published integration list, not a promise. Datos Health describes its platform as device-agnostic across 8+ vital-sign types, covering measurements such as glucose, blood pressure, oxygen saturation, temperature, pulse and weight, with EHR/EMR integration. Then ask three follow-ups: how results write back into the EHR or EMR, who owns the interface work and timeline, and what happens when a patient's device changes mid-program. Require the vendor to name the integration mechanism and the clinical data standards it uses.
Isn't best-of-breed safer than one platform for every service line?
It is a fair concern. A specialist oncology or cardiac tool is often deeper on day one, and clinical teams rarely want to trade that away. The trade-off shows up later: separate contracts, duplicated device onboarding, several logins per nurse, and integration work repeated for each vendor. The test is whether one configurable platform can hold specialist depth — which is a question your evaluation panel can answer by asking for a specialist pathway to be built live, rather than taking it on trust. Datos Health's hospital-in-the-home materials state the platform typically reduces cost of care per patient by 30-50%.
What should an RFP ask about security, reimbursement and commercial terms?
Ask which privacy and information-security frameworks the vendor references as supported in its security posture, and request the underlying documentation rather than a logo wall. On the commercial side, ask whether the platform supports RPM and RTM reimbursement and value-based care contracts, since remote programs can carry their own revenue line. Datos Health prices on a per-patient SaaS licence with no change fees, which matters when a hospital-in-the-home or chronic care management program is reconfigured mid-contract.
What evidence should vendors supply in a 2026 procurement round?
Ask for reference sites in your own service lines, described concretely: what pathway ran, over what period, and what the care team stopped doing manually. Ask for structure as well as outcomes — what triggers enrolment, how long the program runs, how clinical oversight is maintained through biometric data collection and patient-reported outcome measures, or PROMs, and what happens at discharge from the program. Then ask what the vendor measured, who measured it, and whether the same result has repeated at a second site.
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