Hospital billing interface for direct invoicing

We developed a fully automated hospital billing interface for a company, enabling patient invoices to be exchanged directly between hospitals and aid agencies. The focus was on reliable data exchange, domain-specific validation schemes based on EDIFACT, and handling sensitive health data. The project ran from April 2019 to July 2021 and was delivered by a team of 4 people.

Initial situation

A company needed an interface for the direct settlement of patient invoices between hospitals and aid agencies. The task was to map this exchange in a fully automated way while taking account of domain-specific validation schemes and the handling of sensitive health data.

The key requirements for the project were structured data exchange, validation of incoming and outgoing information, and certificate management. A hospital billing interface of this kind must do more than simply transport data; it must process it in a way that is transparent and understandable from a business perspective.

Solution

We implemented the solution as microservices in C# using CQRS. Microservices are small, clearly defined services that each handle individual tasks; CQRS separates write and read operations so that business processes can be structured more clearly.

Our work covered data exchange and validation schemes based on EDIFACT, certificate management for sensitive health data, and Infrastructure as Code and CI. Infrastructure as Code means that technical environments are built using version-controlled definitions; CI stands for Continuous Integration and supports the traceable merging of changes. The project ran from April 2019 to July 2021 with a team of 4.

Result

The project delivered a fully automated interface for the direct settlement of patient invoices between hospitals and aid agencies. It included the implementation of microservices in C#, data exchange with validation schemes based on EDIFACT, certificate management for sensitive health data, and the technical foundation for structured operations through Infrastructure as Code and CI.

The project was completed after a duration of 28 months.

Technology

• C# and .NET Core for implementing the business services
• Microservices for dividing the solution into business-separated services
• CQRS for separating read and write operations
• Angular for the user interface, where required within the project
• EDIFACT for data exchange and validation schemes
• Azure DevOps to support development and integration processes
• MS SQL Server and MongoDB for data storage

In interface projects of this kind, the combination of web development, database development and a cleanly structured integration pipeline is often crucial.

Why a hospital billing interface is structured this way

A hospital billing interface brings together several requirements: accurate business data, reliable exchange between organisations, and particularly careful handling of sensitive information. That is why the architecture in projects like these is often designed so that business responsibilities are clearly separated and individual parts can be developed further independently. A microservice architecture can be well suited to this, because it divides tasks into self-contained services. This makes it easier to assign business rules and helps changes to be implemented in a targeted way.

Separating read and write operations is also often useful in projects of this kind. The CQRS approach separates the capture or modification of data from making it available for display or analysis. This is helpful when validation rules, approval logic or different views of the same business process need to be represented clearly. What matters for decision-makers is this: the separation is not an end in itself, but a means of structuring complex processes more clearly.

A standardised message format also plays a central role in data exchange. EDIFACT is an established format for the electronic exchange of structured business data. In projects involving billing and service data, such a format helps ensure that content is transmitted unambiguously and can be validated automatically. Validation schemes are equally important: they ensure that data not only arrives in the correct format, but is also plausible from a business point of view.

The protection of sensitive data must also be considered. Certificates are used to provide technical proof of identity and to secure data transmission. However, the organisational and legal requirements that apply in each individual case should always be reviewed with the responsible specialist departments, the data protection officer or legal advisers.

A structured operating approach is also sensible for implementation. When environments are built as defined configurations, changes can be prepared in a more traceable way. When software changes are merged and validated automatically, the risk of avoidable errors is reduced. That is precisely why projects like these often combine interface and database services with clear development and operating processes.

How a project like this typically works

For a hospital billing interface, a project typically starts with business clarification. First, it is necessary to understand which parties send or receive data, which messages are exchanged, and where business validations apply. At this stage, the aim is not only to gather requirements, but also to standardise terminology. This is important because different organisations often use different names for similar content.

The next step is to develop the solution concept. This defines how the business processes are translated into technical components, which data must be stored permanently, and how error scenarios are to be handled. In billing scenarios in particular, it is not enough to model only the ideal path. Handling incomplete, contradictory or formally incorrect data is just as important. For those responsible, what matters at this point is that the project describes not only functions, but also responsibilities and traceability.

During implementation, the business logic, data exchange, validations and technical foundation are brought together step by step. This often includes an integration pipeline for incoming and outgoing messages, storage of relevant data, and tools for development and operations. Continuous Integration means that changes are regularly incorporated into a shared state and validated automatically. This helps a project identify inconsistencies at an early stage.

Before going live, quality assurance and coordination with the parties involved take centre stage. Typical activities include tests with realistic messages, validation of exceptional cases, and checks of technical safeguards. In sensitive areas, it should also be clarified which legal and organisational requirements apply. This includes matters such as data protection, retention and access rules; these topics should be reviewed with the responsible internal departments or with legal advisers.

For companies and public-sector clients, it is helpful to break down a project like this into broad work packages at an early stage. If you want to get an initial view of the scope, you can use the project check or arrange a no-obligation initial consultation. This usually makes it quicker to build a sound picture of which steps make sense for the specific project.

Typical pitfalls in operations, data and interfaces

In projects involving sensitive billing data, the difficulties often lie less in individual functions than in the interaction of many different requirements. One typical pitfall is assuming that a message format on its own is enough to ensure smooth exchange. In reality, it must also be clarified which fields are mandatory, how deviations are to be handled, and which rules apply for feedback or corrections. Without this business-level clarification, later queries and unnecessary chains of errors arise.

Another point is traceability. In automated processes, it must remain clear which message was received, which validations were carried out, and why a case was accepted, rejected or put on hold. This concerns not only the technology, but also operations. Anyone running the system later needs usable logs, clear responsibilities and an approach to incidents that does not rely on improvisation.

Data storage also needs conscious decisions. Relational databases such as SQL systems are well suited to clearly structured data relationships. Document-oriented databases can be helpful when messages or substructures need to be stored more flexibly. In many projects, the important question is therefore not only which database to choose, but also the deliberate allocation of which data is stored where and for what purpose.

For operations, it should be clarified at an early stage how environments are provisioned, how changes are rolled out, and how technical dependencies are documented. Hosting and operations are not just an infrastructure issue, but part of the system's overall responsibility. Especially for interfaces with external partners, it is important that certificates, connections and recurring operational tasks are organised reliably. The specific security measures and legal requirements that are needed must always be agreed with the relevant security, data protection and legal stakeholders.

Our experience shows that projects like these work better when business logic, data exchange and operations are considered together from the outset. If you are planning a similar project, you can use the cost calculator to narrow down the scope initially or discuss with ballmüller solutions, in a no-obligation conversation, which approach suits your organisation.