Requirements for Re-Platforming

This is an index for content relevant to the U of M IT team in proposing a solution for hosting our database.

Repeated failure points we should address before going too far

We have had many failed attempts at re-platforming. The technical change would be tedious but doable, the sticking points have always been around the following, so we should discuss these before planning too much further.

• governance of any implemented system
• data ownership
• support model
• our team's continued ability to change this as needed

Relatively Hard Facts

• 15-20 users on laptops, sometimes working from home, sometimes not connected to the network due to lack if wifi
• About 2-2.5GB of data altogether as stored in various MS Access DBs (size may vary on other platforms)
• Has several highly customized front-ends that facilitates efficient and low-error data entry
  • facilitates data entry from a daily dump received from ADT
• Data we need to store is in Auto Data Dictionary
  • it is currently stored in CCMDB Data Structure - this structure could be stored differently but would cause large changes
• We have (and continuously improve) Data Integrity Checks

Requirements

as also discussed in UM MedIT Re-platforming Meetings, with decisions made tracked there and the "current master" located here.

Here is that draft, including for each item, a preliminary notation of its priority, on a scale of 1=lowest priority to 5=highest priority. After the draft is completed, we will need to complete the MedIT Project Intake Process form, and then Kiran and her team will consider the best options for our needs.

• Maintaining, without reduction the current functionality of the data input by the data collectors on the laptops (5)
  • facilitated input of admissions from Shared Health export (5)
  • Data Integrity Checks for complete and incomplete records (5)
  • maintaining the format/structure as much as possible (3)
• Allowing us to upload data collected on patients from the laptops to the server (5) -- although this could possible occur via some intermediary program
• us to modify individual data items in individual records (5)
• Allowing us to modify multiple (and possible ALL) records in a "batch" (5)
• Allowing the statistician and Process Analyst to operate on (read and write) the data using SAS or additional Windows tools (see Statistician's PC for current tools, but consider "our choice of tools" for this requirement)
• Allowing Julie, Pagasa and Tina to bi-directionally transfer the data (5) <-- this item could use some clarification from the 3 of them
• Allowing Julie to interface with the data via SAS (5) -- although this could possible occur via some intermediary program
• To the maximum extent possible, maintaining an interface with the data that looks like, and has functionalities of, our current MS ACCESS interface (4)
• Ability, in future, to expand the capabilities of the databases by linking the data to other data obtained automatically -- e.g. Canadian Blood Services data about blood transfusions (4)
  • Ability for our team to built the ETL to manage these updates, rather than rely on other teams (4)
• Ability, in future, to link our database with the Shared Health Datamart (or name-of-the-day) (4)

Current Implementation

• system of intermittently linked MS Access databases with a fair bit of automation
• facilitated interfaces with Shared Health systems (we request and receive data in files that we import as either temporary or permanent data)
• number of fields not necessarily relevant because of Entity–attribute–value model of the L Tmp V2 table