STD*MIS - FAQ - System Utility Issues
Q1: What Epi Info Programs are available inside STD*MIS?
You can access Analysis and EPED directly from the System Utilities Module in STD*MIS. These are the only Epi Info programs available while in STD*MIS.
Beside the obvious, not having to exit STD*MIS to access another DOS-based product, running ad hoc analysis on the database files is easier. You can read the DBF files without having to path each statement.
NOTE: While accessing individual database files in STD*MIS is possible, the most efficient way to perform ad hoc analysis would be to create temporary analysis files using the Export-Analysis Format feature in System Utilities.
Without having to access another word processing program, EPED is provided so that you have the ability to more easily create new or modify existing morbidity reports.
Q1: Working in a network environment, do I need exclusive access to STD*MIS to perform Duplicate Patient Maintenance?
Yes and no. This is a three step process and only the final step (processing the merge file) requires exclusive access. The first step is creating a file by which you will investigate the records. The second step allows you to mark records for merging. The final step is when the system will actually take the merge file and perform the action. This third step is when you should make sure all users are out of STD*MIS.
NOTE: You must have Administrative rights to access this feature.
No. One option you have here would be to restore from backup and go through the merging process again. This is with the assumption that you have not entered any new data into STD*MIS from the time you made this merge mistake. Another option would be to recreate the merged patient records individually using hard copy records of their events. If you need additional assistance or guidance contact your STD*MIS Support Person.
Q1: How do I send a Year-To-Date NETSS file to CDC?
Requests are sometimes made of a project area to send a Year-To-Date (YTD) file to CDC. Because routine weekly NETSS transmission files are sent on Monday or Tuesday, this file should only be sent to CDC either Wednesday, Thursday, or Friday. It is important to indicate to CDC that this is a YTD file. Please ask your local Epi Reporter (the person who sends the NETSS files from your site to CDC) to include a message with the transmission that this includes a YTD file of STD data. From the NETSS export routine, select the YTD time frame by pressing the F3 function key when entering the date. The pop-up menu displays the date with which the year actually began, based on the MMWR publication deadlines.
The STD*MIS NETSS export utility was designed with the assumption that all morbidity records that have been newly added, modified, or deleted for the PRECEDING week will be included in the current weekly transmission. Therefore, do not generate the NETSS transmission file for the current week anytime during this week. The week ends on Saturday and the new week begins on Sunday. Thus, STD*MIS will not include anything added, modified, or deleted during the current week in the NETSS transmission. For most project areas, the best day to create a NETSS export is Monday.
Since identifying data is natively encrypted in STD*MIS, exports involving identifying information is defaulted to an encrypted format. You can have the export program "decrypt" this information only if you have Administrative Rights in STD*MIS. If you have Administrative rights you should go to System Utilities-Export Data-Analysis Format. After selecting the variables you would like to export and pressing F10 to SAVE, the CREATE (record type) ANALYSIS FILE will appear on screen. In order to view patient data, you must change the Decrypt Output field on this screen from an "N" to a "Y".
Q4: I've noticed that when I do an export analysis file of my data, the numbers don't match what is on my hard copy reports, such as the 688 and 988 and 2638, and it also doesn't match my NETSS numbers. Why is that?
The hard copy reports and the NETSS export exclude morbidity reports where the DISTRICT value is equal to "99". This code indicates that the case is from another state, not your state. This district value is picked up from your GEO_AREA reference file which you can access though "SYSTEM UTILITIES", "UPDATE REFERENCE FILES". Often when a city and/or county and district is unknown, but the case is believed to be within your state, the best way to handle the District field is to create DISTRICT = "88" for these cases. That way the case will be counted, and you can determine how many of your cases are reported with insufficient information to create a valid District. If you have made this mistake in the past, and wish to correct some of the cases with a "99" District, contact your STD*MIS support person.
Q1: I just downloaded the latest version of STD*MIS (3.2) and the import functions are password protected. What is the password?
The purpose of placing an extra password in this area of STD*MIS is to allow CDC the opportunity to provide project areas with some very detailed instructions prior to the project area attempting imports on their own. We have developed a training course to get people up-to-speed with the issues surrounding importing data into STD*MIS. You will receive the password when you attend this training. You can also contact your STD*MIS Support Person to get the password. However, it is strongly suggested that you attend the training prior to attempting to import data!
No. The password is only required the first time the user accesses the import functions.
Q1: What is the process for purging data in STD*MIS?
This feature is located in System Utilities - Purge Patient Registry. There are two ways to purge patient records from STD*MIS: 1. You can purge patient records which have no events; or 2. You can purge patient records that have a last name of Unk., Unknown, or blank, and their only event is a field record older than one year. Any patient with other events on file will NOT be purged.
This is generally a local issue. Some states require that their data systems be purged every several years. However, the options for purging records is limited within the program, so some project areas may need to write specific routines to purge data. See Q1 above for STD*MIS purging options.
Q1: What is the purpose of running the Database QA Reports?
Database QA reports are provided to help maintain STD*MIS system integrity. One report, Check For Blank/Duplicate Keys (CHECKEYS) is a program that determines if any records in STD*MIS have blank or duplicate ID numbers. The other report, Referential Integrity Check (SEEKKEYS) determines if any records have broken linkages to related files. For example: a morbidity record that contains an Address_id that does not have a corresponding Address_id in the address file. If either of these programs report errors you should contact your STD*MIS Support Person for assistance.
NOTE: Errors in these programs can affect the statistics reports run in STD*MIS.
This is generally a local issue, however CDC recommends that you run these programs at least monthly. Download System Maintenance Recommendations (Maintain.zip) for a complete list of suggested activities to preserve the health of STD*MIS.
This is a program that looks at all system generated numbers to determine if they are being sequentially assigned. CDC recommends that this program be run on a monthly basis or anytime STD*MIS will not allow you to create a new record (i.e. field record, interview record, etc.)
No. The only time you should download the new files is if the dates are different. This is an issue caused because some machines work on the basis of civilian time and some work on military time. Therefore, no update is needed.
The System Date/Time Check will give you just three possible error descriptions: 1. "Update this file", 2. "Contact Atlanta", and 3. "Not Found". When the description is "Contact Atlanta" this generally means that you have a file in your system that is newer than the one CDC has. To be more specific, the file in your version of STD*MIS has a newer date than the CURRENT.DBF thinks exists. If you get this message you should first download the most recent CURRENT.DBF from the STD*MIS Web Site and run the report again. If you get the same message again, contact your STD*MIS Support Person for assistance. If you receive a message that says "Not Found" or "Update this file", download the specified file(s) and run the System Files Date/Time Check again.
This is generally a local issue, but CDC recommends that you do this on a weekly basis. You should also do this any time you have question about the quality of data in STD*MIS. Problems with the file indexes are not uncommon. While the databases themselves are usually not affected, what is seen on the screen may look wrong.
There are two ways in which you can re-index your data files. In the System Utilities menu you should select Re-index Data Files. From here you should choose the data files you wish to re-index or depress CTRL-T to select all data files. Alternatively, by going to a DOS prompt, accessing the directory where STD*MIS is installed and then typing "newcdx a", all files will be re-indexed automatically.
You can add Local Use Fields in six STD*MIS events: Clinic Visit Records, Field Records, Interview Records, Laboratory Test Records, Morbidity Records, and Treatment Records. For more information on how to create Local Use Fields download the STD*MIS Installation and Implementation Guide (4x_New.zip).
Q1: My state just reorganized our districts. How do I tell STD*MIS to denote these new classifications?
This change would best be made with the use of a database utilities program like FDBU or xDot. A global change would be the best route to take here because actually going through the Geo_Area.DBF to modify every city in the database would be impractical. contact your STD*MIS Support Person to assist you with this endeavor. Historical data will need to be evaluated at this time as well. Do you want to trend newly entered data using historical data as the basis of this analysis? If so, you will need to make changes in the affected database files to coordinate your new Regions.
It is important for staff to remember that any address record for a person that lives within your project area should have the correct county name, county FIPS code, district, state, and state FIPS code.
Conversely, if a patient lives outside of your project area, the address record should be coded as follows: CITY = city name with state included (e.g. Jefferson City, MO), CITY_FIPS = 9999, COUNTY = UNKNOWN, CNTY_FIPS = 999, ZIPCODE = 99999, DISTRICT = 99, STATE = postal code state abbreviation (e.g. MO), and STATE_FIPS = 99.
NOTE: Every morbidity record is linked to an address in STD*MIS. Therefore, the information on this address record will cause morbidity to be included or excluded on morbidity reports and in the NETSS transmissions to CDC.
This is a local decision, but CDC suggests that you do this on an as-needed basis. If your state doesn't allow F3 - on-the-fly additions to the reference files and just the Administrator of the system is responsible for updating this database, a monthly review should be adequate. However, if F3 additions are acceptable protocol in your state, then it would be advisable to monitor the major reference files on a weekly basis. The longer the period of time with which data is being entered using unacceptable data, the more difficult it will be to bring that data into local compliance.