-
Incomplete or inconsistent periods of observation. For example, when in a claims dataset a patient is under continuous observation for medical coverage but only has prescription coverage for part of that time. Under the current model, the patient would either have a shorter period of complete observation or a longer period of mixed observation status. Currently, conversions can leverage the Payer Plan Period table to specify the types of coverage provided within an observation period, but in practice this is informal and non-standard. Users new to a dataset have no consistent way to check for the types of observation a patient is under or how to define them (or even know if they need to).
A short term solution might be to leverage the Payer Plan Period table using new standard concepts for coverage type (in one of the concept id fields), and make it a best practice to always check the coverage type prior to any new analysis to confirm the types of events expected to be under observation in a given period. This could also be borrowed for combined datasets where the type events under observation may also change over time but are not related to payer coverage (i.e. a combined EHR and claims dataset where a patient’s observation period for each data type may not align perfectly). We could set up defined payer_plan_periods that need to be filled out for claim ETLs and EMR ETLS to help standardize these entries. We’ll use the payer_concept_id field to standardize the following for claims data: medical, drug, medical/drug coverage. Then for EMR, we could use: patient in network (to define all current visit data for that patient), data in network (to define all data related to patients in network), etc.
A better, longer term solution would be to modify the CDM itself to allow for different ‘flavors’ of Observation Period to be captured. This could be done with a new table similar to Payer Plan (i.e. observation_period_detail?), but without the confusion of forcing that domain to do double duty or support cases where the types of events observed are not based on payer coverage. So within a patient’s higher-level observation period, there would be a sub-domain to capture observation period type (what events are expected to be captured) and duration using standard concepts and having standard methods to allow naive users of a dataset to determine when a patient is under observation and eligible for a given analysis. The standards proposed in the payer_plan_period will move to the observation_period_detail table.
If we don’t want to add a new table to the CDM, and we do not like the payer_plan_period option, we can leverage the period_type_concept_id field available in the observation_period table. Please see specs below (from https://github.com/OHDSI/CommonDataModel/wiki/OBSERVATION_PERIOD):
We can set up standards for using this field to define the different types of observation_periods a patient can have. Again, use the following for claims data: medical, drug, medical/drug coverage. Then for EMR data, we could use: patient in network (to define all current visit data for that patient), data in network (to define all data related to patients in network), etc.
- For events which fall outside a patient’s observation period, the current standard places them in the Observation table regardless of original domain and they are considered to be patient history (or else they are excluded from the conversion altogether). This covers some uses rather well, but in other cases may too limited when more complete information about an historical event is needed. Would a new domain type concept id to classify ‘historic’ events, stored in the appropriate event domains, be desirable or useful?