Proposed EthMed Platform: An AI-Enabled, Blockchain-Governed and Digital-Twin-Ready Health Platform for Ethnic Minority Communities in Remote and Hard-To-Reach Areas

Introduction

Digital health has moved from isolated hospital information systems toward integrated ecosystems combining EHRs, telemedicine, AI-assisted decision support, mobile applications, cloud data infrastructure and remote monitoring. Global platforms such as Epic/MyChart, Teladoc Health, Babylon Health, Ada Health, Human API and Patientory illustrate different development paths: some prioritise EHR access, others symptom assessment and telemedicine, while some experiment with blockchain-based personal health-record control [1]. Machine-learning and deep-learning approaches can support diagnosis, triage, prediction, workflow optimisation and personalised care when they are evaluated carefully and embedded within safe clinical governance [2]. The equity problem is especially important in remote ethnic-minority communities. Telemedicine can reduce geographic barriers by connecting community health posts, district facilities, provincial hospitals and specialists, but persistent gaps remain for populations with limited connectivity, low digital literacy, language barriers and incomplete clinical histories. For these communities, telemedicine should therefore operate as a hybrid workflow: local health workers collect and contextualise information, AI supports structured risk assessment, and remote specialists provide advice when predefined thresholds or clinical complexity justify referral.

Many AI-enabled health platforms are developed from datasets collected in urban hospitals, insured populations or technologically mature environments. Their assumptions may not hold in remote communities where laboratory results are scattered, connectivity is intermittent, language affects communication and traditional health practices coexist with biomedical care. Disease risk is shaped not only by biological variables but also by ethnicity, climate, altitude, occupation, housing, nutrition, access to clean water, health-seeking behaviour and distance to high-quality care.

Blockchain has been proposed for health records, consent management, audit trails, provenance tracking and secure data sharing. However, blockchain should not be treated as a substitute for conventional security architecture. EthMed therefore stores clinical information in secure databases and data lakes while using a permissioned ledger for hashes, consent transactions, identity references, timestamps and audit events. The rationale for this selective use is strongest where several independent institutions need a shared, tamper-evident governance record without giving one institution unilateral control of the audit history. Where a single trusted data controller is sufficient, a conventional append-only or WORM audit system remains a simpler alternative [3].

Digital twins in medicine refer to computational representations that are updated with data from the represented individual or system and can support prediction, simulation and personalised decision-making. Because evidence, data integration and validation remain early-stage, EthMed does not equate a longitudinal risk score with a digital twin. Instead, the proposed twin must have an identifiable state representation, repeated data assimilation, an explicit update mechanism, uncertainty estimates, validation against observed trajectories and a defined clinical use case [4]. Multimodal AI can subsequently support integration of clinical text, laboratory results, imaging, physiological signals, wearable data, lifestyle and environmental information [5].

Lao Cai province in northern Vietnam provides a relevant setting because mountainous, border and hard-to-reach communes coexist with a substantial ethnic-minority population and a dual burden of communicable, maternal-child, nutritional and environmental conditions alongside increasing non-communicable diseases. Fragmented data across hospital information systems, laboratory information systems, radiology/PACS systems, electronic medical records and provincial health records limit predictive and preventive pathways.

The objective of this study was to develop a design-science framework for EthMed and specify how it can be implemented and validated without overstating clinical performance. Four questions guided the work: (1) what technical and community requirements should determine the architecture; (2) how can AI, interoperability, telemedicine and governance be combined into a reproducible artefact; (3) what sample-size and validation strategy is appropriate for multiple prediction targets; and (4) what minimum defining characteristics are required before the term digital twin is used. This paper clarified that EthMed is a conceptual and implementation framework, not a validated clinical decision system. First, it provides a requirement-to-design traceability matrix linking community needs to platform components. Second, it separates the pilot dataset size from model-specific sample-size requirements. Third, it defines an AI development and validation framework aligned with TRIPOD+AI principles. Fourth, it justifies permissioned blockchain as a governance option rather than a generic security solution and specifies identity, key, consensus, smart-contract and consent controls. Fifth, it defines a staged digital-twin methodology with state representation, longitudinal updating, uncertainty handling and clinical validation. These additions.

