1 / 17

MAHI Research Database

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

Download Presentation

MAHI Research Database

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. MAHI Research Database Project Directions June 7, 2001

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

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

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

  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 • MAHI’s 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 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.

  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: <Caregiver id=“1234” medgroup=“MHI”> <name> … </name> <ssn> … </ssn> <type> … </type> </Caregiver>

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

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

More Related