View table: ToDo

just Tina's working notes: Scenarios:

• one of a * of ICD10s
• one of a * of ICD10s AND one of a * of ICD10s
• one of a * of ICD10s AND an ICD10 with a word in it
• one of a * of ICD10s AND one of a * of CCIs
• one of a * of CCIs
• two or more of a * of ICD10s

AND any admit procedure is EITHER: (a) of the form 1.AA.xx, 1.AB.xx, 1.AC.xx, 1.AE.xx, 1.AD.xx, 1.AG.xx, 1.AJ.xx, 1.AK.xx, 1.AN.xx, 1.AP.xx

where “xx” = any of 13, 51, 52, 53, 56, 57, 59, 72, 76, 80, 87, 89, 90, 91

or (b) 2.AA.71.yy, 2.AB.71.yy, 2.AC.71.yy, 2.AE.71.yy, 2.AD.71.yy, 2.AG.71.yy, 2.AJ.71.yy, 2.AK.71.yy, 2.AN.71.yy, 2.AP.71.yy

where “yy” = any of 70.^, 71.^

• one of a * of ICD10s AND (one of * of CCI1 and a * of CCI2)
  • might be able to do a pattern recognition on that? Or a regular expression?

_after

• Field is legacy; once no longer used, remove it from sending and then from ccmdb_data. Query to check:

SELECT L_Log.D_ID, L_Log.RecordStatus, L_Log.Accept_DtTm, L_Log.Arrive_DtTm

FROM L_Log

WHERE (((L_Log.RecordStatus)="incomplete") AND ((L_Log.Accept_DtTm) Is Not Null) AND ((L_Log.Arrive_DtTm) Is Not Null));

• 98 left as of 2022-08-04
• None left as of 2023-05-04, field can be removed...
  • remove from sending
  • remove from CCMDB_data

_after

• Identified as something we should do to streamline data collection. I have made this page to document progress toward this import.
  • This will not happen until we have a PHIA approved repository. Ttenbergen 11:32, 2022 February 9 (CST)
    • Nothing will come of this until our data is stored elsewhere, so pulling it onto my list so we have some record that this is an outstanding want. Ttenbergen 13:04, 2022 June 22 (CDT)

_locationData

• How should we now keep track of the ward/unit info on the wiki? More questions on page.Ttenbergen 16:07, 2021 July 14 (CDT)
  • Perhaps this can also be included in the Location metadata storage you will set up showing the start and end dates and the bed size. --JMojica 14:32, 2022 February 7 (CST)
    • Agreed! This is also why I think where possible we should shift the s_dispo contents to the same name so the Location metadata storage can supply both. I want to discuss how to best encode this with you, hopefully tomorrow at out wiki meeting. Ttenbergen 15:14, 2022 February 8 (CST)
      • I need the s_dispo because I am using the other columns as various categories of the detailed numeric locations name and I do not want to drop it for now. I have yet to see the Location metadata storage you are talking about to decide.
        • Sorry didn't say that clearly. Don't mean to eliminate s_dispo table at this time, just want to make sure we use same location name as in Boarding Loc where applicable, so we can store the metadata all in one table. Ttenbergen 13:36, 2022 February 9 (CST)
          • Decided at Task today that this likely needs to be done on wiki with dates. Taking off Julie's list until I figure out details Ttenbergen 16:01, 2022 June 22 (CDT)

_wiki_housekeeping

• How should we now keep track of the ward info on the wiki? Do we actually need to? Or is it sufficient to tell the number of beds at e.g. Grace Medicine? what links to site/locations page is likely an indicator of the audience for this info, but Julie may well link from reports as well. Depending how we want to use this going forward, a static page might be an option, but then we can no longer link to individual locations. If we keep separate locations, we need to make sure we keep them updated.
• I have put this on Julie's question list as well, and emailed Julie and Lisa about it. Ttenbergen 16:07, 2021 July 14 (CDT)

_after

• Identified as something we should do; the notes below are quite old but might still be a starting point.
  • This will not happen until we have a PHIA approved repository. Ttenbergen 11:32, 2022 February 9 (CST)
    • Nothing will come of this until our data is stored elsewhere, so pulling it onto my list so we have some record that this is an outstanding want. Ttenbergen 13:04, 2022 June 22 (CDT)

CTU vs NTU - we decided at task that we wanted to eliminate the distinction. A lot of things are part of their network of information, so we will need to work out the details above before we can move ahead.

• I believe it was only related to Transfer Ready DtTm field between CTU and NTU not eliminate the concept. Medicine program would have to weigh in. Trish Ostryzniuk 16:11, 2018 July 30 (CDT)
  • I seem to remember the reason to stop doing this also involved that we have more and more locations that don't fall into a clean place. For now we pretend we can give medicine this data, but is it true and meaningful? Ttenbergen 15:51, 2018 July 31 (CDT)
    • Allan will contact the medicine stakeholders about eliminating this distinction. Will email Mary-Ann Lynch, VanAmeyde, Griffin. Ttenbergen 12:18, 2019 January 24 (CST)
      • pinged again for Allan to Follow-up. Ttenbergen 13:44, 2019 February 25 (CST)
• AG REPLY: DONE. NOBODY is using or seeking this info. So let's stop collecting it.

