Download
the cdw data lifecycle internals data flows and business intelligence n.
Skip this Video
Loading SlideShow in 5 Seconds..
The CDW Data Lifecycle - Internals, Data Flows, and Business Intelligence PowerPoint Presentation
Download Presentation
The CDW Data Lifecycle - Internals, Data Flows, and Business Intelligence

The CDW Data Lifecycle - Internals, Data Flows, and Business Intelligence

271 Views Download Presentation
Download Presentation

The CDW Data Lifecycle - Internals, Data Flows, and Business Intelligence

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. The CDW Data Lifecycle - Internals, Data Flows, and Business Intelligence (Closet Skeletons Version) Richard Pham Enterprise Architect OI&T Corporate Data Warehouse – Architecture Richard.Pham@va.gov

  2. CDW Informatics and Analytics Ecosystem REGION 2 REGION 4 REGION 1 • Hardware Stats • 411 Servers • 4 PB Storage • 54 Racks CDW – Corporate Data Warehouse RDW – Regional Data Warehouse REGION 3

  3. Some Things Never Change • VHA and OI&T have a tense/unhappy relationship • OI&T project management bureaucracy is onerous • The use and oversight of contractors is problematic • Pharmacy knows what they are doing (more so than OI&T)

  4. In the beginning, there were files (early 70s)…

  5. There were problems… • How do I maintain each file? • If I change one file, what happens to the other files? • How do I control growth of the files?

  6. Then came databases…(late 70s)

  7. And there were more problems… • How can the databases share common elements like patient? • What if some idiot changes one table structure that collapses everything else? • Who remembers how this database was designed?

  8. This is only two packages, think of the 100+ that are in VistA • Now, try extrapolating those trends in your head • Have a picture in your mind?

  9. Did That Picture Look Like This?! (~7% of VistA as of 2010)

  10. One more extension, let’s try to analyze this data…

  11. This Is What Happens With Extracts (90s)

  12. Even more problems…. • Is my data timely (Extract to production system time lag)? • Are the extracts one-time? Are they repeatable? • Who manages all these extracts? • No seriously, this becomes a really ugly problem

  13. Why Am I Giving This Presentation? • Quite simply, feedback on: • “I don’t understand what you mean when you say “File” or “Pointer.” • “Where does the data come from?” • “How does the data get to CDW?” • Also, while you are using the CDW to prepare your work, it really helps if you know the origins of where the data comes from…

  14. DHCP/VistA/CPRS/HealthEVet • VistA – Veterans Health Information Systems and Technology Architecture – 2nd Generation Architecture. Refers both to the architecture and the database which the architecture supports • DHCP - Decentralized Hospital Computer Program – The DOS (Unix-like) system where many of VistA’s non-clinical entries take place • CPRS - Computerized Provider Record System – A user-friendly GUI providing access to clinical order entry functions • HealthEVet – 3rd Generation of VA’s EMR. Planned inclusions are patient-facing applications, better alignment with coding standards, and MDS compliance.

  15. The Health Care Process Is More Complicated Than We Think

  16. Objectives • The main objective is to understand the data lifecycle of VA’s VistA/CPRS and the user experience of VistA/CPRS • A high-level overview of VistA Internals • Learn about data structures and outputs in VistA • Learn where data enters and travels throughout the VA • Try to make sense of data resources within the VA and how they are accessed

  17. The VA Data Lifecycle

  18. The VA Data Lifecycle

  19. Core Patient Care Functionality • VistA is first and foremost an Electronic Medical Record. The architecture design supports veteran health care.

  20. Core Patient Care Functionality • VistA Internals • DHCP • CPRS

  21. VistA Internals 101 • MUMPS • Server and Operating System • Kernel • “Three Wise Men (Managers)” • TaskMan • MailMan • FileMan • Modules

  22. Dead Patients Change Careers

  23. Why Is Med Safety at Ann Arbor?

  24. To Best Care Anywhere…

  25. Massachusetts General Hospital Utility Multi-Programming System (MUMPS or M) • My definition in English • M is a programming language designed for hierarchical databases that is convenient for medical applications or anything else where speed and data storage upkeep are a problem and programmer intelligence/organization is not • My technical definition • M is a Turing-complete, low and high-level, imperative, machine-compiled (no longer interpreted) programming language utilizing a hierarchical global array file structure • Used commonly in healthcare and financial industry settings

  26. Structure of The Veterans Administration Data Efforts (Late 1970s) VHA Ancestor Department of Medicine and Surgery (DMAS) OI&T Ancestor Office of Data Management & Telecommunications (ODM&T) VHA-OI Ancestor Computer Assisted System Staff (CASS)

  27. Comparing The Two Offices CASS ODM&T • Decentralized design philosophy • Rapid, agile development • SME-involved development • Centralized design philosophy • Bureaucratic, process-focused development • Development without SME’s

  28. Contractors

  29. Highlights of ODM&T Development • Took 6 years to deploy APPLES Pharmacy at 10 sites • A 1980 paper detailing ODM&T’s transactional patient treatment file (PTF) system promised an interactive national solution by 1990. • Navigating the mandated 17 steps between system specification and deployment alone is said to have required at least 3 years.

  30. “Standards” and Project Management

  31. Beginnings of DHCP • There were subject matter experts that believed that they could put out useful applications faster than the ODM&T sloth • Development of the testing and principles was done unofficially throughout the early to late 1970s

  32. Original DHCP Design Principles • A commitment to rapid prototype development • All use ANSI MUMPS • Modular Design • Actively Maintained Data Dictionary • Code Sharing/Portability • Involve the SME’s

  33. DHCP Kernel • Functions as both an operating system for VistA applications and an M virtual machine • Kernel shields DHCP modules from needing to know hardware and OS configurations on the server • Isolates M to the ANSI standard (1995) • Provides a toolbox of standard functions for most programmers

  34. It’s only going to be two months…

  35. MUMPS Classic Database • One Data Type • String (Text) • Other types • Cardinal Numbers • Float Numbers • $H Dates • One Data Storage Type • Multidimensional Array aka Globals • Dynamic (duck) typing

  36. VistA Data Organization • Namespace • File • Field • Record • 654 (VAMC Reno) • File 120.5 (GMR Vitals) • Field 0.1 (DATE/TIME VITALS TAKEN) • IEN-1, BP, 140/90 • Most Files have an entry at the 0.001 Field called “IEN” or “Internal Entry Number” as an identity key to mark the record as unique

  37. From The Beginning - Entry • An entry is a “piece” of data • Richard – First Name • Pham – Last Name • 05/03/1983 – Date of Birth

  38. Record (Row) • A group of related data • Richard Pham • M • 05/03/1983

  39. Field • A group of related data • Richard – First Name • Pham – Last Name • 05/03/1983 – Date of Birth

  40. File • A group of related fields and the records that we have • File 200 – NEW PERSON • Richard – First Name – 200 • Pham – Last Name – 200 • Date of Birth -

  41. File Relationships • One-to-One - Pointer • One-to-Many (Subfile, Multiple) • Self-referential (Recursive) • Reverse Recursive (Past Records) • Forward Recursive (Replace Records) • Pointer with Logic – Multiple POinter

  42. File Relationships - Pointers • When two files share a common field with each other, this is called a pointer • There are three major types • Pointer - One record in one file matches to one record in another file • Self-Referential – One record in one file matches to one record in the same file (in the past or the future) • Multiple – One record in one file matches to many records in one file (parent-child) • Variable – One record and some logic matches to one file

  43. Pointers File 52 PRESCRIPTION Field 2 Patient File 2 PATIENT All fields One-to-one

  44. Self-Referential Pointer Warning – DO NOT $o these fields without programmer assistance! You will bring down DHCP this way!!! File 100 OE/RR Field 9 Replaced Order File 100 OE/RR (Past Order) Present-to-Past File 100 OE/RR Field 9.1 Replaced Order File 100 OE/RR (Future Order) Present-to-Future

  45. Multiple Subfile File 52 PRESCRIPTION Field 52 Refill Subfile File 52.1 REFILL All fields One-to-many

  46. File 50.605 DRUG CLASS Multiple Subfile File 50 DRUG One-to-many files File 120.8 PATIENT ALLERGIES Field 1 GMR Allergy File 50.6 NATIONAL DRUG 120.2 GMR ALLERGIES File 50.416 DRUG INGREDIENT

  47. Computed/MCode • A placeholder that does not contain any stored information • Calculated ad hoc when you look up the value • Warning – For this reason, the value ALWAYS has the possibility of changing

  48. How Complicated Is The Pharmacy Package? • 440 files in the File 50 Series • 3,175 fields • 527 Pointers • 310 External References