Diagnostic processes do not forgive imprecision. We develop and operate software for laboratories, medical care centres and diagnostics providers, from process design through to productive routine operation.
8 specialists on the team
Our team of thirty includes several specialists with many years of experience in laboratory and practice IT.
Our clients
Our clients include laboratories, medical care centres (MVZ) and practices at numerous sites across Germany, among them the Academia Gruppe.
Strong partners
Our systems run with large certified partners such as T-Systems, OVH and MS Azure.
An eye on what comes next
We are appearing as a speaker on alternative sampling at the Roche Laborforum 2026.
→ Programme of the Roche Laborforum 2026 (external link, opens in a new tab)
Several sites, systems that have grown over time, shared analytics and differing medical responsibilities: we work in the places where individual laboratories are meant to become a functioning network. We take care of process harmonisation, site connectivity and network-wide analysis.
Gaps open up between the practice management system, the requesting-physician portal, appointment scheduling and patient communication, and in daily work people close them by hand. We build the connections that replace that manual effort, and we align them with how a practice actually works rather than with the data model.
Anyone bringing tests, devices or diagnostic procedures to market needs the IT around them: order entry, sample identification, transmission of findings, integration with their customers' systems. We take on that part, from design through to operations.
Platforms and applications that process medical data and have to scale, integrate and withstand scrutiny from the outset. We support such products technically and in regulatory terms, in several cases as a co-founder as well.
Before software comes into being, the process has to be right. We design diagnostic workflows together with the people who carry them out every day, and on that basis we build systems that hold up as load grows and requirements change.
Typical tasks: process assessment and target architecture, order and sample control, requesting-physician portals, replacing legacy systems while operations continue.


A large part of the work in medical IT lies between the systems, not inside them. We connect laboratory and practice management systems, devices, portals and specialist applications through the established standards of the field.
Standards: LDT 3.x, HL7 v2 and FHIR, GDT and xDT, LOINC, DICOM, POCT1-A; in addition, project experience with KIM-based communication.
Deriving reliable figures from distributed sites requires that catalogues, units and methods have been brought together, and that whatever cannot be compared is made visible. We design foundations of this kind and build analytics layers on top of them.
Typical tasks: data harmonisation, business intelligence for laboratory networks, analyses without unnecessary data disclosure and with pseudonymisation, locally operated AI models.


A system in diagnostics is not finished at go-live; that is where its actual task begins. We operate our solutions ourselves, in German data centres, with the contractual and organisational requirements that processing patient data brings with it.
Typical tasks: operations and monitoring, permission models that follow the legal structure, questions of classification under the MDR and IVDR, data protection and data processing agreements.
Design and architecture are usually not the problem. Projects in diagnostics fail on details that only become visible in production. A selection of the places where we work regularly:
Orders that cross system boundaries. An order is rarely to be found in one system alone. Add-on requests, partial cancellations, additional analyses arising from the findings and sender details corrected after the fact all have to remain consistent across several systems. We identify and model challenges of this kind in the early phases of a project.
LDT dialects that are formally compliant and practically incompatible. The standard leaves room for interpretation, and every manufacturer uses it differently. In practice, interoperability therefore means one profile per counterpart, documented deviations, and test cases that also cover the special characters and field lengths that actually occur in daily work.
Sample identification with several parties involved. When a requesting physician serves several laboratories in parallel, or samples are collected outside a medical setting, barcode namespaces and number ranges collide. The assignment has to remain unambiguous without anyone on site having to keep a rule in their head.
Reporting back on samples that cannot be analysed. Haemolysis, insufficient volume, the wrong tube, pre-analytical time exceeded. The information about it only becomes valuable once the requesting physician can derive an action from it, at the right moment and through the right channel.
Multi-tenancy across a network. Several sites, separate operating locations, shared analytics, differing medical responsibilities. Permissions have to follow the medical and legal structure, not technical convenience, and they have to be changeable as soon as those structures change.
Replacing legacy systems while operations continue. A laboratory cannot be brought to a halt. Migration means parallel operation, comparable results from both systems, a fallback path, and a maintenance window that fits into everyday operations.
Interoperability in diagnostics is rarely a question of the standard, but of how it is interpreted. We work with the established formats of the market and treat manufacturer-specific deviations from them as a task in their own right: documented profiles per counterpart, traceable deviations, test cases drawn from real data.
We have implemented integrations with the common laboratory and practice management systems in production, as well as with communication servers, device interfaces and requesting-physician portals. Which systems are running in your landscape is something we clarify in the first conversation - as a rule, we already know them.
Software in diagnostics is not finished at go-live. We operate our solutions ourselves and over years, in German data centres, under the requirements that processing patient data brings with it.
We operate in T-Systems data centres in Germany as well as at several European locations of OVH and MS Azure, and we have been a project partner there for years. On request, data storage remains within German jurisdiction, without recourse to US hyperscalers. The systems we use are ISO 27001 certified and BSI C5 attested. On request we also operate on premise in our clients' infrastructure, for example for systems with locally processed AI.
Our understanding of operations includes monitoring and alerting, maintenance windows that fit laboratory operations, fallback paths during migrations, and permission models that follow the legal and medical structure of a network.
The processing of health data may be subject to Art. 9 GDPR and, for clients bound by medical confidentiality, to § 203 of the German Criminal Code (StGB). Our data processing agreements are drafted accordingly.
Not every piece of software in diagnostics is a medical device, and the question of where the line runs determines the effort, timeline and cost of a project. We are glad to clarify it right at the start. In several of our systems the scope of functionality is deliberately kept such that no intended purpose within the meaning of the MDR or IVDR arises, because for that particular use case this was the more workable solution. Where classification as a medical device is unavoidable or intended, we say early on what that means in terms of processes, documentation and evidence.
We work with documented development, test and release processes, versioning, traceability of changes and handover documentation.
Behind our medical IT projects stand Matthias Piksa and his team: a core of developers and architects with many years of experience in laboratory and practice IT, embedded in a company of around thirty people. This constellation is intentional: depth of expertise in diagnostics, and behind it the breadth of a firm that also delivers IoT, embedded systems, data architecture and cloud operations in house. Many requirements in medical IT turn out in the end to be questions of integration, devices or infrastructure, and we do not have to bring in anyone externally for them.
We work in small, stable teams. Whoever designs a project stays with it through to operations. In the design phase, Matthias Piksa is personally available as a contact as well.
We do not take our medical expertise from literature or theory: in the joint venture Vytal we develop together with Dr. med. Harald Krebs, specialist in transfusion medicine and haemostaseology with an additional qualification in medical informatics, and Dr. med. Michael Schleef, specialist in transfusion medicine and in laboratory medicine, both co-founders of the Sonnen-Gesundheitszentrum in Munich. This collaboration shapes how we understand diagnostic processes, outside Vytal as well.
→ Vytal - medical AI (external link, opens in a new tab)
You have an undertaking that is larger than a feature: a new system, the replacement of a legacy system, bringing several sites together. We take it on from process assessment through architecture and development to operations, in stable teams and, if you wish, over months and years.
What you need first is clarity: about your interface landscape, about a target architecture, about a vendor or make-or-buy decision. We assess, structure and document. You then decide who implements the project.
Interoperability check — for example a two-day joint workshop at a fixed price. A survey of your interfaces and handovers, breaking points named, a prioritised list of measures with effort estimates. A document you can carry on working with, even without us.
Tell us where you see room for improvement. We will tell you whether we are the right people - and if not, who you should ask instead.