heartbase An Evolution of SIR Functionality by Nick Gawrit

1
heartbase An Evolution of SIR Functionalityby
Nick Gawrit
2
Overview

• In this presentation, we will explore how SIR
  and industry requirements have changed over the
  years and how this has impacted the heartbase
  application.

3
Key Points of Focus
Overview

• PQL enhancements
• Secondary indices
• Datavisors screen painter
• Registry and Government requirements
• Overall impact of these on the heartbase data
  model.

4
Version Migration

• heartbase has successfully migrated to four new
  versions of SIR over the past 12 years, including
  SIR386, SIR40, SIR2000, and SIR2002.
• Version changes have allowed heartbase to
  migrate from a DEC VAX platform to Windows 2003
  (and all the versions in between) creating a
  highly robust database application.

5
Trying to get somewhere better
Migration

• That has been our experience with SIR.
• Each version better than the next, with many
  changes from the time Alpha/Beta is done until we
  complete our mission.

6
Visual Effects
Migration

• Character Based -gt
• Windows OS with character screens -gt
• GUI screens ?
• improved GUI interaction.

7
Software Versions
Migration

• 386 to 4.0
• 4.0 to SIR2000 (also VAX and UNIX migration to
  SIR2000)
• SIR2000 to SIR2002
• SIR2002 to SIRXS

8
How to Migrate to a New Version
Migration

• Unload/Delete/Reload
• Database Export

9
Comment
Migration
Everything worked perfectly and preserved the
deep robust history of the product.
10
PQL Enhancements

• PQL has been a mainstay of the SIR software
  product. We have used it for virtually all of
  the heartbase application development. We will
  explore some of the commands that have been added
  and how they affect heartbase.

11
New commands we use focus on Visual PQL
PQL Enhancements

• DISPLAY infobox
• DISPLAY YESNOBOX
• DISPLAY CANCELBOX
• CURDIR(0)
• APPDIR(0)
• DIALOGS
• BUTTONS, check boxes, edit boxes, etc
• Getitxt, etc
• EDITFILE
• PQL ESCAPE

12
Affect on heartbase
PQL Enhancements

1. Character Based Event Manager

13
Affect on heartbase
PQL Enhancements

1. Initial GUI looking event manager

14
Affect on heartbase
PQL Enhancements

1. Version 2 GUI event manager

15
PQL Enhancements
Old Command Consistency amongst versions
PQL Code 1992 RETRIEVAL PROCESS CASES PROCESS
REC CATH GET VARS ALL WRITE ALL END REC END
CASE END RETRIEVAL
PQL Code 1999 RETRIEVAL PROCESS CASES PROCESS REC
CATH GET VARS ALL WRITE ALL END REC END CASE END
RETREIVAL
PQL Code 2005 RETRIEVAL PROCESS CASES PROCESS REC
CATH GET VARS ALL WRITE ALL END REC END CASE END
RETRIEVAL


16
Comment
PQL Enhancements

• PQL is a very powerful tool that allowed us to
  evolve from a character based set programming
  language to a visually pleasing programming
  language without sacrificing the knowledge base
  we built while learning the product.

17
Secondary Indices

• Alternate lookup techniques for SIR were only
  available if you programmed them yourself. We
  will look at the old methods we used for lookups
  and then show how this code has changed given the
  new Secondary index features in SIR.

18
Case Zero
Secondary Indices

• Issues/Problems
• Synchronization
• Locking case zero impacts
• Programming required for lookups and searches
• Record type requirements

19
Implementation of Secondary Indices
Secondary Indices

• How to use it
• Initial usage had its problems
• Where we are at today

20
Implementation of Secondary Indices
Secondary Indices

• How to use it
• Go to Database on Main Menu and create a
  secondary index
• Create a PQL program to create the index

21
Implementation of Secondary Indices
Secondary Indices

• Initial usage had its problems
• Index Corruption
• Problems accessing with Master

22
Implementation of Secondary Indices
Secondary Indices

• Where we are at today
• Replaced 5 Record Types so far
• Allowed access to data that would have required
  the addition of at least 5 more record types.
• Eliminated about 25 of PQL event management code.

23
Comments
Secondary Indices

• The implementation of secondary indices gave a
  much needed boost to make SIR a more mainstream
  product. Logical case structure, underlying
  relational structure, along with the new
  secondary indices gave SIR the ability to compete
  more effectively with other database software.

