This is a FHIR Implementation guide for HIV Case Reporting developed as part of the DISI initiative.

This documentation and set of artifacts are still undergoing development. This content is only for demonstrative purposes.

The top menu allows quick navigation to the different sections, and a Table of Contents is provided with the entire content of this Implementation Guide.

Introduction

This FHIR IG describes how and submit HIV case reports to a central server conforming to the DISI architecture. The profiles created in this IG correspond to the minimum dataset for HIV case reporting defined for the DISI architecture. This minimum data set may be found here. This dataset is fundamental to this implementation guide and form the basis for the entire architecture.

The sections that follow describe how to submit case reports conforming to the minimum data set and link out to the profiled resources to specify exactly what is required to be submitted. If an implementation requires additional modifications it is suggested a new IG be created that used this one as a base and further specifies additional rules on the already profiled resources.

Submitting case reports

Case report may be submitted in one of three different ways. For more detail about which may be best to choose see the DISI architecture documentation . The transactional approaches allow the submission of a patient per request whereas the batch approach allows the submission of multiple patient per request. The three approaches are:

• FHIR Native (transactional) - this approach allows applications with advanced FHIR capabilities to submit a case report as a FHIR document bundle. This approach gives maximum control over how resources are created and referenced, however, is also more complex to implement.
• FHIR Naive (batch) - this approach allows applications to submit case report as simply as possible via CSV even if the submitting application does not support any FHIR capabilities. It also allows for batches are case reports to be submitted which further simplifying application functionality by preventing the individual handling of request per patient. It does however come which certain caveats which are discussed in the DISI architecture documentation
• FHIR Aware (transactional) - this approach allows applications to submit case reports using FHIR but in a simple way by utilizing a single resource: the QuestionnaireResponse. This is much simpler to implement while remaining FHIR compliant. This approach follow the FHIR Structure Data Capture implementation guide.

FHIR Bundle

When submitting as a FHIR bundle you may submit individual HIV sentinel events or a full case report with multiple sentinel events. The FHIR bundle must be structured as a FHIR document with a Composition resource as the first item in the bundle entries. The Composition resource has a section per sentinel event. Each of those section references the other FHIR resources (one or more) that hold the actual data relating to that sentinel event. See the profile for that Composition resource which show the structure of each section and links to the other profiled resources: Profiled Composition

The FHIR document is to be submitted to a FHIR transaction endpoint using an HTTP POST conforming to the core FHIR specifications.

​A full example of a case report bundle with all sentinel events filled in can be seen here.

CSV

To allow for simple batch import of case reports, data may be submitted in a CSV format. A sample of the expected CSV format can be found here. The headers must be exactly as stipulated in this example and repeating fields are handled by joining values together in a single column separated by a '|' character.

The CSV must be submitted using an HTTP POST with a content-type header of 'text/plain' and the raw csv text in the HTTP body.

FHIR QuestionnaireResponse (not yet implemented)

This section is not yet developed. When defined it will allow entire case reports to be submitted using a single FHIR QuestionnaireResponse resource. This allows for standards based data submission while still remaining simple to implement.

Intellectual Property Considerations

While this implementation guide and the underlying FHIR are licensed as public domain, this guide includes 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

The specification herewith documented is a demo working specification, and may not be used for any implementation purposes. This draft 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.