DRAFT
System Compatibility, Integration, & Interoperability
Guide
System Compatibility, Integration, & Interoperability are related concepts that define stages of connectedness between systems. In order of increasing complexity:
| Concept | Definition | SRS Example |
|---|---|---|
| Compatibility | Systems operate independently and do not interfere with each other’s functioning. They may have been planned with interoperability in mind, but the systems are not linked. | An SRS that has separate IT systems and data formats from existing CRVS and medical processes; systems acknowledge each other’s existence, but do not communicate. Siloed. |
| Interoperability | Interoperability refers to a “loosely-coupled system [whose] components […] are connected by a communication network”1. Interoperable systems are compatible, function independently, and also facilitate some type of data exchange. Data Exchange is the method(s) by which systems can be linked. | An SRS that collects CRVS death data within SRS event collection and transmits those deaths to the CRVS organization—whether manually or electronically—would be interoperable with differing degrees of data exchange. |
| Integration | Integration refers to “the concepts of coordination and coherency”1 between systems; an integrated system functions as a single unified solution. Integration extends interoperability to create systems that are dependent on each other to achieve the end outcome 2. | An SRS that automatically generates death notifications within a CRVS system would be considered integrated. |
Full integration is something that should be core to the design of every SRS. However, at the outset of an SRS project, IT teams should be focused on assisting SRS program staff with understanding the scope and scale of other candidate systems for integration. The goal of this design phase is to identify key pieces of information that need to be shared – and what initial level of compatibility or interoperability will facilitate future integration. Full integration will not happen at the beginning of the SRS program. Rather, the SRS should be designed with integration in mind and launched with compatible and interoperable steps towards that integration.
At a minimum, SRS programs should be designed to enable information sharing; however, such integration does not need to be complex implementations of standards and data exchange. For example, if a country would like to integrate SRS with an existing CRVS processes, simply collecting data according in a compatible format and sharing on a manageable schedule is an appropriate initial goal. This could be as simple as the CRVS team providing an interface for the SRS team to upload a table of deaths. If the interface programming structures are built upon APIs, this can form the basis for a future integrated and automated exchange.
Tech Tip: Think Big, Implement Small
When discussing integration, it is very easy for IT teams to go down a path of “how can we develop a standard or an automated way for these systems to communicate” or “how can we build a fully integrated system by initial launch?” That should always be a future focus, and current systems should be designed with that goal in mind. However, to launch a usable SRS now, refocus the conversation on requirements design to build stakeholder consensus. First determine which systems need to be integrated and the reasons for that integration. Create a detailed list of variables to be shared and consider sharing structures. Which stakeholders need to buy into this plan to facilitate success? Providing simple semi-manual versions of integration now will facilitate complex data exchange later.
After the SRS is launched and initial compatibility and interoperability design elements are tested, the IT teams can focus on moving towards full Integration. Full Integration and automated data exchange is complex, particularly in this context where SRS systems deal with protected identifiable and health information in the context of relevant country regulations. For these reasons, there is no one-size-fits-all approach to interoperability and integration to recommend to SRS country teams. However, we can break the discussion of interoperability into two parts:
- Application programming interfaces (APIs) facilitate the communication between software systems, using;
- Standards to define shared data elements according to an established set of criteria
A detailed discussion of data linkage can be found in the main VIVA site. Information is summarized below.
APIs
Easy methods exist to set up an API to enable quick access to information housed within SRS systems, and some of those methods are discussed in Software. Key questions to determine when establishing an API include:
- Serve or Consume? If an application serves an API, it exposes a set of functionality or data that other applications can access. To do so, the API often defines endpoints. By contrast, if an application consumes an API, it uses an API created, hosted, and exposed by another system. For example, in an SRS context, the SRS team may create an API endpoint to format all death registration data for the CRVS agency to consume.
- Complete or Incremental? Each API will either be complete or incremental. When an application consumes data from a complete API, it access the entire dataset each time; if the API were to be incremental, the application would access only the new data since the last access. The more data in the system, the less efficient a complete API becomes.
Standards
To properly configure application programming interfaces (APIs) that facilitate the communication between software systems, the data elements to be shared need to be organized according to an established set of criteria known as standards. With these standards, the software systems can expect certain data elements in a certain format, making them usable in applications. While the HL7 Fast Healthcare Interoperability Resources) (FHIR) serves as a benchmark for healthcare interoperability, specific standards are not currently configured for SRS data.
Given the early stages of SRS implementation in countries, most existing standards are not useful; to date, no countries have fully implemented data exchange protocols between SRS and other relevant systems. HL7 FHIR standards do exist in other countries for related applications, and a selection of those standards are linked below in Tools. Adapting these existing standards for use in SRS could be a useful future project for global SRS governing and technical assistance bodies, to enable and facilitate cross-country information sharing.
Tools
APIs
None
Standards: United States National Center for Health Statistics Vital Records
The United States has a decentralized system of vital records reporting, where regional offices register births and deaths and need to report those events up to the federal National Center for Health Statistics (NCHS). To enable this reporting, NCHS has released two HL7 FHIR standards that could be adapted for use in similar SRS contexts.
- Vital Records Death Reporting (VRDR)
- Specifies death certificate data elements intended for submission of mortality records to NCHS
- Covers the data elements that appear on a death certificate such as decedent identity, demographic information, cause of death, etc.
- Vital Records FHIR Messaging (VRFM)
- Defines business rules for exchanging information between regional offices and NCHS, which may inspire the integration approach
- VRFM describes an asynchronous data exchange approach with multiple message types
Software
APIs
Modern API frameworks, including the ones mentioned above, can be built in a self-documenting way with a user interface to provide documentation. A set of possible frameworks to consider are listed below as a place to start, as opposed to a comprehensive set of resources.
- Python-based
- R-based
Note: This approach is utilized within the VA Explorer software, discussed earlier in Data Science to allow access to the InterVA5 and pyCrossVA CCVA services.
Standards
No software exists to support SRS standards because no SRS standards exist.
Stories
Mozambique
Public Data Sharing
Mozambique has a large success story related to public data sharing. They host a public data sharing site where data are regularly updated, deidentified, and made available to requesting researchers for academic study.
| Last updated |
|---|
| 23 October 2025 |
| Portions of this page are © 2025 The MITRE Corporation. All rights reserved. Approved for Public Release #25-2779. Distribution Unlimited. The source of this information is the Technical Assistance for Sample Registration Systems (SRS) Planning Grants, a joint project of the CDC Foundation and Swiss Tropical and Public Health Institute through the Gates Foundation SRS Grant. |
-
Panetto, H., & Cecil, J. (2012). Information systems for enterprise integration, interoperability and networking: theory and applications. Enterprise Information Systems, 7(1), 1–6. https://doi.org/10.1080/17517575.2012.684802 ↩ ↩2
-
Panetto, H. (2007). Towards a classification framework for interoperability of enterprise applications. International Journal of Computer Integrated Manufacturing, 20(8), 727–740. https://doi.org/10.1080/09511920600996419 ↩