Consent in an emergency: how patient data access works.

Why this matters.

In modern query-based health information exchanges it is often required that a patient has given explicit permission (consent) prior to his/her information being accessed by, or shared with other care professionals. The basis for this are opt-in consent policies/governance that are enforced by local regulations and/or national laws.

In real-world emergency situations that require accessing patient data from other providers, this often poses a challenge. When those other providers don’t have the patient’s consent to release information, no information is available to doctors during the emergency. This can delay treatment, or introduce risks that harm the patient.

Two approaches are often considered to solve this. Both aim to find a balance between protecting a patient’s privacy and the need to access critical information (blood type, allergies, etc.) in situations where time matters.

Emergency policy.

A policy that allows bypassing normal access controls typically defines the conditions or constraints that must be met before it can be activated. Those conditions identify who is allowed access, for which reasons (why), to what data. For example, an emergency doctor (who) may access a patient’s medical summary (what data) if the patient is brought into the emergency department (why).

(Temporary) Emergency consent.

An emergency consent typically involves asking a patient to consent to his/her information being accessed and/or shared for a limited period of time. Such permission can be pre-registered with the provider holding the information. Or it can be registered with the requesting (emergency) provider and used as (a) evidence that can be presented to other providers allowing them to release information that is being requested, or (b) evidence that the requesting provider was allowed to invoke an emergency procedure according to the local emergency policy.

Emergency consents often have a temporal character and expire after some predefined amount of time. Hence, emergency consent is also referred to as temporary consent.

Both solutions come with their advantages and disadvantages when applied to query-based health information exchange infrastructures. Both aren’t orthogonal either. An emergency policy may require an emergency consent before it is invoked.

The pictures below show the different ways to use consent. The left side represents a setup where a patient has given the data holder prior consent to release his/her information in case of emergency situations. The right side represents a setup where temporary consent is given to the emergency provider to request data from the data holder.

How to make this work in a real-world health information exchange.

Regardless of which approach is adopted, they require that the who, the why, and the what are shared between a data requestor and a data holder. In practice, though, the requestor (a user or a system acting on a user’s behalf) and the holder (a provider organization and its system holding the data) may not have any prior knowledge of each other. Put simply: the EHR system at Hospital A doesn’t know who the doctor from Hospital B is, let alone that their request is being made in the context of an emergency. Technically, this means the EHR needs to be able to pass identifying and contextual information along with its request to a system in another hospital.

Break the glass.

A break the glass function, offered by some clinical applications, can solve the contextual challenge. The name references the fire alarm button that sits behind breakable glass. It solves the why question: the assumption is that if someone breaks the glass, no one questions that a situation is happening that justifies activating an emergency procedure.

However, breaking the glass doesn’t solve the other part of the problem. How does Hospital A know that someone at Hospital B broke the glass? In other words, how is Hospital A aware that an emergency situation is occurring in Hospital B? This is where Purpose of Use comes in: a short, standardized code that travels along with the request and tells the receiving system why access is being asked for, for example “emergency care provision.” A couple of standards define these codes, including ISO 14265 and the HL7 ActReason Codeset, but which one an HIE picks matters less than making sure everyone in the network reads the code the same way.

Identifying the requestor.

But the break the glass functionality doesn’t solve the problem of knowing who the user (or system) requesting access actually is. When everyone uses the same system, a single PACS or a single EHR, capturing user context is easy, because every possible user is already known through their login account. In a health information exchange, that precondition usually doesn’t hold. Solving the who problem comes down to two things: giving systems a way to attach identity information to a request, and building enough trust between the requesting and holding organizations that the holder believes what it’s told.

Attaching identity information works much like signing in to an app with your Google or Microsoft account instead of typing a fresh password everywhere: the request carries a secure, verified token that says who’s asking. In healthcare, IHE defines two standards for this (XUA and IUA) that package that identity information into a token attached to the request.

Trust between organizations that don’t already know each other is the harder problem, and it’s solved in one of two ways: they sign a direct agreement with each other, or they all agree to rely on a shared, trusted third party that vouches for identities on everyone’s behalf. Examples of the latter include the Dutch UZI system for care providers, the upcoming EU Digital Identity Wallet, or other strong identity-verification services such as ID.me or clearme.com.

Put together, solving the who, why and what comes down to three building blocks, each backed by an existing standard. The table below is a quick reference; the labels in the first column are what matters most.

The final gap to close.

