}

Opening a New Medical Practice: Common IT pitfalls that lead to failure

The bottleneck is not the installation itself, but the chain of licensing, BSNR, eHBA, SMC-B, and external approvals. These dependencies must be resolved before the actual IT project begins.
Read the article
Read the article
back
back

Opening a New Medical Practice: Common IT pitfalls that lead to failure

Author
Philipp Krey
Time to read
6 min
Published
October 2026

When opening a new practice, technology is rarely the actual bottleneck. Servers, workstations, networks, printers, and practice management software can be planned, procured, and installed. The critical path, however, begins much earlier: with licensing, the practice site number (BSNR), and the credentials for the telematics infrastructure. These steps form a serial chain, the sequence of which cannot be bypassed by a larger budget or last-minute prioritization.

The same applies to taking over an existing practice. While the formal situation is different, the operational tasks are comparable. An existing practice management system must be adopted or migrated, the data must be verified, and the existing technology must be reconciled with inventory lists, floor plans, and the actual on-site conditions. Consequently, a supposed new opening often begins with legacy equipment.

IT is waiting on a chain of administrative acts

Before a practice can be fully connected to the telematics infrastructure, several prerequisites must be met in sequence. Licensing is followed by the assignment of the practice site number, or BSNR. This number is essential for subsequent applications because the SMC-B, as the practice ID card, is linked to a specific practice site. If the BSNR changes, a new SMC-B is required; when taking over a practice, the predecessor's card cannot simply be reused.

The SMC-B, in turn, cannot be applied for independently of the electronic health professional card (eHBA). According to Section 340 (5) of the German Social Code (SGB V), at least one service provider at the facility must possess an active eHBA. The Association of Statutory Health Insurance Physicians in Thuringia points out that the KV verifies the data against the physician register before approving the SMC-B application.

This establishes a fixed technical and administrative sequence: the next step cannot be completed without the preceding requirements. For this reason, the eHBA in particular must be planned for early on. The National Association of Statutory Health Insurance Physicians (KBV) recommends allowing several weeks for its delivery.

The chain does not end after the application is submitted. Since April 3, 2023, an additional authentication process, such as PostIdent, is required by the trust service provider (TSP). For security reasons, the card and its associated PIN are sent separately. Both an activated SMC-B and the PIN must be physically present for installation; an order confirmation or shipping notification is not sufficient.

Meanwhile, the IT team can prepare the network, workstations, or the practice management system. However, they cannot technically substitute for the missing identity of the practice site. As long as the BSNR, eHBA, SMC-B, or PIN are missing, the connection remains incomplete.

Supply issues are not just a theoretical risk

The current exchange of health professional and practice ID cards demonstrates that these lead times must be taken seriously. Due to ongoing production and delivery problems at card manufacturers, the gematik has agreed to extend the exchange deadline for affected eHBA and SMC-B cards until June 30, 2026.

When the supply chain is so strained that a nationwide deadline must be postponed, the advice to apply in good time is not just a non-binding planning recommendation. It describes a dependency that lies outside the control of the practice owner and the IT service provider. An ID card applied for too late cannot be compensated for by adding more technicians or an extra installation day shortly before the opening.

The consequences have an immediate impact on practice operations. Without a functional SMC-B, the practice site cannot authenticate itself to the telematics infrastructure. Applications such as KIM and associated communication processes depend on this.

What cannot simply be ordered

In addition to the administrative chain, there is a second group of dependencies that often only becomes visible during the IT project. It concerns the structural and organizational requirements at the location.

Based on our experience with over 100 site openings, a large portion of delays begins with missing or inaccurate baseline information. Floor plans are provided too late, network ports are not located where workstations or medical devices are planned, and the server room is still being used for other purposes during the migration. While the IT service provider can plan based on this, they cannot perform a reliable installation.

This becomes particularly evident when coordinating with electricians. A network switch, an uninterruptible power supply, or a card terminal can be delivered. However, if power outlets, cable runs, or suitable connections are missing, the hardware remains in its packaging. Therefore, floor plans and contractor scheduling must be finalized before the actual IT setup, not during it.

When taking over a practice, the condition of the legacy system is an additional factor. We have seen hardware taken over "as is" without any documentation regarding its function, the software running on it, or who holds the administrative access credentials. If inventory lists and reality diverge, the system must be reconstructed before migration can begin.

