# Mapping clinical event time and system store time to openEHR
**URL:** https://discourse.openehr.org/t/mapping-clinical-event-time-and-system-store-time-to-openehr/17364
**Category:** Clinically Relevant RM Discussions
**Tags:** rm, archetype, ehrbase, time, question, mapping
**Created:** [7 October 2026 11:38 UTC](https://discourse.openehr.org/t/mapping-clinical-event-time-and-system-store-time-to-openehr/17364 "2026-10-07T11:38:55Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@Benjamin2107](https://discourse.openehr.org/u/Benjamin2107)
#### Post date: [7 October 2026 11:38 UTC](https://discourse.openehr.org/t/mapping-clinical-event-time-and-system-store-time-to-openehr/17364/1 "2026-10-07T11:38:56Z")
Hey everyone,
I’m currently working on mapping clinical source datasets to openEHR and persisting the resulting Compositions in EHRbase. My current dataset is MIMIC-IV, but the mapping system is intended to support other clinical datasets as well.
During the transformation, there might be several timestamps existing for the same source record:
- the time when a clinical observation was made (MIMIC: `charttime`)
- the start and end of interventions (MIMIC: `starttime` , `endtime`)
- the time when information was entered or validated (MIMIC: `storetime`)
- the time when information became available to clinicians (MIMIC: `storetime`)
- the time when transformed data got imported into EHRbase (Local: `MyOwnTime`)
The exact meaning of `storetime` differs between source tables which makes the correct mapping even harder.
My problem is the following:
I would like to preserve the distinctions instead of treating every timestamp as “clinical event time”, because the differentiation can change the retrospective research outcome. Analyses based on event time versus information availability can produce different results.
My questions are:
1. Is is it appropriate to put timestamps like `starttime` , `endtime` and `charttime` into the clinical ENTRY structures, like `EVENT.time`, `HISTORY.origin`, etc.?
2. Where should a source-system documentation/validation/availability timestamp be represented? Is `FEEDER_AUDIT` intended for this purpose?
My concrete evaluation use case is the calculation of clinical scores, such as SOFA. I want to compare calculations based on when an event actually occured with calculations based on when the information actually was available. Therefore, retaining the different temporal meanings in a queryable correct way is important.
I would be interested in how experienced openEHR contributors would model this, especially when preserving source-system information for research is important.
Thanks in advance 🙂
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [7 October 2026 14:28 UTC](https://discourse.openehr.org/t/mapping-clinical-event-time-and-system-store-time-to-openehr/17364/2 "2026-10-07T14:28:40Z")
Hi Benjamin,
I’ll give it a go!!
- the time when a clinical observation was made (MIMIC: `charttime`)
Definitely OBSERVATION.event.time and OBSERVATION.origin (they are identical for a point in time event)
- the start and end of interventions (MIMIC: `starttime` , `endtime`)
What is meant by 'interventions in this context? Can you give an example?
- the time when information was entered or validated (MIMIC: `storetime`)
COMPOSITION.context.start\_time
- the time when information became available to clinicians (MIMIC: `storetime`)
FEEDER\_AUDIT\_DETAILS.time (as the availability\_time in the original system
- the time when transformed data got imported into EHRbase (Local: `MyOwnTime`)
VERSION wrapper commit\_time ( completed automatically when you commit a composition)
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [7 October 2026 18:21 UTC](https://discourse.openehr.org/t/mapping-clinical-event-time-and-system-store-time-to-openehr/17364/3 "2026-10-07T18:21:59Z")
Just to add to that, this might help (from [here in the specs](https://specifications.openehr.org/releases/RM/development/ehr.html#_time_in_the_ehr)):