However, even when we have solved the user, the context and the data challenges, there is one remaining thing: proof. This means creating an audit trail that can be used to (1) log that access to patient data was done as a result of invoking an emergency policy, and (2) persist the evidence of the emergency or temporary consent given. IHE has profiles for both: ATNA and BALP capture who accessed what, when and why, as part of an auditable event; BPPC persists a patient’s consent given or used during an emergency.

The latter sometimes leads to the question who is responsible for persisting the emergency consent. It seems logical that it is stored by the provider that took the patient in for emergency treatment. However, persisting it at the provider whose data was being accessed makes sense as well. The IHE XUA and IUA profiles offer a provision to deal with this. Both profiles offer an option to include a reference – in addition to the PoU – to a BPPC (consent document) in the token that is shared. A provider whose data is being requested may use this reference to retrieve the consent document and store it locally as evidence justifying the requested patient information.

What to do as an HIE network.

The most important aspect of emergency access to patient data is creating trust among the HIE participants that all follow the same set of consent policies (a.k.a. governance). If data requestors request and use a temporary consent from a patient, data holders need to be assured that the correct emergency procedures were followed. For example, an HIE governance may define a 48-hour consent, and mandate that this consent is available upon request of a data holder in case of a privacy audit. It may define the conditions that need to apply before a 48-hour consent can be used to bypass access control policies for non-emergency treatments. Furthermore, the governance should define the PoU codes that must be shared as part of a data access request, and how users are identified within the HIE network.

How do we handle this at Founda?

The Founda platform fully supports the identity and consent standards described above. Using the same XUA and IUA standards, it packages user or system identity information into a secure token and attaches it to every request from a data requestor to a data holder. Think of it as a data requestor adding a copy of its passport or identity card to its request, allowing the recipient to confirm who’s asking.

Patient consent, whether permanent or temporary and regardless of whether it’s captured by a requestor or a data holder, is stored as an IHE Basic Patient Privacy Consent document. These documents capture a patient’s response to a consent question by referencing the consent policies that are accepted. Consent documents can be shared like any other document. Hence, a recipient of a data access request can retrieve and evaluate the consent document before granting (or denying) access to the data it holds.

Finally, a break-the-glass functionality is available in the Founda Portal, letting users indicate that immediate access is required. Using it requires entering a coded purpose-of-use reason. In addition to normal auditing, audit messages generated during emergency access include that user-entered purpose-of-use code, making it easy to spot these events when reviewing audit trails. The image below shows an example of the break-the-glass function in the Founda Health Portal.

Consent with automatic expiry.

It’s also possible to link a user’s ability to change the purpose of use to an explicit emergency consent given by a patient. This is valuable when a patient gives verbal consent while being admitted to a hospital or emergency room: a doctor or nurse registers the consent, which automatically gets an expiry date (in the Netherlands, sometimes called the 72-hour consent). As a result, the break the glass function is only available for as long as the consent remains valid.

What this looks like in practice.

Earlier this year in Kreis Paderborn, Germany, a person with impaired consciousness, without relatives or other people nearby who could provide information, called the emergency services for help. When the ambulance arrived, the patient was unable to answer important questions about medications, allergies or existing conditions.

Because the patient had previously enrolled in the regional digital health platform and provided consent, the emergency team could access relevant health information directly from the ambulance, before reaching the hospital. That information helped the team adapt treatment and make a more informed decision about which hospital was best suited for the patient’s care, rather than simply going to the nearest one (Kreis Paderborn, 2026).

That’s the outcome this article has been building toward. Solving the who, the why and the what isn’t an exercise in access control for its own sake. In this case, it meant giving an emergency team access to relevant information at the moment they needed it, even when the patient could not provide that information themselves.

The standards behind that exchange — XUA and IUA for identity, Purpose of Use for context, and ATNA, BALP and BPPC for audit and consent — are not the point on their own. Their value is in making use cases like this possible within a consistent governance framework: establishing who is requesting information, why they need it, what they are allowed to access and how that access is recorded.

For any HIE building or reviewing an emergency access model, the starting point is therefore the use case and its governance requirements, not the technology. Define what should happen when a patient cannot provide information themselves, who should be able to access it, under which circumstances and how that access should be governed and audited. From there, established standards can provide the technical foundation without requiring every network to design its own approach from scratch.

Founda’s platform is built around these standards and the real-world use cases they need to support. If you’re working through what consent and access should look like across your own network, that’s a conversation worth having.