Location metadata storage: Difference between revisions

Line 7:

== 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.

~~{{Discuss | include end dates? and if so, do we need automated checks for them not overlapping? or is it enough that main office is interested in this and would care to find and fix discrepancies? }}~~

== Flexibility for what needs to be collected ==

Line 15:

Line 14:

* Value (the value for the named attribute, e.g. ''10'' in the case of beds)

* Start_DtTm (when did this entity-value combination become true)

* End_DtTm (when did the entity-value combination stop being true)

** end dttm is not needed for complete info, and in fact could become inconsistent, but it will make it easier for the [[Statistician]] to use. Since updates will be rarer than use, the difficulty is worth it

== How and where to keep the master data ==

@@ Line 7: / Line 7: @@
 == 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.
-{{Discuss | include end dates? and if so, do we need automated checks for them not overlapping? or is it enough that main office is interested in this and would care to find and fix discrepancies? }}
 == Flexibility for what needs to be collected ==
@@ Line 15: / Line 14: @@
 * Value (the value for the named attribute, e.g. ''10'' in the case of beds)
 * Start_DtTm (when did this entity-value combination become true)
 * End_DtTm (when did the entity-value combination stop being true)
+** end dttm is not needed for complete info, and in fact could become inconsistent, but it will make it easier for the [[Statistician]] to use. Since updates will be rarer than use, the difficulty is worth it
 == How and where to keep the master data ==