Change of remaining location names from "our" names to EPR/Cognos names: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
 
(45 intermediate revisions by 3 users not shown)
Line 2: Line 2:
We have done a [[Change of GRA location names from "our" names to EPR/Cognos names]], this page is about doing the same change at our other sites.  
We have done a [[Change of GRA location names from "our" names to EPR/Cognos names]], this page is about doing the same change at our other sites.  


== Decision to go ahead ==
We decided to go ahead with this change at [[Task_Team_Meeting_-_Rolling_Agenda_and_Minutes_2021#ICU Database Task Group Meeting – April 15, 2021]] (#3), confirmed at [[Task_Team_Meeting_-_Rolling_Agenda_and_Minutes_2021#ICU Database Task Group Meeting – April 22, 2021 |the next Task meeting]] and again the one after.


However, there were emails and/or wiki discussions after this that raised concerns.  
== Preparation needed ==
=== Change of data entry ===
* Nothing to change in [[Previous Location]], [[Pre-admit Inpatient Institution]], [[Dispo]]
** we already use generic *_Med in medicine, so it already doesn't allow automatic mapping
 
== Data use changes ==
We need to make sure that [[Level of care hierarchy]] infrastructure is updated to accommodate the changes. [[User:Ttenbergen|Ttenbergen]] 15:10, 2022 January 26 (CST)
 
 
{{Discuss | JALT - Is there anything here we want to do before SF? Or that still needs to be done at all? [[User:Ttenbergen|Ttenbergen]] 09:42, 2023 July 6 (CDT)
* What happens to the ICU  [[Previous Location]], [[Pre-admit Inpatient Institution]], [[Dispo]] or even [[Service Location]] - should they be changed too by the new COGNOS ICU locations? Example current STB_ACCU is SBGH-CCUO in COGNOS, STB_CICU is SBGH_ICCS, STB_MICU is SBGH_ICMS.  Should the old labels remain? We need to think hard for its implications to queries of linking and/or matching tables before implementing any change. --[[User:JMojica|JMojica]] 16:33, 2022 February 2 (CST)
** It would be nice to have this consistent, and yet you are correct that this would tie into a lot of things. I think the benefits of making it consistent win out, though especially when it comes to also thinking about this in terms of that metadata we discussed the other day. Even if we keep the (possibly identical) data in both s_tmp and s_dispo for now, we would then be able to use that metadata table for both. This would require thinking through the details. Julie, I think it only involves you and me, so maybe we should discuss at our wiki meetings? [[User:Ttenbergen|Ttenbergen]] 13:44, 2022 February 8 (CST)
*** Julie and Tina discussed:
:::* We use the 4 fields [[Previous Location]], [[Pre-admit Inpatient Institution]], [[Dispo]] and [[Service/Location]] also to map patient flow between laptops, and we very much don't use Cognos values for this (e.g. HSC_Med). We need to retain this ability to use the entries for linking but would also make them the same as Cognos where possible. So we need to keep our "own" values for this for locations where we collect.
:::* We decided to use manually split CC entries e.g. HSC_MICU vs HSC_SICU since Julie reports in those increments, ie it is hard to pull apart a stay in two ICU types if it is collected as one record. We don't want to lose that.
:::* We would still like to change these own values to the "modern" values where we use legacy terms, eg. STB ICMS vs STB MICU. As long as we make a clean transition between old and new, or change all old, that should not be a problem, but we need to account for it.
:::* We could use the Cognos values for all places where we don't collect, e.g. if a pt comes from Ward HSC_A1 and Cognos lists that as HSC-GA1, we could just enter that. However, for locations we don't collect we currently aggregate this to HSC_ward. Do we want the extra detail? It would be easier to enter but might be harder to interpret and possibly even harder to work with for collectors.
:::* If we want to keep our proprietary value for locations where we collect, and keep aggregate ones for locations where we don't collect, I am not sure which locations that then leaves where we would use the Cognos values?
*** Julie, do you agree to that summary? If so, there may be nothing to discuss with Lisa, since we will need to leave this as is. If I am missing something pls update and then pass on to Lisa for her take. [[User:Ttenbergen|Ttenbergen]] 16:56, 2022 March 23 (CDT)
**** agree. pass to lisa. --[[User:JMojica|JMojica]] 15:27, 2022 June 8 (CDT)
*I think this is no longer an issue, unless we are looking to change how we collect this, which I am not in favor of [[User:Lkaita|Lisa Kaita]] 12:23, 2022 August 24 (CDT)
** Even though this is no longer an issue, we should keep the above 5 summary issues here for future reference.  --[[User:JMojica|JMojica]] 13:38, 2024 March 12 (CDT)
}}
 
 
 
=== How will we code the HOBS status of a unit ===
Julie reports differently on HOBS units, e.g. the [[Transfer Ready DtTm]] is separate for them. So Julie needs to be able to determine whether a pt is in HOBS. Currently this is done by naming a unit HOBS, i.e. HOBS is not named with its actual location but by its special status. The actual location of the HOBS unit has changed over time and will probably change again.
 
Julie, Lisa and Tina discussed and agreed that all three of the following options are ''possible'' but we have not come to a conclusion which is better.  
 
HOBS information will be implemented as [[Location metadata storage]].
 
We have several possible ways to deal with this going forward:
* continue designating the HOBS property in the name
** Pros:
*** easy for Julie because the info is implied
** Cons:
*** breaks the Cognos tracking
*** makes it hard to assign other meta data to units in the future (eg covid or palliative or other status of a unit)


{{Discuss |
* code boarding loc as Cognos/EPR name and put a check mark if the unit is currently a HOBS unit
*It's a blur to me now, but I seem to remember people still raising concerns about this change after the meeting. If you have ongoing concerns, please post them here. [[User:Ttenbergen|Ttenbergen]] 16:36, 2021 May 6 (CDT)
** Pros:
}}
*** easy for Julie because the info is right in the data she has connected already anway
*** works with Cognos tracking
** Cons:
*** collectors would continually have to enter this for a HOBS unit
*** then we would need a cross check to make sure this is consistently entered, yet if it's entered always for a unit, then why enter it?
*** makes it hard to assign other metadata to units in the future (eg covid or palliative or other status of a unit)


== Preparation needed ==
* store the metadata of a unit in a different table linked by actual location name, with start and end dates
The related data dropdowns live in three tables: [[s_Cognos_Units table]], [[S dispo table]]]], [[s_tmp table]].
** Pros:
*** works with Cognos tracking
*** is invisible / no action required to collectors in day-to-day data entry
*** is flexible and extensible to other metadata we may want to use in the future (but currently would be used for only one thing)
** Cons:  
*** it is more difficult for Julie to set up (but this is a one-time task)
*** collectors would no longer actually declare that a pt is HOBS, so there is concern that we would not find out if a unit changes status in a timely manner
*** who will be responsible to tell the exact start and end date - expected to be done by the collector (also see general caveat)


