MAHI Research Database

Data Validation System Software Prototype Demonstration

September 18, 2001

http://www.cstp.umkc.edu/~yugi/mahi.html

Aug, 2001: Project Status Report

Project Vision & Goal Task Analysis Tentative Schedule Summary of Phase-1 Task

Research: Validation Hierarchy Prototype Development Secure Protocol (Digital Sender)

Potential Future Project

Project Goals

Information System for Medical Databases Phase-1: Data Validation Phase-2: Data Integration Phase-3: Data Mining and Analysis

Improve medical database system using new technologies (XML, hierarchical repository, component, etc)

Focus on an open architecture (scaleable, flexible, available, integrable, etc)

Develop representations and models

Project Task Analysis Research

Technology analysis and review Development of models and algorithms Publication

System Development Requirements/domain analysis System design Prototype development

Deliverables Demo System specification/source code Tutorial

Phase-1: Data Validation

Requirements and Technology analysis Understanding MAHI database system Identifying stakeholders’ needs Technology review and analysis

System architecture: XML-based information system

Prototype development (proof-of-concept) scaleable, flexible, available, integrable,

secure

What’s next? Data Integration

Data integration and storage Understanding of disparate data sources Data integration for multiple data sources Data exchange between XML and databases Seamless Integration with the current MAHI system Data conversion of legacy database

Enhancement of data validation Technologies: XML-repository, databases, data

warehouses, component technologies

Today’s presentation

Prototype overview Live demonstration Audience feedback & discussion

Purpose

We want to make the product tangible, bring usage scenarios to life, and close gaps in understanding user requirements.

3 major focuses: Clarify and complete requirements Explore design alternatives Grow into the fully-realized product

Staged development for the MAHI Research Database System

Structure

Behavior

Data validation

Data integration

Data analysis

Phase 2

Phase 3

Phase 1

Behavioral prototyping:

- Appearance and behavior of user interface

Structural prototyping:

- Implementing application functionality

How we performed prototyping ‘Look-and-feel’ vs. ‘Evolutionary’ prototyping

Gather userrequirements Construct structural

prototype

Design software architecture

Construct and verifyproduct

Deliver product

Constructevolutionary

prototype

Evolve prototype;verify and deliver

increments

Refine user requirements

Develop ‘look-and-feel’behavioral prototypes

Design userinterface

Construct and verify product

Evaluating the prototype

Functionality implemented in expected way? Any missing functionality? Any error conditions that the prototype does not

address? Any unnecessary functions? How comfortable and logical does navigation

seem? Easier ways to perform this task?

Data Validation System Objectives

Provide a common handler to validate all new in-coming data.

Represent the new data in a common, well-structured format that is easily read and manipulated by processing applications.

Separate data content in patient records from process- and presentation-dependent metadata.

Provide a data transformation process to integrate in-coming patient records for storage in the database.

Using the Data Validation Software System

TT Tdb

Researcher(via SAS)

Data Coordinator

IT AdministratorMultiple

disparate data sources

XML Schemas & Stylesheets

Admit File (ASCII)

Inform Screen (.dbo)

Quarantine database

Storage database

XML repositoryXML-Quarantine User Interface (XQUI)

Data interchangeIndustry

standard

Web views

(. xml)

System features

User friendly interface Web accessible Log-in and authentication The Main panel The Settings panel The Record Viewer Correcting errors XML data conversion Exporting to the database

Log-in and authentication

User id and password authenticated in this window. This tab gives user the option to provide user login and password.

User login completed pressing this button.

User can Log-off using this button.

Password log-in feature for accessing the application.

Added security.

The Main Panel

User can select the data source to validate and the XML schema to use.

Files are scanned for errors; errors are displayed.

User can resubmit the corrected records from this panel.

Pop-up window showing user authenticationwas successful.

The Main panel allows the user to connect to the quarantine database.

The Main PanelUser selects table name from a drop down box.

It also shows the records display.

You can enter the range of records to validate.

Pressing this button will call the “validator” module.

Progress bar indicating no files processed.

The Settings Panel

The Settings panel is used to create new user login settings.

Information about the current network port and host settings are also displayed here.

This panel allows you to make new user login settings.

Add user button

Dialog box notifying of the success of the new user id creation.

The Record Viewer

The Record Viewer displays all fields of a particular record.

Fields that have an error have their corresponding ErrorFlags field checked.

Fields that have an error have their corresponding ErrorFlags field checked.

This column lists the values for various fields.

This column lists the values for various fields.

This column lists all the fields for the record.

This column lists all the fields for the record.

After changes in the records are made, using this button, database will be updated.

Correcting errors

Validate the records selected by the user and list them on the screen.

Lists all the records within the range specified by the data operator.

Lists the no. of errors in the particular record.

The validator module returns records containing errors.

XML Data Conversion

InformScreen records in Quarantine database

A validated InformScreen record in XML

The XMLGen module converts validated records into an interim XML representation.

XML Data Conversion The XSLTransform module then converts the

interim XML documents into a common document format (MahiDoc).

Interim AdmitFile record

Interim InformScreen record

MahiDoc AdmitFile record

MahiDoc InformScreen record

Exporting to Database The validated MahiDoc files are exported

into SQL Server 2000 database using Microsoft’s OpenXML extension.

MahiDoc InformScreen record in XML repository

Exported XML data is stored into Patient, Encounters, Readings, and Location tables.

The End