??"Behind the Code": The DeHealth Startup Journey. Episode?5

Data to Save Lives

In the ever-evolving landscape of healthcare technology, few startups face challenges as complex and mission-critical as DeHealth. At the intersection of patient care, data security, and advanced technology, DeHealth is on a quest to revolutionize how individuals manage their health information. This isn’t just a startup story; it’s a journey of relentless problem-solving, technological innovation, and a vision to empower users through their own medical data and health.

In this episode of “Behind the Code: The DeHealth Startup Journey, Episode 5” we delve deep into the world of DeHealth, a health-tech startup breaking boundaries in how medical data is handled and empowering users to take control of their health like never before. In this episode, you’ll discover:

• The data integration methods DeHealth uses to improve health outcomes.
• The obstacles faced by DeHealth and its global partners in unifying medical data.
• Why major U.S. tech companies struggle with problems DeHealth is tackling head-on, leading to setbacks and losses.
• How DeHealth's unique approach to data management enhances diagnostic accuracy and forecasting.
• Why creating a universal database and a global protocol for health data exchange is a monumental challenge for the entire world.

The Challenge of a Universal Health Data System

With more than 120,000 users from 80 countries on our web app www.dehealth.world , DeHealth isn’t just another health app — it's a transformative force that is redefining the healthcare experience. So, how do we tackle the monumental challenge of enabling users to gather all their health data seamlessly, every hour of the day, through the DeHealth ID?

DeHealth ID, their personal Universal Health Passport.?

And what does it mean when we say: whoever controls the information, controls the world?

When it comes to health, the stakes are even higher. If a patient has real-time access to their health data, they can fight diseases more effectively, make more informed decisions, and potentially prevent life-threatening conditions. This is why DeHealth ID is not just a convenience — it's a tool for empowerment and survival.

Securing Health Data in a Volatile World

Medical data is one of the most sensitive and highly sought-after commodities on the planet. Various organizations—pharmaceutical companies, healthcare providers, and tech firms—already hold vast amounts of this data. Even worse, it frequently appears on the black market, where a single medical record can be sold for as much as $1,000. The healthcare data market is expected to balloon from $32.9 billion in 2021 to $105.73 billion by 2030, but the risk is high: 45 million individuals became victims of healthcare data breaches in 2021 alone.

At DeHealth, we aim to change this narrative by giving control of personal health data back to the users. With the power of AI and blockchain, we’re building a future where privacy and security are paramount.

Building a ‘Healthcare Dropbox’

Our latest innovation, DeHealth ID, is essentially a "Healthcare Dropbox"—a secure, decentralized vault for health data that eliminates the need for costly integrations. This solution allows users to upload, store, and manage their health assets from multiple sources globally.

More -? https://dehealth.world/post/healthcare-dropbox-from-dehealth

All data is validated, encrypted, and stored in a decentralized database. Every step prioritizes user privacy and data integrity.

The Challenge: Creating a Global Health Database. The California Setback

After DeHealth’s early success, the team faced a more significant challenge: integrating with a large European medical information system (MIS) that serves over 5 million patients. The task was daunting:

• How do you build a database that consolidates, recognizes, stores, and analyzes health data from different regions of the world?
• How do you align medical data standards like HL7, CDISC, FHIR, and HIPAA, which differ drastically between countries?

DeHealth had to ensure that any data entering their system would be immediately standardized. For example, whether data came from a doctor in Spain or the U.S., the database had to translate and structure it consistently. This is crucial for ensuring that medical professionals can make accurate diagnoses and treatment decisions.

DeHealth approached a renowned California-based company founded by billion-dollar software veterans to help build the database infrastructure. The company had deep expertise in data engineering, but even they struggled with the scope of the project. DeHealth provided them with 40,000 anonymized medical records, but creating a functional database and API for this scale required more time than anticipated.

Our plan involved three collaborative teams: DeHealth's leadership and engineers, the European MIS team, and the Californians. Over the next eight months, we held countless meetings, reviewed thousands of pages of reports, and worked tirelessly on data integration.

But the road was far from smooth. Each country had its own regulations, and data validation across regions proved complicated. Users uploaded information in different formats, from various sources, and in multiple geographies. Historical data was particularly troublesome, with much of it stored on paper or in unreliable formats.

We decided to break the task into smaller steps:

1. We decided to create the first version of the database with the main entities based on FHIR.
2. Try to load the sample data that MIS sent us into this database, making sure it fits. For now, we’ll focus specifically on this dataset.
3. Obtain a working structure and all the necessary scripts for data imports.
4. Present this as version 1.

We were interested in mini datasets like:

• complaints/symptoms – diagnosis – action recommendations – medication recommendations.

The team from California implemented Encounter, Allergy, Condition, and Patient, which wasn’t on the list, and are currently in the process of adding the rest of the entities from the list. The schema looked approximately like this...

Later, four more entities were added to the database structure: Devices, Episodes, Immunization, and Medication statements.

Next, we began importing the data form by form, analyzing the results.

We then took 100 patients with pre-existing conditions, while the rest of the data was optional. Based on two data points, we built a personalization model. Optionally, we chose the gynecology category to simulate a real use case.

At this point, we realized the database needed to account for code conversion for diseases depending on the region. In each country, symptoms and diagnoses are named differently.

International Standards for Disease Codes

DeHealth's database required an intelligent way to manage international medical codes.

Answer.

