Open Immunization Software - Spring 2016

Admin User Manual

Developer Manual

Database ERD v1.08

The latest version of the database ERD can be found here: ERD v1.08.pdf

Complete documentation of all fields needs to be rewritten. Until then the documentation for ERD v1.00 covers nearly 90% of the current database and gives a good grounding in the basic thoughts behind the layout of the database.

Database ERD v1.00

In DQA v1.00 most of the DQA functionality is hidden unseen in the database structure. A thorough understanding of the DQA database design will allow a user to make full use of the functionality. In later versions the DQA will expose the data and control available in the database design.

Database Tables

ERD Diagrams

How to read the following diagrams:

Application Level - ERD Page 1

User Account

Contains a list of users that can access the DQA. Currently only used to authorize the admin user who can access the configuration user interface.


Represents a single reporting entity. The DQA was not built to model every organizational structure that exists, but rather a simple hierarchy that applies for submitting entities. As of version 1.00 this is not depended on for specific logic.

Submitter Profile

A submitting organization sends data and it is classified under a profile. The profile contains settings, characteristics, status, and reports associated with this imported data. Normally an submitting organization would only have one profile, but others would be defined if the organization sends data from more than one system or one account is dedicated for testing.

Potential Issue Status

Indicates the specific status for a given profile and potential issue. This table allows for setting the error/warning/accept/skip status for a specific issue for a specific profile. When creating a new profile the DQA populates this table based on the defaults defined by the base profile associated with the report template. In version 1.00 there is no UI to change potential issue status, but changing it in the database will affect the specific profile.


Represents different installed versions of the DQA. While only one application can run at a time, this allows for dynamically reconfiguring DQA to run as any available application.

Report Template

Represents the settings for a DQA report that may be run on a submitting profile. For version 1.00 most applications will run only one type of DQA report for all import profiles. In the future, when many different kinds of interfaces are developed, DQA reports may be created to represent the characteristics expected for particular sets of interfaces. (For example, the DQA report template for a birthing hospital may be different than one for a family practice.)

Issue Action

Represents the type of actions that can be taken for a given issue.

Potential Issue

Represents the total set of possible issues that the DQA is sensitive to. In version 1.00 not all issues have been implemented. The most important and crucial issues are implemented, the other were not because (1) implementation requires a large amount of effort or (2) the issue is a low priority issue. Eventually all issues will be implemented as improvements are made.

Report Type

Represents the general category for this report. This is so reports from different applications can be grouped in similar categories. These categories are expected to grow as the DQA is used to test different kinds of data sources.

Database Log

Represents comments that were made during upgrades to the DQA database. This can be used to track changes made and also to determine the current version of the database. The latest updated row, with the largest change id is the one considered to indicate the current version of the database.

Report Vaccine Group

Represents a vaccine group that may appear on the DQA report. In version 1.0 this is not used, but in the future this will be used to indicate for this template what vaccinations are expected to be administered. This will allow for creating a list of vaccinations that are expected to be seen from a particular submitter. At this point the DQA report XML defines the vaccine groups globally as DQA users are currently not making profile-by-profile changes.

Keyed Setting

Represents a specific setting tied to a key and an object. This is used for cascading settings. If no value is set then the application will pick a default.

Core Validation - ERD Page 2

Batch Issues

Represents a summary of issues found for the associated batch. This table includes all issues identified in the batch of messages, even those that have A : Accept as a value.

Batch Actions

Represents a summary of actions taken on messages in the associated message batch.

Batch Vaccine CVX

Represents a summary of vaccinations identified and resolved to a known CVX code. This differs from Batch Code Received in that a submission that includes CPT and not CVX will still be reprsented here in this table. The DQA validation process resolves the codes sent to a single CVX code which is the source of counts here. In this way this table may be used to tally the concepts received without regard to the actual code set used. To see counts of what was actually received see the Batch Code Received table.

Batch Report

This is shown on Page 2 of the ERD in order to show how it relates. The full batch report table is shown on page 3.

Receive Queue

Links the received message into a particular batch. Each received message may be associated with one or more batches. Typically a message is first associated with a 'Submission' batch and then at the end of the week to a 'Weekly' batch. At this point the message is considered to be both part of a 'Submission' batch and the 'Weekly' batch. This table makes this possible.

Message Batch

Represents a set of messages that have been grouped together under a particular critiera. For example, all messages that were submitted together in a single file, or all messages that were submitted within a week and are not ready for import into the IIS. Each message batch has associated tables that support the DQA report.

Batch Type

Indicates the type of batch.

Batch Code Received

Represents a summary of the codes received in this batch. Every coded value that is received is represented in this table. If the code value is not received it is not listed here.

Message Received

Represents a single message that has been submitted. Every submitted message that is from an authorized submitter will be recorded here, even if the message has errors. (Unauthorized users are rejected from sending data into DQA and that data is never stored.)

Submit Status

Represents the status of a message or batch in being exported and submitted to the IIS. This table only applies when the DQA is setup to export data out.

Code Table

Represents all the tables that are supported for mapping.

Code Master

An authoritative list of all the known valid values for the Code Tables. These are the values defined by state and local standards.

Issue Found

Represents and identifies that an issue was found when looking at a message received. Every message received normally has a hundred or so issue. Not all issues are errors, and many are expected during normal operation.

Code Received

Represents an actual code value received for a particular submitter profile. The DQA records all code values received, valid or not, recognized or not recognized in this table. In this way it is easy to see exactly what codes are being send and which are not for a particular submitting profile.

Code Status

Represents the current state of a code received or code master value.

Data and Reports - ERD Page 3

Batch Report

Represents the summary data that makes the bulk of the official DQA report. This information is stored here in detailed level in order to support aggregate analysis of all DQA reports generated. For details on how each of these fields are calculated, please see the instructions on how to read a DQA report.


Represents the patient data received. Special notice should be given that this table is similar to a Patient table that may be found within an IIS, but should not be thought of as serving the same purpose. The key difference is that this table can have null or empty values where normally the IIS would not and that there is no attempt to merge duplicate patient information. For example a patient record may have no name and still be listed here, and if the patient is submitted more than once that information will be entered in different rows of this table. This is because this table does not represent a consolidated patient record but rather the record that was received by the DQA at one time. For this reason this table puts very little constraint about what data is populated and allows for a wide range of valid and no-valid values.

Next of Kin

Represents a parent, associated party, next of kin, responsible party, or guardian that has been included with the patient data.


Represents a submitted vaccination. Please note that this table is a corollary with similar tables in most IIS, but is has important differences. This table contains all data received and may be missing required fields. Also, data is not deduplicated and represents a copy of every report received without any merging The DQA can merge data before exporting but does not do that at this point.

Data and Reports - ERD Page 4

Message Header

Represents the message header information received. If the message was not in HL7 format many of these fields will not have values.

Vaccination Meta Data - ERD Page 5

Vaccine Group

Represents a grouping of vaccinations that contain a common component that targets a specific disease. This is used to group vaccines together that are similar for reporting purposes and to determine if reports of expected vaccinations are being received.

Vaccine CVX Group

Joins the Vaccine Group to a Vaccine CVX concept. A CVX code can belong to more than one group.

Vaccine CVX

Vaccine Product

Represents a specific vaccine product with its generic name. This table joins the manufacturer and a specific vaccine.

Vaccine CPT

Vaccine MVX

Represents a vaccination manufacturer. There is a lot of changes in this area as manufacturers merge and names change. The codes shown here represent their use across time.