https://w3id.org/omop/ontology/PayerPlanPeriod
The PAYER_PLAN_PERIOD table captures details of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer. Each Person receiving healthcare is typically covered by a health benefit plan, which pays for (fully or partially), or directly provides, the care. These benefit plans are provided by payers, such as health insurances or state or government agencies. In each plan the details of the health benefits are defined for the Person or her family, and the health benefit Plan might change over time typically with increasing utilization (reaching certain cost thresholds such as deductibles), plan availability and purchasing choices of the Person. The unique combinations of Payer organizations, health benefit Plans and time periods in which they are valid for a Person are recorded in this table.
Instances of Payer plan period can have the following properties:
| PROPERTY | TYPE | DESCRIPTION | RANGE |
|---|---|---|---|
| From class Payer plan period | |||
| Contract source value | owl:DatatypeProperty | For Payer Plan Period: This is the relationship of the PERSON_ID to CONTRACT_PERSON_ID as it appears in the source data. | string |
| Family source value | owl:DatatypeProperty | For Payer Plan Period: The common identifier for all people (often a family) that covered by the same policy. Often these are the common digits of the enrollment id of the policy members. | string |
| Payer source value | owl:DatatypeProperty | For Payer Plan Period: This is the Payer as it appears in the source data. | string |
| Plan source value | owl:DatatypeProperty | For Payer Plan Period: This is the health benefit Plan of the Person as it appears in the source data. | string |
| Sponsor source value | owl:DatatypeProperty | For Payer Plan Period: The Plan sponsor as it appears in the source data. | string |
| Stop reason source value | owl:DatatypeProperty | For Payer Plan Period: The Plan stop reason as it appears in the source data. | string |
| Has contract | owl:FunctionalProperty | For Payer Plan Period: This field represents the relationship between the PERSON_ID and CONTRACT_PERSON_ID. It should be read as PERSON_ID is the *CONTRACT_CONCEPT_ID* of the CONTRACT_PERSON_ID. So if CONTRACT_CONCEPT_ID represents the relationship 'Stepdaughter' then the Person for whom PAYER_PLAN_PERIOD record was recorded is the stepdaughter of the CONTRACT_PERSON_ID. If available, use this field to represent the relationship between the PERSON_ID and the CONTRACT_PERSON_ID. If the Person for whom the PAYER_PLAN_PERIOD record was recorded is the stepdaughter of the CONTRACT_PERSON_ID then CONTRACT_CONCEPT_ID would be [4330864](https://athena.ohdsi.org/search-terms/terms/4330864). If not available, set to 0. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&domain=Relationship&page=12&pageSize=15&query=). | Concept |
| Has contract person | owl:FunctionalProperty | For Payer Plan Period: The Person who is the primary subscriber/contract owner for Plan. This may or may not be the same as the PERSON_ID. For example, if a mother has her son on her plan and the PAYER_PLAN_PERIOD record is the for son, the sons's PERSON_ID would go in PAYER_PLAN_PERIOD.PERSON_ID and the mother's PERSON_ID would go in PAYER_PLAN_PERIOD.CONTRACT_PERSON_ID. | Person |
| Has contract source | owl:FunctionalProperty | For Payer Plan Period: If the source data codes the relationship between the PERSON_ID and CONTRACT_PERSON_ID in an OMOP supported vocabulary store the concept_id here. If not available, set to 0. | Concept |
| Has payer | owl:FunctionalProperty | For Payer Plan Period: This field represents the organization who reimburses the provider which administers care to the Person. Map the Payer directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same payer, though the name of the Payer is not necessary. If not available, set to 0. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Payer&standardConcept=Standard&page=1&pageSize=15&query=). | Concept |
| Has payer source | owl:FunctionalProperty | For Payer Plan Period: If the source data codes the Payer in an OMOP supported vocabulary store the concept_id here. If not available, set to 0. | Concept |
| Has plan | owl:FunctionalProperty | For Payer Plan Period: This field represents the specific health benefit Plan the Person is enrolled in. Map the Plan directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same health benefit Plan though the name of the Plan is not necessary. If not available, set to 0. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Plan&standardConcept=Standard&page=1&pageSize=15&query=). | Concept |
| Has plan source | owl:FunctionalProperty | For Payer Plan Period: If the source data codes the Plan in an OMOP supported vocabulary store the concept_id here. If not available, set to 0. | Concept |
| Has sponsor | owl:FunctionalProperty | For Payer Plan Period: This field represents the sponsor of the Plan who finances the Plan. This includes self-insured, small group health plan and large group health plan. Map the sponsor directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same sponsor though the name of the sponsor is not necessary. If not available, set to 0. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Sponsor&standardConcept=Standard&page=1&pageSize=15&query=). | Concept |
| Has sponsor source | owl:FunctionalProperty | For Payer Plan Period: If the source data codes the sponsor in an OMOP supported vocabulary store the concept_id here. | Concept |
| Has stop reason concept | owl:FunctionalProperty | For Payer Plan Period: This field represents the reason the Person left the Plan, if known. Map the stop reason directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&standardConcept=Standard&page=1&pageSize=15&query=). | Concept |
| Has stop reason source | owl:FunctionalProperty | For Payer Plan Period: If the source data codes the stop reason in an OMOP supported vocabulary store the concept_id here. | Concept |
| From class Date duration | |||
| End date | owl:DatatypeProperty | For Visit Occurrence: For inpatient visits the end date is typically the discharge date. Visit end dates are mandatory. If end dates are not provided in the source there are three ways in which to derive them: Outpatient Visit: visit_end_datetime = visit_start_datetime Emergency Room Visit: visit_end_datetime = visit_start_datetime Inpatient Visit: Usually there is information about discharge. If not, you should be able to derive the end date from the sudden decline of activity or from the absence of inpatient procedures/drugs. Non-hospital institution Visits: Particularly for claims data, if end dates are not provided assume the visit is for the duration of month that it occurs. For Inpatient Visits ongoing at the date of ETL, put date of processing the data into visit_end_datetime and visit_type_concept_id with 32220 "Still patient" to identify the visit as incomplete. All other Visits: visit_end_datetime = visit_start_datetime. If this is a one-day visit the end date should match the start date. - For Device Exposure: The DEVICE_EXPOSURE_END_DATE denotes the day the device exposure ended for the patient, if given. Put the end date or discontinuation date as it appears from the source data or leave blank if unavailable. - For Condition Occurrence: Use this date to determine the end date of the condition Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE. - For Visit Detail: This the end date of the patient-provider interaction. Visit Detail end dates are mandatory. If end dates are not provided in the source there are three ways in which to derive them:<br> - Outpatient Visit Detail: visit_detail_end_datetime = visit_detail_start_datetime - Emergency Room Visit Detail: visit_detail_end_datetime = visit_detail_start_datetime - Inpatient Visit Detail: Usually there is information about discharge. If not, you should be able to derive the end date from the sudden decline of activity or from the absence of inpatient procedures/drugs. - Non-hospital institution Visit Details: Particularly for claims data, if end dates are not provided assume the visit is for the duration of month that it occurs.<br> For Inpatient Visit Details ongoing at the date of ETL, put date of processing the data into visit_detai_end_datetime and visit_detail_type_concept_id with 32220 "Still patient" to identify the visit as incomplete. All other Visits Details: visit_detail_end_datetime = visit_detail_start_datetime. - For Payer Plan Period: End date of Plan coverage. - For Location History: The date the relationship ended - For Drug Exposure: The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for the patient. If this information is not explicitly available in the data, infer the end date using the following methods:/n/n 1. Start first with duration or days supply using the calculation drug start date + days supply -1 day. 2. Use quantity divided by daily dose that you may obtain from the sig or a source field (or assumed daily dose of 1) for solid, indivisibile, drug products. If quantity represents ingredient amount, quantity divided by daily dose * concentration (from drug_strength) drug concept id tells you the dose form. 3. If it is an administration record, set drug end date equal to drug start date. If the record is a written prescription then set end date to start date + 29. If the record is a mail-order prescription set end date to start date + 89. The end date must be equal to or greater than the start date. Ibuprofen 20mg/mL oral solution concept tells us this is oral solution. Calculate duration as quantity (200 example) * daily dose (5mL) /concentration (20mg/mL) 200*5/20 = 50 days. [Examples by dose form](https://ohdsi.github.io/CommonDataModel/drug_dose.html) - For Observation Period: Use this date to determine the end date of the period for which we can assume that all events for a Person are recorded. It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_end_date can be inferred as the last Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer. | date |
| Start date | owl:DatatypeProperty | For Location History: The date the relationship started - For Visit Detail: This is the date of the start of the encounter. This may or may not be equal to the date of the Visit the Visit Detail is associated with. When populating visit_start_date, you should think about the patient experience to make decisions on how to define visits. Most likely this should be the date of the patient-provider interaction. - For Drug Exposure: Use this date to determine the start date of the drug record. Valid entries include a start date of a prescription, the date a prescription was filled, or the date on which a Drug administration was recorded. It is a valid ETL choice to use the date the drug was ordered as the DRUG_EXPOSURE_START_DATE. - For Device Exposure: Use this date to determine the start date of the device record. Valid entries include a start date of a procedure to implant a device, the date of a prescription for a device, or the date of device administration. - For Condition Occurrence: Use this date to determine the start date of the condition Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE. - For Payer Plan Period: Start date of Plan coverage. - For Observation Period: Use this date to determine the start date of the Observation Period It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_start_date can be inferred as the earliest Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer. If a Person switches plans but stays with the same payer, and therefore capturing of data continues, that change would be captured in [PAYER_PLAN_PERIOD](https://ohdsi.github.io/CommonDataModel/cdm60.html#payer_plan_period). - For Visit Occurrence: For inpatient visits, the start date is typically the admission date. For outpatient visits the start date and end date will be the same. When populating visit_start_date, you should think about the patient experience to make decisions on how to define visits. In the case of an inpatient visit this should be the date the patient was admitted to the hospital or institution. In all other cases this should be the date of the patient-provider interaction. | date |
| From class OMOP CDM thing | |||
| Id | owl:DatatypeProperty | For Note: A unique identifier for each note. - For Vocabulary: A unique identifier for each Vocabulary, such as ICD9CM, SNOMED, Visit. - For Observation: The unique key given to an Observation record for a Person. Refer to the ETL for how duplicate Observations during the same Visit were handled. Each instance of an observation present in the source data should be assigned this unique key. - For Note Nlp: A unique identifier for the NLP record. - For Location: The unique key given to a unique Location. Each instance of a Location in the source data should be assigned this unique key. - For Drug Exposure: The unique key given to records of drug dispensings or administrations for a person. Refer to the ETL for how duplicate drugs during the same visit were handled. Each instance of a drug dispensing or administration present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same drug within the same visit. It is valid to keep these duplicates and assign them individual, unique, DRUG_EXPOSURE_IDs, though it is up to the ETL how they should be handled. - For Specimen: Unique identifier for each specimen. - For Observation Period: A Person can have multiple discrete Observation Periods which are identified by the Observation_Period_Id. Assign a unique observation_period_id to each discrete Observation Period for a Person. - For Cohort Definition: This is the identifier given to the cohort, usually by the ATLAS application - For Concept Class: A unique key for each class. - For Device Exposure: The unique key given to records a person's exposure to a foreign physical object or instrument. Each instance of an exposure to a foreign object or device present in the source data should be assigned this unique key. - For Procedure Occurrence: The unique key given to a procedure record for a person. Refer to the ETL for how duplicate procedures during the same visit were handled. Each instance of a procedure occurrence in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same procedure within the same visit. It is valid to keep these duplicates and assign them individual, unique, PROCEDURE_OCCURRENCE_IDs, though it is up to the ETL how they should be handled. - For Cost: A unique identifier for each COST record. - For Domain: A unique key for each domain. - For Survey Conduct: Unique identifier for each completed survey. For each instance of a survey completion create a unique identifier. - For Visit Detail: Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit detail. This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time. - For Care Site: Assign an id to each unique combination of location_id and place_of_service_source_value. - For Concept: A unique identifier for each Concept across all domains. - For Measurement: The unique key given to a Measurement record for a Person. Refer to the ETL for how duplicate Measurements during the same Visit were handled. Each instance of a measurement present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same measurement within the same visit. It is valid to keep these duplicates and assign them individual, unique, MEASUREMENT_IDs, though it is up to the ETL how they should be handled. - For Condition Occurrence: The unique key given to a condition record for a person. Refer to the ETL for how duplicate conditions during the same visit were handled. Each instance of a condition present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same condition within the same visit. It is valid to keep these duplicates and assign them individual, unique, CONDITION_OCCURRENCE_IDs, though it is up to the ETL how they should be handled. - For Provider: It is assumed that every provider with a different unique identifier is in fact a different person and should be treated independently. This identifier can be the original id from the source data provided it is an integer, otherwise it can be an autogenerated number. - For Person: It is assumed that every person with a different unique identifier is in fact a different person and should be treated independently. Any person linkage that needs to occur to uniquely identify Persons ought to be done prior to writing this table. This identifier can be the original id from the source data provided if it is an integer, otherwise it can be an autogenerated number. - For Visit Occurrence: Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit. This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time. - For Payer Plan Period: A unique identifier for each unique combination of a Person, Payer, Plan, and Period of time. | owl:Thing |
| From class Thing | |||
| OMOP CDM name | owl:AnnotationProperty | owl:Thing | |
@prefix omop: <https://w3id.org/omop/ontology/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
omop:PayerPlanPeriod a owl:Class ;
rdfs:label "Payer plan period"^^xsd:string ;
rdfs:comment "The PAYER_PLAN_PERIOD table captures details of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer. Each Person receiving healthcare is typically covered by a health benefit plan, which pays for (fully or partially), or directly provides, the care. These benefit plans are provided by payers, such as health insurances or state or government agencies. In each plan the details of the health benefits are defined for the Person or her family, and the health benefit Plan might change over time typically with increasing utilization (reaching certain cost thresholds such as deductibles), plan availability and purchasing choices of the Person. The unique combinations of Payer organizations, health benefit Plans and time periods in which they are valid for a Person are recorded in this table."@en ;
rdfs:subClassOf [ a owl:Restriction ;
owl:onProperty [ owl:inverseOf omop:has_payer_plan_period ] ;
owl:someValuesFrom omop:Person ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Person ;
owl:onProperty omop:has_contract_person ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_payer ],
[ a owl:Restriction ;
owl:onProperty omop:has_payer ;
owl:someValuesFrom omop:Concept ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:payer_source_value ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_payer_source ],
[ a owl:Restriction ;
owl:onProperty omop:has_payer_source ;
owl:someValuesFrom omop:Concept ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_plan ],
[ a owl:Restriction ;
owl:onProperty omop:has_plan ;
owl:someValuesFrom omop:Concept ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:plan_source_value ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_plan_source ],
[ a owl:Restriction ;
owl:onProperty omop:has_plan_source ;
owl:someValuesFrom omop:Concept ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_contract ],
[ a owl:Restriction ;
owl:onProperty omop:has_contract ;
owl:someValuesFrom omop:Concept ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:contract_source_value ],
[ a owl:Restriction ;
owl:onProperty omop:contract_source_value ;
owl:someValuesFrom xsd:string ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_contract_source ],
[ a owl:Restriction ;
owl:onProperty omop:has_contract_source ;
owl:someValuesFrom omop:Concept ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_sponsor ],
[ a owl:Restriction ;
owl:onProperty omop:has_sponsor ;
owl:someValuesFrom omop:Concept ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:sponsor_source_value ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_sponsor_source ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:family_source_value ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_stop_reason_concept ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:stop_reason_source_value ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_stop_reason_source ],
omop:DateDuration ;
omop:omop_cdm_name "payer_plan_period"^^xsd:string .