
}

The conversations around the table lead to clear agreements: which data is relevant to whom, when is it needed and what happens when something falls outside the expected range? Technology follows these agreements, with the patient record as its foundation, a digitally supported process and secure data exchange across the care chain.
This is part 2 of a two-part series. Part 1 (People and processes first) explained that data sharing starts with clear agreements: who needs to know what and when? This article is aimed at IT and information managers and explores how technology can support those agreements.
The same patient from part 1 returns home after being admitted to hospital with heart failure. The community care team weighs the patient daily and measures their blood pressure. They use a single app to plan visits and record measurements on location. The planner can see who needs a visit that day, while the community nurse records the patient's measurements directly on their phone or tablet. The app supports the process; the healthcare data itself is stored in a CDR (Clinical Data Repository), which stores healthcare information independently of any particular software vendor, using openEHR.
The CDR and the app are hosted within the healthcare organization's IT environment or regional infrastructure, not by the application developer. They also fall under the organization's information security policy (NEN 7510).
The electronic patient record (EPR) in the hospital and the electronic client record (ECR) in community care form the core of every healthcare organization. The app complements these records. The community nurse opens it from within their own ECR, with the correct patient already selected, preferably using SMART App Launch. The measurement can be viewed from the ECR and is also recorded there if the ECR supports this.
Every time a measurement is recorded, the app checks it against the agreed thresholds. If the patient gains two kilos in three days, the designated healthcare professional receives an alert in the system they already work with: the GP in their practice information system and the heart failure nurse in the hospital's EPR.
This can be done using the notified pull principle: the recipient receives an alert and retrieves the measurement via FHIR when they open it. Data is only shared with another care provider in the chain if the patient has given consent.
For the patient, this means one measurement, recorded once, with the information reaching the right healthcare professionals.
The care providers themselves determine which thresholds apply and who receives the alert.
Squad Apps has turned this concept into a working demo using Mendix. It shows step by step how Mendix, openEHR and FHIR work together:
The integration is generic: it uses the standard openEHR REST API and contains no built-in knowledge of specific templates. The templates and fields used for each measurement are configured per application. This means the same integration also works with other CDRs that support these standard APIs, without requiring a new integration for every additional measurement.
Does this sound familiar in your organization or region? Get in touch. A coffee is all it takes to explore whether this approach could work for you too.
Squad Apps builds Mendix applications that support healthcare professionals: designed around their workflows, based on open standards such as openEHR and FHIR, and hosted within the healthcare organization's own IT environment.