Interview: "Digitalization in Healthcare is not failing because of IT"

Why it's not technology that's holding back the healthcare sector, but politics and legislation, explains ITSG CEO Stefan Haibach in our interview.

listen Print view
Wimmelbild, how ITSG works

(Image: ITSG GmbH)

8 min. read

The digitalization of social security largely runs in the background – where hardly anyone looks, but almost everything depends on it. One of the central players is the Information Technology Service Center of the Statutory Health Insurance Funds (ITSG). For almost three decades, it has been organizing and operating the technical foundations for data exchange between health insurance funds, employers, and service providers.

Stefan Haibach, CEO of ITSG since July 1, 2022, knows this engine room from his own experience. After his time as a health insurance administrator, Haibach has been working at ITSG since 2008, most recently for a long time as head of department for the digitalization of specialist procedures. In an interview with heise online, he explains why Germany's digitalization problems are rarely technical in nature, why the Once-Only principle fails due to legal definitions, how much open source actually brings – and why AI cannot save administration but can relieve it.

Stefan Haibach has been working for statutory health insurance for over 40 years.

(Image: ITSG GmbH)

Could Germany be much further along digitally if it wanted to be?

Yes. The technology is there in many areas. For years, we have been operating highly critical systems with millions of data exchange transactions daily – highly available, redundant, BSI-compliant. A good example is the electronic certificate of incapacity for work (eAU). We provide central components for data exchange between doctors, health insurance funds, and employers. The eAU shows that digitalization can work technically if it is implemented consistently.

We operate our data centers for this and other procedures in Germany, with high availability and designed so that central applications continue to run even if one location fails. Databases run synchronously, systems remain online in parallel.

Videos by heise

For us, digital sovereignty means not only that data physically remains in Germany. It also means that we bear the operational responsibility ourselves – and are not dependent on individual cloud or platform providers.

Digital sovereignty is becoming more important than ever due to the political situation. Are you also relying on open source?

Yes. A significant part of our infrastructure already runs on Linux systems – servers, network components, security services, operating platforms. This is not a pilot operation, but productive everyday business.

Our goal is not to demonize proprietary software across the board. But where it makes technical sense, we want to systematically reduce dependencies – especially for operating systems, container platforms, middleware, and, in the future, also for databases and office-related systems.

Is open source really cheaper in the end?

Open source is not free. You have to invest in people – in operation, training, and know-how. But in the long term, proprietary license models are often significantly more expensive, especially when they are tied to cloud usage or scaling.

And fundamentally: if something doesn't work, it's rarely due to a lack of IT skills, but rather to structures, laws, and the fact that we try to regulate every conceivable special case in advance.

What do you mean by that specifically?

We want to clarify everything before starting: every special case, every legal distinction, every eventuality. This leads to projects starting while they are effectively still in test operation – with political deadlines that have nothing to do with reality.

Other countries test under real conditions, learn from mistakes, and iterate quickly. In Germany, however, top-down legislation dominates. A positive example of a project to which the open source community also contributed significantly was the Corona warning app. That worked. We need more open test phases with feedback loops. If a project develops in the wrong direction, it should be quickly reversed. We often lack this culture.

The Once-Only principle has not really progressed in administration for years. Why?

Not because we couldn't build interfaces. But because we don't agree on common terms. A classic example is the "child." In social security, a child is counted differently than in tax law – foster children, children who died after birth, stepchildren.

Technically, we could exchange this data without problems. Legally, we cannot do so meaningfully. The result is bureaucracy: for the care contribution, employers ultimately had to manually report the number of children again, even though the data already exists. This is not an IT failure, it is legislation without digital thinking.

Another recurring topic is digital identities. Why are there so many?

Because each solution emerged in isolation: Bund-ID, ELSTER certificate, and so on – but no overarching architecture. The electronic identity card is technically sound, but cumbersome to use. Anyone who has used it with a smartphone knows how impractical it can be in everyday life.

Could the EUDI Wallet change that?

Yes. A wallet that holds the identity directly in the device is technically sensible. But then you have to be consistent. I honestly ask myself: Why is a reference implementation needed and then a market? Only a state authority prints an identity card. Identity is infrastructure, not a competitive field.

Many health insurance funds are increasingly using AI to process applications or as chatbots. How do you assess the AI boom?

It's not AI itself that is dangerous, but the expectations. Wherever there are clear rules, classic algorithms are faster, cheaper, and safer. Calculating a contribution statement with AI makes no sense.

AI brings real added value in support: for unstructured inquiries with many variations, but few correct answers. It is important that the AI works with verified data and does not research on the open internet.

Anyone who is sick wants one thing above all: an appointment. What role does digital appointment scheduling play in the planned primary care system?

Anyone who is sick doesn't want a marketplace or app experiments, but a medically sensible appointment as quickly as possible. That's precisely where the system often fails today. Appointments are hard to get, existing offers are fragmented, and those with statutory insurance often have worse chances.

Therefore, we consider a common, neutral backend for appointment scheduling to be sensible – accessible both digitally and by phone via 116 117. All channels must access the same data basis. Operating such highly available, neutral infrastructures is clearly part of our core competencies. From our perspective, appointment scheduling is part of public services – not a market game.

Do you have enough people for implementation?

That is one of the biggest challenges. We are continuously looking for specialists – developers, architects, IT security specialists. Many do not know ITSG, even though the tasks are highly relevant and technologically demanding. Ultimately, digitalization does not fail because of servers or software, but because there are enough qualified people to build, operate, and further develop these systems.

Are data protection and practical digitalization contradictory?

No – but different interpretations are. Data protection itself is not the problem. It becomes problematic when a project is assessed differently in Bavaria than in Schleswig-Holstein or by the Federal Data Protection Commissioner. Then data protection effectively blocks digitalization.

Especially with central care functions such as appointment scheduling, clear responsibilities and binding interpretations are needed. This would ultimately also strengthen the trust of citizens.

(mack)

Don't miss any news – follow us on Facebook, LinkedIn or Mastodon.

This article was originally published in German. It was translated with technical assistance and editorially reviewed before publication.