Data-driven healthcare: patient registries in clinical work

A hospital department generates a large amount of data every day: lab results, vital signs, clinical reports, medication and follow-up visits. Yet day-to-day work often relies on a few Excel spreadsheets, printed forms and personal records. As a result, putting together a clinical report can become a separate task that takes weeks.

Data-driven healthcare therefore starts where the data is created. If the care team records data in a consistent structure during the ward round, the examination or the procedure, the same data can feed a patient-level overview, an institutional report and a research analysis. This article explains why clinical data goes wrong at the point of entry, and what needs to be decided when launching a patient registry built into the clinical workflow.

Key takeaways

• The quality of any analysis is decided at data entry. Documentation recorded after the fact can be inaccurate, as studies of delivery room resuscitation have shown. Information recorded as free text often reaches analysis only after someone reads through it by hand.
• A patient registry is more than a database: it combines a data model, a workflow, a legal basis, integration and access management.
• In Hungary, the Health Data Act (Eüak.) governs disease registries and allows them to be kept as electronic registries with pseudonymized data through the EESZT, Hungary's national eHealth infrastructure.
• The European Health Data Space (EHDS) is an EU regulation on sharing and reusing health data. Registry data is among the categories to be made available for secondary use, such as research; for most data categories, these rules apply from March 2029.
• Predictive analytics and research based on real-world care data are a benefit of a well-built data asset, not a prerequisite for getting started.

What does data-driven healthcare mean in clinical practice?

Data-driven healthcare is a way of working in which clinical, institutional and research decisions are based on the same structured, reliable data asset. The emphasis is on "reliable". Even the best analytics tool cannot make up for data that nobody recorded, or that was only recorded later as free text.

Genontech's approach therefore follows a simple order: first, data entry that fits the workflow; then, advanced analytics. Artificial intelligence and predictive models deliver usable results when the data behind them is complete, consistent and interpretable in its clinical context.

In practice, this means three things:

• Patient-centered data structure: data belongs to the patient, not to a department, a test or a spreadsheet.
• Recording at the point of care: data enters the system when it is created, not at the end of the shift.
• One data asset, many uses: bedside decisions, institutional reports and research analysis all draw on the same source.

Why does clinical data go wrong at the point of entry?

Many problems in clinical data management stem from where and how data is recorded. Data ends up scattered across parallel Excel spreadsheets, several unconnected systems and the free text of clinical reports. International research shows the cost of this in three areas.

Documentation takes time away from patients. In a US ambulatory care study, physicians spent 27.0% of their office time in direct contact with patients and 49.2% on electronic health records and other desk work (Sinsky et al., Annals of Internal Medicine, 2016).¹ According to a systematic review of 18 studies, physicians spend nearly 37% of their working day on electronic health records (Pinevich et al., Applied Clinical Informatics, 2021).²

Documentation recorded after the fact can be inaccurate. A Dutch study compared retrospective documentation of delivery room resuscitations with video and physiological recordings. Heart rate was documented correctly in 37% of cases and oxygen saturation in 13% (Schilleman et al., 2014).³ A later systematic review found that documentation of neonatal resuscitation is often inaccurate and that important events go unrecorded.⁴

Information trapped in free text is hard to bring into analysis. In a Dutch primary care database covering 1.8 million patients, only 13% of the clinical concepts extracted from free-text notes were also present as structured codes (Seinen et al., Journal of Medical Internet Research, 2025).⁵ Anything that exists only in the text of a clinical report has to be extracted by hand before it can appear in a summary.

Reports built on incomplete, fragmented data have limited reliability. The first step is therefore not buying a new analytics tool, but sorting out where and how data is recorded.

What needs to be decided when launching a patient registry?

The success of a registry project depends on decisions made before launch. The European Medicines Agency (EMA) defines a patient registry as an organized system that collects uniform data about patients over time.⁶ The two key words in that definition, "uniform" and "over time", are exactly what Excel-based records struggle to provide.

It is worth clarifying the following questions at the design stage:

What is the registry for?

The purpose of the registry determines the dataset. A registry for clinical follow-up needs different data from a system that calculates quality indicators or one that builds a research cohort. If the purposes are known in advance, the fields can be designed at launch so that no separate data collection is needed later.

What data model is it built on?

The data model defines which data is mandatory, and in what format and coding system it is recorded, for example ICD-10 for diagnoses (in Hungary, its national version, BNO-10). A well-designed data model catches errors at the point of entry: a missing mandatory field or an out-of-range value is flagged immediately, rather than surfacing in the half-yearly report.

What is the legal basis?

Under the GDPR, health data is a special category of personal data.⁷ The purpose of processing, its legal basis and the role of the data controller must therefore be clarified before launch, together with the institution's data protection officer.

In Hungary, disease registries are governed by the provisions on data processing for public health purposes in Act XLVII of 1997 on the Processing and Protection of Health and Related Personal Data (1997. évi XLVII. törvény, Eüak.). The Act also allows the operator of a registry to keep it as an electronic disease registry through the EESZT, using pseudonymized data.⁸

