Requirements for Re-Platforming: Difference between revisions

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.

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

*'''Regarding data collection and uploading:'''

** ~~[[Data Integrity Checks]] for complete and incomplete records~~ (5)

**Maintaining facilitated input of admissions from the daily Shared Health data export (5)

** Maintaining the ~~format/structure as much as possible~~ (3)

**Maintaining, without change (or with minimal change) the current data input by data collectors on the laptops (4)

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

**Allowing data collectors to add and update the data they are working on -- up until they mark a record as "complete" (5). Currently we do this by "[[sending]]" -- although this could possible occur via some intermediary program

~~***~~ Currently we do this by "[[sending]]" -- although this could possible occur via some intermediary program

**Allowing data collectors to collect chart data for patients in sites that may have poor or non-existent [[wifi]] (3) -- this relates to [[sending]] (uploading) data to the database

** Allowing data collectors to collect ~~from~~ sites that may have poor or non-existent [[wifi]] (3)

{{DL | difficult to say, right now we have wifi access everywhere, used to be sketchy at the death desk but we no longer are able to review charts there, SBGH does not have wifi in the basement where med records is located would we be able to use the database offline? like we currently do [[User:Lkaita|Lisa Kaita]] 20:59, 23 March 2025 (CDT)}}

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

*'''Regarding data processing after uploading:'''

* 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 our database personnel 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)

**Maintaining the current [[Data Processing]] functionality for the [[data processor]], who often works remotely (5)

**Allowing the [[Statistician]] to interface with the data via SAS or additional tools (5) -- although this could possible occur via some intermediary program

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

}}

**Allow modification individual data items in individual records (5)

**Allow modification of multiple (and possible ALL) records in a "batch" via queries and/or automation (5)

**Continued ability for us to perform [[Data Integrity Checks]], for both complete and incomplete records (5) -- currently done via ACCESS and SAS

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

*'''Miscellaneous items:'''

**Maintaining the back end data format/structure as much as possible (3)

**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) (?)

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

* 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

** Ability ''for the CCMDB team'' to modify the data structure (5)

== Current Implementation ==

@@ 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.
-* 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)
+*'''Regarding data collection and uploading:'''
-** [[Data Integrity Checks]] for complete and incomplete records (5)
+**Maintaining facilitated input of admissions from the daily Shared Health data export (5)
-** Maintaining the format/structure as much as possible (3)
+**Maintaining, without change (or with minimal change) the current data input by data collectors on the laptops  (4)
-** 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)
+**Allowing data collectors to add and update the data they are working on -- up until they mark a record as "complete" (5).  Currently we do this by "[[sending]]" -- although this could possible occur via some intermediary program
-*** Currently we do this by "[[sending]]" -- although this could possible occur via some intermediary program
+**Allowing data collectors to collect chart data for patients in sites that may have poor or non-existent [[wifi]] (3) -- this relates to [[sending]] (uploading) data to the database
-** Allowing data collectors to collect from sites that may have poor or non-existent [[wifi]] (3)
 {{DL | difficult to say, right now we have wifi access everywhere, used to be sketchy at the death desk  but we no longer are able to review charts there, SBGH does not have wifi in the basement where med records is located would we be able to use the database offline? like we currently do  [[User:Lkaita|Lisa Kaita]] 20:59, 23 March 2025 (CDT)}}
-* 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)
+*'''Regarding data processing after uploading:'''
-* 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 our database personnel 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)
+{{Discuss | I think this can go, it's addressed above. }}
+**Maintaining the current [[Data Processing]] functionality for the [[data processor]], who often works remotely (5)
+**Allowing the [[Statistician]] to interface with the data via SAS or additional tools (5) -- although this could possible occur via some intermediary program
 {{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)
 }}
+**Allow modification individual data items in individual records (5)
+**Allow modification of multiple (and possible ALL) records in a "batch" via queries and/or automation (5)
+**Continued ability for us to perform [[Data Integrity Checks]], for both complete and incomplete records (5) -- currently done via ACCESS and SAS
-* 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)
+*'''Miscellaneous items:'''
+**Maintaining the back end data format/structure as much as possible (3)
+**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) (?)
+**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) }}
+* 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.}}
 == Current Implementation ==