Working with the systems public health already has
Government public health departments rarely start with a blank slate. Disease notifications might arrive in one database, laboratory results in another, while outbreak investigations depend on spreadsheets, specialist applications or technology introduced during COVID-19. Some systems have been in place for decades. They may be expensive to replace, difficult to modify, or essential to services beyond infectious disease surveillance.
Introducing another application can add to this fragmentation. Sentinel's longer-term direction is to work alongside established technologies, allowing public health units to adopt its investigation and surveillance capabilities without requiring wholesale replacement of their existing systems.
Why interoperability matters
Much of the burden of fragmented technology falls on public health staff. The same information can be entered repeatedly, changes may be missed between systems, and staff are left reconciling cases and reports by hand. During an outbreak, those problems become harder to manage just when reliable information is most important.
Interoperability should make it easier to use information already available elsewhere, coordinate actions across organisations and preserve a consistent understanding of the people, cases and events under surveillance. It also offers a practical way for departments to evaluate Sentinel using existing data and workflows before deciding whether to use it operationally.
Proposed first step: guided CSV import
The first development stage is an epidemiologist-led import wizard. A user could upload an existing CSV export, identify the source and record types, map fields to Sentinel, and specify information shared by all records, such as disease, laboratory method or jurisdiction.
An import could create related records where appropriate: matching a patient, finding or creating a case under the applicable rules, then associating a laboratory result or exposure. Proposed records would enter a staging table, allowing users to inspect, correct and approve them before changes are applied.
Duplicate matching would distinguish genuinely new records from existing patients, cases and episodes. Staff could choose how conflicts are reviewed, while Sentinel retains source identifiers and a record of decisions so repeated imports do not unintentionally duplicate the same information.
Respecting epidemiological decisions
Connecting systems must not undermine the principles governing surveillance. Information received from another system is an assertion from that source. It does not automatically become Sentinel's accepted case classification, nor should it override a reviewed result simply because a new file contains a different value.
Imported data would remain subject to existing disease configurations, case definitions, laboratory rules, authorisation, validation, duplicate detection and manual overrides. Uncertain matches or consequential conflicts would be staged for review. Later, approved integrations could automatically process routine valid changes while exceptions remain visible to surveillance staff.
From imports to ongoing connections
Once the initial import and review process is established, the same framework could support repeat imports and monitoring for new or modified data. Further development would include scheduled checks, APIs and connections to existing government integration infrastructure.
Sentinel should be integration-engine agnostic. A department already using enterprise middleware should be able to connect through documented interfaces rather than install a second integration platform. Likewise, an epidemiologist should be able to start with a CSV file without needing a technical integration project.
Supporting gradual adoption
One organisation might retain its statutory notification database and use Sentinel only for outbreak investigations. Another may eventually use Sentinel as its primary operational workspace while continuing to exchange information with laboratories, analytics platforms and other agencies.
Future shadow-evaluation functionality could allow selected existing data to be replayed or compared in an isolated Sentinel environment without sending live notifications or altering the source system. Organisations could identify functional gaps and evaluate a transition before changing operational processes.
Planned development
- CSV import and staging: source identification, guided mapping, common values, related records, duplicate review and authorised approval.
- Repeat imports and monitoring: saved configurations, external identifiers, change detection, reconciliation and exception reporting.
- External connectors: governed APIs, adaptable interfaces and compatibility with existing integration engines.
- Bidirectional exchange: approved outbound data, event processing, traceable disclosures and synchronisation.
- Shadow evaluation: controlled parallel trials and comparison with established systems.
The objective is to reduce the effort required to introduce Sentinel into established public health environments, without creating a new source of inconsistent or unauthorised surveillance information.
Status: Proposed future development. The integration wizard and general synchronisation framework are not implemented in the current release. Sentinel already provides narrower HL7 laboratory integration and survey data mapping capabilities.