• I came across this issue because Julie's data and mine had different Transfer Delay when this location was involved. This seems to mean that Julie's doesn't use the table to designate level of care. That could become a source of inconsistency. Should we do this the same way? What is the obstacle? Ttenbergen 13:45, 2022 October 13 (CDT)
  • I do not use the s_level_of_care table for the reason that the same location can be assigned with more than one level of care either CC or HOBS or regular. I simplify the process in my program. For Critical Care, since each record is based by unit, if the patient stays in more than one boarding loc i.e. ER/PACU/Home unit/offservice unit, I consider them under the same level of care. Ex an IICU pt staying at SICU/GGA7/GA7S have same level of care, an ICMS patient staying at L2ME(IMCU)/L2HA(Recovery)/home unit/offunit(ACCU/ICCS) are under same level of care. For Medicine, in my program, for each record and boarding locations, I just need to distinguish the HOBS locations (e.g. HSC-GH7S,HSC_HOBS,HSC_H4H,HSC_B2 (only from dt 4/7/2020 to 8/7/2020) and STB_IMCU) and others not specified as HOBS are treated as regular wards (no need to spell out the individual names and no worry if new location comes up which are not yet added in the s_level_of_care table). --JMojica 16:33, 2022 October 14 (CDT)

• Is this a unit we currently collect on? What is it now? Ttenbergen 13:45, 2022 October 13 (CDT)
  • It is currently empty, I think it is used as contingency beds Lisa Kaita 12:19, 2022 October 20 (CDT)
    • Yes, it seems to be a wildcard place. So we need to document on this page when we find out a change in function, since it affects how we categorize admissions. EG at some point this was an ICU, at another a Med ward (possibly high obs). Ttenbergen 17:31, 2022 November 3 (CDT)

• This same location has different levels of care over time. Currently the s_level_of_care table can only accommodate one, ie changes over time can't be included in it. My first thought was to include start and end times for this, but what if patients from both programs were boarding on a given unit at the same time? Can that happen? The very concept that these are boarding locations kind of means crazy things could go on. How do we best accommodate this? Would we always know as a physical location (especially a boarding one) changes LOC? Ttenbergen 13:53, 2022 October 13 (CDT)

• In the meantime I am changing the LOC for this location to 50 in s_level_of_care table since I think that table is only used by the queries that derive Transfer Delay. Ttenbergen 13:45, 2022 October 13 (CDT)

• discussed 10:59, 2023 April 19 (CDT), we need to be able to assign different values over time. Ttenbergen 10:59, 2023 April 19 (CDT)

_locationData

• _Dev_CFE linking of s_LocationData table
• _Dev_CCMDB - process to import data from wiki (similar to Converting ICD10 between wiki and ccmdb.accdb)
• set up wiki template for locations
• consider data import for locations so no manual pre-populating of pages
• S_level_of_care needs to be integrated with whatever metadata we set up
• discussed at Task whether we should wait for Shared Health info, will make our own; Shared Health's data is no better than ours, so won't do that.
• STB-L2HA is another page we will need to include when we deal with this.

_locationData

• Discussed at JALT; we need to store this on a per page on wiki level, with multiple start and end dates being possible. Tina needs to create the structure for this and pre-populate. Probably discuss with Julie at the planning stage. Ttenbergen 12:04, 2022 June 22 (CDT)
  • It needs to be possible to access this as data. Ttenbergen 09:58, 2022 June 28 (CDT)

• Lisa flagged that, if we do this for Cardiac Arrest, we should really do it for other dxs as well. And if we did that, it could result in a lot of work since it would need to be mediated by Pagasa for now. So we decided to see where the SF implementation goes and review the definition of this check once we have a centralized tool where the data collector would not need to mediate this. Ttenbergen 15:43, 2023 July 13 (CDT)
  • Now that SF is on hold, leave this as a to do?Lisa Kaita 14:42, 2024 October 2 (CDT)
    • I am OK with turning this into a to-do if SF is on hold for the forseeable future. Ttenbergen 12:46, 2024 October 3 (CDT)

• At the meeting about cross checks (a long time ago) it was decided to change the cut-off to SD*3; if we want to proceed with this check, I will need values for that. Ttenbergen 23:08, 2020 October 15 (CDT)
  • the MED above has to changed. I will do a calculation of recent data based on the new process using Mean+3SD. --JMojica 15:16, 2022 February 16 (CST)
    • I am waiting for your Created Variables CC 2021 table and Created TransferReady query to be done and from that table, the calculation of mean +3 SD will be derived. --JMojica 09:41, 2022 June 7 (CDT)
      • Created Variables CC 2021 table is now done. Ttenbergen 14:34, 2022 June 30 (CDT)
        • new queries are live now so this could proceed. Ttenbergen 16:46, 2023 April 19 (CDT)
          • new queries are live but need to be validated before we do this. Ttenbergen 16:08, 2023 May 3 (CDT)

z

• Possible future scenario: The data processor puts the concern into the Notes field and sets the RecordStatus field to "questioned". Next time the collector sends, the record is returned to the laptop by a series of queries. The collector updates the record, sets it to "complete" and sends it in with the next round of sends, at which time it will be processed like any other record.

This process is more automated and would need to be validated before we could implement. It would be the least work for all involved, though, I think.

We keep discussing this, talked about it again today. Ttenbergen 17:44, 2016 December 1 (CST)

locationData

• No longer applicable, we discussed today that we will need multiple start and end dates and that it maybe should be stored on wiki.

---

• _dev_CCMDB - the process to import from wiki should run a consistency check on the start and end dates to ensure there is no overlap of same attribute
• _dev_CFE - include this in the import of s_ tables at startup; there was a second s_ table to pull into CFE, emailed Julie for which one