|
National Claims Data Management System (NCDMS) Overview
The external component of the MHIC's claims management system, NCDMS, appears as an SSL-secured web portal that allows carriers to submit properly formatted data files and to monitor the status of those submissions. Using the web portal, the user indicates the type of submission (test, live data, replacement of live data), browses to the file on their local file system, and uploads the compressed (zip) data file. Each uploaded submission is immediately acknowledged by NCDMS and the user is allowed to upload another file, check the status of submissions or log off. The external component assigns a permanent unique file id that is used to track the submission throughout the process. It also records the stage and status of the submission as well as basic information regarding when it was submitted, the type of data, the submitter, the volume of records and the time span covered. Carriers are responsible for submitting their data through the secure web portal offered through NCDMS or submitting data on a CD or DVD. Appendix II contains pages from the New Hampshire carrier communication package that outlines the responsibilities for each carrier. Step 6 provides the instructions for submitting data via the web uploader or via CD/DVD.
|
| NCDMS Overview |
|
MHIC will use the infrastructure of its National Claims Data Management System (NCDMS) developed for the Maine Health Data Processing Center and the New Hampshire Comprehensive Health Information System (NH CHIS) to meet the data collection and editing needs of the Council. This system has three main components - external, internal and tracking. The external portion of NCDMS (www.ncdms.org) includes the secure web portal used by the reporter and by Council and MHIC authorized users. There is also a non-secure portion of the NCDMS site with information that is publicly available. The internal NCDMS runs on an internal web server and consists of a series of Oracle stored procedures for editing, processing, managing and storing the data. Tracker is the communication component that gathers information from each step in the process for system administration and determines the movement of the data through NCDMS.
|
| Web Portal |
|
The external component appears as a web portal with a secure SSL web upload interface for carriers to submit and monitor data as well as a backend data management tool for tracking the status of each submission. After preparing the submission using the NCDMS encryption application, zipped files are uploaded through the secure web portal created for Massachusetts carriers. Using the web portal, the user (the reporter or the MHIC staff person for submissions received via CD or DVD) indicates the type of submission (test, live data, replacement of live data) and the name of the file being submitted. Each uploaded submission is immediately acknowledged by NCDMS and the user is allowed to upload another file, check the status of submissions or log off.
|
| Prelim |
|
The external component assigns a permanent unique file id that is used to track the stage and status of the submission as well as basic information regarding when it was submitted, the type of data, the submitter, the volume of records and the time span covered. During this PRELIM phase, the submission is unzipped and standard file level checking on the text file is performed. This includes validating date ranges, validating the submitter code, comparing the actual record count against the header record, and comparing the records against the file type indicated in the header. PRELIM fails the submission at the first occurrence of any PRELIM error and automatically emails the reporter that failure has occurred, the reason for the failure, the record containing the failure and a request for resubmission. Any file that has not been run through the encryption tool prior to submission will be failed by PRELIM.
|
| Load |
| The internal system has three major phases - LOAD, TRANSFORMS and EDITS. In the LOAD phase the text file is loaded into Oracle and a text based Oracle view of the file is created. This step is necessary to accommodate data that fails to load due to incompatibility with the data type (e.g. alpha data in a numeric field). LOAD verifies the existence of critical data elements at a high level. This high level existence is programmable at the reporter level. For example, a medical claims submission with more than 10% of the records having a blank primary diagnosis code is a LOAD/FAIL condition. All thresholds are evaluated. In the event a submission fails one or more LOAD conditions, Tracker automatically emails the reporter the list of failures and requires a resubmission. A copy of the automatic email from the LOAD process appears on page 1 of Appendix III. Currently there are 9 eligibility, 20 medical and 15 pharmacy LOAD conditions. This list will be reviewed and updated, if necessary, in the Statistical Plan to meet the Council's needs. |
| Frequency Reports |
| A frequency count is created for every data element to evaluate the percent of records with a null entry, a valid entry and with an invalid entry. The completeness percent, based upon records with a valid entry, is evaluated against the state approved threshold of tolerance for that data element. Any submission with one or more data elements failing the threshold test will be rejected. An email to the reporter containing a brief message indicating failure and a link to the web report for the entire submission will be automatically generated and sent by NCDMS. The statewide threshold is parameter driven and can be changed through NCDMS web pages available to the data managers. In the event that a reporter cannot meet the statewide threshold for one or more data elements, the Council may authorize a lower completeness threshold for a specified period of time. That reporter's data will be evaluated against the lower threshold for the allotted time span. A sample frequency report is shown in Appendix IV. The frequency report will be finalized within the Statistical Plan. |
| Transforms |
|
TRANSFORMS populates value-added fields used in data element validation and in the data warehouse tables. The TRANSFORMS phase includes the setting of age, standardized product and relationship coding across data types, and drug categorization. Any standardization of submitted data occurs in a new field. All of the data submitted by the reporter is preserved as submitted unless the reporter and/or the state agency authorize the changing of submitted data.
|
| Edits |
| The EDITS module includes data verification checks to evaluate the validity and distribution of the individual data elements and to cross check the appropriateness of values in conjunction with other data contained in the same record. There are over 100 eligibility edits, 300 medical edits and 200 pharmacy edits. The edits include cross checking data against national coding systems including, but not limited to, ICD-9 diagnoses, ICD-9 procedures, CPT and HCPC procedures, and NDC codes. EDITS also performs data quality checks to assess the inter-relationship of individual data elements and evaluate rates against parameter driven thresholds. For example, in Maine "M" is a valid gender code for males. A submission with 100% of the records coded as "M" will pass LOAD but will fail the data quality check that flags a submission with less than 20% of the records or more than 80% of the records coded as male. A submission passing all data quality threshold checks is marked as DQ/PASS and an email is automatically sent to the reporter indicating the submission is successful. Carriers are notified a submission is at DQ/REVIEW if it has failed one or more data quality thresholds and the data quality report is flagged for manual review. A sample data quality report appears in Appendix V. Page 2 of Appendix III contains the email language indicating a submission has passed the frequency checks and has moved into manual review. |
| DQ/Review |
| DQ/REVIEW submissions are manually reviewed within 3 business days. Hands-on data mining is generally required for problems identified in these submissions. MHIC's intake specialists send a detailed email to the reporter regarding the problem and what research indicates may be causing the problem. The submission status is then set to DQ/FAIL. This initial email is often followed by conference calls to discuss reporter system issues and limitations, rule clarification, or other contributing factors. MHIC's information systems staff is a major participant in researching data problems, discussing options with the reporter and implementing customized system changes. These discussions may require MHIC to make corrections to the submitted data and the reporter to make changes in subsequent submissions or it may require the reporter to resubmit the data. Samples of the emails that stem from DQ/Review can be found on pages 3 through 5 of Appendix III. |
| Submission Status Tools |
|
The current status of each submission is maintained in an Oracle table that is viewable to the reporter from the reporter's web portal and from the MHIC's data manager's screens. The reporter may click on the "Report" button to see the detailed results. The frequency and data quality reports are accessible online to the carriers as well. Through NCDMS, Council staff may monitor the submission and editing process for NCDMS in general, as well as for any individual payer. This includes the ability to identify overdue submissions by data type and time period. Council staff will have direct access to all reports available to carriers.
|
| Auxiliary Data Quality Evaluation Tools |
|
In addition to the processing and verifying of individual submissions, it is necessary to look at a submission in the context of all other submissions for that data period. Through NCDMS, the data manager has a series of software tools available to look at the database in total. These tools are used to identify duplicate submissions, duplicate records, unusual trends in record volume, unusual trends in payments, and data gaps. Because the insurance industry is an active market and there are so many variables to consider, MHIC has found it inappropriate to program automatic responses to many of the data situations uncovered by these reports. It has sometimes been more effective to identify patterns for specific carriers, make program adjustments for these patterns and continue to monitor the situation on a routine basis. These tools are used by the intake specialists. When an unusual problem is identified, the Director of Information Systems becomes involved in its resolution with the carrier.
|
| Resubmissions |
|
NCDMS also allows for the resubmission of the data and has a specific category of replacement data in the upload menu. A reporter that is replacing accepted data must indicate the type of data and the start and end date for the data before uploading. Data submitted by a reporter for a data type and time period that has already been accepted will be rejected as duplicate data unless the replacement submission procedures are followed. In those unusual situations where a subset of eligibility or claims records were omitted from the original filing, accommodations can be made with the MHIC staff to arrange for a supplemental submission to fill the gap of the missing data.
PRELIM, LOAD, frequency reports, TRANSFORMS, and EDITS are all NCDMS functions and are automatically performed within seconds or hours of the submission, depending upon the file size. DQ/REVIEW is a manual task completed by intake specialists within 3 business days of receipt. Intake specialists are also responsible for manually flagging replaced submissions for system deletion. This flagging occurs as a data warehouse preparation task. |