Patients now expect a portal to do two things well: show them their lab results and let them see and manage appointments. Both sound simple from the outside, and both are deceptively involved underneath, because the data lives in clinical systems that were never designed with a patient-facing app in mind. Getting results and appointment data from the EHR and lab systems into a portal, reliably, matched to the correct patient, and shown at the right time, is an integration problem. This guide is about solving it with Mirth Connect.
We have built patient-facing health products for startups and health systems, EHR integrations for 30+ of them, and the routing patterns below are what make a portal feel trustworthy rather than flaky.
The two data stories a portal tells
Strip a patient portal down, and it is mostly two streams. The first is results and reports: lab values, imaging reports, and clinical documents that arrive from the EHR or a lab system, typically as HL7 v2 ORU result messages and MDM document messages, and map to FHIR resources like DiagnosticReport and DocumentReference. The second is appointments: upcoming and past visits the patient should be able to see and sometimes manage, which flow as HL7 v2 SIU scheduling messages and map to the FHIR Appointment resource. Underpinning both is patient demographic data, arriving as ADT, that ensures every result and appointment lands on the right person's record.
If these message types are unfamiliar, our guide to HL7 explains them, and the FHIR R4 specification documents the resources. The important point is that a portal is not one feed; it is several, and they need to be coordinated.
Why route portal data through Mirth Connect
It is tempting to wire the portal straight to each source system. That falls apart quickly, because a portal needs more than raw data; it needs data that is filtered, formatted, gated, and matched. Mirth Connect gives you one place to do all of that.
- One channel, many sources. Results from the lab, appointments from scheduling, and demographics from the EHR all flow through channels you control, instead of a separate fragile link per source.
- Transformation to the portal's shape. Portals expose their own API or data model. Mirth maps HL7 and FHIR data into exactly what the portal expects.
- Release rules and gating. Not every result should appear the instant it posts. Mirth is where you apply your organization's release logic before anything reaches the patient.
- Patient matching and de-duplication. The engine ensures a result attaches to the right patient and is not shown twice, which is exactly the kind of error that erodes trust in a portal.
If Mirth is new to you, our complete guide to Mirth Connect and the architecture and deployment guide are the place to start, and the same engine connects to any EHR behind the portal, as our Cerner integration guide shows.
Results and appointments, side by side
The two streams have different shapes and different rules. Results arrive as ORU and MDM messages, become DiagnosticReport and DocumentReference, and carry sensitivity: timing and gating matter, and you must de-duplicate and match the patient carefully.
Appointments arrive as SIU messages, become Appointment resources, and are more about keeping status in sync, including two-way updates when a patient cancels or reschedules. Mirth handles both, mapping and gating results, syncing and routing appointments. The lab side in particular shares a lot with general lab integration, which we cover in depth in our lab and LIS integration guide.
The architecture
The pattern is a set of Mirth channels between your clinical systems and the portal. A source connector receives an ORU result, an SIU appointment, or an ADT demographic update. A filter decides whether it is portal-relevant. A transformer applies release rules, maps codes and fields to the portal's format, and confirms the patient match. A destination connector posts to the portal, and often a second destination fires a notification, an email or push alert telling the patient something new is available, while a third writes an audit record of what was released and when.
That fan-out from a single inbound message to portal, notification, and audit is exactly what Mirth is good at, and doing it in one channel keeps the logic in one place. Our HL7 v2 to FHIR R4 mapping guide covers the field-level work, and consistent channel design patterns keep multiple portal feeds organized.
Result release: the rule that catches teams off guard
The trickiest part of portal results is not technical; it is policy made technical. Under the 21st Century Cures Act information-blocking rules, patients are generally entitled to their results promptly, and most organizations now release the majority of results to the portal automatically. At the same time, organizations may apply specific, lawful handling for certain categories, and they need an auditable record of what was shown and when.
Mirth is the natural place to encode this: the transformer is where a result is checked against your release policy before it reaches the patient, and the audit destination is where you prove what happened. Getting this layer right is what keeps a portal both compliant and humane. The current rules are summarized at healthit.gov.
Reliability, matching, and idempotency
Three failure modes hurt portals specifically, and all three are solvable in the engine. The first is patient mismatching, attaching a result to the wrong person, which is a safety issue; robust matching logic in the transformer, keyed on reliable identifiers, prevents it.
The second is duplication, showing the same result twice because a message was resent; idempotency checks, tracking what has already been posted, prevent it. The third is silent loss, a result that never makes it to the portal; every channel needs a dead-letter and replay path so a failed message is caught and reprocessed rather than vanishing, which our guide to message replay and dead letter queues covers. Get these three right, and the portal earns the patient's trust; get them wrong and one bad experience undoes a lot of good ones.
Notifications and the patient experience
A portal that holds new results but never tells the patient is only half a product. The notification layer is what turns a passive repository into something people actually use, and Mirth is well placed to drive it. When a result is released or an appointment changes, a channel can fire an email or push notification in the same flow that posts the data, so the alert and the content stay consistent.
The detail that matters is restraint: batch low-urgency updates, avoid alerting on every minor change, and never put clinical detail in the notification itself, since a message preview on a lock screen is not a private channel. Done thoughtfully, notifications increase portal engagement without overwhelming or alarming patients.
The same channel logic also supports preferences. A patient who wants email but not push, or who wants a daily digest rather than instant alerts, can be honored in the transformer before the notification destination fires. Treating notification preferences as part of the integration, rather than something the portal bolts on separately, keeps the experience coherent and reduces the support burden of patients confused about why they did or did not hear about a result.
A realistic rollout
Bringing portal feeds online works best in stages. Start with appointments, because they are lower-risk than results and immediately useful: patients seeing their upcoming visits builds confidence in the portal with little clinical sensitivity. Add demographics syncing so patient matching is solid before any results flow.
Then introduce results, beginning with a category your release policy handles cleanly, and run it in parallel with existing processes while you confirm that matching, de-duplication, and release timing all behave. Only then, widen to the full set of result types.
Throughout, lean on monitoring. Track how many messages flow to the portal, how many are gated by release rules, and how many fail and get replayed, so you can see the system working rather than hoping it is. This phased approach means a patient never encounters a half-built portal, and your team never faces a single high-stakes launch where results, matching, and notifications all go live at once.
Security and Patient Access
Portal data is Protected Health Information, so a Business Associate Agreement is required, and patient-facing access adds its own authentication concerns: patients authenticate to the portal, and any FHIR-based patient access uses SMART on FHIR scopes so a patient sees only their own data. We sign BAAs with US health systems and digital health customers, and we build on HIPAA-compliant, SOC 2 Type II, and ISO 27001 certified infrastructure with FHIR R4 native architecture.
This content describes engineering patterns. It does not include actual Protected Health Information. All data examples are synthetic.
How Nirmitee.io approaches patient portal work
Healthcare is the only industry we serve, and patient-facing products are a core part of it. We built AffEx Health with a patient dashboard and consultation flow, and PainPal, a chronic-pain mobile app with Apple Health integration, shipped as a HIPAA-compliant build for a startup with no tech team.
Our architecture is FHIR R4 native, which makes mapping results and appointments to portal-ready resources straightforward. The pattern we see work is always the same: one engine in front of the clinical systems, careful patient matching and release logic, and an audit trail you can stand behind.
If you are connecting an EHR to a patient portal and want results and appointments to flow reliably, or want the integration built, share your use case at nirmitee.io and we will tell you what we have shipped for similar products.
