Medicloud: Dental practice management system development

The problem

Due to the size and complexity of the Practicedent product (1.5 million lines of code), coupled with the core dev team’s focus on the generic business logic, Medicloud sought our help to outsource the health insurance integration and mobile app projects.

These three projects required resources with a specific set of technological, language and business analysis skills that were outside of Medicloud’s domain.

We advised the introduction of a permanent off-site team of a total of 12 consultants, in order to guarantee the smooth workflow of the company.

This team has been in place for over 14 months and has been supporting Medicloud in developing mobile apps for PracticeDent and making it compliant with the strict dental health regulation in Germany and Denmark.

The solution

After being approached by Medicloud, Minds hired three senior consultants, to get on-site: one with mobile development expertise, the other with enterprise web app background (node.js, javascript, MongoDB), and a third one with broad PM and business analysis experience. The purpose was to gather more detailed information on the business and functional requirements, in order to define the right profile and skill set of the resources that would be hired later on.

Upon getting valuable insight into the nature of the projects and the client’s needs, our recommendation was to build a team of 12 consultants that would focus on business analysis, spec writing, development of new business logic, testing, and, later on, maintenance and support.

Implementation: Germany

Technical details

The German health insurance regulator (KZBV) has a proprietary API that all dentists need to use to prepare specific reimbursement reports, in order to claim health insurance money for the treatment they provide. In order to integrate with this API, the team created gateway executables in C, which include the object files and make direct calls to the API.

The team used ext.js framework to implement the custom UI that allows input of specific, regulator-required data.

To enable printing of medical data on specific, predefined forms sanctioned by the state, we created a dedicated, server-side Javascript engine. The task also involved installing on the server and using specific Linux system libraries for complex PDF manipulations.

The integration effort also included developing a dedicated desktop agent, to connect to a device that reads patients’ e-health cards and transfers patient data to the cloud. The desktop agent was built on .NET.

Challenges

Since the documentation had numerous gaps, the task involved complex reverse engineering of existing, 3rd-party generated, binary files containing the reimbursement reports. For the purpose, we developed a dedicated tool to reverse the proprietary binary files to json format, and vice versa.

Implementation: Denmark

Technical details

The communication with the Danish health insurance funds is done via a series of UN/ EDIFACT letters. For the purpose, we researched the existing solutions that could read/ generate EDIFACT files. All of those available were quite sub-optimal considering the task at hand. So, we decided to create our own, state-of-the-art reader/generator of EDIFACT files.

Based on the regulator-approved schemas, we implemented the necessary UI, document model and backend functionality, to enable:

• the generation of MEDRUC letters (RUC01, RUC02).
• the interpretation of incoming responses from other healthcare and insurance institutions (CTRL01, CTRL02, CTRL03)

The entire communication runs through 3rd party VANS networks, which involved accommodation of such a VANS provider on the servers, in addition to data polling of incoming responses, their interpretation and visualization in the UI.

Implementation: Mobile

Technical details

We used Sencha Touch (js for the logic, HTML/CSS for the layout) to build the UI To port the single application to both iOS and Android devices, we used Phone Gap.

Challenges

Medicloud wanted to have something delivered relatively fast and cheap. We recommended the cross-platform, hybrid approach. This would not only eliminate the need of recruiting objective C and Java developers (which is harder and more expensive), but would also translate into supporting one, instead of two separate apps later on.

The main challenge was to convince the client that the hybrid approach would be as robust as the native app approach, without having to sacrifice features. What helped us get their OK was that with Phone Gap, all of the device’s native functionalities, such as Camera and Mail for example, are readily accessible from within the web mobile app. Another argument that won the client over was the ability to use Phone Gap as a single build source, allowing “one-click” production of app versions that are ready for both the App Store and Google Play.

From a technical & implementation standpoint, it was challenging to preserve the speed and native look and feel of the hybrid application.