Transcript Sep 18, 2001

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
Data
analysis
Behavioral prototyping:
Phase 3
Data
integration
- Appearance and
behavior of user interface
Phase 2
Structural prototyping:
Data
validation
- Implementing application
functionality
Phase 1
Behavior
How we performed prototyping

‘Look-and-feel’ vs. ‘Evolutionary’ prototyping
Refine user
requirements
Develop ‘look-and-feel’
behavioral
prototypes
Design user
interface
Construct and
verify product
Gather user
requirements
Construct
evolutionary
prototype
Evolve prototype;
verify and deliver
increments
Deliver product
Construct structural
prototype
Design software
architecture
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 processand presentation-dependent metadata.
Provide a data transformation process to integrate incoming patient records for storage in the database.
Using the Data Validation
Software System
Multiple
disparate data
sources
Admit
File
(ASCII)
IT
Administrator
XML Schemas &
Stylesheets
Researcher
(via SAS)
TT
Quarantine
database
(. xml)
XML-Quarantine User
Interface (XQUI)
XML repository
Inform
Screen
(.dbo)
Data
Coordinator
Web views
Industry
standard
Tdb
Storage
database
Data
interchange
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

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.
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.
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.
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.
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.
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
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
Exporting to Database

The validated MahiDoc files are exported
into SQL Server 2000 database using
Microsoft’s OpenXML extension.
Exported XML data is stored
into Patient, Encounters,
Readings, and Location tables.
MahiDoc InformScreen record
in XML repository
The End