Lifen Engineering is on a mission

Lifen (/liːfen/) started 3 years ago with a simple mission:

Create 21st century tools and services for healthcare professionals to help them deliver the best patient care possible.

Many of the early team members were heavily exposed to the medical field either through family history (one or both parents/siblings being doctors), life choices (husband/wife/partner being doctors) or medical history (having been a consumer of the healthcare services available on the market). Bottom line, the mission felt very very personal to all of us.

Given our French roots, we focused initially on the French healthcare market.

This market is characterized by:

• Strong (local) regulations
• Fragmentation (Many small, independent providers) and decentralization (for historic reasons but this is changing)
• Chronic lack of resources

Our love for a challenge took over and we embarked on our mission. After a year of the proverbial search for a “product/market fit”, we learned multiple key things that drove our technical choices later on:

• A large majority of healthcare data, while digitized on a computer in a doctor’s office or in a hospital’s IT system, was trapped in walled gardens for lack of practical, efficient interoperability.
• Communication between healthcare professionals (General Practitioner - Specialist, Hospital - Physician in his/her practice) is mostly done using paper documents (yes we’re in 2018 and trees are still getting killed).
• The lack of data exchange/availability/accessibility results in a massive waste represented by “redundant medical procedures” (17–30% of medical procedures could be saved in France according to this article [French])
• The large majority of the healthcare professionals perceives technology as a hinderance to their day to day job and if they have a setup that “works”, they don’t change it easily (if ever).

With this in mind, we rolled up our sleeves and jumped in. We decided to start with a single product that allows a healthcare professional to:

send a medical report, in structured digital form, using the exact same process that he/she is used to (i.e printing), to another healthcare professional, while ensuring reliable delivery, regulatory compliance and strict security

Our first thought when our product team presented us with this goal was : “Easy! Email has solved most of this ages ago. Where is the challenge?”.

It turns out that it’s not that easy and there are challenges everywhere :)

Let’s break it down:

• send a medical report using the exact same process that he/she is used to (i.e printing): We built a desktop application that includes a virtual printer and a ”synchronization engine” function for Windows/Mac/Linux (yes there is a linux lover among our doctor-customers!) and a dashboard to track documents sent and received. We use React, NodeWebkit (more on why not Electron in a future post) to build it and many other components to manage/operate it (auto-update, diagnostics collection, monitoring, Single-Sign On integration and more).
• in structured digital form: The output of the virtual printer is a PDF document that is uploaded to our platform using our API which implements a healthcare standard for data interoperability (FHIR). Once the PDF document reaches our platform, it is processed by our Artificial Intelligence module that extracts various information including the patient’s name, the recipient doctor, the sending doctor and the type of document (medical report for a visit, an operation, etc). This enriches the original unstructured PDF and turns it into a structured digital document. We also have multiple integrations with partners who send us directly structured documents by hitting our API (documentation). Less work for our AI though :(
• to another healthcare professional: This must be a head scratcher. How hard can it be? It turns out that in order to have a reliable directory of healthcare professionals and the ways to contact them, we had to build it ourselves. There are four aspects to address here :

1. There is a database of doctors and it’s published every day but it’s not always up-to-date for non-primary data.
2. There are two competing, non-interoperable (soon to be fixed) secure messaging systems in France (APICrypt and MSSanté). Both publish more or less a directory of their users on a daily basis but the data quality and integrity can be “hit and miss”.
3. The recipient should be in control of where they find it the most convenient to receive the medical reports even when they have multiple active communication channels. This is compounded by the fact that a large majority of healthcare professionals has multiple activities (Hospital vs private practice for example).
4. If the delivery of a medical report fails for any reason, the channel by which the delivery was made should be marked as “unreliable” in our directory. We therefore treat it as an “Active Directory” (pun fully intended).

• ensuring reliable delivery: We monitor deliveries across all channels (secure digital messaging as well as postal deliveries) to detect what constitutes a “bounce” and we manage it accordingly. We have built the necessary infrastructure to achieve this, detect delivery issues and apply automated or non-automated policies depending on use cases to attempt another delivery using an alternative option.
• regulatory compliance: We are well aware of the heavily regulated environment in which we operate (rightfully so, personal and health data is critical) and we have, since day 1, spared no effort to maintain a compliance level in-line with our ambitions and our commitment to our customers. This is materialized in two examples :

1. Data Privacy: RGPD is all the rage but also french local laws such as CNIL-defined AR-31.
2. Infrastructure Hosting: local regulations mandate hosting at certified hosting providers so no public cloud for our production workloads (yet, more news coming soon), so we have our private cloud (VMware-based) at a certified hosting provider but of course, we leverage the public cloud (and Heroku , what else!) for test&dev and our internal needs. Therefore, “Hybrid cloud” is our natural habitat.

• strict security: We simply encrypt everything (at-rest, in transit), we have an audit trail on all critical operations, we rotate encryption keys often, we require multi-factor authentication for all the services that we provide but also the ones we use, we use combinations of WAFs, Firewalls, VPNs to protect communications and public endpoints. Finally, we strictly adhere to the principle that every person should have access to what they need to get the job done but nothing more.

This blog post is the start of a series that will cover the challenges we faced and are still facing, our learnings, our missteps and our wins. The journey is just beginning, follow our blog or even better, come join us! (careers site)