Materials and methods

Design-science research study

This study uses design-science research because its primary output is an artefact, the EthMed platform architecture and associated governance and evaluation model, rather than an estimate of treatment effectiveness. The design process follows a staged cycle adapted to the EthMed context: (1) problem identification and requirement elicitation; (2) objective definition and design requirements; (3) artefact design and technology selection; (4) prototype demonstration in representative workflows; (5) evaluation against technical, clinical, user and governance criteria; and (6) iterative refinement and validation. This structure is consistent with established design-science principles [6,7]. Requirements were derived from the target setting and the four linked project documents underlying the original concept: an AI health-platform proposal for ethnic-minority communities in Lao Cai; a blockchain governance proposal for digital health data and clinical research; a digital-health-twin and multimodal-AI proposal; and a personal-platform concept note. Requirements were organised into six domains: access and usability; clinical data interoperability; AI-assisted risk assessment; referral and telemedicine; security and governance; and future digital-twin readiness (Table 1).

The matrix is intended to make the architecture auditable: every major platform requirement has a corresponding design response and a proposed verification mechanism. A component is not considered clinically deployable merely because the software function operates; it must also meet the relevant evaluation criteria.

The 3,000-participant target is justified as an initial platform-development and model-building cohort rather than as a universal sample size for all endpoints. For a descriptive community estimate with an assumed prevalence of 50%, a two-sided 95% confidence interval and an absolute precision of approximately 1.8 percentage points, the simple random-sample requirement is approximately 2,964 participants; a target of 3,000 therefore provides a transparent baseline for descriptive estimation. This calculation does not automatically account for clustering, non-response or subgroup-specific precision, so the final recruitment target should be inflated if cluster sampling or substantial attrition is expected. For prediction modelling, sample size must be evaluated separately for each outcome because the number of outcome events, not the total sample alone, determines information available for model development. As an initial planning assumption, an outcome prevalence of 10% in 3,000 participants yields approximately 300 events. With 20 candidate predictors, this corresponds to about 15 events per candidate predictor and can support an initial regularised model, subject to calibration and model-specific sample-size analysis. If prevalence is 5%, only approximately 150 events would be available, and the same 20-predictor specification would be substantially less stable. Rare outcomes such as stroke or selected cancers therefore require pooled multi-site data, longer follow-up, or a larger cohort rather than being presented as adequately powered by the 3,000-person pilot. Accordingly, the study will perform an outcome-specific sample-size calculation before locking each prediction model, considering anticipated outcome prevalence, candidate predictor degrees of freedom, shrinkage/overfitting control, expected model performance, missingness and validation requirements. The 3,000-person cohort is therefore a minimum pilot target; it is not a claim that every proposed disease model is sufficiently powered. This distinction is important for transparent reporting and avoids overinterpretation of the initial cohort.

Setting and target population

The initial setting is Lao Cai province, Vietnam, with priority attention to highland, border, and hard-to-reach communes. The target population includes ethnic-minority residents and the Kinh population for comparison. Enrollment should be stratified by sex, age, major ethnic groups represented locally, highland versus lower-altitude communes, healthy individuals, and people with priority conditions. The proposed initial dataset contains at least 3,000 individuals.

Data sources

EthMed integrates six categories of data: (1) personal and administrative data, including demographics, insurance identifiers, household context and consent status; (2) clinical history, including symptoms, previous diagnoses, allergies, medications, immunisation and family history; (3) laboratory data, including haematology, biochemistry, immunology, microbiology and point-of-care tests; (4) imaging and signal data, including X-ray, ultrasound, CT, MRI, ECG, respiratory function and other DICOM/PACS-compatible information; (5) wearable and home-monitoring data, including blood pressure, heart rate, heart-rate variability, SpO2, blood glucose, sleep and activity indicators; and (6) contextual data, including occupation, altitude, climate, water source, housing, cooking fuel, nutrition, traditional medicine use and distance to health facilities.

