While prior work has advanced digital disease surveillance, gaps remain in interoperability, scalability, and multi-source data integration. Most solutions rely on REST APIs that lack agility for real-time data streaming and complex event processing. In addition, heterogeneity in geospatial, clinical, and entomological data limits the application of fine-grained access controls and automated sharing protocols. This work addresses these gaps by proposing a unified, cost-effective ICT platform that enables real-time integration of multi-source data, improves flexible data exchange, and supports actionable field intelligence in low-resource, high-burden settings.

This paper addresses the identified research gaps through the following contributions:

1) IntegratedInteroperabilityArchitecture: The platform maps FHIR resources (e.g., Observation, Location, Patient) to a unified GraphQL schema, enabling single-query access across heterogeneous datasets and reducing over-fetching and latency compared to REST-based applications.

2) AutomatedSchemaMapping: A semantic mapping engine transforms nested FHIR JSON structures into Graph Mapped Data Structures (GMS), maintaining semantic interoperability while providing fine-grained attribute-level access control, essential for protecting patient privacy.

3) Real-timeSpatialIntelligence: Using PostGIS, the system performs high-performance spatial queries (e.g., ST_DWithin, Kernel Density Estimation) and hotspot analysis with Getis-Ord Gi* statistics (z-scores and p-values), enabling rapid detection of disease clusters and timely vector control interventions.

1) SemanticInteroperability: Uses the FHIR.resources library to ensure every incoming record strictly adheres to HL7 FHIR R4/R5 standards before transformation.

2) ReducedOver-fetching: By flattening the highly nested FHIR JSON, the platform allows front-end mobile apps to request only the specific fields (e.g., testType and result) needed for field surveillance.

3) Scalability: The FastAPI architecture supports asynchronous data processing, which is essential for handling high-velocity diagnostic data during disease outbreaks.

4) Cost-effective: Reduction of hardware expenditure by 40% - 60% compared to conventional automated microscopy solutions

4.1.1. Primary Geospatial Data Capture Mechanism

In this, GraphQL-Mediated Middleware is used to bridge heterogeneous HL7 FHIR clinical data sources with PostGIS spatial databases, reducing dependency on inflexible REST-based APIs, and Security is achieved through Attribute-Based Access Control (ABAC) and Geo-OIDC for authentication and hotspot tracking. Figure 1 below shows method one for demonstrating an interoperable health surveillance platform with GraphQL middleware integrating low-cost Automated Computer Supported Specimen Imaging edge node prototypes to a PostGIS geospatial database, demonstrating data flow from mosquito and clinical data sources to a real-time dashboard.

Figure 1. Depict GraphQL middleware architecture, ACSSI edge node prototype, and data flow & dashboard system.

1) GraphQLMiddlewareArchitectureDiagram

Purpose: Show how our GraphQL layer integrates multiple data sources (HL7 FHIR, PostGIS) and resolves the inflexible REST API bottleneck.

Elementstoinclude:

HL7 FHIR clinical databasePostGIS geospatial databaseGraphQL middleware (central node)REST-based APIs (optional, showing “inflexible” connections)Clients/Applications: Dashboard, Mobile AppFlow arrows showing query aggregation, schema translation, and data delivery

2) ACSSIEdge-NodePrototypeDiagram

Purpose: Illustrate low-cost, automated mosquito specimen imaging and edge processing.

Elementstoinclude:

Edge hardware (camera + mini-computer)Specimen trayACSSI software (TinyML classifier)Output: vector classification → GraphQL middlewareLow-bandwidth connection to server

3) DataFlowandDashboardDiagram

Purpose: Show end-to-end flow from mosquito/clinical data capture → GraphQL → dashboard + hotspot alerts.

Elementstoinclude:

Mosquito data (ACSSI) + Clinical case data (HL7 FHIR)GraphQL middleware for integrationPostGIS databaseDashboard (maps, graphs)Real-time alerts (Geo-OIDC authentication + ABAC control)

Figure 2 is a smartphone and microcomputer-based setup, which illustrates the flow from the physical ACSSI hardware at the edge to the GraphQL/PostGIS core.

4.1.2. Secondary Geospatial Data Capture Mechanism