24
DataVisor Screen Painter

• DVPainter is a data entry screen application
  development tool designed to work with SIR
  databases. With DVPainter, users design the
  content, appearance and behavior of their data
  entry screens.

25
Evolution of Data Presentation
DataVisor Screen Painter

• Windows 3.11 started the change from a character
  based format to a graphical based screen format.
• Industry impacts and perceptions of data
  presentation.
• Graphical (GOOD) vs. Character (BAD)

26
DataVisor Screen Painter
Screen Painting by Tom

• Tom Shriver invented the first screen painter
  (character based.)

27
The Painter
Registry/Government Requirements

• Each logical view is painted independently
• Trigger mechanisms are version independent
• Screen Descriptions and painter functionality
  control what gets displayed.

28
DataVisor Screen Painter
Screen Painter 1- Character Based

• Exit points
• No mouse
• control

29
DataVisor Screen Painter
Screen Painter 2 Graphical based in SIR2000

• Exit points
• Mouse control

30
Screen Painter 3- Graphical based and more
DataVisor Screen Painter

• Graphical
• Buttons
• Exit points
• Mouse control

31
Registry/Government Requirements

• Reporting registries and the government dictate
  changes required in heartbase. In this section
  we will view a concept used by heartbase called
  filter views.

32
Outside factors that influence heartbase
Registry/Government Requirements

• American College of Cardiology
• Society of Thoracic Surgeons
• Anthem
• Oryx (JCAHO)
• CCORP
• Get with the Guidelines
• Leapfrog

33
Problem
Registry/Government Requirements

• How to present data when many registries require
  the same data, different data and have multiple
  versions of their datasets active?

34
Filter Views
Registry/Government Requirements

• Filter views allow users to have logical
  representation of their data in whatever way is
  needed. Recently, we have had to migrate from ACC
  version 2.0c to version 3.04, while allowing
  users to access their data and to harvest their
  data from either version.

35
Possible Solutions
Registry/Government Requirements

• Create a new database for each version
• Add all the new data points to the existing old
  application
• Create a way to logically see the data points
  for each version in one database.

36
Create a new version for each database
Registry/Government Requirements

• Easy to do
• No problem with data definition overlap
• No longitudinal history in the database
• Data replication
• Difficult reporting due to 2 databases.

37
Add all the new data points to the existing old
application
Registry/Government Requirements

• Easy to do for changing data points
• Difficult to interpret underlying relational DB
  model changes
• Confusing to users.
• Difficult to enforce edits, such as parent/child
  relationship
• Appearance of similar definition fields on the
  same screen that are different.

38
Create a way to logically see the data points for
each version in one database.
Registry/Government Requirements

• More PQL programming required than the other
  solutions
• Easy to present different models in effect
• Easy for users to comprehend
• Easy to enforce parent/child relationships
• Easy to move same data from one view to the next
• Maintain all longitudinal history

39
How do filter views work?
Registry/Government Requirements

• The Event Manager
• The Painter

40
The Event Manager
Registry/Government Requirements

• Allows a way to navigate the relational database
  using folder concepts.
• Links various PQL subroutines together.
• Utilizes Secondary Indices
• Manages all manual data collection, including
  add/change/delete

41
heartbase Event Manager
Registry/Government Requirements
42
heartbase ACC Hosp View
Registry/Government Requirements
43
heartbase STS Hosp View
Registry/Government Requirements
44
Registry/Government Requirements
Comment

• One thing is constant, Change.
• When changes occur, the result is data
  dilemmas. What do you do with old data and new
  data. What do you do with definition changes?
  How do users handle the transition period?

45
Data Model Changes

• Given all the changes above, how has the
  heartbase data model changed? The heartbase data
  model has had the need to evolve with changing
  demands, features of SIR, regulatory changes, and
  user input. Lets take a quick look on how the
  data model has evolved since 1992.

46
heartbase Data Model
Data Model Changes
47
Data Model Changes
Data Model Considerations

• Keys (Case and SORTIDs)
• Design with the future in mind
• Sorting out like types of information
• Speed issues
• To normalize or not normalize (types of users
  affect this thought)

48
Impacts on data model
Data Model Changes

• Reporting and data presentation needs
• Flattening out of relational structures in more
  than one format
• Secondary Indices
• Case Zero reliance reduction
• Government/Regulatory Changes
• More detailed oriented data capture
• Definition consolidation and separation

49
The heartbase Team