Mobile-based, offline, asynchronous architecture community oral and dental health screening, data management, and decision support system (Molaris: Examination-Focused Local Oral Risk Monitoring System)

Abstract

This invention encompasses a mobile-based data management and decision support system (Figure 1) and its associated methodology, incorporating an offline-first asynchronous synchronization architecture (Figure 2), a multi-layered epidemiological analytics engine from a community health perspective (Figure 4), and a verifiable digital document infrastructure, all specifically designed for oral and dental health field screenings. The system consists of a Local Persistent Data Repository (LPS), Change Tracking and Queue Management Module (CTQM), Collision Resolution Engine (CRE), Link Status Monitor (CM), multi-layered Community Health Analytics Engine, QR code-based Digital Health Record infrastructure, and a four-level hierarchical user role architecture as shown in Figure 3. The invention structurally distinguishes itself from existing clinical information management systems by its ability to operate without internet dependency, its hybrid processing of individual and community data, and its capacity to collect oral and dental health data of disadvantaged groups in a standardized structure. Keywords: Offline-first architecture, asynchronous synchronization, community oral and dental health, epidemiological analytics, mobile health application, disadvantaged group monitoring, digital health record, QR code verification, triage engine, hybrid data processing.

Description

1 TARIFF A SOCIETY WITH A MOBILE-BASED, OFFLINE, ASYNCHRONOUS ARCHITECTURE. ORAL AND DENTAL HEALTH SCREENING, DATA MANAGEMENT AND DECISION SUPPORT SYSTEM (MOLARIS: Examination-Focused Local Oral Risk Monitoring System) 5 1. SCOPE OF THE INVENTION This invention has implications for the field of oral and dental health, particularly for itinerant / mobile health services and schools. screenings, home care services and access to healthcare for disadvantaged groups with limited access Designed for field studies; offline-first asynchronous synchronization architecture, intelligent data validation, multi-layered public health analytics, and 10 A mobile-based, end-to-end digital gateway that offers a verifiable digital document infrastructure in one place. and dental health screening, data management and decision support system, and the methods and procedures related to this system. It relates to architecture. 2. PREVIOUS TECHNICAL AND TECHNICAL PROBLEMS 2.1 General Structure of Existing Systems 15 Current clinical software and hospital information management systems (HIMS) provide a fixed healthcare system. operating with a constant internet connection within the institution, and the flow of individual patients by appointment. It is built on an architecture based on treatment processes. These systems; Dental4Windows, Dentimax, Eaglesoft, Carestream Dental and similar commercial products It includes the widely used Hospital Information System (HIS) infrastructures in our country. These software programs comprise 20... They are all designed with a focus on individual clinical treatment and from a public health perspective. It lacks the necessary infrastructure for collecting and analyzing epidemiological data. 2.2 Technical Problems Identified in the Previous Technique Current solutions have the following critical technical problems: (a) Online Dependent Architecture Problem: All existing systems are client-server 25 Its architecture requires a continuous and stable internet connection. The internet connection... school buildings that are limited or unavailable, rural areas, temporary health screening points, and Data entry is not possible on mobile devices; the entire workflow stops when the connection is lost. (b) Lack of Public Health Analytics: Data in traditional clinical software is individual They are stored in the form of patient records; categorized by age group, school, neighborhood, district or region. Comparative epidemiological analyses can only be performed using external software and require extensive manual effort. This is possible through intervention. (c) Lack of Hybrid Data Processing Capacity: Anonymizing individual clinical data and processing data for the community A hybrid data processing architecture capable of converting health data into statistics is included in existing systems. It does not receive. 35 2 (d) Data Entry Not Optimized for Field Conditions: Existing software has high patient volumes. Optimized to meet the needs of field teams working under high volume and time pressure. It has not been implemented. Standardized intelligent selection list, mandatory field checking and real-time data. It lacks verification mechanisms. 5 (e) Lack of Specific Monitoring Infrastructure for Disadvantaged Groups: Home care patients, people with limited access to health services, such as migrants, rural residents, and people with disabilities. systematically and comparablely record oral and dental health data of the groups Area-specific infrastructure is not included in existing solutions. (f) Lack of Inter-Agency Digital Approval: 10 regarding scanning permission in existing systems The inter-institutional process is entirely based on paper correspondence, and the documents created... There is no digital signature or verification infrastructure in place to ensure its verifiability. 3. BRIEF DESCRIPTION OF THE INVENTION This invention, MOLARIS, was developed to solve the technical problems described above. (Examination-Focused Local Oral Risk Monitoring System) is a mobile-based, end-to-end digital oral 15 and dental health screening, data management and support system, and offline-before related systems. It relates to an asynchronous synchronization method. The general architecture of the invention is referenced in Figure 1. with numbers (100)-(505), offline-online switching method in Figure 2 (S1)-(S10), User role hierarchy shown in Figure 3 (R1)-(BDS) and from individual data to societal analytics. The data flow is shown in Figure 4 (A)-(F2). 20 The main technical innovations of the invention are: (i) offline-first, independent of the connection state. (ii) asynchronous local storage and intelligent synchronization architecture; public health (iii) Multilayer parameter correlation and epidemiological analysis engine from the perspective of; Hybrid data is the process of anonymizing individual clinical data and transforming it into public health analytics. (iv) processing structure; (v) intelligent data entry modules specific to field conditions; (iv) hierarchical user 25 Roles and digital inter-institutional approval workflow; (vi) QR code / verification code based Verifiable digital health record and institutional record infrastructure. 4. DETAILED DESCRIPTION OF THE INVENTION 4.1 System Architecture Overview The MOLARIS system consists of five main architectural layers, shown in Figure 1: Mobil 30 Client Layer (100), Local Data Layer (200), Synchronization Bridge Layer (300), Central Application Server Layer (400) and Analytics and Reporting Layer (500). This Multi-layered architecture, seamless data delivery regardless of the system's internet connection. It enables the ability to perform summation and allows for batch synchronization. 3 Figure 1 — MOLARIS system architecture: (100) Mobile Client, (200) Local Data, (300) Synchronization, (400) Server, (500) Analytics 5 4.2 Offline-First Asynchronous Synchronization Architecture (Key Technical Innovation) The most original technical component of the invention is its structural shift from a standard client-server architecture. It is an offline-first asynchronous synchronization architecture that differs in this respect. The architecture is shown step-by-step in Figure 2 with reference numbers (S1)-(S10), and there are four It consists of 10 technical sub-components. 4.2.1 Local Persistent Data Store — LPS (201): All running on the mobile client (100) examination data, patient identification information, medical history records, dental findings, and treatment LPS is a database module that stores planning outputs in encrypted form on the local device. (201), fully functional data entry and query operations without internet connection It ensures its execution. 15 4.2.2 Change Tracking and Sequence Management Module — CTQM (202): on LPS (201) A timestamp and transaction identifier (transaction ID) for each data operation performed. It generates change logs containing these changes. These logs are used in conflict resolution. They are stored in a queue structure according to priority. 4 4.2.3 Collision Resolution Engine — CRE (203): On the same patient or scan record When multiple field teams are updating in parallel, conflicting records can occur over time. automatically resolves the data based on the data stamp, record priority, and data integrity rules. or the module that submits it for administrator approval. 5 4.2.4 Connection Status Monitor — CM (301): Continuously monitors the network status of the device and As soon as the connection is established, the changes in the CTQM (202) queue are automatically transferred to the central office. It is the background service that transfers data to the server (400). Data transfer is differential (302). This process ensures that only the changed data is transmitted. Figure 2 — Offline-online transition flow: (S1) initiation, (S2) CM monitoring, (S3) decision, (S5) LPS recording, (S6) CTQM queue, (S9) CRE collision resolution 4.3 Hierarchical User Role Architecture The system defines four main user roles, each with a different level of authority and workflow. The hierarchy is shown in Figure 3 with reference numbers (R1)-(BDS): – Administrator (R1): System definitions (R1-a), creating and submitting scan projects (R1-5) b), analytical access (R1-c), geographic and organizational governance (R1-d). – Dentist (R3): Viewing active scans (R3-a), patient examination and data entry (R3-b), treatment planning and prioritization (R3-c), digital health record creation (R3-d). – Institutional Authority (R2): Approve or reject the scanning project (R2-a), digital 10 Creating and downloading QR code-based verification documents (R2-b). – Patient / Guardian (R4): Authentication via Turkish Republic ID number and SMS-OTP (R4-a), Access to and sharing of digital health record (R4-b). Figure 3 — Hierarchical user role architecture: (R1) Administrator, (R2) Institutional Officer, (R3) Dentist, (R4) 15 Patient / Guardian, (BDS) Document Verification Service 6 4.4 Screening Project Lifecycle and Inter-Agency Digital Approval Workflow The administrator (R1) creates a scan project (R1-b) in the system; the health personnel to be assigned to the project Personnel, screening dates, target institution, and geographic parameters are defined. The project, system. The invitation is sent electronically to the authorized representative (R2) of the target institution. The institution's authorized representative can access the portal 5. They review the project and approve (R2-a) or reject it. A QR code is provided for approved projects. A Digital Certificate of Approval (R2-b) containing a verification code is automatically generated. 4.5 Field Condition-Specific Intelligent Data Entry Modules The Dentist (R3) interface within the Mobile Client Layer (100) is specialized as follows: Includes modules: 10 – Quick Identity Recognition Module (101): Turkish Republic ID card NFC / barcode reading or Patient identification and demographic information is automatically entered into forms via manual entry. It transfers. – Dental Scheme Module (102): FDI (Fédération Dentaire Internationale) Single or 15 adult and primary tooth diagrams, in accordance with the numbering system. It supports rapid finding entry with multiple tooth selections. – Treatment Prioritization Engine (103): Treatments according to the entered clinical findings automatically according to urgency level (Critical-T1, High-T2, Moderate-T3, Routine-T4) It is the sorting module. – Visual Documentation Module (104): Instantaneous taking of intraoral photographs and related 20 Association with tooth / finding record. 4.6 Verifiable Digital Health Record and Institutional Record Once the examination is complete, the system will provide each patient with a unique verification code and a QR code. It creates a Digital Health Record (B1) containing individual clinical data, as shown in Figure 4. It is stored in this scorecard structure (B1) before being transmitted to the anonymization layer (C1). 25 The patient or their guardian can access the health record (R4-a) using their Turkish Republic ID number and SMS-OTP, and select different health records. submits to their organizations. A Digital Institution Scorecard (F1) is created for the scanned institution. The institution can then upload this document as a PDF. It can be downloaded as (F2) and used as a basis for health policy decisions. Document The Authentication Service (BDS) processes QR code or verification code queries in real time over 30 days. By responding, they confirm the authenticity of the document. 4.7 Multilayered Public Health Analytics and Reporting Engine As shown in detail in Figure 4, Analytical Motor (500) analyzes individual clinical data. Epidemiological studies operating in the following submodules via the anonymization layer (C1) It includes one engine: 35 – Performance Analytics (501): AI accuracy rate, bedside examination time, and data. integrity metrics. – Oral Findings Analytics (502): Caries, fillings, gum problems and missing teeth prevalence; regional caries map; triage distribution. 7 – Demographic Analytics (503): Age group distribution (0-6, 7-12, 13-18, 18+), gender risk analysis according to. – Geographic Analytics (504): Province, district and neighborhood based health index; regional risk map. 5 – Corporate Analytics (505): Distribution by institution type; institution-specific health score. Figure 4 — Data flow: (A1)-(A4) raw data, (B1) Health Record, (C1) anonymization, (C2) analytical engine, (D1)-(D2) outputs, (F1)-(F2) Institution Report Card 10