The Automated Computer-Supported Specimen Imaging (ACSSI) approach functions as a secondary geospatial data capture mechanism. Deployed as a low-cost IoT edge node, it combines commodity optics, smartphone imaging, and Raspberry Pi or BeagleBone microcomputers to enable automated, point-of-collection specimen digitization with high spatial accuracy. Images and metadata are preprocessed locally to minimize payloads for GSM/4G or Ethernet transmission under intermittent connectivity. Data are sent to a central PostGIS spatial engine, with diagnostic outputs encoded as HL7 FHIR Observation resources and exposed via GraphQL for real-time querying alongside historical surveillance data. Figure 2 illustrates the proposed system architecture of the smartphone-based surveillance platform.

Figure 2. System architecture of the smartphone-based surveillance platform.

A key challenge in decentralized disease surveillance is the secure sharing of sensitive patient-level diagnostics and precise geospatial data. The proposed platform addresses this through a multi-layered security architecture combining GraphQL field-level authorization and Attribute-Based Access Control (ABAC).

Field-levelauthorization: The GraphQL layer enforces fine-grained permissions on individual fields rather than entire resources. For example, field technicians may access only location and test type, while patient identifiers remain restricted to clinical staff, adhering to the principle of least privilege and reducing accidental exposure.

Context-awareaccess(ABAC): Data visibility is dynamically determined by attributes such as user role, assigned region, and device location. Policies evaluated at the resolver level automatically filter geospatial queries to records within the user’s jurisdiction.

Securegeospatialsharing: To balance transparency with privacy, PostGIS-based spatial masking applies geospatial k-anonymity or aggregates cases into statistically significant clusters before transmission, ensuring compliance with healthcare data protection standards.

The proposed Automated FHIR-to-GraphQL Schema Generation Algorithm maps input in the form of a FHIR resource (StructureDefinition JSON) to an output GraphQL schema (Schema Definition Language string).

Step1:ResourceIntrospectionandPrimitiveMapping

This step involves parsing the FHIR ElementDefinition to map basic clinical data types to GraphQL scalar types.

Action: Iterate over all elements defined within the snapshot component of the resource structure.

Logic:

dateTime, instant → String (or custom ISO 8601 scalar)

decimal, integer → Float, Int

boolean → Boolean

id, base64Binary → ID, String

Step2:FlatteningNestedChoiceTypes

FHIR commonly uses choice-type elements (denoted by “[x]”) to allow multiple data types for a single attribute (e.g., valueString or valueQuantity).

Action: Identify elements that use the “[x]” suffix to indicate multiple possible types.

Logic: Generate either a GraphQL union type or a set of flattened fields.

Example:

A value element that supports multiple types (e.g., quantity or coded concept) is transformed into separate GraphQL fields such as valueQuantity and valueCodeableConcept within the same type.

Step3: Complex Type and Reference Resolution

FHIR extensively uses reference types to link resources (for example, linking an observation to a patient).

Action: Identify elements whose type corresponds to a reference.

Logic: Replace raw reference strings with GraphQL object-type relationships.

Transformation:

Instead of representing a reference as a string (e.g., “Patient/123”), define a structured relationship such as:

subject: Patient!

Step4:MultiplicityandCardinalityAdjustment

The algorithm evaluates minimum and maximum occurrence constraints defined in the FHIR resource.

Action: Examine the minimum and maximum cardinality values for each element.

Logic:

If the maximum cardinality allows multiple values, represent the field as a list: [Type]

If the minimum cardinality is at least one, mark the field as non-nullable: Type!

Step5:PostGISIntegration(CustomSpatialExtension)

To support geographic data capture, the algorithm identifies location-related elements.

Action: Search for location-related resources or extensions associated with geographic coordinates.

Logic: Map latitude and longitude components of position data to a custom spatial type (e.g., a Point) or to an array of floating-point values to support PostGIS queries.

Step6:SchemaDefinitionLanguage(SDL)Assembly

Action: Combine all mapped types into a final GraphQL schema definition string.

Result(IllustrativeExample):

typeObservation{

id:ID!

status:String!

subject:Patient

valueQuantity:Quantity

#CustomSpatialField

coordinates:[Float!]

}

The mosquito classification model was evaluated using a labeled dataset of 2400 specimen images collected from field deployment. Data were split into 80% training and 20% testing. Table 1 below summarizes recent approaches to mosquito and larvae classification, highlighting model types, tasks, and performance metrics.

