Organizing patient consent in practice: What the latest Mitz Webinar made clear
From policy topic to implementation question
In conversations about Mitz, patient consent is often approached as a legal or policy issue first.
That makes sense. Consent is tied directly to regulation, governance, and patient control.
But what became very clear during our recent webinar with VZVZ and Amsterdam UMC is that Mitz is also a very practical technical and organizational issue. For healthcare organizations, the real question is not only what Mitz is meant to solve, but how to implement it in a way that works within existing systems, workflows, and responsibilities.
That was the focus of the session: understanding the shift in the Dutch consent landscape, looking at what implementation actually requires, and hearing what this looks like in practice from an early hospital implementation.
What the webinar showed about Mitz
Judith Opraus from VZVZ walked through the role of Mitz as the national consent service for the exchange of medical data between healthcare providers.
One important point from that discussion is that Mitz changes where consent is managed. Instead of each healthcare provider maintaining separate local consent registrations for every exchange, Mitz creates a shared national facility where patients can manage their choices centrally.
That matters for two reasons.
First, it gives patients more direct control and transparency. They can manage their consent choices online, adjust them when needed, and gain better insight into who holds their data and who may access it.
Second, it changes what healthcare organizations need to manage locally. Consent no longer needs to be handled as a fragmented set of registrations tied to every separate exchange. That reduces administrative burden, but only if implementation is approached correctly.
The misconception that still creates friction
A recurring theme in the session was that organizations often assume Mitz needs to be added as a separate layer on top of the existing landscape.That is where complexity starts.
When consent is treated as something external to the actual exchange process, teams end up creating extra checks, parallel logic, or additional operational steps. That increases the burden on technical teams and makes it harder to keep workflows stable.
What I tried to make clear during the webinar is that the technical impact is often smaller than teams expect, provided consent is integrated in the right place.The question is not whether Mitz can connect to your environment. The more important question is where consent should live in the architecture.
What this means at the XDS layer
In many environments today, consent for XDS exchange is enforced through local BPPC documents. Those documents act as copies of the consent registration from the EPD and are used by the XDS environment to decide whether access should be allowed.
That model works, but it also means that multiple systems are effectively maintaining their own version of consent.
Mitz changes that model.
With the Founda Mitz Connector, the consent decision can be checked centrally and in real time during the exchange itself. That means the XDS layer no longer has to rely on local copies that may become out of sync over time.
This was one of the most practical points in the session. The implementation is not about rebuilding the infrastructure. It is about configuring the exchange layer so that consent is checked at the right moment, against the right source.
That creates a more consistent model for consent enforcement, while keeping the existing exchange workflows intact.
Why the Amsterdam UMC perspective mattered
One of the strongest parts of the webinar was hearing from Jasper van Dijk at Amsterdam UMC.
He shared the path from the early exploration phase in 2022 through to the practical decisions needed to support Mitz in an Epic and XDS environment. What stood out in that story was not only the technical work involved, but the importance of coordination between hospital, vendor, and infrastructure parties.
Their experience showed that implementation is not a single decision or a single connector. It requires a clear view of where consent is registered, when it is checked, and which systems need to align to make that possible in practice.
It also showed something encouraging. What started as a complex and exploratory setup has matured significantly. Early implementation work is now helping create a more repeatable path for other organizations preparing for Mitz.
That makes this moment important. Healthcare organizations no longer have to approach Mitz as a purely theoretical future requirement. There are now concrete implementation lessons to work from.
The larger takeaway from the session
If I had to reduce the webinar to one central point, it would be this:
Consent should not behave like a separate system.
It should be part of the way data exchange already works.
That matters for compliance, but it also matters for usability and operational stability. If consent checks fit naturally into the architecture, clinicians do not need additional steps, administrators do not need extra workarounds, and technical teams do not need to maintain unnecessary duplication.
That is the difference between implementing Mitz as an obligation and implementing it as part of a stronger interoperability design.
What comes next on the Founda platform
At the end of the webinar, we also shared several innovations on the Founda platform that continue this same principle: reducing operational friction by embedding functionality into existing workflows.
These included:
- Auto Reconcile, for automatically archiving external studies in the local PACS in the correct order and with the right metadata
- Image Prefetch, for retrieving relevant historical studies before a consultation starts
- Cardiology integration (PACS2), for enabling cardiology image exchange through XDS in the same way radiology is already handled
- Founda Patient Facing Portal, for allowing patients to view medical images directly in Epic MyChart without separate portals or manual requests
What connects these developments is the same architectural idea discussed throughout the Mitz session. The goal is not to add more layers. It is to make data access, exchange, and use feel more natural within the systems teams already rely on.
The next webinar: Improving Image Retrieval Workflows via XDS
That brings us to the next topic.
On May 28 at 10:00, we will host a new webinar focused on a closely related operational challenge: how healthcare organizations can move away from manual, time-consuming image retrieval through the XDS network.
In this session, we walk through the image retrieval workflow step by step, where bottlenecks occur, what they cost in staff time, and how two Founda capabilities: Auto Reconcile and Image Prefetch, can automate these workflows end-to-end. Whether you are exploring one capability or both, this session will help you understand the value, see live demos, and decide where to start.
This webinar is particularly relevant for imaging decision-makers, radiology team leads, PACS administrators, and IT teams that are still spending significant time on manual retrieval and workarounds each month.
The session will be held in Dutch.
May 28, 2026 | 10:00 Register here
Author
Dimitri Braakman
Dimitri is a product leader with 15+ years of experience building platform strategies across healthcare data interoperability, cloud-native SaaS, and AI. He has scaled API ecosystems from zero to thousands of developers at companies including Exact and Philips, before joining Founda Health to lead interoperability product strategy for hospital networks. His technical depth spans FHIR, HL7v2, IHE, and DICOM, and he has shipped AI products into production including a data transformation engine. He is currently contributing to the European Health Data Space initiative and shaping Founda's AI Hub strategy for medical imaging.
