The First Question in a Patient-Education RFP Should Be: What Are We Missing?

A health-system patient-education RFP can become a spreadsheet of features before the organization has agreed on the problem.

Does the platform integrate with the EHR? Does it send messages? Does it include a content library? Does it monitor symptoms? Does it support video? Can it personalize a care plan? Does it escalate to staff?

Those are legitimate questions. They do not all describe the same job.

A health system may already have an EHR, portal, discharge workflow, content library, contact center, care-management platform, and text-messaging vendor. The unmet need may not be another system for prescribing information or prompting the next task.

It may be a private place where patients can ask the question that surfaces after the encounter—the question the existing pathway did not anticipate.

That leads to a better first RFP question:

What does our current patient-education and engagement stack still fail to let the patient do?

Begin by separating four different jobs

The patient-education market combines products with very different operating models. Comparing them in one undifferentiated feature matrix produces false equivalence.

Established platforms often span more than one category. Mytonomy combines patient-education content, communications, analytics, and EHR integration. Get Well emphasizes personalized care plans, proactive communication, navigation, monitoring, and adherence. CipherHealth focuses on structured post-discharge outreach, EHR integration, risk identification, and staff escalation. Mytonomy Get Well transitions of care CipherHealth post-discharge follow-up

Those capabilities can be valuable. They are also broader and operationally different from a governed conversational education layer.

HealthConvos is intentionally bounded. It does not replace the EHR, portal, remote patient monitoring, triage, care coordination, or clinical follow-up. It lets patients ask questions in their own words, routes those questions to previously reviewed responses, and shows the organization aggregate patterns in what patients tried to understand.

The RFP should make that distinction visible before feature scoring begins.

RFP section 1: Define the patient moment

“Improve patient engagement” is too broad to procure against.

Name one transition:

• A new diagnosis
• Hospital discharge
• Medication initiation
• Preparation for a procedure
• Recovery after an ambulatory encounter
• A missed or delayed follow-up
• Ongoing management of a chronic condition

Then describe the specific failure in that moment.

Is the patient unable to find the approved information? Are instructions available but difficult to apply? Are practical or emotional concerns emerging later? Is the care team receiving repetitive calls? Are patients avoiding questions because the available channel feels attributable? Does the organization know which parts of the education are incomplete?

The narrower the transition, the more meaningful the vendor comparison becomes.

Questions to include

1. Which patient population and care moment will the initial deployment support?
2. What must the patient understand or do next?
3. What education already exists?
4. Where does uncertainty currently appear—calls, portal messages, missed follow-up, complaints, qualitative interviews, or another source?
5. Which functions require a human care-team response?
6. Which outcomes can the pilot responsibly measure?

RFP section 2: Decide who begins the interaction

Most education systems begin with an organizational decision: send this video, assign this care plan, show this diagnosis-specific resource, or ask this structured follow-up question.

A patient-question system begins differently. The patient chooses the starting point.

Neither model is universally better. They solve different problems.

Prescribed education is effective when the organization knows what every patient in a defined situation needs to receive. Patient-led exploration is useful when the important concern may differ from the expected sequence.

The RFP should ask:

• Can patients use natural language, or must they navigate predetermined choices?
• Does the system accommodate questions outside the expected sequence?
• Does it distinguish the patient’s information need from the emotional character of the question?
• Can the experience preserve disease-specific differences rather than impose one universal journey?
• What happens when the platform does not have an appropriate response?

HealthConvos production behavior provides early, directional evidence for this distinction. Observed questions include diagnosis, disclosure, symptoms, family, prognosis, diet, logistics, and explicit emotional-information needs. The mix varies materially by disease. Emotional texture—such as frustration, anger, overwhelm, fear, hope, or grief—can surround any of those intents and should not replace them as the content taxonomy.

These observations are useful for generating hypotheses and finding content gaps. They are not stable population benchmarks.

RFP section 3: Make response governance inspectable

“Uses approved content” is not specific enough.

Ask vendors to demonstrate the patient-facing output model:

• Does the platform display an existing approved asset or generate new wording?
• Can reviewers inspect every script, visual, video, transcript, caption, link, and boundary response before launch?
• Is a response fixed after approval?
• What change-control process applies when a new patient need appears?
• How does the platform prevent medical advice outside its educational role?
• Can the organization verify which response library was live during the pilot?

In HealthConvos, AI identifies intent and selects from a finite response library. A new need becomes a new reviewed addition. The model does not quietly rewrite an approved answer.

That approach may be particularly relevant where clinical, brand, medical, legal, regulatory, or accessibility review must occur before publication.

RFP section 4: Treat multilingual support as a governance model, not a language count

“Multilingual” can describe several different capabilities: translated interface labels, multilingual question understanding, live machine translation, translated text, dubbed audio, captions, transcripts, or a complete patient experience reviewed in each language.

An RFP should separate them. A platform that recognizes a question in one language but answers in another does not provide the same experience as one that lets the patient ask naturally and receive a culturally appropriate, previously reviewed response in the same language.

The governance question is especially important. A response approved in English does not automatically make every translation, voice track, caption, or culturally adapted variation approved. If the platform translates at runtime, reviewers may be evaluating a process rather than the exact words the patient will receive.

Ask vendors:

• Which languages are supported across the interface, patient input, response content, audio, captions, transcripts, and linked next steps?
• Can patients ask naturally and receive a response in the same language?
• Is each language-specific script and media asset available for review before launch?
• Does translation happen before approval or dynamically at runtime?
• Who validates clinical terminology, health literacy, cultural meaning, and regional language differences?
• What fallback appears when the platform cannot confidently understand or answer in the selected language?
• Can aggregate intent be compared across languages without assuming that concepts map perfectly from one language to another?