A lack of access to the configuration of the old practice management system can block data transfer just as effectively as an undocumented interface. In such cases, the new IT service provider can neither verify which data can be exported nor reliably plan how long the transition will take.

Specialized devices follow their own approval processes

Practice IT consists of more than just standard workstations and office applications. Laboratory equipment, imaging systems, card readers, and other specialized devices often require manufacturer-specific interfaces. Their integration requires that current installation guides are available, necessary licenses are released, and the manufacturer supports the planned configuration.

These processes can only be controlled to a limited extent by the IT service provider. If a license update needs to be approved or manufacturer support needs to be involved first, another external dependency arises. The same applies to changes to KIM addresses or TI connectivity, which are linked to new identities, cards, or practice site data.

In addition, there are requirements that play almost no role in a normal office but are mandatory for individual practice workflows. This can include printing specific forms, for example using suitable printers. If such a requirement is only identified during the first real-world workflow, it is of little help that standard printing and networking are technically functional.

Security applies from the very first day of operation

The new practice does not start with a transitional phase regarding security regulations. The updated IT security directive according to § 390 SGB V has been binding for the contract medical sector since October 2025. It describes requirements for practice IT, while Appendix 5 contains separate specifications for decentralized components of the telematics infrastructure.

As a result, security requirements must be incorporated into the setup from the start. If, for example, shared accounts and a single password for multiple systems are carried over from the previous practice, this conflicts with a controllable authorization model. Individual access credentials must then be set up and tested before the launch.

Such changes do not only affect technology. Employees must know their accounts, be able to perform multi-factor authentication, and understand how to access the required applications. If training is scheduled too late, the environment may be technically ready but not operational.

The same problem arises if no test cases based on real practice workflows have been defined. A general functional test shows whether a workstation can log in and a printer can be addressed. It does not show whether a prescription is output on the correct device, whether a finding from specialized equipment appears in the correct patient file, or whether a KIM message can be processed in its entirety.

Why end-to-end responsibility is necessary

Checklists do not resolve these dependencies on their own. Their value lies in making lead times visible before the IT project officially begins. An item like "apply for SMC-B" is scheduled too late if it is only checked at the installation appointment. It must be included in the overall schedule with its prerequisites, processing paths, and delivery dependencies.

This requires a person who is responsible for the process across administrative acts, construction, medical technology, practice software, and traditional IT. Without this end-to-end view, everyone involved only optimizes their own section: the electrician waits for the floor plan, the manufacturer for the license release, the IT service provider for access data, and the practice for the card delivery.

Based on our project experience, with orderly prerequisites, about four weeks of technical preparation and about one week of closure for the actual transition is a realistic timeframe. These figures are not universal deadlines. Rather, they show how tight the technical window already is and why outstanding administrative or construction issues cannot be accommodated within it.

The IT of a new or acquired practice does not become reliable in terms of scheduling just because the installation starts early. It becomes reliable when the critical path is fully known and the steps that cannot be accelerated are initiated well before the technical setup. Only then can the IT be ready by the planned opening date, instead of waiting for prerequisites that lie outside its project scope.

FAQ: Opening a new practice

When should I start planning the IT?

Planning should begin as soon as the location, acquisition model, and intended opening date are set. The decisive factor is not just the timing of the hardware order, but whether the licensing, BSNR, eHBA, and SMC-B are initiated early enough. Since several weeks must be planned for the eHBA and subsequent steps build on it, this chain must not wait until shortly before the opening.

Can the SMC-B be applied for in parallel with the eHBA?

Not entirely. To apply for the SMC-B, at least one service provider at the facility must be the holder of an active eHBA. The steps are therefore dependent on each other and cannot be handled in parallel like two ordinary hardware orders.

Can I continue to use the SMC-B from the acquired practice?

A new SMC-B is required for a new practice site number. The old card is assigned to the previous practice site and must not simply be transferred to the successor in the event of a change of ownership.

Which documents does the IT service provider need first?

Reliable floor plans, an up-to-date inventory, information on practice software and specialized equipment, and administrative access to the legacy system are needed early on. When taking over a practice, it should also be clearly defined which data, devices, and contracts are actually being transferred. Without these foundations, any technical planning remains provisional.

Is a technical test shortly before opening enough?

A simple functional test is not enough. Specific workflows must be checked, such as registration, patient intake, access to legacy records, prescription and document printing, specialized equipment integration, and TI and KIM processes. Test cases should be derived from actual day-to-day practice operations and run through by staff before the opening.