Aita Consulting Research Series on Syrian Health Reform · No. 2
A national digital health system is not a single piece of software. It is a set of shared rules, identities, standards and services that let many systems work as one. Syria should build those foundations before it buys the applications.
The risk: rebuilding fragmentation
Reconstruction brings money, urgency and many actors at once. Hospitals, primary care programs, laboratories, donors and humanitarian agencies will all need information systems, and each will be tempted to buy what works for its own project. The result, if nothing coordinates them, is predictable: dozens of systems, each with its own patient numbers, codes and interfaces, none able to talk to the others.
That is the principal digital risk in Syria today. It is not a shortage of software. It is the risk of rebuilding fragmentation faster than anyone can undo it.
The answer is to treat digital health as a health-system reform enabled by technology, not as an IT project. The goal is not a national application. It is one national health information ecosystem in which different, certified systems share common identities, standards and rules. Existing systems should be treated as assets: assessed, kept where they are useful, connected where feasible and replaced only when necessary. None should become the national architecture simply because it was installed first.
Ten design principles
Every digital health investment, procurement and system decision should pass ten tests.
| # | Principle | What it means in practice |
|---|---|---|
| 1 | Health needs before technology | Technology serves agreed health-system requirements |
| 2 | Process before software | Future workflows are designed before systems are specified |
| 3 | Data before applications | Identifiers, terminology and datasets come before procurement |
| 4 | Interoperability by design | No national application may become an information silo |
| 5 | One ecosystem, not one application | Different systems coexist under common national rules |
| 6 | Modular architecture | Distinct systems connect through governed interfaces |
| 7 | Security and privacy by design | Health information is treated as critical national infrastructure |
| 8 | Vendor neutrality and national ownership | Identifiers, standards, interfaces and data models stay under government control |
| 9 | Phased implementation | Pilot, measure, correct, then scale |
| 10 | Measurable benefits | Success is judged by better care and efficiency, not by systems installed |
These principles are consistent with the WHO Global Strategy on Digital Health, which the World Health Assembly extended to 2027, and with the open reference architecture published by the OpenHIE community for national health information exchange.
A six-layer national architecture
A national ecosystem can be described in six layers. The bottom two are where care is delivered and the system is run. The middle layers connect them and turn their data into intelligence. The top two set the rules everything else must follow.
Layer 3 is the decisive one. National shared services are built once, governed centrally and used by every system in layers 1 and 2. They are what allow a laboratory system from one supplier, a hospital system from another and a primary care record from a third to function as a single national system.
Identity first
Every other component depends on knowing, reliably, who the patient is, who the provider is and which facility delivered the care. Without that, records cannot be linked, referrals cannot be tracked, claims cannot be verified and statistics count the same person several times.
A national identity architecture rests on three elements:
-
A National Health Number that is stable and carries no meaning. It identifies the person and nothing else: no insurance status, no geography and no clinical information built into the number.
-
A National Patient Registry that holds the reference demographic record linked to that number.
-
A Master Patient Index that matches records across systems, combining exact identifiers with probabilistic matching.
The same logic applies to providers, facilities and organisations, each with its own authoritative registry. Licensing, contracting, claims and reporting then all refer to the same verified entities.
Two Syrian realities must shape the design:
-
Arabic names. Naming conventions, transliteration differences between Arabic and Latin scripts, and inconsistent historical records make exact-name matching unreliable. Matching should combine verified identifiers with configurable demographic rules.
-
People without documents. Many displaced people and returnees lack complete civil documentation. Care must never be delayed for lack of a confirmed health number. Temporary identities should be issued at the point of care and reconciled later through the master index.
Linking the health number to civil identity is valuable, but it must be designed so that healthcare continues for those the civil registry cannot yet confirm.
Information before applications
Before any system is bought, the country should define the information it needs. Eight domains cover the whole health system:
| Domain | Core information |
|---|---|
| Population and patient | Identity, demographics, household, geography, eligibility |
| Clinical care | Encounters, diagnoses, problems, allergies, procedures, observations, outcomes |
| Medicines | Formulary, prescribing, dispensing, procurement, stock, utilisation |
| Diagnostics | Laboratory, imaging, pathology, orders and results |
| Providers and facilities | Professionals, organisations, facilities, services, capacity, licensing |
| Financing and purchasing | Costing, tariffs, claims, payments, budgets, expenditure |
| Public health | Surveillance, immunisation, registries, outbreaks, mortality |
| Health-system management | Workforce, assets, procurement, capacity, utilisation, quality, performance |
Each domain needs a named data steward, an authoritative source, a mandatory minimum dataset, terminology rules and data-quality standards.
The standards themselves are mature and internationally available. Syria needs national profiles that define how to apply them:
-
ICD for classifying diseases and causes of death
-
SNOMED CT / MEDCIN for detailed clinical terminology, subject to licensing
-
LOINC for laboratory tests and observations
-
DICOM for medical imaging
-
ATC/RxNorm and a national drug dictionary for medicines
-
HL7 FHIR for exchanging information between systems
-
Alongside these standards, DHIS2 for national data aggregation, statistics and disease management
Two principles matter more than the choice of standard. First, terminology must be published in Arabic, with searchable synonyms, while the underlying codes stay stable. Second, a code list without governance is not a standard: every national standard needs version control, implementation guidance and conformance testing.
The national patient record should also be a logical view, not one central database. It is assembled from trusted sources, such as clinical summaries, referrals, laboratory results, imaging reports, prescriptions and discharge summaries, and every item keeps its provenance: source system, facility, author, date and version.
Ten process chains, not ten software modules
Software requirements should come from how care and administration actually flow, not from vendor catalogues. Ten national process chains capture most of what the health system does:
| Process chain | From start to finish |
|---|---|
| Patient to care | Registration, triage, consultation, diagnosis, treatment, follow-up |
| Order to result | Order, specimen or image, processing, validation, result, acknowledgement |
| Prescribe to dispense | Decision, prescription, validation, dispensing, administration, monitoring |
| Referral to care | Referral decision, request, scheduling, specialist care, feedback, continuity |
| Admission to discharge | Admission, assessment, orders, treatment, discharge planning, follow-up |
| Population to primary care | Registration, risk stratification, prevention, chronic care, recall, referral |
| Disease event to response | Detection, notification, validation, investigation, response, outcome |
| Procure to pay | Need, procurement, receipt, inventory, distribution, payment, audit |
| Claim to payment | Eligibility, authorization, service, claim, adjudication, payment, audit |
| Hire to retire | Registration, credentialing, deployment, performance, training, exit |
For each chain, the current workflow should be documented, the future workflow agreed with clinicians and managers, and only then translated into system requirements. A referral, for example, is only complete when feedback returns to the referring doctor; a system that sends referrals but never closes the loop automates the problem rather than solving it.
Where DHIS2 fits, and where it does not
DHIS2 is widely used for aggregate health reporting and should remain a central instrument for monitoring health-system performance. It is well suited to routine statistics, program indicators, selected disease surveillance and dashboards for decision-makers.
It is not a hospital information system or a national electronic medical record. It does not replace the functions needed for admissions, clinical orders, medication administration, surgery, billing or long-term patient care. Stretching it into those roles produces weak clinical systems and weak statistics at the same time.
The right direction is to strengthen DHIS2 in its own role:
-
align its list of reporting units with the national facility registry;
-
maintain a governed national indicator dictionary, with definitions, denominators, reporting frequency, owners and validation rules;
-
remove duplicate indicators and improve data quality;
-
feed it progressively from clinical, laboratory and surveillance systems through controlled interfaces, reducing manual re-entry of the same data;
-
use its outputs for dashboards on disease surveillance, service coverage, facility performance, equity and health outcomes.
Even simple data collection can connect to it. A vaccination-schedule tracker in a mobile personal health record, for example, can feed immunization data directly into DHIS2 reporting: a small, high-impact first step for disease prevention.
Architecture before procurement
The single most consequential rule is simple: no major national digital health purchase should come before the architecture, workflows, standards and interoperability requirements it must fit into.
This rule prevents the most expensive mistakes: duplicated systems, isolated data silos, dependence on a single vendor, records that can never be reconciled, and interfaces that have to be rebuilt later. It does not mean freezing all activity. Urgent projects can continue under a transitional review, provided they show they conform to the national rules as those rules take shape.
The same discipline applies to documents. A national strategy should state why and what. Below it, an enterprise architecture and standards framework sets how the parts fit together; functional blueprints describe how each domain, such as primary care, hospitals or medicines, should operate; system specifications set what each system must do; and only the final level, procurement documents, defines exactly what is being bought. Mixing these levels in one document is how strategies turn into software catalogues.
How to measure success
A digital health program should not be judged by the number of computers installed, facilities connected or applications deployed. It should be judged by whether the country can answer, routinely and reliably, the questions needed to deliver care and govern the health system:
-
Who needs health care, and where are they?
-
What services do they need, and what care have they received?
-
Was that care safe and effective, and are services equitable?
-
What medicines and resources were used, and at what cost?
-
Where are disease patterns changing, and where are resources insufficient or wasted?
-
Are health outcomes improving?
Those questions translate into measurable indicators:
| Area | Indicative measures |
|---|---|
| Identity and data quality | Duplicate patient rate, verified provider and facility coverage, coding completeness |
| Continuity of care | Referral completion, availability of discharge summaries, use of shared summaries |
| Clinical operations | Laboratory turnaround, medication reconciliation, fewer duplicate tests |
| Medicines | Stock-out rate, expiry losses, forecast accuracy, order fill rate |
| Financing | Claims rejection, adjudication time, payment reconciliation |
| Workforce and facilities | Verified license status, distribution gaps, functional capacity, equipment downtime |
| Health intelligence | Indicator timeliness, data completeness, use of data in decisions |
What this means for vendors, donors, hospitals and investors
The question for any new system in Syria will not be what it does on its own, but whether it fits into one national ecosystem.
For organizations planning to work in Syria’s health sector, the practical signals are clear:
-
Software vendors should expect national conformance requirements: support for the national health number and registries, national terminology profiles, HL7 FHIR interfaces, audit trails and Arabic-language support. Products that keep identifiers, codes or data models proprietary will be at a disadvantage.
-
Development partners will add the most value by funding shared national components, such as registries, terminology services, information exchange, cybersecurity and workforce training, and by requiring their own projects to conform to one national architecture rather than building parallel systems.
-
Private hospitals and laboratories that invest early in coding, structured records and interoperable systems will be ready to connect to referral networks, claims processing and national reporting.
-
Investors should look beyond selling applications. Long-term value lies in implementation, integration, data quality, training and the managed services that keep a national ecosystem running.
Digital health and health financing are also inseparable. Eligibility checks, provider contracting, claims, tariffs and purchasing intelligence all depend on the same identities and standards described here. The insurance reform discussed in the first article of this series cannot operate without them.
Conclusion
Syria has a rare opportunity: to build its health information environment once, and build it right, instead of inheriting decades of incompatible systems. The order of work is the strategy. Understand the health system, design the processes, define the information, standardize the data and design the architecture. Only then specify, procure, pilot, measure and scale.
By 2035, success would mean a nationally governed health information ecosystem rather than a collection of disconnected applications: one in which essential information follows the patient, professionals have what they need to provide safe care, and government has timely, trustworthy information to protect population health and allocate scarce resources.
About the author. Dr. Sami Aita, MD, is the founder of Aita Consulting (Damascus), which advises international companies and institutions on entering and operating in Syria’s healthcare and regulated markets. He founded and led MedcomSoft Inc., a Toronto Stock Exchange-listed electronic medical record company whose software was among the first certified ambulatory EHRs in the United States, and has designed health information systems, clinical terminology integration and patient identity architectures for four decades.
About this series. The Aita Consulting Research Series on Syrian Health Reform publishes independent analysis based on public sources and international experience. Previous article: Health Insurance Is Not a Card.
To discuss this research or its implications for your organisation, contact info@aitaconsultingsy.com or +963 952 600 716.
Sources
-
HL7 International, FHIR standard; WHO, International Classification of Diseases; SNOMED International, SNOMED CT; Regenstrief Institute, LOINC; NEMA, DICOM; WHO Collaborating Centre, ATC classification; Medicomp Systems, MEDCIN; University of Oslo HISP Centre, DHIS2
1 thought on “One Ecosystem, Not One Application: Building Syria’s National Digital Health Architecture”