autogen-stedi 0.3.2

Auto-generated, strongly-typed Rust client for the Stedi APIs
Documentation
/*
 * Stedi Healthcare
 *
 * No description provided (generated by Openapi Generator https://github.com/openapitools/openapi-generator)
 *
 * The version of the OpenAPI document: 2024-04-01
 * Contact: healthcare@stedi.com
 * Generated by: https://openapi-generator.tech
 */

use crate::healthcare::models;
use serde::{Deserialize, Serialize};

/// Encounter : Details about the eligibility or benefit information you are requesting for the patient. - If you don't specify either `serviceTypeCodes` or a `procedureCode` and `productOrServiceIDQualifier`, Stedi defaults to using `30` (Plan coverage and general benefits) as the only `serviceTypeCodes` value. - You can specify either a single `dateOfService` or a `beginningDateOfService` and `endDateOfService`. The payer defaults to using the current date in their timezone if you don't include one. - When checking eligibility for today, omit the `dateOfService` property to ensure consistent behavior across payers. - We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers such as the Centers for Medicare and Medicaid Services (CMS) do support requests for dates further in the future - especially the next calendar month. Check the payer's documentation to determine their specific behavior.
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct Encounter {
    /// The beginning date of service. If you include this value, you must also include the `endDateOfService`.
    #[serde(rename = "beginningDateOfService", skip_serializing_if = "Option::is_none")]
    pub beginning_date_of_service: Option<String>,
    /// The date of service. You can use this value to specify a single occasion, such as a doctor's visit. If you don't specify a service date (either a single day or a range of dates), the payer defaults to using the current date in their timezone.
    #[serde(rename = "dateOfService", skip_serializing_if = "Option::is_none")]
    pub date_of_service: Option<String>,
    /// Diagnosis code pointers in order of importance to the service. These pointers are an index to the ICD-10 codes you included in the `subscriber.healthCareCodeInformation` or `dependents.healthCareCodeInformation` object arrays. The pointer values can be from 1 - 8 (integer numbers). If you are including diagnosis codes, you **must** set at least one pointer here for the primary diagnosis. Then, you can add up to three additional pointers (up to four in total). Don't put ICD-10 codes here.
    #[serde(rename = "diagnosisCodePointer", skip_serializing_if = "Option::is_none")]
    pub diagnosis_code_pointer: Option<Vec<String>>,
    /// The end date of service. If you include this value, you must also include the `beginningDateOfService`.
    #[serde(rename = "endDateOfService", skip_serializing_if = "Option::is_none")]
    pub end_date_of_service: Option<String>,
    #[serde(rename = "industryCode", skip_serializing_if = "Option::is_none")]
    pub industry_code: Option<models::IndustryCode>,
    /// Use only when you need to send multiple procedure codes in a single request. Otherwise, use the `encounter.procedureCode` and `encounter.productOrServiceIDQualifier` properties.
    #[serde(rename = "medicalProcedures", skip_serializing_if = "Option::is_none")]
    pub medical_procedures: Option<Vec<models::MedicalProcedure>>,
    /// The prior authorization or referral number for a particular benefit or procedure.
    #[serde(rename = "priorAuthorizationOrReferralNumber", skip_serializing_if = "Option::is_none")]
    pub prior_authorization_or_referral_number: Option<String>,
    /// The procedure code.
    #[serde(rename = "procedureCode", skip_serializing_if = "Option::is_none")]
    pub procedure_code: Option<String>,
    /// The procedure modifier that provides additional information related to the performance of the service.
    #[serde(rename = "procedureModifiers", skip_serializing_if = "Option::is_none")]
    pub procedure_modifiers: Option<Vec<String>>,
    #[serde(rename = "productOrServiceIDQualifier", skip_serializing_if = "Option::is_none")]
    pub product_or_service_id_qualifier: Option<models::EncounterProductOrServiceIdQualifier>,
    #[serde(rename = "referenceIdentificationQualifier", skip_serializing_if = "Option::is_none")]
    pub reference_identification_qualifier: Option<models::EncounterReferenceIdentificationQualifier>,
    /// One or more codes classifying the type of services for which you want to receive benefits information.  If you don't specify a service type code or a `procedureCode` and `productOrServiceIDQualifier`, Stedi defaults to using `30` - Health Benefit Plan Coverage. Visit [Service Type Codes](https://www.stedi.com/docs/healthcare/eligibility-stc-procedure-codes#full-stc-list) for a complete list.  Not all payers support all service type codes, and not all payers support multiple service type codes in the same request. We recommend including one service type code per request unless you're sure the payer supports multiple.  Payers aren't required to respond with exactly the same STC(s) in the response, so you may receive benefits information for STCs you didn't request. However, receiving different STCs can mean that the payer is ignoring the STC you sent, which is why we recommend [testing payers](https://www.stedi.com/docs/healthcare/eligibility-stc-procedure-codes#test-payer-stc-support) to determine their support for specific STCs.
    #[serde(rename = "serviceTypeCodes", skip_serializing_if = "Option::is_none")]
    pub service_type_codes: Option<Vec<models::RequestEligibilityServiceTypeCode>>,
}

impl Encounter {
    /// Details about the eligibility or benefit information you are requesting for the patient. - If you don't specify either `serviceTypeCodes` or a `procedureCode` and `productOrServiceIDQualifier`, Stedi defaults to using `30` (Plan coverage and general benefits) as the only `serviceTypeCodes` value. - You can specify either a single `dateOfService` or a `beginningDateOfService` and `endDateOfService`. The payer defaults to using the current date in their timezone if you don't include one. - When checking eligibility for today, omit the `dateOfService` property to ensure consistent behavior across payers. - We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers such as the Centers for Medicare and Medicaid Services (CMS) do support requests for dates further in the future - especially the next calendar month. Check the payer's documentation to determine their specific behavior.
    pub fn new() -> Encounter {
        Encounter {
            beginning_date_of_service: None,
            date_of_service: None,
            diagnosis_code_pointer: None,
            end_date_of_service: None,
            industry_code: None,
            medical_procedures: None,
            prior_authorization_or_referral_number: None,
            procedure_code: None,
            procedure_modifiers: None,
            product_or_service_id_qualifier: None,
            reference_identification_qualifier: None,
            service_type_codes: None,
        }
    }
}