In our previous article, we argued that digital patient experience isn’t a set of channels but the ability of a health system to behave as one coherent system from the patient’s point of view. If you accept that, the comfortable part is over. Naming the experience layer is easy. Where the real work begins is in building, owning, and, finally, measuring it against the systems and vendors that already run your hospital. 

This article is about that work: the architecture and the metrics that turn coherence from a slogan into something an enterprise architect can design and a CIO can govern. We’ll spend less time on Fast Health Interoperability Resources (FHIR) than you might expect, and more on the parts that decide whether any of this survives contact with your org chart. Most experience-layer efforts fail because no one owns the journey, while the metrics still reward local system performance. As a result, the first hard architecture decision gets quietly overruled by whoever owns the biggest system.  

Read on to learn about our three-point solution to break out of this deadlock. 

Executive summary

Building a patient experience layer is an architecture and governance problem before it’s a technology one. The hard parts are deciding who owns the end-to-end journey, making integration carry context rather than just data, and replacing system-level metrics with journey-level ones. 

  • Treat the experience layer as a permanent architectural tier above your systems, not a project that ships once and ends. 
  • Integration has to move meaning and journey state, not only records. This is where most FHIR-only efforts stall. 
  • The politics are the point: a journey-first layer redistributes control away from system and vendor owners, so the CIO’s real job is brokering that shift. 

Start with a layer, not a project

The first mistake is treating the transformation as an integration project with an end date. A point integration solves one handoff and then rots, and every new system you add multiplies the number of brittle connections you maintain. An experience layer is different in kind: it’s a permanent tier that owns the patient journey across all your systems, and it outlives any single tool underneath it. 

Concretely, the layer holds the control logic. It decides the sequence a patient moves through and constantly tracks where they are to determine the next step, while the separate systems it connects become capabilities to orchestrate rather than destinations the patient is dumped into. Underneath it sits the FHIR-based integration layer from the first article.  

To summarize: transport and data shape are FHIR and ISiK. The experience logic lives one level up. 

In engineering terms, that layer is an orchestration tie; not just a database and definitely not a screen. The layer fulfills several functions:  

  • It keeps journey state, meaning where each patient sits in each pathway, in its own store.
  • It exposes a small set of journey APIs that the front-end channels call.
  • It drives the underlying systems through the integration layer.

Diagram comparing Disconnected systems and a nutzerzentrierte Softwareschicht (Coherent experience layer): On the left, scattered arrows connect Portal, Booking, and HIS. On the right, all connect to a central nutzerzentrierte Softwareschicht + Journey orchestration box.

Capabilities to watch out for

Two capabilities decide whether it works or not:  

The first is a shared patient identity that resolves the same person across every system. This is typically an enterprise master patient index, because without it you cannot follow one patient across touchpoints.  

 The second is a way to embed the layer’s logic inside clinical tools rather than bolting it on beside them. This is what standards like SMART on FHIR and CDS Hooks exist to do, so clinicians get guidance in the system they already use instead of yet another separate screen. 

Crucially, this is buildable on top of what you already run. For example, at Frankfurt University Hospital, Fraunhofer’s OneViewMed project put a single coherent view on top of several separate hospital information systems using an FHIR repository, without replacing any of them. That’s what we’re trying to accomplish: a layer above the stack, not a rip-and-replace of it. 

Integration means context flow, not system connection

The word integration is where most of these efforts quietly go wrong. Connecting two systems moves records between them, and that’s not enough for us. Coherence needs to move context. In other words, the layer has to carry identity, journey state, what already happened, and what comes next, so that each touchpoint knows more than what’s in its own database. 

Picture intake. A connected system can look up that a patient exists in the booking database. A coherent layer knows that a patient:  

  • booked a specific procedure.  
  • already submitted their history last Tuesday.  
  • is now at the step where pre-admission checks happen.  

As a result, it can skip the re-entry and point them straight at what’s next.  

Simply put, a connected system answers whether a record exists. A coherent layer answers where the patient is in their journey and what should happen next. 

Why standards aren’t enough

This is also why FHIR alone doesn’t get you there. FHIR standardizes how data is structured and exchanged, which is necessary, but it doesn’t carry journey state or orchestrate anything. Hence, standardization efforts like ISiK have so far produced only limited real interoperability. The semantics and sequencing have to be owned above the transport layer, by the experience layer itself. 

Practically, you adopt this incrementally. The strangler-fig pattern fits well here: route one journey at a time through the experience layer while leaving the underlying systems in place, and expand as each journey proves out. That’s not just engineering caution. Core system lock-in is real, and some vendors actively resist opening their systems, so you design around the legacy estate rather than betting the program on replacing it. 

The operating model: someone has to own the journey

A layer with no owner becomes another silo within a year. The experience ownership gap we described in the previous article is closed by one specific thing: a role or a team accountable for a patient journey from end to end, sitting above the owners of the individual systems that journey passes through. 