* Tina would need to map current [[s_dispo table]] locations with [[Boarding Loc]] options so they compare properly. Some of this was previously started in [[s_Cognos_Units table]].Dispo, but this has blanks and has not been validated.
'''Caveat:'''
* Tina would need to determine what needs to be added to the [[Boarding Loc]] dropdown. {{Collapsable
* For all of these options, a concern is how would main office ever find out if a unit changes to or from being a HOBS unit. Julie doesn't hear about this from management. This is more of a problem for option 3, but it is also an issue for options 1 and 2.
| always= here is the query
* As an example why this is relevant, this affects e.g. [[Level of care hierarchy]] and therefore [[Transfer Ready DtTm]].
| full=  }}


== Collector instructions ==
== Collector instructions ==
Line 24: Line 72:
** we will keep the old ones around for now - if we removed them there would likely be problems in CCMDB
** we will keep the old ones around for now - if we removed them there would likely be problems in CCMDB
*** we will leave both old and new active until all are changed   
*** we will leave both old and new active until all are changed   
* Nothing to change in [[Previous Location]], [[Pre-admit Inpatient Institution]], [[Dispo]] - we will change the "names" you see in the fields that use [[s_dispo table]] - you won't need to change these, they will just reflect the change in the reference table
{{Discuss |
* that will likely be more complicated at the other sites since these are not necessarily one-to-one mappigns... }}


