🏥 | Implementation guide for Digital Health Platform [maintainer=@roosyabuddy]
  • GLSL 83.4%
  • JavaScript 16.3%
  • Batchfile 0.2%
  • Shell 0.1%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Ernest Nuritdinov 33eb8c32fb
Code screening questionnaires in SNOMED CT, document unspecified program type (#107)
Switch Questionnaire.code on the IHD, fertility, helminth, cardiovascular
risk, diabetes, breast cancer, oncohematology and cervical cancer
questionnaires from UZ Core screening-code-cs to the same SNOMED CT
concept as their program type identifier, with Uzbek and Russian display
translations. The cerebrovascular questionnaire keeps
screening-code-cs#mserv-0007-00003, as SNOMED CT has no suitable concept.

Document breast-cervical-unspecified in the screening program type
NamingSystem usage and on the cervical and breast cancer screening page:
the HPV screening system writes it on a Condition or branch referral it
cannot attribute to either program. Align the SNOMED CT display names in
that usage text with the International edition.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 21:16:16 +02:00
.github publication build, prepare 0.9.1 (#93) 2026-09-17 11:40:40 +00:00
docs Add 0.10.0 to package feed (#105) 2026-09-30 10:43:32 +02:00
input Code screening questionnaires in SNOMED CT, document unspecified program type (#107) 2026-10-05 21:16:16 +02:00
.gitignore copy DHP integrations content 2025-11-13 12:51:58 +01:00
.gitlab-ci.yml Add GitLab CI configuration inclusion (#73) 2026-09-03 07:00:49 +00:00
_build.bat update publisher scripts (#23) 2026-05-12 17:59:28 +02:00
_build.sh update publisher scripts (#23) 2026-05-12 17:59:28 +02:00
_gencontinuous.bat copy DHP integrations content 2025-11-13 12:51:58 +01:00
_gencontinuous.sh copy DHP integrations content 2025-11-13 12:51:58 +01:00
_genonce.bat update publisher scripts (#23) 2026-05-12 17:59:28 +02:00
_genonce.sh copy DHP integrations content 2025-11-13 12:51:58 +01:00
_updatePublisher.bat update publisher scripts (#23) 2026-05-12 17:59:28 +02:00
_updatePublisher.sh copy DHP integrations content 2025-11-13 12:51:58 +01:00
AGENTS.md AGENTS.md: tag questionnaires with their integration area (#103) 2026-09-30 07:32:51 +00:00
CLAUDE.md Point AI agents at core modelling guidelines (#101) 2026-09-29 07:13:08 +00:00
fast-narrative-rebuild.sh Forms 066 and 066-1 (#24) 2026-06-17 14:22:35 +00:00
ig.ini copy DHP integrations content 2025-11-13 12:51:58 +01:00
LICENSE copy DHP integrations content 2025-11-13 12:51:58 +01:00
README.md Test commit for integrations (#75) 2026-09-03 11:05:06 +02:00
RELEASING.md release doc: core dependency ordering, auto-merge, announcement (#106) 2026-09-30 13:13:08 +02:00
Requirements-fromNarrative.json Forms 066 and 066-1 (#24) 2026-06-17 14:22:35 +00:00
sushi-config.yaml Form 066: code operations with ICHI (#100) 2026-09-30 09:51:23 +02:00
updateSiteBasedOnMarkdownChange.sh copy DHP integrations content 2025-11-13 12:51:58 +01:00

🇺🇿 DHP Integrations Implementation Guide

Welcome to the official repository of the Digital Health Platform (DHP) Integrations Implementation Guide. This guide defines FHIR R5-based integration specifications for third-party systems that integrate with the Digital Health Platform (DHP). It enables external healthcare systems to exchange data with DHP while maintaining their own data sovereignty.

📌 Published by Uzinfocom in collaboration with the Ministry of Health of Uzbekistan under the national healthcare digitalization program supported by KfW Development Bank.


🌐 About the Project

The DHP Integrations IG provides standard data structures, terminology, API specifications, and integration patterns for third-party systems integrating with DHP. It supports DHP's hybrid architecture where not all data is centralized, combining centralized storage of core healthcare data with distributed, specialized data maintained by external systems.

  • 📅 Project duration: 2024–2027
  • 🧭 Aligned with: Digital Uzbekistan 2030, Presidential Decree PD-415, Concept for Health 2019–2025
  • 🔗 Interoperability standard: HL7® FHIR® R5
  • 🔄 Depends on: DHP Core Implementation Guide

📘 Guide Contents

This Implementation Guide includes:

  • ✅ FHIR profiles and extensions for external systems integrating with DHP
  • 🔄 Integration patterns for DHP's hybrid architecture (centralized + distributed data)
  • 🏥 Data exchange approaches: atomic FHIR resources and clinical documents
  • 📝 Clinical forms (e.g., Form 003 inpatient, Form 096 birth) as Clinical Documents
  • 🌍 Terminology services: CodeSystems and ValueSets for standardized coding
  • 🧪 Conformance requirements for third-party system integrations

🎯 Target Audience

This IG is intended for implementers developing or configuring systems that need to integrate with DHP, including:

  • 🏥 Medical Information Systems (MIS) - patient records, appointments, billing
  • 🖼️ Picture Archiving and Communication Systems (PACS) - medical images
  • 🧪 Laboratory Information Systems (LIS) - lab workflows and results
  • 🔌 Other third-party healthcare applications needing data exchange with DHP


👥 Contributors

Name Role Organization
Rustam Sadykov IG Maintainer Uzinfocom
Vadim Peretokin Primary Author Peretokin Consulting
Bekhzod Akhmedov Co-Author Uzinfocom
Sarvar Kubaev Co-Author Uzinfocom
Saodat Kadirova Business Analyst Uzinfocom
Irina Berger Business Analyst Uzinfocom
Ministry of Health of the Republic of Uzbekistan Strategic Partner Government
KfW Development Bank Financial & Technical Support International Donor

🛠️ Repository Management and Development Standards

Semantic versioning: Version identification follows the conventions documented at https://build.fhir.org/ig/vadi2/DHP-temp/en/index.html#identification-of-versions.

Branching strategy: Feature branches are created as needed and merged into the main branch via rebase or squash-commit. All releases are tagged from the main branch according to semantic versioning standards.

Code review policy: Pull requests must pass IG Publisher QA checks without introducing new errors or warnings, and require approval from at least one FHIR expert before merging.

Quality assurance: Static analysis is enforced through the FHIR IG Publisher's built-in validation and QA tooling, which checks for conformance issues, broken references, terminology validation errors, and a host of other issues.


📜 License

This Implementation Guide is open-source under the CC0-1.0 license.