Design and implement the system

Understanding what data are available, and where those data CAN and NEED to be shared, you can now design and implement an OHSS that addresses the agreed upon objective(s).

This process is benefited by relevant stakeholder involvement, although an iterative process cycling through drafting/re-drafting by the working group then presentation for discussion to the stakeholders until a satisfactory result is arrived at would likely be an efficient approach. 

The surveillance pathway outlined below can be used as the starting point to begin to design your OHSS. In most cases, the steps prior to the point where data sharing will occur will not need to be addressed in your OHSS given that they are determined by the existing system.

It may be helpful to establish what attributes the group believes are important for the surveillance system you are designing. The important attributes will help shape the system. In general, flexibility and sustainability are two attributes flagged as important for long-term success of OHSSs. Other attributes to consider are acceptability, timeliness, sensitivity and data quality. No system can perform well against all attributes and therefore, deciding which are a priority for your system will be important.

Considerations for designing a system that integrates data or information at the:

Data transfer and collection (storage) stage

Sharing of individual level data is often considered the holy-grail of data or information sharing across surveillance systems. While many systems set out to achieve this initially, few exist in practice. This is likely a result of both the practical and legal difficulties with sharing this level data.

 

Specific considerations

  • What relational database will be used to manage the data?
    • Will you add to an existing database from one of the surveillance systems to be integrated or create a new purpose-built data-base?
  • Which variables will contribute data?
  • What transformation (text to numbers etc) and recoding of data will be required?
    • How can this process be automated?
  • Will individual level or aggregated data be shared, if so what level of aggregation will be used?
  • Will all data be shared or only subsets?
  • Who will have access to the data?
    • Will filters be used to define what level of access users have to the data?
  • Who will analyse and interpret the data, and how will the data be analysed and interpreted (data analysis plan)?
    • A common criticism or concern of sharing data in this manner is the possibility of it being analysed and subsequently interpreted without the background sectoral context and, thereby, produce misleading results. This criticism or concern can be addressed by ensuring that each sector is representated at the data analysis and interpretation step.

Data analysis

This approach allows a level of standardisation between the analyses and therefore improved multi-sectoral interpretation of the information, without the obstacles of sharing individual level data.

Specific considerations

  • When will the data be analysed (how frequently)?
  • How will the data be analysed (produce clear data analysis plans)?
  • How will the analysis results be shared between sectors?
  • How often will the analysis results be shared between sectors?
  • How will the results be interpreted?
    • Will all sectors be represented to avoid misinterpretation based on lack of sectoral context?

Data Interpretation

OHSS that share data analysed within their own sector at the interpretation stage are the most common OHSSs encountered. There are a number of reasons why this approach may be popular. It often grows out of existing relationships between the sectors, where regular or reactive communication and information sharing are already in place.

Specific consideration   

  • How will analysis results be jointly interpreted?
    • If by joint discussion at meetings:
      • How often will meetings be held?
        • Regularly or reactively to a situation?
        • If reactively – what is the trigger to initiate a meeting?
      • Who will attend the meetings?
      • Will meetings be held in person, or virtually?
        • Experience has shown that physical meetings are important for building relationships and trust between participants, meaning they should not be overlooked for the convenience of virtual meetings. A feasible approach can be to hold virtual meetings with physical meetings interspersed at regular intervals (eg every 3rd meeting)
      • Is there a succession plan in place to ensure that when an existing member requires replacement (eg retires, or moves to another employment), that the replacement is sufficiently introduced to the group to be trusted
    • What information will be shared?
Other Considerations

Regardless of where along the surveillance pathway data or information are shared, every OHSS will need to consider how outcomes are communicated and how the system will respond to, and prioritise signals, if and when they occur. These activities are beyond the scope of this guide but are covered in detail elsewhere.

The last aspect that requires consideration and inclusion into the surveillance system design is the evaluation plan. This is described in more detail next.

**Beta Version** - not for further distribution