Has provider leaf node

@prefix omop: <https://w3id.org/omop/ontology/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix owlready: <http://www.lesfleursdunormal.fr/static/_downloads/owlready_ontology.owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

omop:has_provider a owl:FunctionalProperty,
        owl:ObjectProperty ;
    rdfs:label "Has provider"^^xsd:string ;
    owlready:python_name "provider"^^xsd:string ;
    rdfs:comment "For Condition Occurrence: The provider associated with condition record, e.g. the provider who made the diagnosis or the provider who recorded the symptom. The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the admitting vs attending physician on an EHR record."@en,
        "For Device Exposure: The Provider associated with device record, e.g. the provider who wrote the prescription or the provider who implanted the device. The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record."@en,
        "For Drug Exposure: The Provider associated with drug record, e.g. the provider who wrote the prescription or the provider who administered the drug. The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the ordering vs administering physician on an EHR record."@en,
        "For Measurement: The provider associated with measurement record, e.g. the provider who ordered the test or the provider who recorded the result. The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record. For example the admitting vs attending physician on an EHR record."@en,
        "For Note: The Provider who wrote the note. The ETL may need to make a determination on which provider to put here."@en,
        "For Observation: The provider associated with the observation record, e.g. the provider who ordered the test or the provider who recorded the result. The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record. For example the admitting vs attending physician on an EHR record."@en,
        "For Person: The Provider refers to the last known primary care provider (General Practitioner). Put the provider_id from the [PROVIDER](https://ohdsi.github.io/CommonDataModel/cdm54.html#provider) table of the last known general practitioner of the person. If there are multiple providers, it is up to the ETL to decide which to put here."@en,
        "For Procedure Occurrence: The provider associated with the procedure record, e.g. the provider who performed the Procedure. The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the admitting vs attending physician on an EHR record."@en,
        "For Visit Detail: There will only be one provider per  **visit** record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). This is a typical reason for leveraging the VISIT_DETAIL table as even though each VISIT_DETAIL record can only have one provider, there is no limit to the number of VISIT_DETAIL records that can be associated to a VISIT_OCCURRENCE record. The additional providers associated to a Visit can be stored in this table where each VISIT_DETAIL record represents a different provider."@en,
        "For Visit Occurrence: There will only be one provider per visit record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). If there are multiple providers associated with a visit in the source, this can be reflected in the event tables (CONDITION_OCCURRENCE, PROCEDURE_OCCURRENCE, etc.) or in the VISIT_DETAIL table. If there are multiple providers associated with a visit, you will need to choose which one to put here. The additional providers can be stored in the [VISIT_DETAIL](https://ohdsi.github.io/CommonDataModel/cdm54.html#visit_detail) table."@en ;
    rdfs:domain [ a owl:Class ;
            owl:unionOf ( omop:Person omop:BaseVisit omop:ConditionOccurrence omop:ProcedureOccurrence omop:Exposure omop:Measurement omop:Observation omop:Note ) ] ;
    rdfs:range omop:Provider ;
    omop:omop_cdm_name "condition_occurrence.provider_id#70 AS Provider"^^xsd:string,
        "device_exposure.provider_id#126 AS Provider"^^xsd:string,
        "drug_exposure.provider_id#92 AS Provider"^^xsd:string,
        "measurement.provider_id#147 AS Provider"^^xsd:string,
        "note.provider_id#195 AS Provider"^^xsd:string,
        "observation.provider_id#168 AS Provider"^^xsd:string,
        "person.provider_id#10 AS Provider"^^xsd:string,
        "procedure_occurrence.provider_id#109 AS Provider"^^xsd:string,
        "visit_detail.provider_id#49 AS Provider"^^xsd:string,
        "visit_occurrence.provider_id#32 AS Provider"^^xsd:string .