In practice, that means organizing teams around journeys instead of systems. Today you probably have a hospital information system (HIS) owner and an appointment-system owner, each optimizing their own box. The shift is to a team that owns admission or aftercare as a whole, and treats the systems as components it composes. That team sets the standards a new system has to meet before it’s allowed to join the layer, which quietly turns procurement into an experience decision. In other words, the key buying question is no longer about the product’s features. Instead, it’s whether it fits the journey logic. 

None of this holds without budget attached to journeys, not only to systems. If every euro is allocated per system, every incentive pulls back toward local optimization, and the layer starves. Funding a journey the way you’d fund a product is what keeps an owner genuinely accountable for the experience rather than for uptime. 

A flowchart shows the Admission journey owner at the top, leading to a nutzerzentrierte Softwareschicht (user-centric software layer) in the Experience layer, which then branches out to HIS owner, Booking owner, RIS owner, and Ward owner at the bottom.

Thinking in layers forces a category of decision that a pile of separate systems lets you dodge: consent and access. The moment one tier aggregates a patient’s context across multiple systems, purpose limitation and access control stop being a checkbox on each stop and become properties of the layer itself.  

  • Which staff role sees which slice of a journey?  
  • What a patient consented to and when?  
  • How a withdrawal of consent propagates back across systems?  

These are now design questions, not policy footnotes. 

Under GDPR this isn’t optional, and retrofitting it is expensive. You need to build consent state and role-based access into the experience layer from the first journey, the same way you build in identity. A coherent view of the patient is also a concentrated one, and that concentration is exactly what the regulation exists to enforce. 

Metrics move from system to journey

You can’t govern a journey with system metrics. For instance, per-system uptime, login counts, and feature usage can all be green while the patient’s actual path is broken. Each of those measures a box, not the flow between boxes. If your dashboards only show systems, you are structurally blind to the thing you’re trying to fix. 

Journey-level metrics measure the handoffs, rather than the nodes. Here’s a workable starter set: 

  • How often a patient re-enters information the organization already holds. 
  • Drop-off or abandonment between two touchpoints, for example, booked but never completed pre-admission. 
  • Time to a clear next step after each contact, and how often the patient is left to work it out alone. 
  • Share of journeys completed without staff having to manually bridge a gap between systems. 

You shouldn’t think of those as soft experience scores because each maps directly to operating cost. Every manual bridge is staff time you can’t spare when two-thirds of hospitals can’t fill their nursing posts, and every point of friction hurts more as the ambulatory shift compresses pathways into high-turnover day cases with no slack. Journey metrics are how you connect coherence to the balance sheet. 

The architecture decisions become political

Here’s the part the reference architectures leave out: a journey-first layer redistributes authority. It places a cross-cutting owner above powerful system and department heads, and it constrains the vendors whose products it orchestrates. That makes several of your architecture decisions political long before they’re technical, and pretending otherwise is how good designs die in committee. 

The sharpest version is lock-in. Some core system vendors decline to open their systems to competitors and sidestep interfaces they are legally required to support, so if you let the experience layer live inside a vendor’s product, you have simply moved the monopoly up a level. The strategic stance is that the experience layer is yours: built on open standards and independent of any single system underneath. You can buy the systems, but you need to own the coherence. 

That reframes the CIO’s role in a way that’s worth stating plainly. Your job is no longer to pick the best systems and connect them. It’s to broker a journey the patient never sees the seams of, across departments and vendors whose incentives mostly run the other way. The architecture is the straightforward part. Getting each of those parties to cede a little control to a journey that neither of them will owns completely is the real work. 

A pragmatic first move

Don’t try to model every journey at once. Pick one high-friction, high-volume pathway and set up the experience layer for just that. Make sure it’s instrumented with journey metrics from day one. Elective day surgery is often the right first target: the pathway is compressed, while friction is both visible and expensive. 

Doing one journey well gives you three things the big fights will need later:  

  • a working reference implementation,  
  • a governance precedent for how systems join the layer,  
  • a metrics baseline that shows the operational payoff in numbers.  

Coherence proven on one pathway is a far stronger argument than coherence promised across all of them. 

How Cloudflight can help

Cloudflight builds custom software for precisely this: an experience layer shaped around a specific patient journey, sitting on a FHIR-based integration layer over your existing systems, designed so you own the coherence rather than renting it from a product vendor. Because we’re digital engineers rather than a single-product vendor, we can start with one journey, prove the model, and help you define the ownership and the journey metrics that make it stick. 

The engineering is the part we’re comfortable with. Where we work together with you is in getting the combination of architecture, operating model, and measurements right. 

Where this leaves you

So, what does an architect or CIO actually do on Monday? Here are your four moves, none of which require a platform decision yet: 

  • Pick one high-friction journey to be your reference implementation. 
  • Name a single owner accountable for that journey end to end, above the system owners. 
  • Define three or four journey metrics and start measuring them, even crudely. 
  • Set the rule that any new system has to join the experience layer on the layer’s terms, not its own. 

The layer, the ownership, and the metrics reinforce each other, and none of them works alone. Get one journey right, and you’ve built the argument and the blueprint for every one that follows.