SOWEDO/Showcases/European Patient Summary

A patient nobody knows, understood in a minute.

A German woman is admitted to an emergency department in Porto. The doctor speaks no German and has no access to her records. Even so, within a minute the top of the screen says that penicillin could be fatal.

Does this sound familiar? →

What the system does

Finds a patient by number, name or date of birth
Turns openEHR data into a European summary in FHIR
Puts allergy and medication on top, as a warning
Shows the code, the source and the date per item

The brief

Retrieving a record is not the same as reading it.

A patient from another European country comes in. The doctor has minutes to choose an antibiotic. The very things that change that choice, such as a serious penicillin allergy, a blood thinner or a kidney value, sit a thousand kilometres away, in another language, in another system.

We built that entire path. From the nurse recording a value in one country, to the screen where a doctor in another country makes a decision. Not a sketch: a working prototype on a real openEHR platform, with an entry application that knows nothing about the viewer.

Source: openEHR, six templates plus demographics

Mapped to the Europe Patient Summary (FHIR R4)

Looked up live: SNOMED CT, LOINC, ATC, ICD-10

A viewer that supports the decision, not FHIR

An entry application sharing only the repository

Access logging, GDPR, EHDS and the AI Act

In brief

Two standards that complement each other, not clash.

openEHR keeps the data separate from every application that will ever show it. FHIR exchanges it across the border. The layer in between may be thin, as long as it sits in the right place.

Book an intro call →

What it comes down to

Three things that make a summary usable.

The order

Allergies on top, visible without scrolling. Then medication, then the active problems. That order comes from the clinic, not from a design.

Empty is not no

“No known allergy” is not the same as “no allergies”. What is missing appears as a risk, not as white space.

The origin

The code, the source and the date with every item. A lab result older than three months says so itself, before anything is dosed on it.

On screen

This is what it looks like.

Patient summary with a penicillin allergy warning at the top

The allergy sits on top, with SNOMED CT code, reaction and date. The identity stays in view, the access is logged.

The same application with a nearly empty record, flagging missing medication

The same screen, nearly empty record. “No known allergies” is a recorded finding. Missing medication is a risk.

The underlying FHIR document bundle following the HL7 Europe Patient Summary

Underneath lies the standard: a FHIR R4 bundle following the HL7 Europe Patient Summary, exactly as a hospital receives it.

Clinical briefing in four points, each with the data it rests on

The briefing puts the underlying data under every sentence. Without an AI key it keeps running, rule based.

What it delivers

Where the gain sits.

Not in screens, but in boundaries. Each layer knows exactly one thing, and that is what makes the whole thing portable.

6 → 1Six openEHR templates become one European summary.

2 → 0Two openEHR platforms. Switching left the interface alone.

0 linesShared code between entry and viewer. Only the repository.

100%Synthetic patient data. No real record was used.

This is not only about healthcare.

Wherever data outlives the application that shows it, the same question applies. Healthcare is simply the domain where you see straight away what it costs when it goes wrong.

Prototype, built as a practical assignment. All patient data in it is fictional and synthetic.