Custom Puur by Ecare API integration development
An integration with an electronic health record is not an ordinary integration. It involves health data, so the question is not only what is technically possible but also what is permitted, who may see it, and how you demonstrate that later. That shapes the design from day one, not at handover.
What makes an EHR integration different
Puur by Ecare is an electronic health record used in care for, among other things, client details, care plans, scheduling and reporting. An integration is usually requested because something sits alongside it: a separate scheduling tool, a client portal, a billing process or a report the EHR does not provide. The EHR then remains the source; the aim is not to create a second record.
That last point is the most important design rule. Data you copy and store separately will drift out of step with the EHR, and in a record on which care professionals base decisions that is not acceptable. We therefore retrieve as little as possible and store as little as possible. Where data is genuinely needed outside the EHR, we record where it comes from and how old it is.
What can be exchanged depends on the interface the vendor makes available and on your own contract and modules. We map that out before committing to anything. We are not partners of the vendor, and we do not promise an integration we have not seen; we do know how such a project typically unfolds and where it usually stalls. For what NEN 7510 requires of you, see nen.nl.
How we build this
The first question is which data is really needed outside the EHR, and that is almost always less than the initial inventory suggests.
Which exchange the supplier makes available, under which conditions, and with what lead time for requesting it. This step often takes weeks rather than days, and it determines whether the plan is feasible.
Per field, ask why it is needed and whether it could be left out. This is not about cutting costs but about data minimisation: every field you do not pull across is one you do not have to secure, retain and account for.
Every sprint ends with something you can check yourself, and we begin with the narrowest useful exchange. Expanding is always possible; reversing it once data has spread is not.
We work alongside the teams who will use it. That shows whether the integration does what is needed, and what still happens manually around it.
What the integration actually does
What is possible follows from the interface. These are the six questions that almost always come up in such a project.
Client data synchronisation
Basic data from the EHR to the application beside it, in one direction and without creating a second record. Which fields and how often depends on the interface and on what you actually need.
Planning and care delivered
Exchanging appointments and records of care delivered, usually because a planning tool or route planner runs alongside. This is where most of the daily value lies, and also where the risk is greatest that two systems contradict each other.
Client or family portal
A protected entry point where a client or relative can view or submit something. This is a separate component with its own access arrangements and its own decisions about what is and is not visible; it is not a by-product of the integration.
Signals instead of record copies
For reporting and management, a set of aggregated figures is often enough rather than a full record. Where possible we work with aggregated signals, because that removes the risk without leaving the question unanswered.
Visible error handling
In a care record, an integration that silently fails is the most dangerous scenario. Failed exchanges become visible and remain open until someone resolves them.
Logging of what has been exchanged
Which data went where and when. For health data this is not a luxury: it is what you need when a client asks a question or when an incident occurs.
Who we build for
The reason to integrate differs greatly between organisations. Four situations we encounter.
District nursing and home care
Scheduling and routes often sit alongside the EHR, and that is where the integration is most often missed. The gain is that a change is made in one place instead of two. If care logistics is also involved, see care logistics software.
Organisations with their own management information
You want figures the EHR does not provide in that form. The question is whether you need a record-level integration or only aggregated data, and that makes a difference to risk and lead time. For the wider care system, custom care software is the answer.
Care organisations with a client portal
A dedicated environment for clients or relatives, fed from the EHR. This requires the most demanding decisions about what may be visible and to whom; see also care compliance for the frameworks around it.
Chain partners and collaboration
Sharing data between organisations is legally quite different from integrating within a single organisation. Establish that legal basis before anything is built. If you're also certified under HKZ, see the HKZ quality manual.
Technology and integrations
The frameworks determine the design here, not the other way round. NEN 7510 for information security in care, a data processing agreement with every party that processes data, and logging sufficient to account afterwards for who saw what.
Why Appfront
Health data drives the design
It's not the technology but the sensitivity that drives the choices. We design to keep data outside the EHR to a minimum, rather than to maximise features.
The EHR remains the source
A second record that drifts out of step is worse than no integration at all. We fetch only what's needed and retain as little as possible.
Failure must not happen silently
In care, an integration that quietly fails is the most dangerous scenario. Failed exchanges stay visibly open until they're resolved.
Honest about what we don't know
We are not a partner of the vendor. What the interface makes possible is established during the discovery phase; we don't promise an integration we haven't seen.
Security and privacy
This is health data, which makes it special category personal data. That changes everything about the approach: not only encryption and access control, but also whether a given item needs to leave the EHR at all. For many questions, a count is enough rather than a record, and in that case we choose the count. What we do fetch, we fetch by role rather than by organisation: a scheduler doesn't need to see clinical reporting.
On the formal side, this should fit within your NEN 7510 framework, with a data processing agreement for every party that processes data and with sub-processors you know about. Logging is not an afterthought here but part of the functionality: if a client asks, or in the event of an incident, you must be able to show which data was exchanged, when, and who viewed it. Whether your intended exchange is lawful is for you to assess with your data protection officer; we build within those boundaries. How we handle security ourselves is set out in our information security policy; reports from outside reach us through our vulnerability disclosure policy.
Frequently asked questions about a Puur integration
That depends on the interface the vendor makes available and on your contract and modules. We are not a partner of the vendor, and we won't promise an integration before we've established what's possible. That assessment is the first step and often takes weeks rather than days, partly because permissions and documentation are involved.
That's exactly what we want to prevent. The EHR remains the source; what we build alongside it fetches only what it needs and retains as little as possible. Data you store separately inevitably drifts out of step, and for a record on which care professionals base decisions, that's unacceptable.
Then that must be visible. In a care record, an exchange that stops unnoticed is the most dangerous scenario, because people keep relying on information that is no longer correct. We build failed exchanges as open alerts that only close once someone has dealt with them, and we show how old each piece of data is.
They shape the design, not the other way round. In practice that means data minimisation as the starting point, encryption in transit and at rest, access by role, logging of access and a retention period the system enforces itself. Whether your intended exchange is permitted is for you to assess with your data protection officer; we build within those boundaries.
Sometimes, and it's a weightier decision than it sounds. Writing back means a system outside the EHR changes the record, with all the questions of responsibility that brings. We advise starting with read access and only writing back once there's a clearly defined process behind it.
Then the integration has to be rebuilt, and that's a real risk with this kind of custom work. We limit it by isolating the exchange in a separate layer, so your own application doesn't depend directly on the EHR. A switch then affects that layer rather than the whole system.
We have no partner relationship and don't present ourselves as one. In practice, contact over the interface runs through you as the client, because you hold the contract. What we do is prepare the technical side so that conversation is concrete: which interface, which fields, which frequency.
That depends mainly on what the interface permits and how much data is genuinely needed. A narrow, read-only integration is a manageable project; two-way traffic with a client portal is a multiple of that. Expect the vendor's assessment to have its own lead time. We'll give a reasoned estimate after the discovery phase.
Get a Puur integration built?
Tell us which process runs alongside the EHR today and which data is entered twice. The integration needed is usually narrower than expected. We build this as part of a wider custom software project or through smart API integrations.