With AI tools, analyses, dashboards and small applications can now be built in days rather than months. Many hospitals are already doing this: a doctor builds an overview for her ward, a therapy team an analysis for its team meeting. The question is rarely whether an application works technically. The question is whether it can be operated with health data on a sound legal footing. Building software has become cheaper. Operating it securely has not.
Health data is special data
Under the GDPR, health data belongs to the special categories of personal data (Art. 9 GDPR). Processing it is only permitted under strict conditions, for example with explicit consent or as part of treatment. For every new application it must therefore be clear on what legal basis it processes which data for which purpose.
So the first question is not “What can the application do?” but: which data does it really need – and what for?
Consent and purpose limitation
Consent must be documented, verifiable and revocable. This also applies to every application you build yourself. If a patient withdraws her consent, the withdrawal must reach every place where her data is used – including the analysis a team built three months ago.
So ask: where is consent stored? How does your own application learn of a withdrawal? Does the existing consent cover the new purpose at all?
Roles and permissions
Self-built applications often bypass existing permissions because they access a database or an export directly. Suddenly an analysis shows data that the person using it would never be allowed to see in the hospital information system (HIS).
Roles and permissions must therefore also apply to self-built applications. Where a personal reference is not needed for the purpose, the data should be pseudonymised.
Where the data is stored
Hosting location, data processing agreements and data flows determine whether processing is permissible. Health data that is sent to an AI service outside the EU for processing is particularly critical. Clarify: where is the data stored and processed? Are there data processing agreements with everyone involved? Does data leave the EU, for example via a cloud AI?
One approach that reduces this risk: the AI helps to build the application but does not see the raw data. It configures analyses and dashboards; the actual calculation then runs in your own protected environment – traceable and reproducible.
Traceability and audit trail
Who used which data and when, and on what data basis was a result produced? Without an audit trail and a clear data origin, this cannot be demonstrated either to patients or to supervisory authorities.
This also includes the origin of every single value. Values from different devices have different formats, units and measurement methods. An AI application is only as good as its data. For every value it should be clear which device it came from, and when and how it was measured.
When an application becomes a medical device
Software intended for diagnosis, therapy decisions or patient monitoring may fall under the Medical Device Regulation (MDR). The intended purpose is decisive. Pure documentation and display are assessed differently from automatic therapy recommendations. A simple rule helps: the application shows, the professional decides.
The division of tasks that works
A clear separation has proved its worth. A proven foundation takes on the obligations that have to be met permanently: device integration, data storage, consent, roles and permissions, audit trail. On top of this, organisations build their own analyses and applications. That way you keep the freedom to build, and the obligations sit where they are met permanently.
This is exactly the role Datico® takes on. The Datico® Life Hub connects devices, wearables and hospital systems, stores the data together with its origin, manages consent via double opt-in, enforces roles and permissions and logs access in the audit trail. Hosted in Germany or, on request, on-premise in your own infrastructure. Your applications access the data via the Smart API and the AI Connector – with the same permissions as every other access.
You build the application. We provide the foundation.
Short checklist
- The purpose and legal basis of the application are documented.
- Consent is verifiable; withdrawals reach the application.
- The hosting location is known; data processing agreements are in place.
- No health data goes to services outside the EU without a verified legal basis.
- Roles and permissions also apply in your own application.
- Access is logged; the origin of every value is traceable.
- The intended purpose has been checked with regard to the MDR; the decision stays with the professional.
- The data protection officer is involved.
This article provides guidance and is not a substitute for legal advice. If you would like to check how your own applications can run on such a foundation, book an initial consultation.
