MAHI Research Database

1
MAHI Research Database

• Data Validation System Software Prototype
  Demonstration
• September 18, 2001
• http//www.cstp.umkc.edu/yugi/mahi.html

2
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

3
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

4
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

5
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

6
Whats 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

7
Todays presentation

• Prototype overview
• Live demonstration
• Audience feedback discussion

8
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

9
Staged development for the MAHI Research Database
System
Structure
Data analysis
Behavioral prototyping - Appearance and behavior
of user interface
Phase 3
Data integration
Phase 2
Structural prototyping - Implementing
application functionality
Data validation
Phase 1
Behavior
10
How we performed prototyping

• Look-and-feel vs. Evolutionary prototyping

Gather user requirements
Refine user requirements
Construct structural prototype
Construct evolutionary prototype
Develop look-and-feel behavioral prototypes
Design software architecture
Evolve prototype verify and deliver increments
Design user interface
Construct and verify product
Construct and verify product
Deliver product
11
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?

12
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.

13
Using the Data Validation Software System
IT Administrator
XML Schemas Stylesheets
Multiple disparate data sources
Researcher (via SAS)
Admit File (ASCII)
T
T
T
db
(. xml)
Quarantine database
Storage database
XML repository
XML-Quarantine User Interface (XQUI)
Data Coordinator
Inform Screen (.dbo)
Data interchange
Web views
Industry standard
14
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

15
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.

16
The Main Panel

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

Pop-up window showing user authentication was
successful.

• 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.

17
The Main Panel
User 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.
18
The Settings Panel
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 Settings panel is used to create new user
  login settings.
• Information about the current network port and
  host settings are also displayed here.

19
The Record Viewer

• The Record Viewer displays all fields of a
  particular record.

This column lists all the fields for the record.
This column lists the values for various fields.
Fields that have an error have their
corresponding ErrorFlags field checked.
After changes in the records are made, using this
button, database will be updated.
20
Correcting errors

• The validator module returns records containing
  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.
21
XML Data Conversion

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

A validated InformScreen record in XML
InformScreen records in Quarantine database
22
XML Data Conversion

• The XSLTransform module then converts the interim
  XML documents into a common document format
  (MahiDoc).

MahiDoc AdmitFile record
Interim AdmitFile record
Interim InformScreen record
MahiDoc InformScreen record
23
Exporting to Database

• The validated MahiDoc files are exported into SQL
  Server 2000 database using Microsofts OpenXML
  extension.

Exported XML data is stored into Patient,
Encounters, Readings, and Location tables.
MahiDoc InformScreen record in XML repository
24
The End