The problem both systems are trying to solve
A hospital information system is built around a registered patient with a hospital identifier, an episode of care and a bill. An enquiry has none of those. Somebody has called, messaged or filled a form asking whether you treat a condition, what it costs and when they could be seen, and they may never become a patient at all. Forcing that person into the patient master creates a registration record for someone who was never treated, which pollutes the patient index and inflates every count derived from it.
So hospitals add a customer relationship system, which is designed for exactly this: a contact who is not yet a customer, a pipeline of stages, follow-up tasks, and attribution back to the campaign or channel that produced them. That is a genuinely better fit for the pre-registration period, and the decision to use one is usually correct.
The failure comes immediately afterwards, at the handover. The enquiry converts, the person registers, and now there are two records of the same human being in two systems with no link between them. Everything painful about running both systems flows from that single unresolved point, and it is an architecture decision rather than a product choice.
Identity is the whole problem
The question that decides everything is what links the enquiry to the patient record when conversion happens. If nothing does, you get the standard outcome: marketing reports enquiries and conversions using its own numbers, operations reports registrations using its own, the two never reconcile, and nobody can say what a given campaign actually produced in treated patients or revenue.
The workable answer is that the enquiry record carries an identifier which is written onto the patient record at registration, so the linkage exists on the clinical side rather than being inferred later by matching names and phone numbers. Retrospective matching on demographics fails at exactly the rate you would expect in a country with common names, shared family phone numbers and inconsistent spelling — well enough to look plausible and badly enough to be wrong.
This has to be built into the registration workflow, not bolted on afterwards. When a converting enquiry arrives at the desk, registration should open pre-filled from the enquiry rather than starting blank, carrying the link automatically. If the clerk has to search another system and copy an identifier across, it will happen for a while and then stop, and you will be back to matching on names.
What the handover from enquiry to registration must do
- Pre-fill registration from the enquiry rather than starting from blank
- Write the enquiry identifier onto the patient record automatically
- Check the patient index first, so returning patients are not duplicated
- Carry the source and campaign attribution through to the episode
- Mark the enquiry converted, with the resulting patient identifier
The duplicate patient problem this creates
A poorly designed integration creates duplicates at scale, and duplicates in a patient index are expensive to live with and worse to fix. The mechanism is straightforward: an enquiry converts and creates a new patient record without checking whether that person already exists, so an existing patient who enquired about a different service arrives in the index a second time with a different identifier and half a history.
Any conversion path therefore has to search the existing patient index before it creates anything, and has to make it easy for the desk to attach the enquiry to a found record rather than defaulting to creation. That default matters more than the search quality. A clerk under pressure will take whichever path is fewer clicks, and if creating is faster than attaching, the index will fill with duplicates regardless of what the policy says.
Watch the duplicate rate as a metric of integration health rather than as a data quality problem to be cleaned periodically. A rising duplicate rate after a campaign tells you the conversion path is creating records it should be matching, which is a fixable workflow issue and is invisible if you only ever see the cleaned-up index.
“We ran a campaign that generated eleven hundred enquiries and, apparently, nine hundred new patients. About three hundred of them already existed in our system under a slightly different spelling. We spent longer merging records than we had spent running the campaign.”
Deciding whether you need a separate system at all
Not every hospital needs one. If enquiry volume is modest, comes through one or two channels, and is handled by the same front-desk team who register patients, a well-configured enquiry module inside the hospital system is usually the better answer. One system means one identity, no integration to maintain, and attribution that reconciles by construction. The functionality is thinner than a dedicated platform, and for many hospitals that is an acceptable trade.
A separate system earns its place when enquiry handling is a distinct operation with its own team, when volumes are high enough to need queueing and task management, when there are many channels to consolidate, or when campaign attribution and multi-touch follow-up genuinely matter to the business. In those conditions the specialised tooling does things a hospital module will not, and the integration cost is worth paying.
Be honest about which situation you are in rather than buying for the situation you hope to be in. Hospitals routinely acquire a platform sized for an operation they do not have, use a fraction of it, and take on an integration burden for capability they never use. The reverse error — running a serious acquisition operation out of a basic module and a spreadsheet — is less common but equally real.
What the integration has to carry in each direction
If you do run both, the integration is bidirectional and both directions matter. Outward, from the relationship system, goes the converting enquiry with enough demographic detail to pre-fill registration and the identifier that will link the two records. That direction is usually built and usually works.
The return direction is the one that gets skipped, and it is where the value is. Back from the hospital system should come the registration outcome, the appointment attended or not, the episode type, and ultimately whether the patient was treated and what that episode was worth. Without that return path the enquiry system knows only that someone converted to an appointment, so every conversion looks identical and no channel can be evaluated on what it actually produced.
Decide deliberately what is not shared. The relationship system does not need clinical detail, and putting it there widens the population who can see clinical information to a marketing and call-centre team, which is difficult to justify. Send the fact of an episode and its commercial characteristics; leave the clinical record where it belongs and where its access controls already exist.
Fields the return path should carry
- Whether registration occurred, and the resulting patient identifier
- Appointment booked, attended, cancelled or not attended
- Episode type and department, without clinical detail
- Episode value, for channel and specialty economics
- Date of first treated episode, to measure true conversion lag
Consent and communication rules that apply to enquirers
An enquirer is an identified individual whose personal data you are processing, and the fact that they contacted you does not licence indefinite marketing. Establish what you told them at the point of enquiry, what they agreed to, and how long you may retain their details if they never become a patient. Those answers belong in the system's configuration rather than in a policy document nobody consults.
Practically that means a notice at the point of capture in language people understand, a recorded basis for contacting them, an easy way to opt out that is honoured across every channel, and a retention rule that actually deletes unconverted enquiries after the stated period. The last one is almost never implemented, and hospitals accumulate large databases of people who asked a question years ago and have no relationship with them.
Separate marketing consent from care communication cleanly. Someone who opted out of campaigns must still receive appointment reminders and clinical communication once they are a patient, and the two must not be governed by the same flag. Collapsing them either spams people who opted out or silences necessary clinical messages, and both are worse than keeping two fields.
Getting the reporting to reconcile
The test of whether the architecture works is whether marketing's numbers and operations' numbers agree. They should be derivable from the same underlying records: enquiries by source, conversions to registration, attended appointments, treated episodes and value. If the two teams present different figures for the same period, the integration is not carrying enough or the identity link is failing, and no amount of reconciliation meetings will fix it at the reporting layer.
Report the whole funnel in one view rather than each team reporting its own stage. A hospital that can see enquiries by channel flowing through to treated episodes and revenue by specialty can make real decisions about where to spend. A hospital where marketing reports cost per lead and finance reports revenue by department has two numbers that never meet.
Expect the reconciliation to be uncomfortable the first time. It usually reveals that reported conversion is substantially lower than believed, because it had been measured to appointment booked rather than to treated episode. That is a better number to know than not to know, and it is generally where the most valuable operational improvements are hiding.