=== Transition plan ===
=== Transition plan ===
* The [[Boarding Loc]] entries for all records currently on the laptops will be manually changed by the respective collectors collectors starting on <code>[[#Change Date]]</code> and before <code>[[#Change Date]]</code> + 7 days.  
We are planning to do this on admissions start Jan 1, 2022 (2022Q1), so some retrospective entries will be needed. Pagasa would need to make changes for any that are already completed and sent.
 
It was decided to store the HOBS info in [[Location metadata storage]], so the actual location should be used in [[Boarding Loc]].


== Tina's instructions ==
== Tina's instructions ==
Line 47: Line 94:


== Change Date ==
== Change Date ==
<code>Change Date</code> '''= 2020-12-16''':  
Working on implementation date. [[User:Ttenbergen|Ttenbergen]] 12:56, 2022 January 25 (CST)


== Status ==
== Status ==
*2021-04-29 - Julie email confirmed that she doesn't need the specific info listed on these pages since we now get the details in [[Boarding Loc]]. [[User:Ttenbergen|Ttenbergen]] 15:43, 2021 April 29 (CDT)
* 2021-04-15 [[Task_Team_Meeting_-_Rolling_Agenda_and_Minutes_2021#ICU_Database_Task_Group_Meeting_–_April_15,_2021 | Task Meeting]] decided we should change these to the designations in Cognos.


* ?? [[Change of GRA location names from "our" names to EPR/Cognos names|completed at GRA]]
=== Decision to go ahead ===
 
We decided to go ahead with this change at [[Task_Team_Meeting_-_Rolling_Agenda_and_Minutes_2021#ICU Database Task Group Meeting – April 15, 2021]] (#3), confirmed at [[Task_Team_Meeting_-_Rolling_Agenda_and_Minutes_2021#ICU Database Task Group Meeting – April 22, 2021 |the next Task meeting]] and again the one after.  
{{DJ |
* As per email from 2021-05-04, "The question is whether to use the generic HIGH OBS and IMCU instead of physical locations H7S or L2ME if we would like to  enter the physical locations COGNOS is showing.  If the decision is physical Locations – how would I know which are the high obs  wards? we would have to put it in the comments, so are we any further ahead?" How does that feature into our plan to move all to Cognos values? On the same note, it appears that GRA is using two designations for PACU dependign on post-OR vs Covid use...
** I say we use the actual location. Whether or not that location is currently HOBS or otherwise might change. Boarding Loc is a location, not a location type. This would make working [[Level of care hierarchy]] harder; we would likely need to add a new table that includes when units were what level, ie location, level startdttm. Are there other things it would make harder?
}}
 
* 2021-04-15 [[Task_Team_Meeting_-_Rolling_Agenda_and_Minutes_2021#ICU_Database_Task_Group_Meeting_–_April_15,_2021 | Task Meeting]] decided we should change these to the designations in Cognos.


== Related articles ==  
== Related articles ==  

Latest revision as of 13:38, 2024 March 12

We use different names for locations in s_dispo table (Previous Location, Pre-admit Inpatient Institution, Dispo) than in Cognos EPR Report, and sometimes different again in Boarding Loc. We have done a Change of GRA location names from "our" names to EPR/Cognos names, this page is about doing the same change at our other sites.


Preparation needed

Change of data entry

Data use changes

We need to make sure that Level of care hierarchy infrastructure is updated to accommodate the changes. Ttenbergen 15:10, 2022 January 26 (CST)


JALT - Is there anything here we want to do before SF? Or that still needs to be done at all? Ttenbergen 09:42, 2023 July 6 (CDT)
  • What happens to the ICU Previous Location, Pre-admit Inpatient Institution, Dispo or even Service Location - should they be changed too by the new COGNOS ICU locations? Example current STB_ACCU is SBGH-CCUO in COGNOS, STB_CICU is SBGH_ICCS, STB_MICU is SBGH_ICMS. Should the old labels remain? We need to think hard for its implications to queries of linking and/or matching tables before implementing any change. --JMojica 16:33, 2022 February 2 (CST)
    • It would be nice to have this consistent, and yet you are correct that this would tie into a lot of things. I think the benefits of making it consistent win out, though especially when it comes to also thinking about this in terms of that metadata we discussed the other day. Even if we keep the (possibly identical) data in both s_tmp and s_dispo for now, we would then be able to use that metadata table for both. This would require thinking through the details. Julie, I think it only involves you and me, so maybe we should discuss at our wiki meetings? Ttenbergen 13:44, 2022 February 8 (CST)
      • Julie and Tina discussed:
  • We use the 4 fields Previous Location, Pre-admit Inpatient Institution, Dispo and Service/Location also to map patient flow between laptops, and we very much don't use Cognos values for this (e.g. HSC_Med). We need to retain this ability to use the entries for linking but would also make them the same as Cognos where possible. So we need to keep our "own" values for this for locations where we collect.
  • We decided to use manually split CC entries e.g. HSC_MICU vs HSC_SICU since Julie reports in those increments, ie it is hard to pull apart a stay in two ICU types if it is collected as one record. We don't want to lose that.
  • We would still like to change these own values to the "modern" values where we use legacy terms, eg. STB ICMS vs STB MICU. As long as we make a clean transition between old and new, or change all old, that should not be a problem, but we need to account for it.
  • We could use the Cognos values for all places where we don't collect, e.g. if a pt comes from Ward HSC_A1 and Cognos lists that as HSC-GA1, we could just enter that. However, for locations we don't collect we currently aggregate this to HSC_ward. Do we want the extra detail? It would be easier to enter but might be harder to interpret and possibly even harder to work with for collectors.
  • If we want to keep our proprietary value for locations where we collect, and keep aggregate ones for locations where we don't collect, I am not sure which locations that then leaves where we would use the Cognos values?
      • Julie, do you agree to that summary? If so, there may be nothing to discuss with Lisa, since we will need to leave this as is. If I am missing something pls update and then pass on to Lisa for her take. Ttenbergen 16:56, 2022 March 23 (CDT)
        • agree. pass to lisa. --JMojica 15:27, 2022 June 8 (CDT)
  • I think this is no longer an issue, unless we are looking to change how we collect this, which I am not in favor of Lisa Kaita 12:23, 2022 August 24 (CDT)
    • Even though this is no longer an issue, we should keep the above 5 summary issues here for future reference. --JMojica 13:38, 2024 March 12 (CDT)
  • SMW


  • Cargo


  • Categories


How will we code the HOBS status of a unit

Julie reports differently on HOBS units, e.g. the Transfer Ready DtTm is separate for them. So Julie needs to be able to determine whether a pt is in HOBS. Currently this is done by naming a unit HOBS, i.e. HOBS is not named with its actual location but by its special status. The actual location of the HOBS unit has changed over time and will probably change again.

Julie, Lisa and Tina discussed and agreed that all three of the following options are possible but we have not come to a conclusion which is better.

HOBS information will be implemented as Location metadata storage.

We have several possible ways to deal with this going forward:

  • continue designating the HOBS property in the name
    • Pros:
      • easy for Julie because the info is implied
    • Cons:
      • breaks the Cognos tracking
      • makes it hard to assign other meta data to units in the future (eg covid or palliative or other status of a unit)
  • code boarding loc as Cognos/EPR name and put a check mark if the unit is currently a HOBS unit
    • Pros:
      • easy for Julie because the info is right in the data she has connected already anway
      • works with Cognos tracking
    • Cons:
      • collectors would continually have to enter this for a HOBS unit
      • then we would need a cross check to make sure this is consistently entered, yet if it's entered always for a unit, then why enter it?
      • makes it hard to assign other metadata to units in the future (eg covid or palliative or other status of a unit)
  • store the metadata of a unit in a different table linked by actual location name, with start and end dates
    • Pros:
      • works with Cognos tracking
      • is invisible / no action required to collectors in day-to-day data entry
      • is flexible and extensible to other metadata we may want to use in the future (but currently would be used for only one thing)
    • Cons:
      • it is more difficult for Julie to set up (but this is a one-time task)
      • collectors would no longer actually declare that a pt is HOBS, so there is concern that we would not find out if a unit changes status in a timely manner
      • who will be responsible to tell the exact start and end date - expected to be done by the collector (also see general caveat)

Caveat:

  • For all of these options, a concern is how would main office ever find out if a unit changes to or from being a HOBS unit. Julie doesn't hear about this from management. This is more of a problem for option 3, but it is also an issue for options 1 and 2.
  • As an example why this is relevant, this affects e.g. Level of care hierarchy and therefore Transfer Ready DtTm.

Collector instructions

Work in progress, don't go ahead with these yet!

  • we would make available the new unit entries as per wording in Cognos EPR Report as options for the Boarding Loc dropdown
    • we will keep the old ones around for now - if we removed them there would likely be problems in CCMDB
      • we will leave both old and new active until all are changed

Transition plan

We are planning to do this on admissions start Jan 1, 2022 (2022Q1), so some retrospective entries will be needed. Pagasa would need to make changes for any that are already completed and sent.

It was decided to store the HOBS info in Location metadata storage, so the actual location should be used in Boarding Loc.

Tina's instructions

  • inactivate the old options
    • target date #Change Date
    • confirm no remaining old entries in pre-inpt, previous, service/loc, dispo.
SQL - but this is the wrong one...   

SELECT L_Log.D_ID, s_dispo.location_name, L_Log.RecordStatus, s_dispo.program FROM L_Log INNER JOIN s_dispo ON L_Log.Service_Location = s_dispo.dispo_ID WHERE (((s_dispo.location_name)<>"GRA_Med" And (s_dispo.location_name)<>"GRA_CC") AND ((L_Log.RecordStatus)<>"vetted") AND ((s_dispo.Site)="GRA"));

Data Processor's instructions

  • For Vetted cases, Pagasa has to change the affected ITEM values; this should be done by query, ask Tina for help with the queries if needed

Change Date

Working on implementation date. Ttenbergen 12:56, 2022 January 25 (CST)

Status

  • 2021-04-15 Task Meeting decided we should change these to the designations in Cognos.

Decision to go ahead

We decided to go ahead with this change at Task_Team_Meeting_-_Rolling_Agenda_and_Minutes_2021#ICU Database Task Group Meeting – April 15, 2021 (#3), confirmed at the next Task meeting and again the one after.

Related articles

Related articles: