In application
MDR: Medical Device Regulation applies
Including rules for software as a medical device.
Healthcare & Life Sciences
Less paperwork, with the clinician still in charge.
What we build for hospitals, care networks, insurers and life-sciences companies: interoperable health data flows, administrative AI that keeps clear of clinical decisions, and validated systems that stand up to inspection.
For hospitals, care networks, health insurers and life-sciences companies working across European health systems with different eHealth platforms and languages.
26 March 2025
European Health Data Space in force
Patient access, cross-border exchange and secondary use of health data, applied in phases.
2 August 2028
AI Act duties for AI in medical devices
High-risk obligations for AI that is a regulated product or safety component, as amended in 2026.
26 March 2029
EHDS exchange and secondary use begin
Patient summaries and ePrescriptions exchanged, and health data access bodies open for secondary use.
What is changing in health and life sciences
Health data becomes portable
The European Health Data Space gives patients electronic access to their data and sets common formats for exchange. Health data access bodies will grant regulated access for research and policy in secure processing environments.
SourceRegulation (EU) 2025/327
Administration eats clinical time
Documentation, coding, referrals and prior authorisations take hours that should go to patients. Well-bounded assistance can return some of that time, if clinicians stay the author of the record.
The device boundary matters
Software that informs diagnosis or treatment can be a medical device under the MDR, and AI inside it is high-risk under the AI Act. Keeping administrative AI clearly on the other side of that line is a design decision.
SourceRegulation (EU) 2017/745
Hospitals are critical infrastructure
Healthcare providers are in scope of NIS2. Ransomware has shown what happens when recovery is not rehearsed, so resilience and segmentation belong in the architecture.
Challenges and what we build
- The challenge
Clinicians spend evenings finishing documentation.
Our responseDocumentation assistance that drafts letters and summaries from structured data and notes. The clinician edits and signs; nothing reaches the record unsigned.
- The challenge
Referrals and intake forms arrive in every format.
Our responseIntake processing that classifies referrals, extracts the clinical question and flags missing information for staff to complete, with a complete audit trail.
- The challenge
Systems do not speak the same language.
Our responseIntegration on HL7 FHIR and IHE profiles with shared terminology such as SNOMED CT, connected to national eHealth infrastructure instead of one-off interfaces.
- The challenge
Research teams wait months for usable data.
Our responseData pipelines with pseudonymisation, documented lineage and access controls, ready for secure processing environments and health data access body requests.
- The challenge
Validated systems slow every change in GxP environments.
Our responseRisk-based computerised system validation in the spirit of GAMP 5: automated testing and traceable requirements, so validation evidence is produced with each release rather than after it.
- The challenge
Medical, quality and regulatory knowledge sits in thousands of documents.
Our responseKnowledge search over SOPs, labelling and regulatory correspondence that cites the controlled version of every source.
Three zones, one data layer
We keep administrative support, clinical decision support and secondary use apart by design. Each zone has its own rules, approvals and evidence, on top of one interoperability layer.
Illustrative example
Only the administrative zone is in scope of the assistance we describe here. Clinical decision support follows a medical-device route.
Read the diagram as text
The diagram shows three zones above one interoperability layer built on HL7 FHIR, IHE profiles and SNOMED CT, which connects to the EHR and clinical systems.
The administrative support zone contains documentation drafts and coding and referral intake. Everything passes a clinician sign-off before it reaches the record.
The clinical decision support zone is separate: such software is validated as a medical device under the MDR and is high-risk under the AI Act.
The secondary use zone follows the European Health Data Space: a health data access body grants a permit, data is processed in a secure processing environment, and research and registries use the results.
Clinician sign-off
Drafts and suggestions are never written to the record without a named clinician's approval.
A clear device boundary
If a function starts to inform diagnosis or treatment, it moves to a medical-device development path, not a quiet feature update.
Standards over interfaces
FHIR resources, IHE profiles and shared terminology instead of bespoke point-to-point links.
Secondary use by permit
Research data leaves the care zone only pseudonymised, under a permit, into a secure processing environment.
The regulatory timeline for health and life sciences
Dates that shape health data platforms, AI and validated systems. Several depend on implementing acts that are still being written.
In application
NIS2: National NIS2 rules apply
Healthcare providers are in scope.
In application
EHDS: European Health Data Space enters into force
In application
EU GMP: Draft Annex 11 revision and new Annex 22 on AI published
Consultation closed; final texts not adopted as of the status date.
Status as of 2 October 2026
Upcoming
EHDS: General application of the regulation
Implementing acts set the detailed formats and requirements.
Upcoming
MDR: First transition deadline for legacy devices
Class III and implantable class IIb devices; a targeted revision of the MDR is under discussion.
Upcoming
AI Act: Obligations for AI in regulated products apply
Covers AI in medical devices, as amended in 2026.
Upcoming
EHDS: Exchange of first priority categories and secondary use
Patient summaries and ePrescriptions; health data access bodies operational.
Upcoming
EHDS: Second group of priority categories
Medical images, laboratory results and discharge reports.
Regulation and standards reference
The instruments most often behind a health or life-sciences specification, and what they mean for delivery.
This overview supports planning conversations. It is not legal, regulatory or clinical advice. Dates reviewed on 2 October 2026.
- GDPR: health data as special-category dataScopeEU-wide
Health and genetic data are special categories under Article 9. Processing needs a specific legal basis, and a data protection impact assessment is expected for large-scale processing.
What it means for your programmeAccess boundaries, pseudonymisation and retention are designed before build, and we supply the technical input for your DPIA.
SourceRegulation (EU) 2016/679, EUR-Lex (opens external site)
- European Health Data SpaceScopeEU-wide
Gives people electronic access to their health data, sets a common European exchange format and requirements for electronic health record systems, and creates a framework for secondary use through health data access bodies. It applies in phases between 2027 and 2031.
What it means for your programmeSystems built now should expose data in standard formats and log access in a way that will meet EHDS requirements without a rebuild.
SourceRegulation (EU) 2025/327, EUR-Lex (opens external site)
- Medical Device Regulation (MDR)ScopeEU-wide
Software intended for diagnosis, prevention, monitoring or treatment can be a medical device, typically in class IIa or higher under the software classification rule. Transition periods for legacy devices were extended by Regulation (EU) 2023/607.
What it means for your programmeWe document intended purpose early. Administrative tools are designed to stay outside the device definition; device software follows a regulated lifecycle.
SourceRegulation (EU) 2017/745, EUR-Lex (opens external site)
- EU AI ActScopeEU-wide
AI that is a medical device, or a safety component of one, is high-risk. Under the Act as amended in 2026, these obligations apply from 2 August 2028, alongside the MDR conformity assessment.
What it means for your programmeWhere AI and device rules meet, we plan one set of technical documentation that serves both.
SourceRegulation (EU) 2024/1689, EUR-Lex (opens external site)
- EU GMP Annex 11 and GAMP 5ScopeEU-wide
Annex 11 sets requirements for computerised systems in GMP environments, and GAMP 5 is the industry guide for risk-based validation. A revised Annex 11 and a new Annex 22 on artificial intelligence were published in draft in July 2025.
What it means for your programmeValidation is built into the delivery pipeline: requirements traced to tests, evidence generated per release, and AI use cases assessed against the draft Annex 22.
SourceEudraLex Volume 4, European Commission (opens external site)
- NIS2 for healthcareScopeEU-wide
Healthcare providers, EU reference laboratories and manufacturers of certain medical products are in scope, with duties for risk management, incident reporting and supply-chain security.
What it means for your programmeSegmentation, backup and rehearsed recovery are part of the architecture, and we support your incident reporting as a supplier.
SourceDirective (EU) 2022/2555, EUR-Lex (opens external site)
Illustrative use cases
Illustrative exampleDischarge letter drafting
A draft letter assembled from structured data and notes, edited and signed by the responsible clinician.
Referral intake
Incoming referrals classified and checked for completeness, with missing information requested before triage.
Pharmacovigilance case intake
Adverse event reports extracted into structured cases; safety specialists assess and decide on every report.
SOP and quality knowledge search
Answers from controlled SOPs and quality documents, always citing the current approved version.
Patient and member service
An assistant for appointments, coverage and practical questions, handing over to staff for anything medical.
Platforms in health and life sciences
Salesforce
Summit PartnerPatient and member service, field teams and partner programmes, with clinical data kept in the clinical systems it belongs to.
SAP
Gold PartnerSupply chain, batch management and finance for life-sciences manufacturing, connected to quality and validation processes.
Partner levels are those held by FromNine. Product names are trademarks of their respective owners.
International
European standards first, national eHealth second
The EHDS, MDR, AI Act and GDPR set a common European frame, but care is organised nationally: eHealth platforms, identifiers, terminology releases and reimbursement rules differ per country, and so does the role of health data access bodies.
We design health data flows on European standards first, then connect to the national infrastructure of each country a system serves, so a second market is an integration project rather than a rewrite.
- European Health Data SpaceEuropean Health Data Space Regulation (EU) 2025/327 (opens external site)
- MDRMedical Device Regulation (EU) 2017/745 (opens external site)
- EU AI ActArtificial Intelligence Act, Regulation (EU) 2024/1689 (opens external site)
- GDPRGeneral Data Protection Regulation (EU) 2016/679 (opens external site)
Frequently asked questions
Will an AI assistant turn our software into a medical device?
It depends on intended purpose. Assistants for documentation, coding or intake are designed to stay administrative, with a clinician approving every output. If a function would inform diagnosis or treatment, we say so early and plan a medical-device route.
Where is health data processed?
Where your legal basis and policies allow, typically in your own environment or an EU region with encryption keys under your control. Data flows, retention and access are documented before build.
Do you work with national eHealth infrastructure?
We design integration on HL7 FHIR and IHE profiles so it can connect to national eHealth platforms and the European exchange format, rather than building proprietary interfaces.
How do you handle validation in GxP environments?
Risk-based, following GAMP 5 principles: requirements traced to automated tests, evidence produced with each release, and change control that your quality unit can follow.
What if the AI gets something wrong?
It sometimes will. That is why drafts are never filed without sign-off, uncertain extractions are flagged for review, and quality is measured against agreed test sets before and after each release.
Discuss your health or life-sciences project
Reducing documentation load, preparing for the EHDS or modernising a validated system? Start with the workflow and the rules that apply to it.