Direct Laboratory Notification of Communicable Diseases

6.2 Privacy

The Health Act 1956 allows for named patient information to be shared for the purpose of protecting the public health. However, all health-related information relating to individuals must still be adequately protected.
Some notifiable conditions (AIDS and sexually transmissible infections) are, or will be, notifiable on either an anonymised or an unnamed basis. AIDS notification presently utilises an anonymised code set out in Schedule 1 of the Health (Infectious and Notifiable Diseases) Regulations 1966. The diagnosing clinician assigns an anonymous code (set out on the paper case report form) and sends this via the PHU to the AIDS Epidemiology Group. AIDS cases are not entered onto EpiSurv. Only the diagnosing clinician is able to identify a patient, based on the code used for AIDS notification. From 2008 HIV will be made notifiable on an anonymous basis using the special case report form available on the ESR website.
Notifications for HIV should not be sent to, or entered onto, Episurv.
In the near future (early 2008), the addition of conditions such as chlamydia, gonorrhoea and syphilis will require ‘unnamed’ data to be captured. Unnamed notifications are likely to be linked with a patient’s NHI number (a unique identifier) and so are not anonymous. For this reason, additional security, provided through an electronic system such as role-based security (ie, blocking certain information from general view) will be the ideal solution to ensure individual privacy. By using an electronic solution, access to patient-level data for all other diseases and conditions will be restricted to the staff at the responsible (local) PHU. All identifiable information will be blocked from the view of ‘national users’.
Electronic data transfer will require the use of SSL encryption, digital certificates, closed networks and/or other means to ensure security. See section 6.5, ‘Security requirements’, for more information.

6.3 Notifiable disease database

Internationally, many surveillance systems rely on, or are moving towards, electronic reporting of notifiable diseases. To be effective, such reporting must be timely and accurate, and the system user-friendly and low-cost.
Functional areas to be supported by an electronic notifiable disease reporting information system include:

1. information receipt – the capability to capture data either electronically or manually (web-based); a schematic overview of the information flow is detailed in Figure 5

2. case processing (ESR, EpiSurv) – the recording of cases of notifiable disease and subsequent investigation details

3. contact tracing – the recording of contact tracing information

4. outbreak reporting – the recording of outbreak information, with links to individual cases

5. analysis – providing functionality and tools to enable temporal, demographic and spatial analysis of data

6. reporting – providing tools to extract data in tabular, graphical and geographical formats.
Figure 4 summarises the national electronic notification process. Section 6.4 provides more information about the system’s functionality requirements.
Figure 5: Electronic laboratory notification process

6.4 System functionality

Data will be managed at the PHU provider level but will not be physically restricted to a single location or office. All data will be available in real time at a national level (see section 6.11). Security arrangements will allow a PHU to view and report on their local data in detail, and to view and report on national data at a summary level.
The system will:

• 
  support the ability to receive data from external systems (eg, laboratory information management systems and practice management systems)
  
• 
  support the relevant messaging and coding standard(s) (eg, HL7, LOINC and NZPOCS)
  
• 
  support geographical information system (GIS) capability
  
• 
  support reporting capability at a local PHU and national level
  
• 
  support notifiers to notify electronically or manually
  
• 
  support condition-specific design and functionality
  
• 
  support privacy and freedom of information legislation and policies
  
• 
  parse relevant data (if parsing is not possible, data will be able to be viewed in a human-readable format to enable manual processing)
  
• 
  alert users that new results are available for viewing
  
• 
  assign, or be able to display, results by priority
  
• 
  allow attachments in the following formats: .doc, .pdf, .txt, .xls, .qes, .rec, .jpg, HTML
  
• 
  support integration with local case management systems
  
• 
  control functionality through the access level assigned to individual users
  
• 
  include activity logs (audit trails) with the ability to show who (which user) made changes to the data and what changes were made
  
• 
  ensure data security (eg, audit trails and user identification, encryption, secure SSL certificates)
  
• 
  be able to support 100 concurrent users and ‘significant’ volumes of electronic messages (eg, during a serious epidemic)
  
• 
  improve data quality through more rigorous validation at data point-of-entry
  
• 
  provide a national and local view of the data in real time
  
• 
  enable sharing and re-use of data for epidemiological analysis
  
• 
  automatically parse, process and store information with minimal user intervention
  
• 
  include or allow for contact tracing management, analysis and reporting functionality
  
• 
  allow ad hoc searches over multiple criteria across different components of the system
  
• 
  be flexible, configurable and expandable and allow for increased functionality  it is expected that in future, further functionality required by system users will be able to be included in the system
  
• 
  be designed to ensure flexibility to make minor changes (centrally) without application development change
  
• 
  allow for de-notification of a case upon receiving additional information from a clinician or a laboratory
  
• 
  be designed to allow for the future use of mobile technologies (eg, PDAs).