Schema for some models not consistent

[dpro-shc]

---

Certain models materialize in the default schema for the dbt profile when running +core__claims. In particular core__stg_claims_eligibility, core__stg_claims_medical_claim (probably should be in the core schema), service_category__stg_inpatient_institutional, service_category__stg_medical_claim, service_category__stg_office_based,service_category__stg_outpatient_institutional, service_category__stg_professional (probably should be in claims_preprocessing)

• Tuva project package version (e.g. 0.6.0): 0.12.2
• dbt version (e.g. 1.7): 1.8.8
• dbt type (e.g. dbt cloud or dbt CLI): CLI
• Data warehouse (e.g. Snowflake): DuckDB (and Postgres)

---

Steps to reproduce the behavior:
dbt run -s +core__medical_claim

A clear and concise description of what you expected to happen.
The appropriate tables materializing in their respective schemas

If applicable, add screenshots to help explain your problem.

Excerpt from querying the information.schema:
table_catalog table_schema table_name
0 dwh_dev main core__stg_claims_eligibility
1 dwh_dev main core__stg_claims_medical_claim
2 dwh_dev main medical_claim
3 dwh_dev main service_category__stg_inpatient_institutional
4 dwh_dev main service_category__stg_medical_claim
5 dwh_dev main service_category__stg_office_based
6 dwh_dev main service_category__stg_outpatient_institutional
7 dwh_dev main service_category__stg_professional

---

I would like to get some clarity as to whether this is intended behavior since I have been unable to produce a non-empty core.medical_claim table

[dpro-shc]

While this behavior is still unexpected, updating Tuva to 0.12.4 and adding in claim_type for all rows did the trick for getting a non-empty result🥳

[cocozuloaga]

Yes, claim_type is needed and that should solve the problem of populating core.medical_claim, but agree that certain tables appearing in the default schema for the dbt profile is unexpected behavior. The appropriate schema for each of those tables should be determined and specified in the corresponding YML file. We'll look into this.