mahi research database
Download
Skip this Video
Download Presentation
MAHI Research Database

Loading in 2 Seconds...

play fullscreen
1 / 17

MAHI Research Database - PowerPoint PPT Presentation


  • 97 Views
  • 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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
slide3

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

Management Database

(contains metadata)

M

Generates user interface using DHTML, ASP

Patient

Primary customer:

Physicians

Processing, normalization using ATL, COM, C++

MAHI DB Interface

(HTML?)

SAS

Ad-Hoc

Query

HL7

SPSS

Q

R

A

ODBC

ODBC

T

ASCII

ASCII

HL7

Change Request

/Record Editor

ACC

L

Legacy database (no quarantine/data cleansing)

Cardiff

(optical recognition

software)

DTS

STS

Currently manually implemented using SQL scripts

Digital form scanner/transmitter

(model HP 9100C)

Digital Sender

DB Explorer

user interface

Interim Solution

current implementation
Status:

Interim solution in place

Angioplasty and Cardiac Cath data available

Simple queries available via DB Explorer

Limitations:

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

documents

  • XML-enabled web server

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

database

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>

</Caregiver>

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

Q

R

Current architecture

I

Adaptable front-end apps for Query/Report

Adapter

Extender

Neutral storage facility

Q/R

XQ

XR

XML

H

Report Harvester (e.g. ACC, STS)

Converter

Legacy storage

Legacy

(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’.)
ad