Industries · Healthcare

Healthcare software development with security built in

Our healthcare software development covers systems for healthcare providers, patient portals and integrations with electronic medical records - with the level of security that health data requires. We take into account the GDPR, the confidentiality of patient information under Polish law, the obligations of the Polish KSC Act and accessibility requirements, and our penetration testers check every system before it goes live.

Let's talk about your project Health data in your system

01Challenges

Healthcare software development: what makes it different

Healthcare software processes data that enjoys the strongest protection in law: health data is a special category of personal data, information about patients is confidential, and medical records must be available whenever they are needed for treatment.

That is why, in these projects, non-functional requirements - security, system availability, an audit trail of data access and business continuity - matter as much as features.

We build systems that complement core hospital and clinic systems:

patient portals and apps - appointment booking, test results, documents, communication,
internal systems for healthcare providers - document workflow, rotas, orders, reporting,
integrations - between a provider's own systems, laboratories, partners and the Polish e-health platform,
analytics tools - working on pseudonymised data, with access control.

For integrations we use the patterns described on our system integration page, and we build patient apps in the same way as our mobile and web applications.

02Health data

Special category data and patient confidentiality

Illustration: health data in a separate zone, with authorisations and an access log.

Data concerning health is a special category of personal data; processing it is prohibited in principle unless one of the exceptions listed in the Regulation applies (Art. 9(1) and (2) GDPR).
One of the exceptions covers medical purposes: preventive or occupational medicine, medical diagnosis, the provision of health care or treatment and the management of health care systems and services, subject to professional secrecy (Art. 9(2)(h) and (3) GDPR).
An impact assessment is required in particular for large-scale processing of special categories of data, such as data concerning health (Art. 35(3)(b) GDPR).

Polish Act on Patient Rights

Patients have the right to confidentiality of information about them obtained by persons practising a medical profession (Art. 13 of the Act on Patient Rights and the Patient Ombudsman).
A healthcare provider keeps, stores and makes available medical records and ensures the protection of the data they contain (Art. 24(1) of the Act on Patient Rights and the Patient Ombudsman).
Persons who maintain the ICT system holding medical records and ensure its security process the data on the basis of the controller's authorisation and are bound by secrecy, even after the patient's death (Art. 24(2)(2) and (3) of the Act on Patient Rights and the Patient Ombudsman).
An entity entrusted with processing data from medical records is bound by secrecy, and the performance of the data processing agreement must not disrupt access to the data, which must remain available without undue delay (Art. 24(5)-(6) of the Act on Patient Rights and the Patient Ombudsman).

03Integrations

Electronic medical records and the Polish Medical Information System

Healthcare service providers are required to keep electronic medical records (Art. 11(1) of the Act on the Healthcare Information System).
Healthcare service providers submit medical event data to the Medical Information System (SIM) - an obligation that has existed since 1 July 2021 (Art. 11(3) and Art. 56(2a) of the Act on the Healthcare Information System).
Prescriptions and referrals, and data on their fulfilment, are entered by the service provider into SIM in real time and, after a platform failure, no later than 3 days after it has been resolved (Art. 11(5)(1) and (5a) of the Act on the Healthcare Information System).
The colloquial name “P1” refers to the Electronic Platform for Collecting, Analysing and Sharing Digital Resources on Medical Events - an ICT system operated under the Act (Art. 7(1) of the Act on the Healthcare Information System).

The systems we build for healthcare providers rarely replace the clinic or hospital system - more often they complement it: a patient portal, document workflow, reporting. That is why we design integrations so that health data has a single source of truth and every transfer is recorded in a log.

We test integrations with external systems for security in the same way as APIs - the scope is described on our API penetration testing page.

04NIS2/KSC

NIS2 and the Polish KSC Act in healthcare

Healthcare is a sector listed in Annex 1 to the Polish National Cybersecurity System Act (KSC Act) - medium-sized and large entities in this sector are, as a rule, important or essential entities (Art. 5(1)(1) and (2)(1)-(2) of the KSC Act). The competent authority is the minister responsible for health (Arts. 41 and 41a of the KSC Act).