The HealthConvos governed-content model supports a language-specific response library: each translated or culturally adapted script, voice, video, transcript, and caption track can be treated as its own inspectable asset. The patient’s question remains open, while the response in each supported language remains finite and reviewed.

RFP section 5: Evaluate access friction separately from personalization

A highly personalized experience may require identity, enrollment, EHR context, or an app. Those requirements can be appropriate when the platform performs care management, monitoring, scheduling, or clinical escalation.

They can also create unnecessary friction when the job is simply to let a patient explore approved education.

Include explicit access questions:

• Is an account required?
• Must the patient provide a name, email address, diagnosis, medical-record number, or other identifier?
• Is an app download required?
• Can the experience begin from a QR code, direct link, email, SMS, or embed?
• Does the URL or referral path reveal a condition or treatment interest?
• What happens if the patient arrives from a site using advertising or behavioral tracking?
• Can a low-data deployment operate without EHR integration?

HealthConvos can be deployed through QR codes and privacy-preserving links without requiring a patient account. That makes a focused pilot possible without first building an identity and integration layer that the educational use case may not need.

RFP section 6: Ask for a complete data-flow explanation

A privacy policy is not a data-flow diagram.

The evaluation team should request a technical account of every step between the patient opening the experience and the organization receiving a report.

At minimum, require vendors to disclose:

• Identifiers collected or inferred
• Cookies, local storage, device identifiers, and session identifiers
• URL parameters and referrer information
• Third-party scripts, pixels, analytics, and session-replay tools
• Raw message storage and retention
• Application, infrastructure, security, and support logs
• AI subprocessors and model-training restrictions
• Whether individual conversation histories or marketing profiles are created
• How aggregate reporting is produced
• Whether a patient can be reconnected to a specific question

HHS notes that tracking technologies can transmit identifiers and health-related context to third parties, including from authenticated and certain unauthenticated healthcare pages. A cookie banner alone does not create a HIPAA authorization. HHS guidance on online tracking technologies

HealthConvos screens and processes patient wording transiently and retains non-identifying intent for aggregate reporting. It does not require a patient account or build patient marketing profiles. Each deployment still requires technical verification and appropriate legal, privacy, security, and organizational review.

RFP section 7: Define what the organization wants to learn

Traditional analytics frequently measure exposure: sends, opens, page views, video starts, completion, or clicks.

A patient-question layer can answer a different question:

What did patients try to understand that the organization’s prescribed education did not make easy to find?

The RFP should distinguish:

• Content usage from patient intent
• Intent from emotional texture
• Aggregate learning from individual profiling
• An unanswered question from a clinical escalation
• A directional early pattern from a stable benchmark
• A content gap from an outcome claim

The most useful report may show that recurring questions are concentrating around disclosure, family, prognosis, diet, logistics, or another disease-specific need. That can guide qualitative investigation and the next governed content asset.

It should not be presented as conventional marketing attribution or as a statistically stable estimate of the entire patient population.

RFP section 8: Require honest boundaries

A credible vendor should be able to state what the platform does not do.

For a governed patient-education layer, the RFP should distinguish it from:

• Diagnosis
• Treatment recommendation
• Emergency response
• Symptom monitoring
• Clinical triage
• Care coordination
• Pharmacovigilance workflow
• The medical record
• Patient-specific outcome attribution

HealthConvos can help patients understand reviewed information, find an appropriate next step, and reveal aggregate content demand. It cannot claim that education alone prevents readmissions, improves adherence, raises a quality score, or produces financial savings without an appropriately designed evaluation.

That boundary protects the patient and makes the pilot easier to evaluate.

A practical evaluation matrix

Score each criterion only after the health system assigns its importance for the selected transition.

Start with one transition, not an enterprise promise

A useful first deployment is bounded enough to govern and important enough to teach the organization something.

Choose a population where:

• Questions predictably surface after the encounter
• Existing reviewed content can seed the first response library
• The next appropriate action is clear
• The clinical boundary can be stated plainly
• Privacy requirements can be tested end to end
• The sponsoring team has authority to add new governed content
• Success can be evaluated without claiming that education caused every downstream result

The goal of the first pilot is not to prove that one platform can become the entire digital front door.

It is to determine whether giving patients a private, governed way to ask questions reveals information needs the current system cannot see.

That is a smaller procurement claim—and a more consequential patient question.

Frequently asked questions

Is a patient-question platform a replacement for a portal or care-management system?

No. A patient-question layer can complement portals, EHRs, content libraries, outreach tools, and care pathways. Systems responsible for clinical monitoring, individual follow-up, documentation, or escalation require capabilities and workflows beyond education.

Does the first pilot require EHR integration?

Not necessarily. A no-account educational experience can often begin through a QR code, link, email, SMS, or embed. Integration requirements should follow the job the pilot must perform rather than be assumed in advance.

Should a health system require generative AI?

The RFP should specify the desired patient experience and governance outcome, then ask vendors to disclose whether patient-facing wording is generated or previously reviewed. “AI” alone is not a sufficient requirement.

What should the health system measure?

Measure reach, use, question intent, unmet content demand, governed response coverage, appropriate next-step engagement, and operational fit. Clinical, utilization, financial, or patient-experience outcome claims require a suitable evaluation design and relevant controls.