Interoperability and storage architecture

The proposed architecture uses HL7 FHIR for structured health-data exchange, DICOM for medical images, APIs/webhooks for integration with hospital and laboratory systems, PostgreSQL for structured EHR and registry data, MinIO or equivalent object storage for medical data-lake files, and Elasticsearch for search and retrieval. Legacy prescriptions, laboratory reports and PDF records can be digitised through OCR before structured extraction and clinical validation. EthMed does not replace hospital information systems; it creates a harmonised analytical and coordination layer.

AI modelling framework

The AI framework is explicitly separated into clinical application, target definition, data handling, model development, validation, performance assessment, fairness assessment and deployment. This structure follows the reporting logic recommended by TRIPOD+AI and related prediction-model guidance [8] (Table 2).

Data handling will prevent patient-level leakage by ensuring that repeated observations from the same individual remain in the same partition and that temporal information used for prediction is available only before the prediction time. Missingness will be described and clinically interpreted; imputation, when appropriate, will be performed within training folds. Candidate predictors will be prespecified, and feature selection will not use the held-out test set. Internal validation will use bootstrap or nested cross-validation as appropriate, while temporal and/or external validation will be performed before clinical deployment. Performance assessment will include discrimination (e.g., AUROC and, for imbalanced outcomes, area under the precision-recall curve), calibration-in-the-large, calibration slope and calibration plots, sensitivity, specificity, positive and negative predictive values at clinically meaningful thresholds, Brier score and decision-curve analysis where appropriate. Fairness assessment will compare discrimination, calibration and error rates across sex, age, major ethnic groups, highland/lower-altitude setting and other relevant subgroups. Model cards, versioning, data provenance, uncertainty estimates and post-deployment drift monitoring will be maintained. Deployment will use a staged gate: research-only model → silent prospective evaluation → clinician-visible decision support → controlled clinical pilot → broader deployment. AI outputs will display confidence/uncertainty information, data-quality warnings and recommended next steps. The final clinical decision remains with qualified health professionals.

Blockchain governance and security model

Blockchain is justified only for governance functions that benefit from a shared, tamper-evident record across organisations. Conventional centralised audit logs remain preferable when one trusted authority controls all participants and rapid correction of audit records is required. Alternative technologies include append-only databases, WORM storage, signed event logs and conventional PKI-backed audit systems. EthMed proposes permissioned blockchain because community health posts, district/provincial facilities, specialist institutions and research partners may require independent verification of consent and access events without placing clinical records on a public ledger. The network is envisaged as a permissioned consortium. Nodes may be operated by authorised health-system or research institutions rather than anonymous participants. A crash-fault-tolerant or Byzantine-fault-tolerant permissioned consensus mechanism appropriate to the selected platform should be configured after institutional requirements are defined; the exact consensus protocol will be fixed during implementation rather than assumed at the conceptual stage. This avoids claiming a particular performance profile before benchmarking. Identity and key management will use institutional identity providers, PKI, role- and attribute-based access control, MFA and managed cryptographic keys. Key rotation, revocation, recovery and separation of duties will be documented. Smart contracts will be limited to explicit governance functions: recording consent status and purpose, authorising or denying access requests, recording revocation events, and writing audit references. Smart contracts will not contain full clinical data or irreversible personal identifiers. Consent management will be purpose-specific and revocable. The off-chain consent service stores the human-readable consent record, while the ledger stores a cryptographic reference, timestamp, authorised purpose, version, and revocation status. A clinician or researcher must therefore satisfy both institutional access controls and the consent policy before data are released. Data minimisation, encryption in transit and at rest, TLS 1.3, AES-256, PKI, data masking, differential privacy for research datasets, incident response and periodic access review remain mandatory; blockchain does not replace these controls.

Digital-twin methodology