The obligations include an information security management system, incident reporting and - for essential entities - an audit. The status of independent public healthcare institutions (SP ZOZ) and of hospitals run as companies, the competent authority, the CSIRT and the deadlines are described on our NIS2 and the KSC Act in hospitals page, and you can check the status of your facility with our NIS2 scope checker.

For a software vendor, this means that the healthcare provider will assess the security of the vendor's systems as part of its supply chain. We help the provider demonstrate this with:

penetration tests before go-live and after major changes,
a description of safeguards and data flows based on the threat model,
vulnerability management as part of maintenance,
answers to vendor security questionnaires.

05Accessibility

Accessible systems for patients

Polish accessibility rules for the public sector, including public healthcare:

The Digital Accessibility Act covers, among other bodies, public finance sector units - including independent public healthcare institutions (Art. 2(1) of the Act of 4 April 2019; Art. 9(10) of the Public Finance Act).
Websites and applications of public entities meet the WCAG 2.1 requirements at levels A and AA set out in the annex to the Act; meeting clauses 9-11 of EN 301 549 V3.2.1:2021 means compliance (Art. 5(1) and (3) and the annex to the Act of 4 April 2019).

Many patients are older people, have visual or hearing impairments, use screen readers or browse on a phone with heavy magnification. We design interfaces to WCAG 2.2 level AA and check them both with tools and manually - as described on our web applications page.

06Security

Securing medical systems in practice

Authorisations and logging

Access to health data only for authorised roles, with a log of who viewed or changed which data and when.

Encryption and backups

Encryption in transit and at rest, and backups in the EU with tested restores - records must be available whenever they are needed.

Testing before go-live

A penetration test of the application and its integrations before launch, with a retest of fixes - as part of our secure by design lifecycle.

The whole process is described on our secure by design page. If a healthcare provider uses systems from other vendors, we can test their security too - see web application penetration testing.

Frequently asked questions

Can a vendor's IT staff access medical records?

Yes, but under strictly defined rules: under Polish law, the people who maintain a system holding medical records and keep it secure process the data on the basis of the controller's authorisation and are bound by secrecy, also after the patient's death (Art. 24(2)(2) and (3) of the Act on Patient Rights and the Patient Ombudsman). That is why we grant access to named individuals only, on a least-privilege basis and with an event log.

Do we need to carry out a data protection impact assessment?

Large-scale processing of health data requires an impact assessment (Art. 35(3)(b) GDPR). We help prepare its technical part - a description of data flows, safeguards and risks - because it follows naturally from the threat model of the system.

Do you integrate systems with the P1 platform?

We design integrations between healthcare providers' systems and their environment, including the health data flows required by the Polish Act on the Healthcare Information System. Service providers keep electronic medical records and submit medical event data to the Medical Information System (SIM) - in Poland this is often called “integration with P1”, after the platform defined in Art. 7 of the Act. We agree the scope of the integration with the vendor of the clinic or hospital system the provider uses.

Is a hospital subject to the Polish National Cybersecurity System Act?

Healthcare is a sector of high criticality listed in Annex 1 to the KSC Act, and the status of an entity depends on factors including its size. You will find who the rules cover and which deadlines apply on our NIS2/KSC audit page.

Does a patient app have to be accessible to people with disabilities?

Public healthcare providers in Poland, such as independent public healthcare institutions (SP ZOZ), are subject to the Polish Digital Accessibility Act and to WCAG 2.1 level AA. Whatever the legal obligation, we design interfaces to WCAG 2.2 AA - many patients are older or have impairments.

Sources

Legal status as of 9 October 2026 Updated 9 October 2026

Related services

Compliance · NIS2/KSC

From Innovix Insights

Software

How to choose a software development company: an RFP checklist for large organisations

8 October 2026 13 min read