There are several ways to potentially define an episode. Fundamentally, we need a start and an end datetime. The start is already required to onboard patients into the database and so is 100 serves to identify the end of an epsiode, which is often much less clearly defined. Potential sources of information, in order of precidence include:
date and time of in unit death: 0042 and 0043
date and time of brainstem death: 0044 and 0045
episode end date time: 0412
date and time of body removed: 0038 and 0039
the last regularly recorded observation from HR (0108) and SpO2 (0129)
The goal is not to create a perfect record, as doing so drops too many cases. Rather, the goal is to characterise the episode in a meaningful way. This means that episodes cannot have negative episode length, and you should not be able to record a vital sign after a death has occurred. If date and time of death preceed the discharge time we overwrite the episode end datetime with the date and time of death. The same is not true for brainstem death and body removal. This would result in a situation whereby a body is kept physiologically active on the ICU, but the episode is now listed as finished.
characterise_episodes(connection = NULL)
| connection | a connection to the CC-HIC database |
|---|
a tibble that characterises each episode. The attribute "invalid_records" contains information related to invalid records and the reason for invalidation
Since a patient can only die once, checks are also performed to ensure that death events, can only be linked to a single episode. This is relevent for the following situations:
More than one episode has become linked with the same death event. In this situation, the final episode is closed with an end datetime of the datetime of death. The death is then uncoupled from any prior episodes
A patient was discharged alive, but subseqnetly died.
Checks are taken to ensure that episodes are non-overlapping, though they can run immediately from one to the next.