Skip to content

Digital
Health
Applications

DIGA DEVELOPMENT

We support you in planning, implementation, approval and operation of your DiGA .

DiGAs can provide patients with the best possible treatment and simplify their daily lives. The applications can be reimbursed by the statutory health insurance as digital health applications. For this purpose, the Digital Health Care Act (DVG) was passed and came into force on 19.12.2019. The aim is to improve the care of the insured through an even more data-driven healthcare. This is often referred to as "App on prescription" - one of several building blocks on the way to a system that can be used by patients, doctors and scientists. The aim is to use the data collected to enable the best possible care and research into diseases and other limitations.

We develop medical apps and backends for you that can optionally interact with body sensors or diagnostics.

We meet the strict requirements for medical devices and the regulatory requirements of the fast track procedure for digital health applications (DiGA) in accordance with § 139e SGB V.

Planung

Planning

We discuss your current situation and your short, medium and long-term goals.

We bring the experience of several DiGA implementations into the planning. Thus, we address necessary topics regarding approval, DSGVO compliance, app store reviews, security and interoperability at an early stage.

In this way, we avoid risks, reduce costs and accelerate the development.

Entwicklung

Development

Do you already have a development team that you would like us to support and advise on the way to a DiGA? Or are you looking for a rehearsed team of experts to bring your idea of a DiGA to life?

We offer the expertise of a rehearsed team of software developers who have implemented multiple DiGAs.

For many DiGA challenges we have proven solutions. For topics such as DiGA billing and penetration tests we have ready-made solution components.

Zulassung

Approval

The path to approval includes a large number of requirements, which are carefully reviewed by the BfArM after submission. Since we have already gone through this process several times together with our customers, we know what is important here.

We regularly inform ourselves about relevant changes in the legal situation and incorporate this knowledge into the development process.

We can cover the topics of software quality, privacy, interoperability and security of the fast-track process for you.

Betrieb

Operation

After inclusion in the DiGA directory, their application finds its way to physicians, patients, and scientists.

We develop in such a way that, if desired, you can take over operation and maintenance independently and no unwanted dependencies arise.

We develop in such a way that, if desired, you can take over operation and maintenance independently and no unwanted dependencies arise.

In addition, we also offer to take over operation and maintenance for you completely.

Our team is well-rehearsed and has already developed various DiGAs from planning to approval.

FIRST CONSULTATION

Get to know us and our principles in a short conversation!

REFERENCES

Digital Health Applications (DiGAs) developed by us

Apps

Get to know us and our principles in a short conversation!

The front end is the part of the system that is visible to patients, physicians, scientists, and other users and enables interaction.

We regularly use Flutter as technology to create native apps. This has the advantage that code only needs to be written and maintained once - with corresponding cost and time benefits. Also deep hardware integration, the use of native code or the use of Bluetooth Low Energy for communication is no problem.

Accessibility

The DiGAV requires that apps be usable by people with various physical impairments.

We consider switching tohigh contrast rendering, dynamic scalability of text and user interfaces and screen reader functionality from the very first minute.

Multilingualism

We prepare apps for multilingual usez from the very first hour. This does not cause any additional effort.

We provide a user-friendly website for creating translations and customizing texts so that they can be easily customized by you or professional translators even during the development process.

Studies

To be submitted as a DiGA, a positive care effect evidence-based must be demonstrated.

We regularly implement study modes so that the app can be used not only as a DiGA, but also to gather study data.

We integrate configurable questionnaires and send them regularly with collected usage and measurement data to a cloud system for analysis.

An integration into study management systems is possible via API.

User Experience

The DiGAV requires that the app store guidelines of Apple and Google are adhered to. If the design guidelines are deviated from, the usability must be proven via user studies.

Our rehearsed team of experts includes UX designers who have designed various DiGAs and other health applications.

 

Hardware

Connection of body-related sensors or of medical technology for diagnostics.

Bluetooth Low Energy

Bluetooth Low Energy

We like to use Bluetooth Low Energy for hardware connectivity

Schnittstellen

Interfaces

It is possible for us to connect existing (also proprietary)interfaces (also proprietary), or to realize a new interface.

White Label

Custom or White Label

We are able to connect purchased, ready-made hardware. We are also adept at connecting to own developed hardware.

Interoperabilität

Interoperability

The DiGAV prescribes interoperability in hardware. We explain how you can meet this requirement optimally and cost-efficiently.

Verschlüsselung

Encryption

The DiGAV requires that sensor technology and diagnostics only communicate with companion apps via encrypted channels. We have already successfully implemented this several times.

Authentication

Authentisierung

The DiGAV requires that apps and sensors authenticate each other. We have proven strategies for both in-house developed hardware and purchased ready-made hardware.

Security

Penetration testing,mitigation and permanent hedging.

Pentest

The DiGAV requires that the security of the solution be verified by a penetration test, the results documented and weaknesses eliminated.

We follow the Best Practices of the German Federal Office for Information Security (BSI) and the Open Web Application Security Project® (OWASP).

