Mahi research database
1 / 17

MAHI Research Database - PowerPoint PPT Presentation

  • Uploaded on

MAHI Research Database. Project Directions June 7, 2001. Overview of Client Requirements. Quaterly reports (STS, ACC) Data to/from external organizations. General patient data Simple queries. Fast & reliable queries Add new data points . Efficient data storage

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'MAHI Research Database' - jud

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Mahi research database

MAHI Research Database

Project Directions

June 7, 2001

Overview of client requirements
Overview of Client Requirements

  • Quaterlyreports

  • (STS, ACC)

  • Data to/from external

  • organizations

  • General patient data

  • Simple queries

  • Fast & reliable queries

  • Add new data points

  • Efficient data storage

  • Internal security

  • Extensibility

  • Maintenance

Mahi research database

Concept Diagram of MAHI Architecture(designed by: Kelly Kerns)

Management Database

(contains metadata)


Generates user interface using DHTML, ASP


Primary customer:


Processing, normalization using ATL, COM, C++

MAHI DB Interface
















Change Request

/Record Editor



Legacy database (no quarantine/data cleansing)


(optical recognition




Currently manually implemented using SQL scripts

Digital form scanner/transmitter

(model HP 9100C)

Digital Sender

DB Explorer

user interface

Interim Solution

Current implementation


Interim solution in place

Angioplasty and Cardiac Cath data available

Simple queries available via DB Explorer


Missing Surgical data (legacy database)

Unable to perform quarterly reports

No single repository to store common data

No simple analytic tools built-in

Current Implementation

Why are we using a database
Why are we using a database?

  • To expose legacy data

  • To record/store/maintain/access patient and treatment information

  • To allow extraction and investigative analysis of above information

  • To meet clinical organization IS standards

  • To collect and store data from external entities

Storage and processing
Storage and Processing

  • MAHI’s storage and processing needs are data-centric (as opposed to document-centric), related to dynamic procedures, and patient-oriented.

Storage and retrieval technologies
Storage and Retrieval technologies

  • Database (relational, OO, hierarchical) and middleware (built-in or 3rd party)

  • Data warehousing

  • XML server

    - Native XML database to manage large numbers of XML


  • XML-enabled web server

    - Web server that can build XML documents from data in a


Database features of xml
Database features of XML

  • Storage (XML documents)

  • Schemas (DTDs, XML Schema)

  • Query language (XQuery)

  • Programming interface (SAX, DOM)

Why xml as storage format contd
Why XML as storage format? (contd.)

  • System needs to store data with repeating fields

    • Example:

      • Caregiver has several patients (some repeat patients)

      • Location can be used for multiple encounters

      • Patient may be administered multiple materials/medication (some prescriptions are repeated)

    • XML provides mechanism to quickly parse and extract data with repeating structure, or to generate new documents.

  • System needs to store data with arbitrary length

    • Example:

      • Text of medical notes

    • XML can store nested elements of arbitrary depth and length.

Why xml as storage format contd1
Why XML as storage format? (contd.)

  • System needs to exchange information with other organizations

    • Example:

      • External Stroke database, external Women’s Health Clinic database, external HL7 compliant database; currently this formatting has to be done manually because data formats are different.

    • XML can be used to make formatting easier (similar data items will have similar markup tags; more human readable), and possibly automate some of the work by using DTDs/Schemas as reference.

Why xml as storage format contd2
Why XML as storage format? (contd.)

  • System needs to store standard queries/analytical results for display on multiple end-user client apps

    • Example:

      • Currently, Kelly and biostatisticians have to make specialized query every time it is requested by a user.

    • Standard queries can be stored as SQL procedures, and query results can be returned in a single XML format document (with its associated DTD) to be transformed into views for multiple end-users (e.g. via XML-enabled web server).

Why xml as storage format contd3
Why XML as storage format? (contd.)

  • System needs to store metadata

    • Example:

      • Medical groups access to information, originating source of data, etc.

    • Metadata can be easily incorporated into XML documents as attributes in the element tags.

    • Example:

      <Caregiver id=“1234” medgroup=“MHI”>

      <name> … </name>

      <ssn> … </ssn>

      <type> … </type>


Limitations of xml as storage format
Limitations of XML as storage format

  • Efficient storage?

  • Security?

  • Transactions and data integrity?

  • Multi-user access?

  • Recovery and fault-tolerance?

  • Queries across multiple documents?

  • Others?

An xml extension to existing architecture
An XML extension to existing architecture

Input data



Current architecture


Adaptable front-end apps for Query/Report



Neutral storage facility






Report Harvester (e.g. ACC, STS)


Legacy storage


(e.g. Surgical database)

Key tasks initial thoughts
Key tasks (initial thoughts)

  • Develop storage facility for XML documents

  • Design schema/DTD for data to be converted and stored

  • Develop retrieval (via query) facility for searching, indexing, extraction, and analysis of documents

  • Perform data conversion of legacy database

  • Integrate into existing architecture

Modified project tasks
Modified Project Tasks

  • Re-visit the tables in the Repository data store

    • Re-engineer

  • Validate structure of Repository data model

  • Develop a X-Quarantine using XML (from Legacy & New Data)

  • Develop a process from X-Quarantine to Repository

  • Develop a process from Repository to X-Repository

  • Query tool (for Bio-Statistician) from X-Repository

Other issues
Other Issues

  • Ensure X-Repository information is ‘secure’ (i.e. bio-statisticians can ‘trust’.)