There is a dictionary of diagnoses, each with its own code. When a doctor in Spain prescribes a diagnosis to someone, it is not “flu” that is stored in the database, but A02.

These are the dictionaries in the DeHealth database. This is how the base works at the current moment.

If the Spanish doctor chooses his language, then in his language, the diagnosis will be pulled up based on the corresponding code A02

These are international standards for disease coding (complaint, diagnosis, prescription, action in case of illness, active substance in a prescribed drug)

More specifically, HL7 is a "database structure" type standard. That the patient should have the “weight”, “height” fields.... And what you see above are the dictionaries that are used when entering a medical examination by a doctor.

These are dictionaries that operate according to WHO worldwide. https://www.who.int/standards/classifications/other-classifications/international-classification-of-primary-care

We have digitized all WHO medical dictionaries.

Further, inside the database, the algorithm assigns code B73 to this diagnosis.

This code is in international codes and it will be displayed to a doctor from Spain or France (any country) in his medical language.

These codes are official everywhere, all over the world.

Iterative Process: Breaking Down the Problem

The solution required multiple iterations. DeHealth’s working group—comprising CEOs, CTOs, and data engineers from DeHealth, the California firm, and the European MIS—spent eight months on this project. Thousands of pages of documentation were analyzed, data formats were tested, and countless meetings were held. The team faced several roadblocks:

1. Varying regulations across countries: Medical data laws differ from one country to another, making it difficult to create a one-size-fits-all solution.
2. Validating unstructured data: Users had medical records in different formats, from different sources, and often in non-digital forms like paper records.
3. Handling historical data: Many patients' old records were poorly digitized or incomplete.

The team decided to break down the project into smaller steps. They first developed a database with a foundation in FHIR, a standard for electronic health records. Then, they tested loading the MIS sample data into the system to ensure compatibility. Initial datasets focused on key elements like symptoms, diagnosis, and medication recommendations, while future updates would include more complex data like allergies, medical devices, and immunizations.

The engineers hit a dead end. The task was reformulated to build a receiving database where we can store data and an ETL system that can retrieve, parse, and load the data into this database.

Iteration 1: 222 forms with scattered data (many corrupted or broken data entries, often not conforming to https://jsonlines.org). After many days of work and attempts to fit these data into the database and find connections between them (keeping in mind that 221 of them were custom forms), we decided that this was a strange export. We needed one form, but in a different format. In other words, the ETL, database, and everything we had built so far needed to be scrapped, and we had to start over.

Iteration 2: We received instructions to take a Dummy package from EHealth with a note that the data would come in this format. We created the database again, started the data import process, and requested an archive, which we expected to arrive in the required structure. The result was a dump of a database that was encrypted and compatible with EHealth.

Iteration 3: We were assigned another developer from the MIS team, who provided us with data that was no longer encrypted but still in a format we hadn’t expected. Different clinics and MIS systems use various formats, so there was no consistent format on input that we could reliably parse and store in the tables.

In the end, we got:

1. A database built on the eHealth structure is ready to be populated. There are two types of data: 1.1 Old data in various formats, without structure. These are filled with free-text entries from doctors. There's a lot of it, and it's detailed but without a clear structure, which makes it difficult to analyze. 1.2 eHealth data – well-structured data. There isn't much of it, but it's clearly structured and easy to use.
2. Two test rows have been loaded into the database.
3. We failed to correctly import the historical data.
4. The issue of encryption and data loading from other MIS systems remains unresolved.

The Setback

The result of the entire eight-month campaign was disappointing for DeHealth. DeHealth is financially in the red, and the Californian team is upset because, for the first time, they failed to complete a task due to a lack of expertise. They admitted defeat—unable to meet the rigorous demands of the project.

The main roadblocks:

• Inconsistent data formats from various sources.
• Historical data, often unstructured or poorly formatted, posed significant challenges.
• Data encryption issues during transfers from multiple systems.

Ultimately, the California company was unable to complete the task. This led DeHealth’s CEO to make the bold decision to bring everything in-house. Despite this setback, the team felt a renewed determination to build the infrastructure independently.

Taking Control In-House

With a mounting frustration and a dwindling budget, the decision was made: DeHealth would take matters into their own hands. The startup’s CEO rallied the team and decided that DeHealth would build their own database, scalable architecture and integration systems in-house.

By digitizing WHO medical dictionaries and medical forms, by introducing HL7, CDISC, FHIR, and HIPAA standards DeHealth has already laid the groundwork for this next phase, which will lay a powerful technological foundation for creating a global super app for health.

Conclusion

What started as an ambitious project to empower patients to control their health data has grown into a comprehensive platform that could reshape the healthcare industry. DeHealth’s journey has been one of innovation, perseverance, and a relentless commitment to solving some of the most complex challenges in healthcare data management. Through their DeHealth ID, Healthcare Dropbox, and BlockChain protocol, they are bringing the future of healthcare to the present, one line of code at a time.

The future is bright. This isn’t just about technology; it’s about improving health outcomes for people worldwide.

DeHealth’s blockchain and cybersecurity frameworks, led by CEO Denys Tsvaig, a world-renowned expert in the field, ensured the highest levels of data security.

Looking ahead, DeHealth’s journey is far from over.

Stay tuned—this is just the beginning.

To be continued.

#DeHealth #HealthTech #DataSecurity #AI #Blockchain #HealthcareRevolution #UniversalHealthID #BehindTheCode #HealthData #CDISC? #FHIR? #HIPAA #Globaldatabase #EHealth #MIS #historicaldata