Index - Major Sections
Home

**InHCc HMIS**

Site Map
Health Economic and Reform

Benefits

Discussion

Data and Data Analysis

Health Management

Product and Services
References
Team

_______________

Index - Same Level Subject

Index - Child Subjects

Introduction

In order to Maintain the integrity of the data procedures must be available for two types of changes:

• Correction: Corrections of information that has been previously entered and was found to be in error

• Version change: Changes in the standards where the coding is changed 

• Rule Changes: Changes in the validation of data through business rules.

• Data tables Additions: The requirement of new data collection requires that new tables, data structures, data forms, and data presentation methods be developed.  

Rule Changes

Validation is generally used to verify and check inconsistencies in recorded information. Although there are "rules" that are followed at the time of data entry, other checks such as family relationships, household relationships must be consistent.

This validation program searches through all records and reports any inconsistent information. The report is then given to the responsible HCP to verify.

This report will be run before the "final commitment" to the centralized data warehouse. At any time previous to this local information may be corrected by the responsible HCP.

Any information that has already been committed to the centralized data warehouse must be corrected through the Correction Protocol.

Validation Procedure Examples

• All addresses reported by Clients are matched with a Household ID and the detail Household Record
• Spouses/Partners are reported as "belonging" to each other. i.e. both partners report the other as a partner.
• Move From and Move To addresses must be consistent in the client address files.
• etc

Version Changes

There are two different events that can trigger a "Version" change. 

• A change in the client information
• A change in the "standards" being used to code the client information

Only authorized personal are allowed to enter new or change coding standards.  This will usually take place at the international or national level. 

Version Control Problem

Many systems implement well-known version control paradigms which tracts the particular "version" of a change in a record, process, software, etc. 

What is important in studying relationships between variables is the timely of these events and what is happening at the SAME TIME. 

An example: 

We want to analysis the relationship of family planning practices to education. 

Data is obtained on the client on 10 July 1996: education level - 6 grade

Data is obtained on the client on 1 June 1998: education level - 7 grade. 

Data is obtained on the client at 10 September 1997: Husband does not use condoms. 

Data is obtained on the client at 10 September 1999: Husband does uses condoms. 

Can we relate the education level - 7 grade with the data obtained in 1999?

Versioning allows you to obtain the latest (newest information) on each client. ie using our example

Client ID         = 1089

Education        = 7 grade

Condom use    = yes 

But Can we use this data to determine the relationship between the variables? The answer is NO! 

Version Control

