Healthcare systems that must operate continuously

Most of my work has been in healthcare IT, in environments where systems are expected to operate continuously under regulatory, operational and interoperability constraints. This included hospital information systems such as MedSolution and eMedSolution, used in daily clinical practice at all four Hungarian medical universities, as well as national-scale infrastructure related to Hungary’s Egyesített Egészségügyi Szolgáltatási Tér (EESZT). In these environments, failure has real consequences and must be anticipated and handled by design.

Selected system and responsibility: HisCom

One of the defining systems in my career was HisCom, an inter-hospital information system designed to connect independent hospital systems into a shared integration backbone. I designed and implemented this system largely on my own, covering system architecture, integration logic, API design and operational behavior, including patient data exchange, document sharing and cross-institution scheduling, with interoperability as a primary constraint.

The system successfully participated in IHE Connectathon events in 2012 and 2013, first as a client and later as a server, across profiles including PIX, PDQ, XDS.b, XCA and XCPD. Concepts, interfaces and integration patterns developed in HisCom later became part of the foundations for systems related to Hungary’s national healthcare platform (EESZT), and strongly shaped how I think about integration boundaries, responsibility and long-term operability in must-run healthcare environments.

Systems that work as a whole

In healthcare environments, individual components are rarely the primary problem; systems usually fail at the boundaries between them. I have seen systems where each module behaved correctly, yet the overall system was unreliable because responsibilities and assumptions were not clearly defined. For this reason, I design healthcare systems as cooperating parts of a single whole, with backend services, integration layers, APIs and data models designed together so that each part can operate independently while still fitting into a coherent system.

Boundaries, APIs and responsibility

I treat APIs as system boundaries, not merely technical interfaces. In regulated environments, an API defines data ownership, responsibility for failures and how change can be introduced safely. In my experience, many integration problems stem not from missing functionality, but from unclear or implicit responsibility, while clear boundaries allow healthcare systems to evolve without breaking existing integrations even as external partners or standards change.

Ecosystems, not isolated systems

Healthcare systems do not operate in isolation; in my work, they have always been part of broader ecosystems including hospital systems, national services, external vendors, legacy platforms and international interoperability initiatives. Systems I designed and implemented were validated at IHE Connectathon and Projectathon events, both as client and server, across profiles such as PIX, PDQ, XDS.b, XCA and XCPD. In these environments, interoperability is not theoretical: a system either works with unknown partners, or it fails visibly.

Long-term operational sustainability

Healthcare systems often outlive the teams that originally built them, and I have worked on systems that remained in production many years after their initial design. For this reason, I prioritize clarity over cleverness, explicit contracts over implicit coupling, and evolvable architectures over tightly bound solutions. Systems built this way can absorb regulatory, organizational and technological change without constant rework, which is the kind of work I have been doing for most of my career.

Imaging systems under clinical constraints

More recently, I worked as Technical Lead on the Advanced Workstation Server project at GE HealthCare, in a radiology environment with strong DICOM requirements. This work involved formal interoperability testing in the RAD and imaging domain, with systems expected to integrate reliably into existing clinical workflows and operational environments.