This Implementation Guide contains the specifications for COVID19 case reporting.

• This implementation guide and set of artifacts are still undergoing development.
• This content is only for demonstration purposes only.
• Providing Feedback: Please submit any issues via the Feedback link next to the appropriate section of the implementation guide

Introduction

There is a need for countries to centralize and report on COVID19 data that is captured at the point of service systems by effectively monitoring and measuring individuals diagnosed with the disease and their status towards being up-to-date vaccinated. The COVID19 vaccination status of Up-to-date Vaccinated refers to those individuals who have been fully vaccinated (received all doses for the Primary Vaccine Series) and received all doses for the specified Booster Vaccine Series.

This is a content specific implementation guide that has been derived from the COVID19 Minimum Dataset in order to effectively report on COVID19 cases.

The Business Description for this implementation guide offers more detail in regards to its purpose.

Technical

Background

Establishing a Health Information Exchange (HIE) with the purpose of enabling COVID19 case reporting is a very challenging task. Therefore, this implementation guide identifies a suitable reference platform architecture to assist those in need of establishing an architecture as such. This implementation guide will provide the messaging standards specification for the Data Integration Strategies & Implementation (DISI) reference platform architecture and implementations alike that are concerned with COVID19 case reporting.

DISI proposes to create a standards-based reference platform architecture that would allow multiple countries to adopt a similar framework for generating reports that they require. Currently, there are two DISI Reference Implementations for data centralization and reporting, one for HIV and another for COVID19.

The DISI architecture brings forth a set of components that are common among HIV and COVID19.

The below generic architecture illustrates the high-level components for DISI and implementations alike to support case reporting in a HIE. For a more technical representation of the DISI architecture to support case reporting, please see the DISI Component Architecture.

Messaging & Testing

This specification defines the key FHIR messaging bundles needed to support COVID19 case reporting & lab integration.

Using an application called Postman, you will be able to submit requests (message bundles) to the DISI Platform for processing & reporting.

There are two Postman Collections namely:

1. COVID19 Case Reporting
2. COVID19 Lab Integration

Please see our Postman Collections for COVID19 as well as the descriptions for each of the message bundles that exist in each postman collection.

Each of the these postman collections have been tailored to support end-to-end testing between the EMR and lab systems. Moreover, each collection comes with a set of postman variables which have been designed to randomly populate data for all key fields in all resources. This is a great way to carry out exploratory testing.

The use of postman variables also allows you to statically initiate variables to actual values you need.

Another way is to automate end-to-end testing over the data pipeline till the point that case report data is available in the analytics platform.

Target audience for this Implementation Guide

This Implementation Guide is targeted at the following typical audiences:

• SMEs, Health program managers and specialists, informaticists who wish to consult the architecture for case reporting.
• Healthcare IT analysts who wish to design or integrate systems for case reporting, case surveillance.
• Technical designers who must implement such case surveillance and reporting systems and their interfaces.

Cross Version Analysis

Dependency Table

Globals Table

IP Statements

Intellectual Property Considerations

While this implementation guide and the underlying FHIR are licensed as public domain, this guide may include examples making use of terminologies such as LOINC, SNOMED CT and others which have more restrictive licensing requirements. Implementers should make themselves familiar with licensing and any other constraints of terminologies, questionnaires, and other components used as part of their implementation process. In some cases, licensing requirements may limit the systems that data captured using certain questionnaires may be shared with.

Disclaimer

This specification is provided without warranty of completeness or consistency, and the official publication supersedes this draft. No liability can be inferred from the use or misuse of this specification, or its consequences.

Credits and Acknowledgements

This specification is based on FHIR and the FHIR tooling ecosystem and community processes. It has been defined with the support and participation of the following institutions.

Institutions

• Centers for Disease Control and Prevention (CDC)
• Program for Appropriate Technology in Health (PATH)
• Jembi Health Systems (Jembi)

Contributors

• Jose Costa Teixeira (PATH) - Co-author
• Chris Seebregts (Jembi) - Project Sponsor & Co-author
• Richard Langford (Jembi) - Author
• Marius Naude (Jembi) - Co-author
• Xhanti Mdyeshana (Jembi) - Co-author

Viewers

• Wendy Blumenthal (CDC) - Project Lead
• James Kariuki (CDC) - Project Sponsor
• Kendi Mburu (PATH) - Project Manager