Table 1. Comparison of mosquito and larvae classification models and their performance.

As summarized in Table 1, recent deep learning approaches for mosquito identification typically report accuracy and F1-scores between 90% and 99% under laboratory or high-quality imaging conditions. While transformer-based models achieve near-perfect performance, they require substantial computational resources. In contrast, the proposed ACSSI classifier operates on low-cost commodity off-the-shelf hardware using lightweight edge inference, achieving approximately 92% accuracy and 0.89 F1-score. Although slightly lower than laboratory benchmarks, this performance is sufficient for practical field surveillance while enabling real-time, decentralized, and cost-efficient operation.

An autonomous mosquito surveillance and smart fogging system was implemented using a distributed edge-cloud architecture to enable real-time sensing, actuation, and remote monitoring.

At the edge layer, the Automated Computer-Supported Specimen Imaging (ACSSI) node integrates an ESP32 microcontroller, temperature and humidity sensor (DHT22), gas concentration sensor (MQ-series), infrared-based mosquito activity detector, GPS module for geo-tagging, and an automated fogging actuator. Sensor measurements are sampled at 5 s intervals and locally preprocessed to reduce network transmission overhead. Threshold-based anomaly detection is executed on the node, and fogging is triggered only when mosquito activity and environmental risk indicators exceed predefined thresholds.

Communication between edge devices and the cloud backend is achieved via Wi-Fi/4G connectivity. The backend exposes services for data ingestion, device control, historical data storage, and real-time visualization.

Two middleware communication approaches were implemented and evaluated:

1) RESTful API using HTTP/JSON endpoints

2) GraphQL API using a single query endpoint

Both middleware implementations were deployed on identical server hardware to ensure experimental consistency. The backend stack consists of a NodeJS application server, MongoDB database, GraphQL resolver engine, and a web-based monitoring dashboard.

ExperimentalSetupandEvaluationMetrics

System performance was evaluated in terms of communication efficiency and scalability using the following metrics:

Latency (ms): elapsed time between request submission and response receptionThroughput (requests/s): number of successfully processed API requests per secondCPU utilization (%): average processor usage on the backend server

Latency measurements were obtained using a Python-based benchmarking tool that records high-resolution timestamps at request dispatch and response receipt. Each experiment was repeated across multiple iterations, and mean values were computed to reduce measurement variability.

LoadTestingMethodology

Concurrent client workloads were simulated using multi-threaded request generation to approximate realistic IoT traffic patterns. Load tests were conducted for request rates ranging from 10 to 200 requests per second for both REST and GraphQL services. This methodology enabled evaluation of system responsiveness, scalability, and computational overhead under increasing load.

Results

1) LatencyRESTvsGraphQL

The GraphQL-based implementation consistently demonstrated lower average response latency compared to the REST-based approach. This reduction is primarily attributed to minimized over-fetching and the consolidation of multiple endpoint requests into a single query. Figure 3 illustrates an observed latency reduction of approximately 30% - 40%.

Figure 3. Depicts the average latency comparison between GraphQL and REST.

2) ResponseTimeRESTvsGraphQL

The GraphQL implementation consistently achieved lower average response times than the REST approach. This improvement stems from single-endpoint queries and reduced over-fetching, which decrease network round-trips and processing overhead, yielding faster end-to-end responses. As illustrated in Figure 4, GraphQL response times are over 50% shorter than those of REST.

Figure 4. Depicts the response time comparison between GraphQL and REST.

3) ThroughputRESTvsGraphQL

Under identical experimental conditions, the GraphQL service sustained a higher number of requests per second compared to the REST service. As shown in Figure 5, the observed throughput improved by approximately 20% - 30%.

Figure 5. Depicts the throughput comparison between GraphQL and REST.

4) CPUUtilization

Backend CPU utilization was slightly lower for the GraphQL implementation, reflecting reduced request-handling overhead and consolidated query processing. As shown in Figure 6, the observed CPU usage decreased by approximately 10% - 15%.

Figure 6. Depicts the system CPU usage comparison between GraphQL and REST.

5) CostAnalysis:

Table 2 presents the cost comparison between the ACSSI prototype and conventional alternatives for specimen imaging and processing.

Table 2. ACSSI prototype cost breakdown.