MAHI Research Database

1
MAHI Research Database

• Project Directions
• June 7, 2001

2
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
• Internal security
• Extensibility
• Maintenance

3
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
HL7
ASCII
Change Request /Record Editor
ACC
L
Legacy database (no quarantine/data cleansing)
DTS
Cardiff (optical recognition software)
STS
Currently manually implemented using SQL scripts
Digital form scanner/transmitter (model HP 9100C)
Digital Sender
DB Explorer user interface
Interim Solution
4
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

5
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

6
Storage and Processing

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

7
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

8
Database features of XML

• Storage (XML documents)
• Schemas (DTDs, XML Schema)
• Query language (XQuery)
• Programming interface (SAX, DOM)

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

10
Why XML as storage format? (contd.)

• System needs to exchange information with other
  organizations
• Example
• External Stroke database, external Womens 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.

11
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).

12
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
• ltCaregiver id1234 medgroupMHIgt
• ltnamegt lt/namegt
• ltssngt lt/ssngt
• lttypegt lt/typegt
• lt/Caregivergt

13
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?

14
An XML extension to existing architecture
Q
R
Input data
Current architecture
I
Adaptable front-end apps for Query/Report
Extender
Adapter
Neutral storage facility
Q/R
XQ
XR
H
XML
Report Harvester (e.g. ACC, STS)
Converter
Legacy storage
Legacy
(e.g. Surgical database)
15
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

16
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

17
Other Issues

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