Mitigation

We evaluate the data obtained from the pentest, suggest options for mitigation and, of course, are available to implement the required hardenings.

Our knowledge spans many levels of software systems, from application configuration to cluster setup to the introduction of new network components.

Automation

After acute vulnerabilities have been eliminated, it is important to maintain this state in the future. Therefore, we mainly rely on reproducible and automatable processes, which are recurrently executed and promptly draw attention to possible vulnerabilities.

Constant Analysis

In addition to manual analysis, we use a whole range of automated vulnerability scanners. These range from static code analysis in the SAST area to black-box vulnerability scans (DAST) and automatic analysis of all third-party libraries used. In the process, the software libraries used are checked against international vulnerability databases (e.g. NIST NVD).

Cloud

Backends for data storage, user management, billing and studies.

Kubernetes

We rely on Kubernetes to orchestrate Docker-based backends. We create and operate the clusters ourselves on European hosted infrastructure.

Location Germany

The BfarM requires the use of DSGVO-compliant infrastructure. Due to recent rulings of the ECJ on the EU Privacy Shield, a use of American service providers is not permitted. We therefore use data centers of German providers.

Certificate Management

The certificates required for transport encryption are generated and extended automatically with proven standard components.

Auditability

The DiGAV requires that the modification of personal data is traceable. We use standard components to version records in databases.

Separation of accounting / data management

The DiGAV stipulates that health data must be kept separately from personal data. The processing must be organisationally separate. We offer established solutions for this.

Deletion concept

Data must be deleted or anonymised at the request of the user. At the end of retention periods, data must be reliably deleted. Again, we bring experience from various DiGAs to the table.

Identity Management

The BfarM requires the use of standardized authentication components.

We offer a proven architecture based on a standardized OAuth2 & OpenIdConnect authentication server.

 

Access Management

The permission management can be fine-grained based on roles, resources (e.g. studies), user groups and access vectors (app/web/API).

Individual users, groups or even APIs can be specifically granted or denied access.

We recommend a proven model that strikes a meaningful balance between power and complexity.

User management

The authentication components we recommend include web-based user management that can also be used by Customer Support.

Email verification, password resets, maintenance of personal data and license management are covered by standardized and cryptographically secured workflows.

Billing

Validation, submission and billing of DiGA codes as a service.

DiGA Abrechnung

After the attending physician prescribes a digital health app, the patient receives a DiGA unlock code from their health insurance company.

The app validates this code and then allows access to the health app functions.

For validation and billing, each statutory health insurance company offers an API. Thus, over 200 APIs with partly different, from the standard different implementations, must be addressed.

For uncomplicated connection to the billing systems, we operate a service that consolidates the connection to the billing systems and thus saves considerable time and costs.

Interoperability

The DiGAV requires that patients be able to have their information stored in the DiGA in an interoperable format.

Interoperable

In the context of medical applications, interoperability means that the consumer of a data set can fully interpret not only syntactically, but also semantically. This also requires medical terminology that unambiguously associates the data. This includes, for example, SNOMED-CT or LOINC.

Units used must also be clearly described, for example with UCUM.

HL7 FHIR

A homegrown data exchange format using CSV, JSON, or XML is regularly insufficient for the requirements of a DiGA.

HL7 FHIR has proven itself as a proven format of interoperable data exchange and is used as the export format by the vast majority of listed DiGAs.

We use industry-standard tools to create this format and, of course, can handle integration into your app if you wish.

Registries

To enable a frictionless exchange of data a publication of the defined exchange formats is required.

In the universe of HL7 FHIR this is done by so-called registries, which centrally hold a very large variety of exchange formats.

We take care of the listing in the common registries such as Simplifier and arrange for the entry in the vesta interoperability directory of the Gematik. The vesta listing is a mandatory requirement for approval as a DiGA.

Automation

Long-term efficiency and maintainability through high automation

Tests

We rely on automated software tests to ensure the quality of apps and backends at all times. Knowledge and requirements are codified in this way.

Also in the future we can make changes easily and efficiently without fear of regressions.

Infrastructure as Code

We define infrastructure (e.g. servers, load balancers, databases) similarly to program code and generate and modify infrastructure always via automatic scripts.

This ensures that changes are transparent and reversible. Built-up know-how is integrated into program code and documented.

Peer Reviews

Every change to the software goes through the test suite and is tested by the Continuous Integration system.

Integration into the main development branch is only possible once all quality criteria have been met.

Before integration, we rely on peer reviews from other developers to ensure process quality on the one hand. In addition, knowledge in the team is distributed over several shoulders.

Updates

The BfArM requires regular market monitoring for software components in use.

We automatically monitor the developed software daily for reported security vulnerabilities and available updates.

Updates are installed independently and the new software version is submitted to a designated person for testing.

Automated tests ensure that the system is fully functional.

YOUR GOALS

Get in contact with us now!

Email:  LinkedIn | XING | Phone: 0234 52 00 76 57