Claims

8 5. REQUIREMENTS Independent Claim 1: Structured to conduct oral and dental health screenings in field conditions, as shown in Figure 1. Based on the five-layered architecture shown, a mobile-based, offline-first asynchronous 5 An oral and dental health screening, data management, and decision support system with a synchronization architecture. It is a system, and the system consists of the following components: – all examination, medical history, and treatment planning data without internet connection. a Local Persistent Data Store (LPS) (201) which stores in encrypted form; – Tracking every change on LPS (201) with a timestamp and transaction ID and 10 a queue that is sent to the central server (400) when a connection is established Change Tracking and Sequence Management Module (CTQM) (202); – timestamping and prioritizing conflicting records from parallel field teams A Collision Resolution Engine (CRE) that automatically resolves according to its rules. (203); 15 – automatically triggers the CTQM (202) queue when network connection is established and A Connection Status Monitor that transmits only the changed data in a differential manner. (CM) (301); – individual clinical data were anonymized and regional (504) as shown in Figure 4, a multilayered 20 that correlates with demographic (503) and epidemiological parameters Public Health Analytics Engine (500); – Verifiable Digital Health Card (B1) containing QR code and verification code. Infrastructure for generating Institutional Scorecards (F1). Independent Claim 2: 25 An offline-first asynchronous data collection and synchronization process for the system in Claim 1. The method shown in the flowchart in Figure 2 involves the following steps: It includes:

