Results for “prmry_care_prvdr_typ_cd_m”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

BENBV_PRMRY_CARE_PRVDR_V is a read-only view owned by the APPS schema within the Oracle E-Business Suite Advanced Benefits (BEN) module. Its documented purpose is to identify the primary care providers, physicians, and chiropractors associated with a participant enrolled in a plan or option in plan, or linked to a dependent covered under that enrollment. The view presents this provider information through a business-group-secured query, meaning visibility is restricted to records matching the business group derived from the security profile of the querying session. Because it is defined WITH READ ONLY, it is intended strictly for reporting, inquiry, and integration extraction rather than for DML operations. The object is documented as VALID in both the 12.1.1 and 12.2.2 releases of Oracle EBS.

Underlying Base Objects

The view is defined over a single base object: BEN_PRMRY_CARE_PRVDR_F (referenced via a synonym). This is the primary care provider entity table in Advanced Benefits, and it supplies all descriptive, identification, and WHO (audit) columns exposed by the view. In addition to the base table, the view text calls the HR_BIS package for two purposes: HR_BIS.BIS_DECODE_LOOKUP is invoked to translate the provider type code from the BEN_PCP_SPCLTY lookup into its meaningful display value, and HR_BIS.GET_SEC_PROFILE_BG_ID is used in the WHERE clause to enforce business group security. The view therefore does not introduce joins to enrollment or dependent tables in its SELECT text; associations to participants and dependents are carried as foreign key columns (PRTT_ENRT_RSLT_ID, ELIG_CVRD_DPNT_ID) rather than resolved relational joins.

Key Columns

• PRMRY_CARE_PRVDR_ID — Unique identifier of the primary care provider record; the primary key carried from the base table.
• NAME — Name of the care provider, physician, or chiropractor.
• PRMRY_CARE_PRVDR_TYP_CD — Code indicating the provider type (for example, physician, chiropractor, or other care provider).
• PRMRY_CARE_PRVDR_TYP_CD_M — Decoded, translated value of the provider type code, derived from the BEN_PCP_SPCLTY lookup via HR_BIS.BIS_DECODE_LOOKUP.
• EXT_IDENT — External identifier for the provider, useful for cross-system reconciliation.
• ELIG_CVRD_DPNT_ID — Identifier of the covered dependent to whom the provider assignment relates.
• PRTT_ENRT_RSLT_ID — Identifier of the participant enrollment result row associating the provider with a plan or option in plan.
• BUSINESS_GROUP_ID — Business group owning the record; the security filter applied by the view.
• EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — Date-effective bounds of the provider record.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID — Concurrent processing and program context columns.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATED_BY, CREATION_DATE — Standard WHO audit columns.
• A descriptive flexfield reference column, labeled "_DF:PPR" and mapped to the segment _DF:BEN:BEN_PRMRY_CARE_PRVDR:PPR, exposing provider flexfield data.

Common Use Cases and Queries

This view is typically queried in benefits reporting and carrier or provider integration extracts, where the objective is to list the primary care provider associated with a given participant enrollment or covered dependent. A representative query retrieving provider assignments within the session's business group follows:

• SELECT p.PRMRY_CARE_PRVDR_ID, p.NAME, p.PRMRY_CARE_PRVDR_TYP_CD_M, p.EXT_IDENT, p.PRTT_ENRT_RSLT_ID, p.ELIG_CVRD_DPNT_ID FROM APPS.BENBV_PRMRY_CARE_PRVDR_V p WHERE p.PRTT_ENRT_RSLT_ID = :enrt_rslt_id;
• SELECT p.NAME, p.PRMRY_CARE_PRVDR_TYP_CD_M FROM APPS.BENBV_PRMRY_CARE_PRVDR_V p WHERE p.ELIG_CVRD_DPNT_ID = :dpnt_id ORDER BY p.NAME;
• SELECT p.NAME, p.EXT_IDENT, p.EFFECTIVE_START_DATE, p.EFFECTIVE_END_DATE FROM APPS.BENBV_PRMRY_CARE_PRVDR_V p WHERE p.PRMRY_CARE_PRVDR_TYP_CD = :type_code AND TRUNC(SYSDATE) BETWEEN p.EFFECTIVE_START_DATE AND NVL(p.EFFECTIVE_END_DATE, TRUNC(SYSDATE));

Because business group security is enforced within the view definition, no additional business group predicate is required in consuming queries; however, this also means the view cannot be used to report across business groups without appropriate profile configuration. Date-effective filtering remains the responsibility of the caller.