About the Role
About the role
We are reshaping how patients and hospitals deal with each other. Behind that is a lot of unglamorous engineering: because none of it works unless our software can talk to the systems the hospital already runs.
We are looking for experienced Senior PHP/Symfony engineers to join a long-term eHealth initiative building and improving the software used inside hospitals and healthcare organisations. You will work on complex, business-critical applications where stability, maintainability, performance and clean engineering practices are essential. This is a hands-on development role for engineers who are comfortable working independently, discussing technical decisions and contributing as senior members of a team.
We have an ongoing need for strong PHP/Symfony engineers, so this is an opportunity for long-term cooperation on an established healthcare technology platform.
The team
You would join INTOP, the integration team behind the platform. INTOP owns everything that sits between the hospital's own systems and the patient-facing products: the services that receive, translate and deliver clinical and administrative messages, and the connectors built for each hospital system we onboard. It is a small, friendly, senior group of engineers with end-to-end ownership: the same people design an interface, ship it, and are on the call with hospital IT when it misbehaves.
What you will actually do
Design and build backend applications and services in modern PHP and Symfony: clean, testable, well-structured components that other people can pick up.
Build and own integrations with hospital systems: HL7 v2 over MLLP, FHIR, DICOM, plain REST, and the occasional vendor-proprietary format that exists only in one hospital's basement.
Read specs and reverse-engineer reality. Vendor documentation is sometimes optimistic. You will work from message dumps, capture files and calls with hospital IT to establish what a system really sends.
Make integrations operable. Reconnect logic, idempotency, retries, timeouts, backpressure, structured logging.
Modernise what is already there. An established platform has history. You will improve it incrementally.
Work to GDPR and healthcare security requirements as a design constraint.
Touch the frontend when the feature needs it: mostly Twig and some JavaScript. You do not need to be a frontend engineer, but you should not need someone else to render a page.
Shape the technical direction, not just the ticket: set the bar in code review and architecture discussion, raise what needs rebuilding, and help decide what the next quarters look like.
Own tasks end to end, from analysis through implementation to production behaviour.
What we work with: hospital systems
Hospitals do not run one system. They run a HIS (Hospital Information System — the administrative and clinical core: patients, cases, admissions, discharges), usually a RIS and PACS for radiology, a scheduling module, an ERP, and years of local customisation on top. These systems talk through healthcare-specific protocols.
HL7 v2 is the workhorse of hospital messaging: pipe-delimited messages, usually over raw TCP framing.
FHIR is the modern, REST-and-JSON successor to HL7 v2.
DICOM is the standard for medical imaging and the metadata attached to it.
Vendor-proprietary interfaces include CSV drops, SOAP endpoints, ERP-specific formats, and things that predate all of the above.
You are not expected to know these on day one. Most engineers do not — they are learned on the job, and we will give you the time and the people to learn them. What matters is that the idea of decoding somebody else's message format sounds interesting rather than tedious.
Must-haves
6+ years of professional PHP experience.
3+ years of hands-on Symfony (DI, console, events, HTTP kernel) or a comparable PHP framework.
Strong experience developing and integrating REST APIs.
Demonstrable external-systems integration experience: you have built and operated interfaces for systems you did not control.
Fluency with the failure modes of distributed integration: partial delivery, duplicates, ordering, silent schema drift.
Doctrine ORM and solid MySQL/MariaDB knowledge: schema design, indexing, and knowing when the ORM is the wrong tool.
SOLID, design patterns and clean architecture.
Experience writing unit and integration tests.
Confident with the Linux shell and Docker.
Strong debugging discipline, including log correlation across process and system boundaries.
Proactiveness: you raise risks, gaps and bad assumptions early instead of waiting to be assigned the next ticket.
A user-first mindset: the people at the other end are patients and hospital staff, and pragmatic, well tested code is what protects them.
Fluent English, written and spoken: all technical discussion, review and day-to-day work happens in English.
Nice-to-haves
HL7 v2, FHIR, DICOM, or hands-on work with a HIS.
Previous work in healthcare, eHealth or another regulated domain (medical devices, finance, or comparable).
Experience with other business-critical or data-sensitive platforms.
Twig and enough JavaScript to be useful at the edges of a full-stack team.
PHPStan and Psalm, or comparable static analysis at a strict level.
DevOps and deployment experience: CI/CD pipelines, infrastructure work, server administration (Linux, Apache, nginx), MariaDB/MySQL operations.
Experience modernising or upgrading legacy PHP/Symfony applications.
Working with JIRA in an Agile/Scrum environment.
Productive use of AI coding assistants (Claude Code, Codex or similar): you know where they genuinely accelerate work and where their output is a first draft, not a merge candidate.
Our stack
Backend: PHP 8.x, Symfony 7.x, Doctrine ORM
Healthcare protocols: HL7 v2, FHIR, DICOM
Data: MariaDB, MySQL
Frontend and templating: Twig, JavaScript
Quality: PHPUnit, Psalm, PHPStan, PHP CS Fixer, automated architecture checks
Infrastructure: Docker, Linux, CI pipelines
How we work
Small team with direct ownership: including talking to the people whose problem you are solving.
Every change goes through review, static analysis and the test suite.
Architecture decisions are written down and argued before they are merged.
AI assistants are part of daily work here, not a policy debate. We expect engineers to use them where they genuinely speed things up, and to review their output like any other first draft.
We value engineers who challenge ideas constructively and explain their reasoning, rather than working purely from predefined specifications.
Hiring process
The hiring process consists of three stages: technical screening questions covering your experience, PHP/Symfony knowledge, REST API development and relevant projects; a technical interview focusing on your previous experience, technical decisions you made, Symfony/PHP knowledge and your approach to engineering problems; and a coding challenge — a practical exercise on a problem close to the actual work. We do not use algorithm puzzles unrelated to the job.