EthMed uses the term digital twin only for a computational representation that has: (1) a defined state vector representing the individual or clinical system; (2) a persistent linkage to the real-world subject through governed identity references; (3) repeated data assimilation and state updating; (4) an explicit model that maps current state and new observations to updated state or predicted trajectories; (5) uncertainty estimation; (6) validation against observed longitudinal outcomes; and (7) a defined clinical or operational use case. A conventional one-time risk score that predicts an outcome from baseline variables is therefore not labelled a digital twin. The first stage is a risk twin. Its state may contain age, diagnoses, blood pressure, glucose, BMI, smoking or exposure variables, laboratory indicators and contextual determinants, and it produces continuously updated probabilities for selected conditions. The second stage is a physiology twin, which models trajectories such as blood pressure, glucose, BMI, oxygen saturation or functional status. The third stage may integrate genomic or pharmacogenomic information only after governance, consent, technical validation and clinical utility are established. State updating will occur when new validated observations enter the longitudinal record. Each update will carry a timestamp, data-quality status and provenance. Uncertainty will be quantified through predictive intervals, ensemble variance or calibrated probabilistic outputs depending on the model family. Validation will compare predicted trajectories with subsequent observed measurements using calibration, trajectory error and clinically relevant thresholds. Model drift will trigger revalidation rather than silent updating. Clinical applicability will be restricted to use cases in which a clinician can interpret the state, uncertainty, and recommended action (Table 3).

Evaluation framework

Evaluation is conducted at five levels. Technical evaluation measures uptime, data completeness, FHIR/DICOM conformance, latency, integration success, cybersecurity controls and audit-log integrity. AI evaluation measures discrimination, calibration, sensitivity, specificity, F1 score where appropriate, subgroup fairness, uncertainty quality and clinical utility. Clinical workflow evaluation measures referral appropriateness, time to consultation, chronic-disease follow-up, adherence and health-worker workload. User evaluation measures acceptability, usability, trust, language support and perceived cultural appropriateness. Governance evaluation measures consent comprehension, data-access transparency, privacy incidents, institutional compliance and research readiness. Demonstration will use representative end-to-end scenarios: community registration and consent; collection of symptoms and vital signs; import of laboratory/imaging information; AI risk assessment; low-, medium- and high-risk routing; teleconsultation; consent revocation; and research-access audit. Validation will proceed from technical verification to retrospective model validation, then silent prospective validation and finally controlled clinical implementation. No clinical deployment is authorised solely based on software demonstration.

Results

Overall architecture

The EthMed architecture contains six layers. Layer 1 is community access through mobile applications, web portals and assisted-use interfaces at commune health stations. Layer 2 is data acquisition and interoperability connecting symptoms, EHRs, laboratory results, imaging, wearable devices and contextual variables. Layer 3 is secure data storage using structured databases and medical data-lake storage. Layer 4 is AI analytics for risk prediction, stratification, early warning, summarisation and decision support. Layer 5 is telemedicine and referral coordination linking commune, district, provincial and specialist services. Layer 6 is governance for consent, identity, provenance, audit trails and controlled research access (Table 4).

Priority health pathways

EthMed prioritises health pathways where early detection and longitudinal monitoring can produce substantial benefits. For adults, the initial pathways include hypertension, diabetes, cardiovascular risk, stroke risk, chronic respiratory disease, chronic kidney disease, musculoskeletal disease and prolonged fatigue. For children and maternal-child health, the initial pathways include malnutrition, anaemia, respiratory infection risk, immunisation follow-up and maternal risk screening. For all groups, the platform records social and environmental determinants relevant to mountainous communities, including cold climate exposure, indoor smoke from cooking fuel, water safety, workload, nutrition, distance to care and traditional medicine use (Table 5).

These pathways are prioritised because they combine a meaningful prevention or early-detection opportunity with data that can reasonably be collected or imported in primary-care settings. They should not be interpreted as evidence that EthMed improves outcomes for these diseases; they define the initial implementation scope to be evaluated.

Expected operational workflow

