The CTO of a telehealth scale-up signs off a roadmap for the next two quarters: a patient app, a clinician portal, video consultations and, as the headline feature, an AI symptom checker that suggests whether a patient should book a GP visit or go to the emergency department. The development partner quotes seven months. Four months in, the company’s regulatory consultant reads the marketing copy and says one sentence: “That triage feature is a Class IIa medical device.” The schedule, the budget and the architecture all change in the same afternoon.
That is the defining trait of healthcare software development. The code itself is rarely harder than in fintech or e-commerce. What differs is that a single sentence in a product description can change the legal status of the whole system, that data belongs to the most sensitive category under every privacy law, and that the software has to talk to decades-old clinical systems in standards most developers have never used.
Below we walk through what that means in practice in 2026: which types of healthcare software exist, when software becomes a medical device, which standards govern the development process, what HIPAA, GDPR, the European Health Data Space and the AI Act require, why interoperability is the hardest technical part, and what a regulated build really costs compared with a non-regulated one. Amounts are in Polish złoty with indicative US dollar values at an assumed PLN 3.70 per USD. This article is not legal or regulatory advice.
What makes healthcare software development different from other software projects?
Three things set healthcare apart, and each has a direct cost.
The legal status of the product depends on its intended purpose. The same algorithm can be a wellness feature or a regulated medical device depending on what the manufacturer claims it does. That decision determines the development process, the documentation, the approval route and who is liable if something goes wrong. It has to be made before architecture, not after launch.
The data is special-category data. Health information is protected by HIPAA in the United States and by Article 9 of the GDPR in the European Union, where processing it is prohibited unless a specific legal basis applies. Breaches are also the most expensive of any sector: IBM’s Cost of a Data Breach Report 2025 put the average healthcare breach at USD 7.42 million, with an average of 279 days to identify and contain it — five weeks longer than the cross-industry average. Healthcare has topped IBM’s cost ranking for fourteen consecutive years.
The software must fit into an existing clinical ecosystem. Hospitals run electronic health record (EHR) systems, laboratory and radiology systems, pharmacy systems and national e-health platforms. New software that cannot exchange data with them is rarely adopted, however good its user interface. Integration work often takes a larger share of the budget than the new features themselves.
None of this makes healthcare projects impossible or even unusually slow. It makes them unforgiving of decisions taken late. The organisations we see succeed make three calls in the first weeks: the intended purpose of each module, the regulatory route, and the integration targets. The broader business case for digital health — telemedicine adoption, HIS selection, ROI — is covered in our article on digital transformation in the Polish healthcare sector; here we focus on building the software.
What types of healthcare software are built today?
“Healthcare software” covers very different products. Their regulatory and technical profiles differ enough that it helps to name the category before estimating anything.
| Category | Typical examples | Usually a medical device? | Main technical challenge |
|---|---|---|---|
| EHR / EMR and hospital systems | Electronic health records, HIS, departmental systems | Usually not, unless modules calculate doses or support diagnosis | Integration, data migration, performance, audit logging |
| Telehealth platforms | Video consultations, e-visits, scheduling, e-prescribing | Usually not (communication), triage features may be | Availability, video quality, identity verification |
| Patient apps and portals | Appointment booking, results access, medication reminders | Usually not, unless they interpret results for the patient | Accessibility, security, integration with provider systems |
| Remote patient monitoring | Data from glucometers, blood pressure monitors, wearables | Often yes, if it triggers clinical alerts | Device connectivity, data quality, alarm logic |
| Clinical decision support | Risk scores, triage, diagnostic suggestions | Often yes | Clinical validation, explainability, risk management |
| Software as a Medical Device (SaMD) | Image analysis, diagnostic algorithms, therapy planning | Yes, by definition | Full regulated life cycle, clinical evaluation |
| Integration and middleware | Interface engines, FHIR gateways, national platform connectors | Usually not | Standards (HL7 v2, CDA, FHIR, DICOM), mapping, reliability |
| Analytics and population health | Dashboards, registries, research data platforms | Usually not | Pseudonymisation, data governance, secondary use rules |
Most real products are combinations. A telehealth platform may consist of non-device modules (scheduling, video, payments) and one device module (triage). Treating the whole platform as a device multiplies the cost; treating the whole platform as non-device creates legal exposure. The practical answer — separating modules architecturally and by intended purpose — is discussed later.
When does your software become a medical device?
In the European Union, the question is governed by the Medical Device Regulation (EU) 2017/745 (MDR). Software is a medical device when its manufacturer intends it to be used for a medical purpose for individual patients — diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, among others. The key word is intended: what counts is the purpose stated in the labelling, instructions for use and marketing materials, not what the code technically can do.
The main guidance is MDCG 2019-11, whose first revision was published in June 2025. It walks through qualification (is it a device at all?) and classification (which risk class?). Revision 1 clarified intended purpose, modular software and Rule 11, and added cross-reference tables linking the significance of the information the software provides to the seriousness of the healthcare situation.
Classification then follows Rule 11 of the MDR, written specifically for software:
- Software providing information used to take decisions with diagnostic or therapeutic purposes is Class IIa by default.
- It is Class IIb if such decisions could cause a serious deterioration of health or a surgical intervention.
- It is Class III if they could cause death or an irreversible deterioration of health.
- Software intended to monitor physiological processes is Class IIa, or IIb when it monitors vital parameters where variations could result in immediate danger.
- All other software is Class I.
In practice, Rule 11 pushes most decision-support software into Class IIa or higher, which means a notified body must assess the manufacturer’s quality management system and technical documentation. Class I software can be self-certified, but still needs a quality system, technical documentation and post-market surveillance.
Two practical consequences follow. First, marketing copy is a regulatory document. “Helps you decide whether to see a doctor” and “diagnoses your symptoms” can put the same feature into different categories. Second, the MDR transition is still running for older devices: Regulation (EU) 2023/607 extended it to 31 December 2027 for Class III and implantable Class IIb devices and to 31 December 2028 for other classes, but only for legacy devices without significant changes. New software goes straight to the MDR.
In the United States, the FDA regulates “device software functions” and Software as a Medical Device through the 510(k), De Novo and PMA pathways, with a risk-based approach and specific exemptions for certain clinical decision support and wellness functions. If you plan to sell in both markets, align the intended purpose statement early — divergent claims create two products to maintain.
Which standards govern the development process: IEC 62304, ISO 13485, ISO 14971 and IEC 82304-1?
Regulations say what must be demonstrated; harmonised standards say how manufacturers usually demonstrate it. For software, four standards form the core.
IEC 62304 — software life cycle. It defines the processes for developing and maintaining medical device software: planning, requirements, architecture, detailed design, implementation, integration, system testing, release, maintenance, configuration management, problem resolution and risk management of software items. Its central concept is the software safety class:
- Class A — no injury or damage to health is possible;
- Class B — non-serious injury is possible;
- Class C — death or serious injury is possible.
The class determines the depth of documentation: Class A needs requirements, system testing and release records; Class C additionally needs detailed design down to software units, unit verification and more rigorous traceability. The current version is Edition 1.1 (Amendment 1 of June 2015), which rewrote the classification rule and added a clause on legacy software. A second edition is in preparation; its draft replaces classes A/B/C with two process rigour levels and widens the scope to health software generally.
ISO 13485 — quality management system. The QMS standard for medical device manufacturers: document control, design controls, supplier management, corrective and preventive actions, training. For a software company it is the organisational wrapper around IEC 62304.
ISO 14971 — risk management. Identifying hazards, estimating and controlling risks, and monitoring them after release. Software risk management under IEC 62304 plugs into this process.
IEC 82304-1 — health software product safety. It covers standalone health software as a product, including requirements for accompanying documents and post-market activities, and relies on IEC 62304 for the development process. It matters for health software that is not a device but still needs a recognised safety baseline.
Two further standards appear in almost every project: IEC 62366-1 for usability engineering (use errors are a major hazard source) and IEC 81001-5-1 for security activities in the health software life cycle.
None of this rules out agile development. IEC 62304 does not prescribe a life-cycle model, and the AAMI TIR45 technical report describes how to apply agile practices within it. What it does require is that every requirement, risk control, test and release is traceable. Teams that automate traceability in their tooling keep agile velocity; teams that do it by hand in spreadsheets before each release lose it. We compare development models in regulated contexts in our article on software development models compared.
What do HIPAA, GDPR and the European Health Data Space require from the software?
Privacy and data-exchange rules apply to almost all healthcare software, whether or not it is a medical device.
HIPAA (United States). The Privacy Rule governs uses and disclosures of protected health information (PHI), the Security Rule sets safeguards for electronic PHI, and the Breach Notification Rule defines reporting duties. A software vendor processing PHI on behalf of a provider is a business associate and signs a business associate agreement. The Security Rule is being overhauled: HHS published a proposed rule in January 2025 that would make encryption of ePHI at rest and in transit, multi-factor authentication, network segmentation and documented restoration times mandatory rather than “addressable”. As of mid-2026 it remained a proposal. Designing for those controls now is cheaper than retrofitting them.
GDPR (European Union). Health data is a special category under Article 9. Software must support a valid legal basis for processing, data minimisation, access controls, audit trails, retention rules and data subject rights. Health data processing at scale typically requires a data protection impact assessment (Article 35), and transfers outside the EU need a lawful mechanism.
The European Health Data Space. Regulation (EU) 2025/327 entered into force on 26 March 2025 and changes the landscape for EHR vendors:
- 26 March 2027 — general application of the regulation;
- 26 March 2029 — patient summaries and ePrescriptions/eDispensations must be exchangeable across all member states through the MyHealth@EU infrastructure;
- 26 March 2031 — medical images, laboratory results and hospital discharge reports follow.
EHR systems will have to meet harmonised requirements for interoperability and logging, and patients gain rights to access and share their data electronically. If you are building an EHR component with a five-year horizon, EHDS requirements belong in the architecture now.
Poland. Since 8 January 2020 e-prescriptions have been mandatory, since 8 January 2021 e-referrals, and since 1 July 2021 all healthcare providers — public and private — must report medical events and make electronic medical records (EDM) available through the national P1 platform run by the Centrum e-Zdrowia. Any software serving Polish providers has to integrate with P1.
Cybersecurity law. In the EU, many healthcare providers are essential or important entities under the NIS2 directive, implemented in Poland by the amended National Cybersecurity System Act in force since April 2026. That translates into supplier security requirements in contracts.
How does the EU AI Act affect AI-based medical software?
AI in healthcare is covered by both the MDR and the AI Act (Regulation (EU) 2024/1689). An AI system that is a medical device, or a safety component of one, requiring notified body assessment is classed as high-risk under Article 6(1) of the AI Act.
The timeline changed in 2026. The Digital Omnibus on AI, published in the Official Journal on 24 July 2026 and in force since 27 July 2026, deferred the high-risk obligations. For AI embedded in products covered by EU harmonisation legislation listed in Annex I — including medical devices — the application date moved to 2 August 2028. Stand-alone high-risk systems under Annex III moved to 2 December 2027. The main reason was the delay in harmonised standards needed to demonstrate compliance.
Deferred does not mean irrelevant. High-risk AI obligations include a risk management system, data governance for training, validation and test data, technical documentation, logging, transparency to users, human oversight, and accuracy, robustness and cybersecurity requirements. For a medical device, these are assessed together with the MDR conformity assessment, and much of the evidence overlaps with IEC 62304 and ISO 14971 work. A product launched in 2027 will be on the market when the obligations apply, so the data governance and logging design decisions are being made now.
Practical implications for the development process:
- Version the data as carefully as the code. Training and validation datasets, their provenance and their known limitations become part of the technical documentation.
- Design human oversight into the user interface. Clinicians must be able to understand, override and report the system’s outputs.
- Plan for change control. A retrained model can be a significant change to a medical device. Define in advance which changes fall within a predetermined plan and which trigger a new assessment.
Why is interoperability the hardest technical part of healthcare software?
In most sectors, integration means REST APIs and agreed JSON schemas. In healthcare it means working with standards that evolved over three decades and coexist in the same hospital.
HL7 v2 — pipe-delimited messages from the late 1980s — still carries a large share of admissions, orders and results inside hospitals. HL7 CDA structures clinical documents; the Polish EDM ecosystem is based on the Polish HL7 CDA implementation guide. DICOM governs medical imaging. And HL7 FHIR is the modern, resource-based API standard that regulators increasingly reference.
For FHIR, version choice matters:
- R4 (2019) is the first release with normative content and the version referenced by US regulations under the 21st Century Cures Act. It is the safe default for new APIs.
- R5 was published on 26 March 2023 as a trial-use release; it added no new normative content.
- R6 went through its first normative ballot in January 2026, with a further ballot opening in July 2026; final publication is expected in 2026 or 2027.
Choosing R4 today and designing an abstraction layer for a later upgrade is what most teams do. More important than the version is the implementation guide: national and regional profiles (US Core, European and national profiles) define which fields are mandatory, which code systems apply and how identifiers work. Two “FHIR-compliant” systems using different profiles still need mapping.
Terminology is the second hidden cost. SNOMED CT, LOINC, ICD-10 (and ICD-11), ATC for medicines — mapping local codes to standard terminologies is detailed, clinical work that developers cannot do alone.
The third is testing against real counterparts. National platforms and EHR vendors provide test environments with their own availability, data sets and certification procedures. Plans that assume integration testing takes two weeks at the end of a project are almost always wrong; it runs through the whole project. Our general approach to connecting systems through APIs applies here too, with an extra layer of clinical data semantics.
How do you secure healthcare software without slowing delivery?
The breach figures above explain why security in healthcare is a board-level topic. Three sets of requirements shape it in practice.
Regulatory expectations for devices. In the US, Section 524B of the Federal Food, Drug and Cosmetic Act requires manufacturers of “cyber devices” to submit cybersecurity information with premarket submissions — including a software bill of materials (SBOM) covering commercial, open-source and off-the-shelf components, and a plan to monitor and address post-market vulnerabilities. The FDA’s final guidance on cybersecurity in medical devices was updated on 27 June 2025. In the EU, the MDR’s general safety and performance requirements include IT security, and IEC 81001-5-1 describes the related life-cycle activities.
Provider requirements. Hospitals now send security questionnaires covering penetration test results, vulnerability management, encryption, identity management, logging and incident response. Answering them convincingly is part of the sales process.
Architecture patterns that work:
- Encryption everywhere, with keys managed separately from data.
- Strong identity for patients (national e-ID where available) and clinicians (MFA, role-based access, break-glass procedures with audit).
- Immutable audit logs recording who accessed which record and why — required by law in many jurisdictions and the first thing investigated after an incident.
- Data minimisation and segregation, for example keeping identifiers separate from clinical data and pseudonymising analytics.
- SBOM and dependency management integrated into the build pipeline, not assembled before an audit.
Security that is automated in the pipeline does not slow teams down; security performed as a manual gate before each release does. Our guide to DevSecOps in 2026 describes how to build it into CI/CD.
What does the development process look like in a regulated healthcare project?
The stages below describe a medical device software project; non-device health software follows a lighter version of the same sequence.
- Intended purpose and qualification. Write the intended purpose statement, determine device status per module and classify under Rule 11 (and FDA rules if relevant).
- Quality system and plans. Set up or extend an ISO 13485 QMS, a software development plan per IEC 62304, a risk management plan per ISO 14971 and a usability engineering plan per IEC 62366-1.
- Requirements and risk analysis. User needs, system and software requirements, hazard analysis and risk controls — all traceable to each other. Describing clinical workflows first, for example in BPMN, makes the requirements far more complete.
- Architecture and segregation. Define software items, their safety classes and interfaces. Isolate device modules from non-device ones, and record SOUP (software of unknown provenance — third-party libraries) with their known anomalies.
- Iterative development and verification. Build in sprints with unit, integration and system testing proportional to the safety class, and keep traceability current in the toolchain.
- Validation and usability. Summative usability testing with representative users, clinical evaluation (for devices) and performance validation of algorithms on independent data.
- Conformity assessment and release. Technical documentation, notified body review for Class IIa and above, CE marking, EUDAMED registration; in the US, the relevant FDA submission.
- Post-market surveillance. Complaint handling, vigilance reporting, vulnerability monitoring, periodic safety updates and change control for every release.
The stage that most often surprises software teams is the last one. A medical device is never “done”: each release is a controlled change with an impact assessment. Planning the team as if the project ended at CE marking leaves no capacity for the obligations that begin there.
How much does healthcare software development cost and how long does it take?
Costs depend on scope far more than on the sector, so instead of a price range we show how regulation changes the same project. The example is the telehealth platform from the introduction: a patient app, a clinician portal, video consultations and integration with a national e-health platform.
Variant 1 — non-device software, 7 months. Team rates are the midpoints of the Polish nearshore ranges from our body leasing rate benchmark; the business analyst / project manager rate of PLN 190 per hour is our assumption. We assume 160 hours per month per full-time person.
| Role | FTE | Rate (PLN/h) | Cost over 7 months |
|---|---|---|---|
| Senior backend developer | 2 | 220 | PLN 492,800 |
| Mid backend developer | 1 | 155 | PLN 173,600 |
| Senior frontend / mobile developer | 1 | 205 | PLN 229,600 |
| QA automation engineer | 1 | 165 | PLN 184,800 |
| Senior DevOps engineer | 0.5 | 240 | PLN 134,400 |
| Senior security engineer | 0.25 | 255 | PLN 71,400 |
| Business analyst / project manager | 1 | 190 | PLN 212,800 |
| Total | 6.75 | PLN 1,499,400 (≈ USD 405,000) |
Variant 2 — the same platform with a Class IIa triage module, 10 months. Based on our project experience, we add a verification tester (1 FTE at PLN 120), a regulatory and quality specialist (0.5 FTE at PLN 220 — our assumption) and three months for design controls, verification, usability validation and technical documentation. The result is PLN 2,510,000 (≈ USD 678,000) — 67% more than variant 1.
Three observations follow. First, the extra cost is mostly process, not features: verification, risk management, documentation and time. Second, the estimate excludes notified body fees, clinical evaluation, external regulatory consulting and legal costs, which vary widely by product and class. Third, the gap shrinks considerably if only the triage module is regulated and the rest of the platform is architected as non-device software — which is why modular design is the single most effective cost lever.
Three items are missing from healthcare budgets most often, regardless of device class. The first is clinical experts’ time — doctors, nurses and pharmacists who describe workflows, approve terminology mappings and take part in usability testing. Their hours are expensive and hard to schedule, and without them requirements remain guesswork. The second is test data: realistic but anonymised or synthetic patient data sets, without which integrations and algorithms cannot be tested properly; preparing them can be a small project in itself. The third is integration environments and certification — access to test environments of national platforms and EHR vendors, their schedules and acceptance procedures. In our experience, adding these three items to the plan at the estimation stage is the cheapest way to avoid delays that no development team can make up later.
Timelines follow the same logic. A non-device MVP of this size typically takes 6–9 months. A Class IIa device adds the conformity assessment, which depends on notified body capacity and the quality of the technical documentation. The general budgeting logic for early product versions is covered in our MVP cost guide; for fixed-price contracts in regulated work, read about who really pays for risk transfer first, because regulatory uncertainty is exactly the kind of risk vendors price in.
How do you choose a healthcare software development partner?
A partner for healthcare software needs more than developers who have “worked on a health app”. The checklist below separates vendors that can carry a regulated project from those that will learn on your budget.
| Criterion | What to ask | Red flag | Strong answer |
|---|---|---|---|
| Regulatory literacy | How would you classify this module under Rule 11? | ”Regulation is your job” | Asks about intended purpose before estimating |
| Process maturity | How do you implement IEC 62304 in sprints? | Documentation written at the end | Traceability in the toolchain from sprint one |
| Quality system fit | Can you work within our ISO 13485 QMS, or provide your own? | No experience with design controls | Clear split of QMS responsibilities in the contract |
| Interoperability | Which FHIR profiles and national platforms have you integrated? | ”We do REST APIs” | Named standards, profiles and test environments |
| Security | How do you produce an SBOM and handle vulnerabilities after release? | Security testing only before go-live | SBOM and scanning in CI/CD, post-market monitoring plan |
| Data protection | Where is data processed and who can access it? | Vague answers on location and access | Documented data flows, EU hosting options, access logging |
| Team continuity | What happens if a key developer leaves? | No replacement policy | Replacement guarantee, knowledge transfer, documentation |
| Post-market support | Who maintains the device after CE marking? | Project ends at release | Maintenance and change-control model agreed upfront |
The most revealing question is the first one. A partner who asks what your marketing materials will claim before quoting understands the sector. A partner who quotes from a feature list does not — and the difference will surface four months in, as in the introduction.
Staffing models matter too. Many healthcare organisations keep product ownership, clinical expertise and the quality system in-house and extend engineering capacity with external specialists. We describe that model and the competencies involved in our article on building an IT team for an e-health project, and industry use cases in the glossary entry on body leasing in healthcare.
How can you reduce regulatory risk without slowing product delivery?
Regulation raises the cost of mistakes, not the cost of good engineering. The organisations that ship regulated healthcare software at a steady pace tend to share five habits.
Decide the intended purpose per module, in writing, first. Every later decision — classification, architecture, test depth, marketing — depends on it. Revisit it whenever the product roadmap changes.
Architect for segregation. MDCG 2019-11 recognises modular software: a device module can be separated from non-device modules if interfaces and responsibilities are clearly defined. A regulated triage engine behind a clear interface lets the booking, video and payment modules evolve at normal speed.
Automate traceability and evidence. Link requirements, risks, code changes, tests and releases in the tools the team already uses. Evidence generated by the pipeline is always current; evidence assembled before an audit never is.
Treat integration as a continuous workstream. Start FHIR, CDA and national platform integration in the first sprints, test against real environments early, and budget terminology mapping with clinical input.
Plan the life after release. Post-market surveillance, vulnerability management, AI model change control and EHDS or national platform updates are ongoing work. Staff them as such.
Key takeaways:
- Intended purpose drives everything. One sentence in marketing copy can turn a feature into a Class IIa device.
- Rule 11 places most decision-support software in Class IIa or above, requiring notified body involvement.
- IEC 62304, ISO 13485 and ISO 14971 are compatible with agile — as long as traceability is automated.
- 2027–2031 brings new obligations: EHDS from March 2027 onwards, AI Act high-risk rules for medical AI from August 2028, and possibly a stricter HIPAA Security Rule.
- In our example, regulation added 67% to the build cost, mostly through verification and documentation. Modular architecture is the biggest lever to reduce it.
At ARDURA Consulting we have been building and staffing software teams for clients in Europe, the Middle East and the USA for more than ten years, including specialists for healthcare IT projects. Through our software development services we help healthcare organisations and healthtech companies structure products so that regulated modules stay regulated and everything else moves fast.
If you are planning healthcare software and want a second opinion on classification, architecture or team composition before you commit a budget, talk to our team.