1. The Internet connection status on the mobile client device can be viewed using the Connection Status Monitor. Continuous monitoring by CM (301) (S2); 30 2. All examinations, medical history taking, and treatment planning, regardless of relationship status. recording of data in encrypted form to LPS (201) (S5); 3. Time-stamped by CTQM (202) for each transaction recorded in LPS (201). Creation of change log and synchronization queue (S6); 4. Upon CM (301) detecting a network connection, 35 in the CTQM (202) queue Transfer of changes to the central server (400) in a differential manner (302) (S8); 5. Detecting conflicting records by CRE (203) on the central server and time automatic resolution according to the stamp and priority rules or by the authorized user Submission for approval (S9); 9 6. After the synchronization is completed, the central database (400) of LPS (201) Consistency and logging of the transfer record (S10). Dependent Claim 3: The system in Claim 1 is the Community Health Analytics Engine (500); age group, gender, 5 decay based on school, neighborhood, district and regional parameters (C2-i, C2-ii, C2-iii, C2-iv) prevalence, filling distribution, periodontal problem rates, and triage level distributions a multi-layered system that calculates and produces regional health index outputs (D1, D2) It is characterized by containing a parameter association sub-engine. Dependent Claim 4:10 The system in Claim 1, and the anonymization layer (C1) shown in Figure 4, is the individual clinical examination data using the K-anonymity principle and sectoral data anonymization. By anonymizing it in accordance with the rules, it is fed into the Public Health Analytics Engine. (500) is characterized by what it transmits. Dependent Claim 5:15 The system in Claim 1 is the Digital Health Record (B1) infrastructure; unique for each patient. A document signing module that generates an alphanumeric verification code and a QR code, TC Patient identification with identification number and SMS-based one-time password (OTP) Verification module (R4-a) and QR code / verification code query in real time. The Document Verification Service (BDS) responded by stating that it contains 20 features. is being done. Dependent Claim 6: The system in Claim 1 is the field data entry interface; for the FDI numbering system. suitable interactive dental diagram module (102), standardized anamnesis selection lists, Rule-based instant validation with mandatory field and format validation rules 25 Treatment engine that automatically suggests urgency ranking (T1-T4) based on clinical findings. Prioritization Engine (103) and intraoral photographs with the relevant findings record It is characterized by containing the Visual Documentation Module (104) which relates to it. Dependent Claim 7: The system in Claim 1 is shown in Figure 3, consisting of Administrator (R1), Dentist (R3), and Institution 30. Four levels of hierarchical user roles: Authority (R2) and Patient (R4). Creating an inter-institutional screening project with its architecture (R1-b), digital invitation transmission, the steps of institutional approval / rejection (R2-a) and generating a digital QR code approval certificate (R2-b) It is characterized by including a comprehensive Digital Inter-Agency Approval Workflow. is being done. 35

Images