Each series of codes (Standards) will have a version number (each code will have two parts

• The Code 
• The Version of that code

An Example may be a code of "1012"  for "30 minute Family Planning Consultation"

The Version may be "1" 

-> coded internally as 1-1012

If at some future time if the code of "111012" is assigned to "30 minute Family Planning Consultation" then it will have a version of "2." The computer will "know" to pull the description from the version 2 file. 

In this way codes can be changed and also tracked over time. 

Change in Client Information

Whereas the Client Master #1 has only unvarying time information, the Client Master #2 has time-varying information. 

The Version Number is an identifying number that tracks the relationship of events over time. When a condition changes, the Version Number changes. Whenever, ANY information is changed in a record the Version Number in the record will be Updated and a Copy of the Old Record will be stored. Therefore a list of all changes to the attitudes of a client can be tracked over time.  (See Record layouts at Client)

At the same time the Version Number (separate number) in the detail table, the Client Master #2 will be updated. 

Example (using only education  and occupation as an example)

By analyzing only the Master #2 record, all changes in the Client information can be determined over time and all events (attitudes of the client) that coexist AT THE SAME TIME can be viewed. This is necessary in order to determine the relationships between variables. 

At Time #3 the following files and Records Exists

Discussion Client Information Changes

The same information may be obtain without using the version number by performing advance query and selection but would be more time consuming and computer intensive. For Example, in order to determine the relationship between any two variables, say education and occupation (Assuming at this moment for one client only)

Pick a date to determine the relationship between variables

Perform a Query against Each and Every file that you want to analysis for relationships (the education and occupation) and Select The Record in each file that is nearest to the date chosen for the study (on each variable file. Then these records must be joined together in one file for analysis. Using our example from about, if we had picked time #2 to run the analysis, we would have the following records. 

This tells us that at time 2, the client had a 6th grade education and he "probably" was a farmer based on the last information that we had. 

The Version Number is also used in preparation for an OLAP database where the "Star"  design will be implemented. From the one record, Master #2, a multitude of relationships can be determine, and "drill downs" will be easily implemented. 

Transferring of information to a Central Database

A situation may occur where the client visits two clinics within a short time of each other and the clinics have not had time to update the Master files in the Central Database. How do you Merge the information from the two clinics? How are the ID's and Version Numbers reconciled?

Although the example above was given with a Sequential Version Number, the Version number, can be either a random generated number, a Global Unique Identifying Number, or a Date-Time. The actual date on the record notifying the event is used for analysis, not the Version number. The Version Number only signifies that the records are different. 

In our product, the Version Number will be the Date-time that the Event was entered into the system. Even if the client attends two clients within a short time of each other, both "bits" of information will be captured as separate evens...albeit...in a very short time. 

Based on this "separate information" the probably that any one "piece" of information is correct can be determined by comparing the answers to questions at one location with the answers given to the same questions at a different location. 

Change in "Standards" 

If standards are changed, then how is the system to run an analysis comparing one period to another. Several methods can be used to account for  these changes. 

• Along with the "Standards" code include a version code that indicates which version is being used
• Map the Old Standards to the New Standards (programming)
• Programming...all records before a certain date use one table, all records after that date use a different table. 
• Update all records in the System to reflect the new standards (requires a one time mapping). 

It is InHCc belief that the last option is the most viable?

Corrections

Ability to Alter Information previously entered

The  "correction" or amendment of any data after it has been committed to the Information system will be in a very controlled manner and will allow for the auditing of that correction. Information can be corrected or amended at two different points in the data collection.  

• Before the information has been committed to the Central Data Warehouse
• After It has been Committed to the Central Data Warehouse

Before the information has been committed to the Central Data Warehouse

Information that has been recorded at the local level but has not been sent to the centralized data warehouse, can be corrected in place by an authorized staff. This is made possible by having separate files for "temporary" collected local data on the Client and the Permanent "Downloaded" Central Database files on the Client. 

Temporary Files are created on the Client because in many cases the Health Care Unit may not have had time to download the Permanent Information from the Centralized Database and or they do not have a listings for the Client ID because s/he may be from a different geographical area or has just recently entered into the system. The Local Unit may want to wait in order to view the whole history of a client and make corrections to their file before commitment. 

Once the temporary files are corrected at the local level, they are merged with both the Permanent Downloaded Central Database files on the local computer and the Central Data Warehouse files.

After It has been Committed to the Centralized Data Warehouse

The  "correction" or amendment of any data after it has been committed to the Information system will be in a very controlled manner and will allow for the auditing of that correction. 

Users will NOT be able to alter information that has previous been entered into a record, however, they will be able to create a new record replacing the old. This will be done by entering a delete code into the record that needs changing and then creating a record with the "corrected" information. The amended recorded will include a code linking it with a "audit" record that identifies the user making the change, date/time, reason for change, and his or her authority to make that change. 

The original record has a "C", change indicator, and a pointer into a "Change File" to indicator the information that has been changed. 

The original file has both the old record, with the "C" and change pointer, and the new record with all the information including the corrected fields. 

In this manner, analysis can be easily performed by only excluding the records with the "C" code.

Audits of changes can be easily made by running a report on the Change File. 

Change Record (a record separate from the original record)

The original record and the Change File are in two separate files. The original record has a pointer into this file. 

• Client ID
• Sequence of this change (the same record may be changed more than once)
• ID of the person Authorizing this change
• ID of the user changing the information
• Date/Time of change to take place (of the original data on record to change)
• Reason for the change
• Record being changed (index of record)
• Field named
• Old information
• New information
• Date/Time that the information was entered into the system

Discussion

There are several ways that a correction can be made.

• Both the New Record and The "C" record can be kept in the file and "queried out of" any analysis. The Change File will serve as an audit record. 
• The New Record can be kept in the file and the "C" record can be deleted, with only the Change Record serving as an audit record.  

If change is allow in records that have already been committed to the the Centralized Data Warehouse this implies that updates are possible to the Warehouse.

Is it necessary to keep the Changed record in the original file? Research: "reconciling" differences between two time periods?  

Back to Top