A typical workflow begins with community registration and purpose-specific consent. A health worker or user enters demographic information, symptoms, vital signs, and available historical records. Laboratory and imaging data are imported when available. The data-quality layer checks completeness and plausibility. The AI layer then generates a preliminary risk profile with uncertainty and data-quality warnings. Low-risk users receive education and scheduled follow-up; medium-risk users receive additional testing or commune-level follow-up; high-risk users are referred for teleconsultation or in-person care. Governance services record consent and authorised data-access events. Doctors review the AI-supported summary, verify clinical relevance and make final decisions.

Expected outputs and validation

The expected outputs are: a minimum viable EthMed platform; a community health dataset of at least 3,000 individuals; an interoperability module using FHIR and DICOM-compatible design; disease-specific AI models developed only where outcome-specific sample-size requirements are met; a telemedicine workflow; a governed consent and audit module; and a staged roadmap toward validated digital health twins and multimodal AI. Additional outputs may include implementation guidelines for commune health stations, user manuals, software copyright registration, and peer-reviewed publications. The framework adds explicit validation gates. Gate 1 verifies data and interoperability; Gate 2 verifies model development and retrospective performance; Gate 3 evaluates temporal/external validity and fairness; Gate 4 evaluates silent prospective performance and workflow safety; Gate 5 evaluates controlled implementation and post-deployment monitoring. Failure at a gate requires refinement or restriction of the relevant component rather than progression by default.

Discussion

The EthMed concept addresses a structural gap in digital health: the mismatch between advanced AI platforms and the realities of remote, culturally diverse populations. Telemedicine platforms often emphasise convenience, EHR systems focus on hospital administration, and AI applications narrow to predictive or imaging tasks. EthMed integrates these components around prevention, early detection, remote consultation, secure data sharing, and long-term personalised care. Compared with Epic/MyChart, EthMed places less emphasis on patient-portal functions embedded in mature hospital systems and more emphasis on community-level screening, AI risk stratification and assisted access. Compared with Teladoc Health, EthMed treats teleconsultation as part of a longitudinal record and risk-management pathway rather than primarily as an on-demand consultation service. Compared with symptom-checking platforms, EthMed combines symptoms with laboratory, imaging, wearable, contextual and EHR data. Compared with blockchain-centred health-record concepts, EthMed deliberately keeps full clinical data off-chain and limits the ledger to governance and provenance.

The priority health pathways illustrate why an integrated rather than disease-isolated platform is appropriate. Hypertension, diabetes and cardiovascular risk share repeated measurements and referral infrastructure; respiratory risk can incorporate environmental and occupational exposures; child malnutrition and maternal-child pathways require community-level follow-up; kidney disease requires longitudinal laboratory and blood-pressure monitoring. A common interoperability and governance layer can support all of these pathways while allowing disease-specific models to be validated independently. This is preferable to claiming that one AI model can safely cover all conditions. The methodology also changes the interpretation of the 3,000-person target. It is sufficient as a transparent initial platform cohort and can support several common-outcome models under appropriate assumptions, but it is not automatically adequate for rare outcomes or highly granular subgroup analysis. This staged approach is consistent with the principle that prediction-model sample size should be tied to outcome events and model complexity rather than a single arbitrary participant number.

The AI framework strengthens reproducibility by separating development data from validation data, preventing patient-level and temporal leakage, reporting discrimination and calibration, and requiring subgroup fairness assessment. This is particularly important for ethnic-minority health because an apparently strong overall model can conceal systematic miscalibration or unequal error rates in smaller groups. Local language support, assisted use and community engagement are therefore part of model safety rather than merely interface design. The blockchain decision is similarly narrower and more defensible after revision. A conventional centralised audit log may be cheaper and simpler when a single trusted controller exists. A permissioned ledger becomes useful when multiple institutions need a shared record of consent and access events and no single institution should be able to rewrite the historical governance record unilaterally. Even in that case, blockchain contributes integrity and shared provenance, not complete cybersecurity; IAM, encryption, endpoint security, privacy engineering and institutional accountability remain essential. The digital-twin roadmap is intentionally conservative. A longitudinal risk model is not automatically a digital twin. EthMed requires persistent state representation, data assimilation, updating, uncertainty, and validation before the terminology is used. The risk-twin stage can therefore be implemented earlier, while physiology and precision twins remain research stages. This staged architecture reduces the risk of premature claims and creates measurable validation requirements.

