Requirements for Re-Platforming: Difference between revisions
Jump to navigation
Jump to search
Ttenbergen (talk | contribs) |
Ttenbergen (talk | contribs) |
||
| Line 22: | Line 22: | ||
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. | 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) | * 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) | ** [[Data Integrity Checks]] for complete and incomplete records (5) | ||
** | ** Maintaining the format/structure as much as possible (3) | ||
* Allowing | ** Allowing data collectors to add and update the data they are working on, but not other collectors records (this will need definition), but to no longer be able to update it once they "complete" it. (5) | ||
* | *** Currently we do this by "[[sending]]" -- although this could possible occur via some intermediary program | ||
* Allowing us to modify | ** Allowing data collectors to collect from sites that may have poor or non-existent [[wifi]] | ||
* Allowing the [[ | {{DL | (Lisa, what priority?) }} | ||
* | * Maintaining the current [[Data Processing]] functionality for the [[data processor]], who often works remotely (5) | ||
* Ability for the following two things is necessarily interconnected, but listed separately to allow for some flexibility | |||
** Ability ''for the CCMDB team'' to update that functionality to data collection and data processing by adding to or updating front end, queries and automation, without gatekeeping | |||
{{Discuss | let's talk about this... is that a 5? It is to me.}} | |||
** Ability ''for the CCMDB team'' to modify the data structure (5) | |||
{{Discuss | let's talk about this... is that a 5? It is to me.}} | |||
* Allowing us to modify bulk data via queries and/or automation (5) | |||
* Allowing the [[Statistician]] and the [[Process Analyst]] to transfer data into and out of the database, such as an export to file or import from file, ad hoc (5) | |||
* Allowing the [[Statistician]] to read the data using SAS or additional Windows tools (see [[Statistician's PC]] for current tools, but consider "our choice of tools" for this requirement) (3) | |||
{{DJ| | |||
* I don't think you write from SAS, right? [[User:Ttenbergen|Ttenbergen]] 14:33, 17 March 2025 (CDT) | |||
* I made this a (3) because the ability to export above would provide a work-around of copying data to local; open to discuss. [[User:Ttenbergen|Ttenbergen]] 14:33, 17 March 2025 (CDT) | |||
}} | |||
* To the maximum extent possible, maintaining an interface with the data that looks like, and has functionalities of, our current MS ACCESS interface (4) | * To the maximum extent possible, maintaining an interface with the data that looks like, and has functionalities of, our current MS ACCESS interface (4) | ||
{{Discuss | I think this can go, it's addressed above. }} | |||
* 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, 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) | ||
{{Discuss | I think we would have this covered technically with the CCMDB team's ability to edit data, queries, automation and front end, so this one needs to cover the governance portion of our ability (permission?) to do this. How do we need to paraphrase it? [[User:Ttenbergen|Ttenbergen]] 14:33, 17 March 2025 (CDT)}} | |||
** Ability for our team to built the ETL to manage these updates, rather than rely on other teams (4) | ** Ability for our team to built the ETL to manage these updates, rather than rely on other teams (4) | ||
* | ** Technical ability, in future, to link our database with the Shared Health Datamart (or name-of-the-day) (?) | ||
{{Discuss | | |||
* What would be the priority for this? | |||
* Technical because governance and permissions are a separate issue we would need to address; not SH's, but our service providers for any solution. | |||
* Let's talk about this; this is where SH data will live, and if we can't interact with it in the future the utility of our data will be greatly reduced. [[User:Ttenbergen|Ttenbergen]] 14:33, 17 March 2025 (CDT) }} | |||
== Current Implementation == | == Current Implementation == | ||
Latest revision as of 14:33, 17 March 2025
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 data collectors to add and update the data they are working on, but not other collectors records (this will need definition), but to no longer be able to update it once they "complete" it. (5)
- Currently we do this by "sending" -- although this could possible occur via some intermediary program
- Allowing data collectors to collect from sites that may have poor or non-existent wifi
|
(Lisa, what priority?) |
- Maintaining the current Data Processing functionality for the data processor, who often works remotely (5)
- Ability for the following two things is necessarily interconnected, but listed separately to allow for some flexibility
- Ability for the CCMDB team to update that functionality to data collection and data processing by adding to or updating front end, queries and automation, without gatekeeping
|
let's talk about this... is that a 5? It is to me. |
- Ability for the CCMDB team to modify the data structure (5)
|
|
let's talk about this... is that a 5? It is to me. |
- Allowing us to modify bulk data via queries and/or automation (5)
- Allowing the Statistician and the Process Analyst to transfer data into and out of the database, such as an export to file or import from file, ad hoc (5)
- Allowing the Statistician to read the data using SAS or additional Windows tools (see Statistician's PC for current tools, but consider "our choice of tools" for this requirement) (3)
|
|
- To the maximum extent possible, maintaining an interface with the data that looks like, and has functionalities of, our current MS ACCESS interface (4)
|
|
I think this can go, it's addressed above. |
- 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)
|
|
I think we would have this covered technically with the CCMDB team's ability to edit data, queries, automation and front end, so this one needs to cover the governance portion of our ability (permission?) to do this. How do we need to paraphrase it? Ttenbergen 14:33, 17 March 2025 (CDT) |
- Ability for our team to built the ETL to manage these updates, rather than rely on other teams (4)
- Technical ability, in future, to link our database with the Shared Health Datamart (or name-of-the-day) (?)
|
|
|
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
Related articles
| Related articles: |