Every hospital we work with already runs an EMR. The question is never whether to integrate. It is which seam to use, and what that choice costs you three years later.
The hardest part of a PROMs programme is rarely the assessment itself. It is that the hospital already has an EMR, the clinicians already live in it, and nothing you add gets used if it means a second login.
So the real design question is where to cut the seam. In a hospital there are usually four candidates, and they are not equivalent.
HL7 v2 is what almost every EMR already speaks. The ADT feed is often the cleanest enrolment trigger you will find, because admission, transfer and discharge are events the hospital already publishes reliably. It is terse, weakly typed, and every site has its own local dialect. It is also still going to be there in ten years.
FHIR R4 gives you resources that mean what they say. A Patient, an Appointment, an EpisodeOfCare, carried in a single transaction bundle. It is the right answer when the EMR exposes a modern API and you want enrolment to carry clinical context rather than just a name and a date. It is also what makes writing results back into the clinician’s workflow straightforward.
CSV over SFTP is the option people are embarrassed to propose and the one that gets a pilot live in a fortnight. It is a legitimate starting point as long as everyone agrees that is what it is.
REST against a vendor API is the cleanest when the EMR team can build to you. In a large hospital that usually means a queue measured in quarters.
We tend to start at the lowest friction option that still carries enough clinical context to be useful, then design the enrolment so the transport can be swapped later without touching the pathway. Getting results back in front of the clinician matters more than how the patient was enrolled. The patient should never be able to tell which one you picked.