If the software also provides functions that influence diagnostic or therapeutic decisions, such as a suggested risk classification, it must also be assessed whether it qualifies as a medical device under Regulation (EU) 2017/745 on medical devices (MDR).⁹

How does it connect to existing systems?

Data already held in the hospital information system (HIS), the laboratory system or the Electronic Health Service Space (Elektronikus Egészségügyi Szolgáltatási Tér, EESZT) should not have to be typed in again. Duplicate data entry means extra work and can lead to conflicting data versions. The Eüak. defines the EESZT as the system that ensures interoperability between the IT systems of the healthcare provider network.⁸

Who can see what, and where does the system run?

Role-based access control ensures that each user sees only the data needed for their work, and the visibility of patient data can be restricted to the user's own institution. The system can be hosted in the cloud or on premises, depending on the institution's IT and data protection requirements.

How does the data stay reliable in operation?

A registry is not finished at launch. During operation, the completeness and quality of the data must be monitored continuously: missing fields, contradictory values and missed follow-up events. The EMA guideline on registry-based studies also addresses data collection, data quality management and analysis as separate topics.⁶

If the registry processes health data on a large scale, a data protection impact assessment under Article 35 of the GDPR may also be required.⁷ For research use, ethics approval and patient information should also be planned in advance. For data exchange, it is worth building on international interoperability standards such as HL7 FHIR.¹⁰ Finally, it must be clear who is responsible for the registry's clinical content and who is responsible for IT operations.

What does the EHDS mean for registries?

The European Health Data Space (EHDS) is a common EU framework for health data. It has two main goals. First, patients should be able to access their own health data digitally, and that data should be shareable across the EU (primary use). Second, the data should be reusable for research, innovation and policymaking, subject to a permit and within a secure processing environment (secondary use).¹¹

Regulation (EU) 2025/327 on the EHDS entered into force on March 26, 2025. The rules on secondary use of health data, for example for research, apply from March 2029 for most data categories and from March 2031 for the rest.¹¹

Among the data categories to be made available for secondary use, the Regulation lists data from public health and medical registries.¹² An institution that already records data in a structured way, using a consistent data model, will be better prepared for this period as well.

How does a registry built into the workflow work in practice?

Genontech's Smart Registry platform is built on these principles. It links every piece of data to the patient, its screens follow the flow of clinical reasoning, and the recorded data immediately produces a draft report, a trend chart or a clinical score. It is not a general hospital information system: it is designed for structured data collection in a specific specialty, patient group or research program, and it connects to the HIS and the EESZT.

Structured patient record in the oncology module of a myeloma registry, from the Genontech publication, with sample data. The system highlights values that fall outside the reference range.

The patient record above shows how this differs from a spreadsheet. Fields are grouped according to clinical logic: labs, disease-specific markers, cytogenetics, comorbidities and lines of therapy. Values outside the reference range are visible at a glance, and missing mandatory fields are caught at the point of entry.

Data entry becomes part of the workflow when the system also gives something back to the clinician. The workflow support module has four main functions:

• Pre-filled fields and automatic scheduling: known data does not need to be re-entered, and the next step that is due appears automatically.
• Protocol and calendar scheduler: based on the diagnosis and risk classification, the platform calculates the dates of follow-up visits and case consultations.
• Dynamic milestone tracking: in long-term follow-up, such as follow-up of preterm infants or chronic oncology care, status is shown on an interactive timeline.
• Report and summary generation: natural-language draft reports and draft discharge summaries are generated from the structured data, and a clinician reviews and finalizes them.

Protocol tracking: how far has care progressed?

In the system, the clinical protocol becomes a treatment plan that can be tracked. It shows how far care has progressed, which phases are complete, where the decision points are and when the next step is due.

Treatment plan based on a pediatric acute lymphoblastic leukemia protocol, with sample data. Colors distinguish completed, active and planned steps.

Longitudinal overview: the patient journey on one timeline

The same data is used to build a complete overview of the patient. Diagnostic, treatment and follow-up events appear in chronological order and can be filtered.

Longitudinal patient view with sample data. Hovering over an event shows its details, such as the result of a pathology test.

This view is not the result of a separate data collection effort. It builds up as protocol steps, ward rounds and reports are recorded, so it updates as data is entered.

Department- and institution-level summaries

The same data also appears aggregated at department, institution or network level, with configurable filters. With built-in Self-Service BI, users can drill down from aggregate indicators to a specific patient group without help from developers.

Summary view of the pediatric acute leukemia diagnostic platform, showing an earlier data snapshot. The filters at the top (sex, age group, institution, disease type, test type) narrow down every chart at once.

What does a well-built data asset make possible?

If data is recorded at the moment it is created, in a consistent structure and with full clinical context, later analysis does not require a separate data collection project. Predictive analytics, structuring of free-text reports and research use then become a benefit of the registry. Our article on clinical decision support describes the four levels of decision support, from the bedside to predictive analytics.

Two developments are particularly significant for registries. The first is that real-world care data is playing a growing role in regulatory decisions as well. According to the EMA, wider use of real-world data and evidence can strengthen the evidence base for benefit-risk decisions, and the agency counts disease registries among the sources of such data.¹³

