| OHDSI Home | Forums | Wiki | Github |
Many EHR data holders have “historical” data. Historical data is generally defined as data that was recorded in an EHR system prior to the current EHR in use at a hospital. Not all data transfers over, so it isn’t the complete record of data for a person. However, this is important data that is converted to the CDM, but it is of potentially questionable quality because it’s incomplete. We need a generic type_concept_id for this.
@aostropolets thoughts?
Why not just start the OBSERVATION_PERIOD with the new EHR? Then, all the data from before automatically are considered not fulfilling the completeness expectation.
Hm. I’d create two observation periods for two EHR systems, as you can’t really say if a new one is of a better quality than an old one. It actually makes more sense to separate the transition period when people don’t know how to deal with the new system 
Good ideas and logic, but Observation Periods for EHR data isn’t complete to begin. Per the description, “The OBSERVATION_PERIOD table contains records which uniquely define the spans of time for which a Person is at-risk to have clinical events recorded within the source systems”. We interpret it as the first event for a person_id to the last event for person_id. This includes our historical data.
A type_concept_id = ‘historical’ allows us to identify the provenance of the data. Similar to “person (self) reported”, “From physical examination”, or “EHR billing diagnosis”.
Yes, but you are saying you don’t trust the old one to be complete, which means, you assume the new one to be reasonably complete. As good as EHR gets. Here you go. We changed the convention for this reason.
Yes, except it is unintelligible outside your system. Nobody knows that the old one is not trustworthy, and the new one is. Unless we create a new convention, where it says “historical” = not complete. In that case, we could just call it “incomplete”. Well, or we use OBSERVATION_PERIOD, which is designed to say exactly that. See my point?
Don’t kick the can down the road to some analyst who happens to have tacit knowledge of a specific database. It’s not interoperable. We need to solve these issues generically.