Location metadata storage: Difference between revisions
Jump to navigation
Jump to search
Ttenbergen (talk | contribs) |
Ttenbergen (talk | contribs) m Text replacement - "s_tmp" to "s_tmp table" |
||
| (16 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
We track locations in many fields; they are drawn from either [[s_tmp table]] [[Boarding Loc]] entries or from [[s_dispo table]]. We are interested in some information about some of these locations, like their [[Level of care hierarchy]] / [[s_level_of_care table]] or how many beds they have. | |||
{{Todo | |||
| who =Tina | |||
| question = _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. | |||
| todo_added = 2022-02-09 | |||
| todo_action = 2022-02-09 | |||
}} | |||
{{Todo | |||
| who = Tina | |||
| todo_added = 2022-06-22 | |||
| todo_action = 2022-06-22 | |||
| question = _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. [[User:Ttenbergen|Ttenbergen]] 12:04, 2022 June 22 (CDT) | |||
** It needs to be possible to access this as data. [[User:Ttenbergen|Ttenbergen]] 09:58, 2022 June 28 (CDT) | |||
}} | |||
== Flexibility for values changing over time == | == Flexibility for values changing over time == | ||
| Line 9: | Line 28: | ||
== Flexibility for what needs to be collected == | == Flexibility for what needs to be collected == | ||
There also might be information we have not even considered yet that we might need to track. So, we would want a flexible infrastructure. One way to do this would be something similar to the [https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model Entity–attribute–value model] we use for the [[s_tmp table]] | There also might be information we have not even considered yet that we might need to track. So, we would want a flexible infrastructure. One way to do this would be something similar to the [https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model Entity–attribute–value model] we use for the [[s_tmp table]]. See [[s_LocationData table]] for more info. | ||
== How and where to keep the master data == | == How and where to keep the master data == | ||
| Line 25: | Line 38: | ||
== Types of data to consider == | == Types of data to consider == | ||
* | * CC bed numbers are in | ||
** | ** S:\WRHA\WRHA_CCMED\CCMDB_SAS_by_Julie\SASCFE\CC_data\CCBedMonth.xlsx | ||
* | ** S:\MED\MED_CCMED\CCMDB_ADMIN_DATABASE\Bed_CountAndDates\CCBedMonth.xlsx | ||
* Med numbers are not really tracked; there is an outdated list that was maintained by Trish in | |||
* | ** S:\MED\MED_CCMED\CCMDB_ADMIN_DATABASE\Bed_CountAndDates\BedBaseMonthly_Medicine.xlsx | ||
* | ** S:\MED\MED_CCMED\CCMDB_ADMIN_DATABASE\!BedBase_count_CC_Med | ||
* possibly other things: [[Collection location documentation]] / [[Site and Location table]] | |||
* [[STB-L2HA]] is an overflow location... do we want to designate those somehow? | |||
* we need a process to import the data from the wiki into ccmdb.accdb | |||
* we need a process to get a download from https://whiteboard.manitoba-ehealth.ca/whiteboard/icu onto wiki when it updates | |||
* HOBS info - [[Change_of_remaining_location_names_from_"our"_names_to_EPR/Cognos_names#How_will_we_code_the_HOBS_status_of_a_unit]] | * HOBS info - [[Change_of_remaining_location_names_from_"our"_names_to_EPR/Cognos_names#How_will_we_code_the_HOBS_status_of_a_unit]] | ||
* | * [[Level of care hierarchy]] - currently lives in [[s_dispo table]] as "acuity_level" but we need to move it to here because it now needs to apply to [[Boarding Loc]]s | ||
* another possible use would be to store COVID status of a unit | |||
== Related articles == | == Related articles == | ||
{{Related Articles}} | {{Related Articles}} | ||
[[Category: Location Information]] | |||
Latest revision as of 08:40, 2023 May 18
We track locations in many fields; they are drawn from either s_tmp table Boarding Loc entries or from s_dispo table. We are interested in some information about some of these locations, like their Level of care hierarchy / s_level_of_care table or how many beds they have.
|
_locationData
|
|
|
|
_locationData
|
|
Flexibility for values changing over time
The actual values for some of this information change over time, e.g. a ward may cease to be a HOBS, or an ICU may increase its bed number. If we simply included a column for the information, we would not be able to store different information over time. So we need to store this in a linked table instead, where there could be multiple lines with different dates per location. We could include start and end dates, but really including only start dates would be enough to encode this fully, since the start date of the next later location would automatically be the end date of the former. It would be easier to use lines with both start and end dates (no linking between lines required that way), but then there would be a risk of overlapping time periods.
Flexibility for what needs to be collected
There also might be information we have not even considered yet that we might need to track. So, we would want a flexible infrastructure. One way to do this would be something similar to the Entity–attribute–value model we use for the s_tmp table. See s_LocationData table for more info.
How and where to keep the master data
This data is useful to external users of our data to make sense of it.
We would become aware of changes to this data either when a collector stumbles across the change during their collection activities, or when management informs us, usually as part of requesting data.
We already collect data with a similar requirement: the ICD10 Categories. We could store this data the same way and make use of similar mechanisms to integrate it into our analyses. That is, the data is updated on wiki by whoever finds out that something has changed, and Tina then runs a process to extract an updated data table from the wiki to include in CCMDB.accdb.
Types of data to consider
- CC bed numbers are in
- S:\WRHA\WRHA_CCMED\CCMDB_SAS_by_Julie\SASCFE\CC_data\CCBedMonth.xlsx
- S:\MED\MED_CCMED\CCMDB_ADMIN_DATABASE\Bed_CountAndDates\CCBedMonth.xlsx
- Med numbers are not really tracked; there is an outdated list that was maintained by Trish in
- S:\MED\MED_CCMED\CCMDB_ADMIN_DATABASE\Bed_CountAndDates\BedBaseMonthly_Medicine.xlsx
- S:\MED\MED_CCMED\CCMDB_ADMIN_DATABASE\!BedBase_count_CC_Med
- possibly other things: Collection location documentation / Site and Location table
- STB-L2HA is an overflow location... do we want to designate those somehow?
- we need a process to import the data from the wiki into ccmdb.accdb
- we need a process to get a download from https://whiteboard.manitoba-ehealth.ca/whiteboard/icu onto wiki when it updates
- HOBS info - Change_of_remaining_location_names_from_"our"_names_to_EPR/Cognos_names#How_will_we_code_the_HOBS_status_of_a_unit
- Level of care hierarchy - currently lives in s_dispo table as "acuity_level" but we need to move it to here because it now needs to apply to Boarding Locs
- another possible use would be to store COVID status of a unit