The second is the situation of small patient populations. In the European Union, a disease is considered rare if it affects no more than 5 in 10,000 people, yet according to the European Commission, 18–34 million people in the EU live with a rare disease.¹⁴ Their data is scattered across hundreds of registries throughout Europe.¹⁵ Where every patient counts, every missing data point is a loss.

Where is this approach already in use?

Genontech develops its solutions together with clinical partners. Workflow-embedded data entry is part of systems already running in several specialties. These include hematology and oncology specialty registries, a national pediatric hemato-oncology system and a delivery room event tracking application. Genontech's featured solutions also include the Biobank Information Management System (BIMS), which supports the management of biobank samples and their data.

Two examples in more detail:

• Pediatric acute leukemia diagnostic platform: developed with the Molecular Diagnostics Laboratory of Semmelweis University, the system manages genetic, molecular and clinical results in one place. In line with international protocols, it suggests a risk classification.
• NeoTracker: developed with the Department of Obstetrics and Gynecology at Semmelweis University, the app records interventions during newborn stabilization in real time, with time stamps, and automatically generates documentation from them.

Both systems follow the same logic: clinicians record structured data as they work, and the data can immediately be read back to support decisions. NeoTracker specifically offers real-time recording to address the inaccuracy of documentation done after the fact; its clinical impact still needs to be studied in a larger number of cases.

Frequently asked questions

Summary: less administration, more time for patients

Time spent on administration is often time taken away from patient care. When data entry is part of the work and immediately returns reports, trends and alerts, less time goes into after-the-fact administration and more is left for patients.

Data-driven healthcare therefore does not start with an analytics tool, but with the decision to record data where and when it is created. This is the foundation for bedside decision support, institutional reporting and, later, predictive analytics and research. On the analytics side, Genontech's AI-powered health data platform builds on this foundation.

This article was written by the professional team at Genontech. Genontech develops digital health solutions that support the collection, management and interpretation of healthcare data, working together with clinical partners. The article is based on the company's executive publication "Adatvezérelt egészségügy Smart Regiszterrel" (Data-driven healthcare with Smart Registry, 2026); external sources and legal provisions were checked on November 3, 2026. This article is not medical advice.

Sources

1. Sinsky C. et al.: Allocation of Physician Time in Ambulatory Practice: A Time and Motion Study in 4 Specialties. Annals of Internal Medicine, 2016; 165(11): 753–760. ↩

2. Pinevich Y. et al.: Interaction Time with Electronic Health Records: A Systematic Review. Applied Clinical Informatics, 2021; 12(4): 788–799. ↩

3. Schilleman K. et al.: Auditing documentation on delivery room management using video and physiological recordings. Archives of Disease in Childhood – Fetal and Neonatal Edition, 2014; 99(6). ↩

4. Avila-Alvarez A. et al.: Documentation during neonatal resuscitation: a systematic review. Archives of Disease in Childhood – Fetal and Neonatal Edition, 2021; 106(4): 376–380. ↩

5. Seinen T. M. et al.: Using Structured Codes and Free-Text Notes to Measure Information Complementarity in Electronic Health Records: Feasibility and Validation Study. Journal of Medical Internet Research, 2025; 27. ↩

6. European Medicines Agency: Generating high-quality evidence from registry-based studies. October 26, 2021. The news item summarizes the EMA guideline on registry-based studies (EMA/426390/2021). ↩ ↩²

7. Regulation (EU) 2016/679 of the European Parliament and of the Council (General Data Protection Regulation, GDPR), Article 9 (special categories of personal data) and Article 35 (data protection impact assessment). Text of the Regulation on EUR-Lex. ↩ ↩²

8. 1997. évi XLVII. törvény az egészségügyi és a hozzájuk kapcsolódó személyes adatok kezeléséről és védelméről (English: "Act XLVII of 1997 on the Processing and Protection of Health and Related Personal Data"), Section 16 (data processing for public health purposes, disease registries), Section 35/A (EESZT) and Section 35/L (electronic disease registry). Nemzeti Jogszabálytár (National Legislation Database), text in force from October 1, 2026. In Hungarian. ↩ ↩²

9. Regulation (EU) 2017/745 of the European Parliament and of the Council on medical devices (MDR). Text of the Regulation on EUR-Lex. ↩

10. HL7 International: FHIR specification. Last checked: November 3, 2026. ↩

11. European Commission: European Health Data Space Regulation (EHDS). Dates of entry into force and of the application phases. Last checked: November 3, 2026. ↩ ↩²

12. Regulation (EU) 2025/327 of the European Parliament and of the Council on the European Health Data Space, Article 51(1): data from public health and medical registries, and from registries for medicinal products and medical devices, are among the data categories to be made available for secondary use. Text of the Regulation on EUR-Lex (CELEX: 32025R0327). ↩

13. European Medicines Agency: Real-world evidence. Last checked: November 3, 2026. ↩

14. European Commission, Directorate-General for Research and Innovation: Rare diseases. Last checked: November 3, 2026. ↩

15. European Commission, Joint Research Centre: European Platform on Rare Disease Registration. Last checked: November 3, 2026. ↩