As the study results, it recommends the following policy and implementation steps. First, provincial health authorities should establish interoperable data-governance agreements before large-scale data integration. Second, community health workers should be treated as essential participants in data quality, interpretation and referral rather than passive users of technology. Third, AI procurement should require transparent model documentation, subgroup validation, uncertainty reporting and human override. Fourth, digital-health programmes should fund connectivity, devices, training and maintenance alongside software. Fifth, traditional-medicine information should be captured respectfully and subjected to scientific evaluation without allowing it to replace appropriate biomedical diagnosis. Sixth, research governance should distinguish clinical care, service improvement and secondary research, with purpose-specific and revocable consent. These recommendations align with the broader direction of digital-health ecosystem development and the need to assess implementation rather than technology alone [9-11]. The proposed architecture is therefore intended to be scalable beyond Lao Cai, but transfer to other regions should require local requirements assessment, language adaptation, data-quality evaluation and governance review [12-20].

Limitations and future work

This paper presents a conceptual architecture rather than clinical trial outcomes. No claims are made about diagnostic accuracy, reduction in morbidity, cost-effectiveness or patient outcomes. The proposed AI models require locally collected, ethically approved and quality-controlled datasets. The 3,000-person cohort is an initial target, not a universal power calculation for all endpoints. Rare diseases, complex imaging tasks and detailed subgroup analyses may require substantially larger multi-site datasets. The initial AI capabilities are expected to rely primarily on established machine-learning algorithms and foundation models rather than a completely new medical AI model developed from scratch. This reduces development time and can facilitate implementation, but existing models may not represent the epidemiological characteristics, ethnic diversity, environmental conditions, lifestyle factors, traditional-medicine practices and healthcare-access constraints of remote Vietnamese communities. Domain adaptation, local validation and continuous monitoring are therefore essential. Foundation models may also be insufficiently transparent. Future work should incorporate explainable AI, uncertainty quantification, safety monitoring, model cards, version control and human-in-the-loop governance. Prospective validation, independent safety assessment and, where appropriate, randomised or quasi-experimental implementation studies are required before clinical effectiveness claims can be made. For the digital-twin component, future work must establish validated state-space models, data-assimilation methods, uncertainty quantification and longitudinal benchmarks. For blockchain, future work should benchmark the permissioned architecture against conventional append-only audit systems on latency, cost, availability, recovery and governance burden. For the overall platform, implementation research should quantify referral completion, time to specialist consultation, health-worker workload, user trust and subgroup equity.

Conclusion

EthMed is proposed as an AI-enabled, blockchain-governed and digital-twin-ready health platform for ethnic-minority communities and other remote populations with limited direct access to high-quality healthcare. The framework integrates community screening, EHR interoperability, AI risk prediction, telemedicine, secure storage, governed consent and a staged digital-twin pathway. Its principal novelty is the alignment of these technologies with an equity-oriented implementation model for mountainous and culturally diverse settings.

This paper clarifies that EthMed is a design-science artefact and research framework, not a clinically validated product. Its proposed 3,000-person cohort is an initial platform and common-outcome modelling target, while disease-specific sample-size calculations are required before each model is locked. AI deployment is gated by retrospective, temporal/external and prospective validation; blockchain is limited to governance functions for which a shared ledger has a defensible advantage; and the digital-twin label is reserved for longitudinal, updating, uncertainty-aware and validated computational representations. The next step is therefore a staged pilot followed by rigorous technical, clinical, ethical, fairness and implementation evaluation before any clinical or policy claims are made.

Conflict of Interest

The authors are members of the research team developing the EthMed platform. No commercial product has been released, and no financial benefit has been received from the technology described in this manuscript.