5.1 Healthcare Data Sourcing & Lineage

Healthcare Data Sourcing & Lineage

For a Certified Health Data Analyst (CHDA), data sourcing and lineage represent the foundational bedrock of all downstream analytics, clinical quality measurement, and financial modeling. Healthcare data does not originate in a single, pristine database; rather, it is generated across dozens of disparate, specialized operational systems that capture clinical observations, diagnostic results, medication dispenses, supply chain movements, and billing transactions. Understanding the operational context of these source systems, the database architectures that house them, the mechanisms required to trace their provenance, and the master data structures that bind them together is critical to ensuring data integrity, regulatory compliance, and analytical validity.

---

1. The Healthcare Source Systems Landscape

Modern healthcare delivery organizations rely on a federated ecosystem of specialized transactional information systems. Each system is engineered to support specific clinical, diagnostic, logistical, or financial workflows, capturing data at varying levels of granularity, velocity, and structure.

+---------------------------------------------------------------------------------------------------+
|                               HEALTHCARE SOURCE SYSTEMS LANDSCAPE                                 |
+-------------------+--------------------+--------------------+--------------------+----------------+
| EHR / EMR         | LIS                | RIS / PACS         | PIS / ADCs         | ERP & BILLING  |
| - CPOE Orders     | - Analyzer results | - DICOM images     | - Formulary / DDI  | - Supply Chain |
| - Clinical notes  | - Specimen IDs     | - Radiologist rpts | - Dispense logs    | - Patient Acct |
| - eMAR / vitals   | - LOINC codes      | - Modality worklist| - NDC / RxNorm     | - CDM / Claims |
| - Flowsheets      | - Reference ranges | - Accession nums   | - Pyxis / Omnicell | - RTLS / Beds  |
+-------------------+--------------------+--------------------+--------------------+----------------+

Electronic Health Record (EHR / EMR)

• Core Functional Scope: Serves as the central longitudinal clinical repository for patient care delivery across acute inpatient and ambulatory settings (e.g., Epic, Cerner/Oracle Health, MEDITECH, Altera/Allscripts).
• Primary Data Elements: Computerized Provider Order Entry (CPOE) diagnostic and therapeutic orders, multidisciplinary clinician documentation (SOAP progress notes, history & physicals, discharge summaries), nursing bedside flowsheets (vital signs, pain scores, Glasgow Coma Scale, Braden Scale, intake/output), problem lists (active and resolved conditions mapped to ICD-10-CM and SNOMED CT), allergy records, and patient demographic/encounter metadata.
• Data Characteristics: Highly heterogeneous mix of structured discrete data elements (discrete numeric vitals, coded problem lists) and unstructured/semi-structured free-text narratives (operative notes, pathology narratives).

Laboratory Information System (LIS)

• Core Functional Scope: Manages the pre-analytical, analytical, and post-analytical workflows of clinical laboratories (hematology, clinical chemistry, microbiology, urinalysis, transfusion medicine, molecular pathology) (e.g., Sunquest, Cerner PathNet, Epic Beaker).
• Primary Data Elements: Laboratory order requisitions, unique specimen accession numbers, collection timestamps, analyzer instrument telemetry, quantitative result values (e.g., Serum Potassium 4.2 mmol/L), qualitative result interpretations (e.g., Staphylococcus aureus positive), laboratory reference ranges (stratified by age and biological sex), abnormal result flags (High, Low, Panic/Critical), and standardized LOINC (Logical Observation Identifiers Names and Codes) identifiers.
• Integration Protocols: Transmits discrete laboratory results to the EHR via standardized HL7 v2 ORU (Observation Result Unsolicited) messages or HL7 FHIR Observation resources.

Radiology Information System (RIS) & Picture Archiving and Communication System (PACS)

• Core Functional Scope: The RIS manages radiology department scheduling, patient tracking, modality worklists, and diagnostic reporting, while the PACS archives and distributes digital medical images across imaging modalities (Computed Tomography [CT], Magnetic Resonance Imaging [MRI], Positron Emission Tomography [PET], Ultrasound [US], Plain Radiography [X-ray]).
• Primary Data Elements: Modality Worklist (MWL) orders, accession numbers, radiation dose index monitoring data, digital imaging objects stored under the DICOM (Digital Imaging and Communications in Medicine) standard, DICOM header metadata (Study Instance UID, Series UID, SOP Instance UID, slice thickness, tube voltage [kVp], acquisition matrix), and unstructured diagnostic radiology reports containing clinical findings and radiologist impressions.
• Integration Protocols: Diagnostic imaging orders route via HL7 ORM^O01, image objects route across PACS networks via DICOM network protocols (C-STORE, C-FIND, C-MOVE), and finalized reports return to the EHR via HL7 ORU^R01.

Pharmacy Information System (PIS) & Automated Dispensing Cabinets (ADCs)

• Core Functional Scope: Manages medication order verification, formulary management, clinical decision support (drug-drug interactions [DDIs], drug-allergy contraindications, dose-range checking), intravenous (IV) compounding, and inventory control, interfacing directly with point-of-care Automated Dispensing Cabinets (ADCs) such as Pyxis, Omnicell, or BD (e.g., Epic Willow, Cerner PharmNet).
• Primary Data Elements: Pharmacist order verification status, National Drug Codes (NDC), RxNorm concept unique identifiers (RxCUIs), therapeutic drug monitoring levels, unit-dose dispense timestamps, ADC override access events, medication waste/destruction logs (governed by DEA Schedule II-V controlled substance regulations), and point-of-care Barcode Medication Administration (BCMA) scan verification logs.

Enterprise Resource Planning (ERP) & Supply Chain Systems

• Core Functional Scope: Manages enterprise-level back-office operations, human capital management, financial general ledgers, payroll, and supply chain/materials management (e.g., Infor/Lawson, SAP, Workday).
• Primary Data Elements: Materials management item masters, purchase orders, vendor contracts, high-cost surgical implant/device tracking incorporating FDA Unique Device Identifiers (UDI), department-level cost centers, nurse staffing grids, shift hours worked, and enterprise general ledger accounts.

Patient Accounting & Revenue Cycle Billing Systems

• Core Functional Scope: Aggregates billable clinical activity, executes claim scrubbing algorithms, generates standardized electronic billing claims, processes payer remittances, and manages patient accounts receivable (A/R) (e.g., Epic Resolute, Cerner Patient Accounting).
• Primary Data Elements: Charge Description Master (CDM) line items, facility revenue codes, professional CPT/HCPCS codes, ICD-10-CM/PCS diagnosis and procedure codes, CMS National Correct Coding Initiative (NCCI) edit flags, electronic claim transaction sets (ANSI ASC X12N 837I for institutional UB-04 claims and 837P for professional CMS-1500 claims), and Electronic Remittance Advice (EDI 835) files detailing payer adjudication, contractual adjustments, and Claim Adjustment Reason Codes (CARCs).

Bed Management, ADT & Real-Time Location Systems (RTLS)

• Core Functional Scope: Oversees inpatient bed placement, bed turnover hygiene, patient transport tracking, and physical asset location monitoring utilizing active/passive Radio Frequency Identification (RFID), infrared (IR), and Wi-Fi triangulation technologies (e.g., TeleTracking, CenTrak).
• Primary Data Elements: Admission-Discharge-Transfer (ADT) event streams (HL7 ADT^A01 admission, ADT^A02 transfer, ADT^A03 discharge, ADT^A08 update), bed clean/dirty status timestamps, Emergency Department boarding times, patient transport durations, and physical asset location coordinates for mobile biomedical equipment (IV infusion pumps, telemetry packs, crash carts).

---

2. Healthcare Source Systems Matrix

The following matrix summarizes the core operational source systems, the primary healthcare domain data captured, key identifiers, integration standards, and typical analytical applications:

---

3. Transactional (OLTP) vs. Analytical (OLAP) Databases

Health data analysts must navigate two fundamentally different database paradigms: Transactional systems optimized for operational care delivery and Analytical systems optimized for aggregate intelligence.

+---------------------------------------------------------------------------------------------------+
|                         TRANSACTIONAL (OLTP) VS. ANALYTICAL (OLAP)                                |
+-------------------------------------------------+-------------------------------------------------+
| ONLINE TRANSACTION PROCESSING (OLTP)            | ONLINE ANALYTICAL PROCESSING (OLAP)             |
| - Application: Production EHR, LIS, Billing     | - Application: Enterprise Data Warehouse (EDW)  |
| - Design: 3rd Normal Form (3NF) relational      | - Design: Denormalized Star / Snowflake Schema  |
| - Focus: High-concurrency inserts, updates      | - Focus: Complex aggregate queries, trend read  |
| - Integrity: ACID compliant, strict constraints | - Integrity: Read-optimized, historical depth   |
| - Storage: Row-store relational architecture    | - Storage: Columnar storage, compressed blocks  |
| - Volume per query: Single row / small subsets  | - Volume per query: Millions of rows aggregated |
+-------------------------------------------------+-------------------------------------------------+

Online Transaction Processing (OLTP) in Healthcare

OLTP databases power front-line clinical applications where thousands of concurrent clinicians, nurses, and staff perform real-time data entry and retrieval.

• Normalization (3rd Normal Form / 3NF): Relational tables are strictly decomposed to eliminate data redundancy and prevent update/insert/delete anomalies. For example, patient address, provider specialty, and clinic location are stored in dedicated lookup tables referenced via foreign keys rather than repeated across every clinical encounter row.
• ACID Guarantees: Ensures that clinical transactions are Atomic (all-or-nothing execution, e.g., placing an order and debiting inventory occur together), Consistent (database constraints and foreign keys remain valid), Isolated (concurrent transactions do not interfere), and Durable (committed data survives system crashes).
• Limitations for Analytics: Executing complex analytical queries (e.g., calculating 5-year readmission trends across 500,000 diabetic patients) directly against an OLTP production EHR database requires joining dozens of normalized tables, causing severe row-level locking, database resource contention, and potentially catastrophic slowdowns for active clinical care.

Online Analytical Processing (OLAP) & Dimensional Modeling

OLAP systems and Enterprise Data Warehouses (EDWs) utilize dimensional modeling principles established by Ralph Kimball, restructuring normalized relational data into intuitive, read-optimized schemas.

• Star Schema: Consists of a centralized Fact Table surrounded by multiple denormalized Dimension Tables, resembling a star pattern. The fact table references dimension tables via single-column foreign keys, enabling simplified SQL queries with minimal table joins.
• Snowflake Schema: A variation of the star schema where certain dimension tables are partially normalized into sub-dimension tables (e.g., a Dim_Provider table referencing a normalized Dim_Specialty table). While saving storage space and reducing attribute redundancy, snowflake schemas introduce additional joins, slightly reducing query execution speed compared to pure star schemas.

+---------------------------------------------------------------------------------------------------+
|                                 KIMBALL STAR SCHEMA ARCHITECTURE                                  |
+---------------------------------------------------------------------------------------------------+
                                     +-----------------------+
                                     |     Dim_Patient       |
                                     |-----------------------|
                                     | PK: Patient_SK        |
                                     |     MRN, Name, DOB    |
                                     |     Gender, Race/Eth  |
                                     +-----------+-----------+
                                                 |
+-----------------------+                        |                        +-----------------------+
|      Dim_Date         |                        |                        |     Dim_Provider      |
|-----------------------|                        |                        |-----------------------|
| PK: Date_SK           |                        |                        | PK: Provider_SK       |
|     Full_Date, Year   |---------+              |              +---------|     NPI, Full_Name    |
|     Quarter, Month    |         |              |              |         |     Specialty, Dept   |
+-----------------------+         |              |              |         +-----------------------+
                                  v              v              v
                           +-------------------------------------------+
                           |          Fact_Inpatient_Encounter         |
                           |-------------------------------------------|
                           | FK: Patient_SK                            |
                           | FK: Provider_SK                           |
                           | FK: Date_SK                               |
                           | FK: Diagnosis_SK                          |
                           | FK: Facility_SK                           |
                           |-------------------------------------------|
                           | MEASURES:                                 |
                           | - Length_Of_Stay_Days                     |
                           | - Total_Billed_Charges                    |
                           | - Total_Direct_Cost                       |
                           | - Reimbursement_Amount                    |
                           | - Readmission_30Day_Flag                  |
                           | - Mortality_InHospital_Flag               |
                           +-------------------------------------------+
                                  ^                             ^
                                  |                             |
+-----------------------+         |                             |         +-----------------------+
|     Dim_Diagnosis     |         |                             |         |     Dim_Facility      |
|-----------------------|---------+                             +---------|-----------------------|
| PK: Diagnosis_SK      |                                                 | PK: Facility_SK       |
|     ICD10_Code, Desc  |                                                 |     CCN, Name, Type   |
|     CCS_Category, MDC |                                                 |     Bed_Count, State  |
+-----------------------+                                                 +-----------------------+

Fact Tables vs. Dimension Tables

1. Fact Tables

Fact tables capture the quantitative, numerical measurements generated by business or clinical events. Every fact table row contains numerical metrics (measures) and foreign keys mapping to surrounding dimension tables.

• Fact Measure Classifications:
  • Fully Additive Measures: Can be meaningfully summed across all dimensions (e.g., Total_Billed_Charges, Total_Inpatient_Cost, Units_Of_Medication_Dispensed).
  • Semi-Additive Measures: Can be summed across some dimensions (such as facility or clinical service line), but cannot be summed across the time dimension (e.g., Inpatient_Midnight_Census, Current_Account_Balance). Summing midnight census across 30 days yields an erroneous cumulative sum; instead, analysts must calculate the average or select point-in-time snapshots.
  • Non-Additive Measures: Cannot be summed across any dimension, typically representing ratios, percentages, or unit prices (e.g., Cost_To_Charge_Ratio, Temperature_Fahrenheit, Readmission_Rate).
• Fact Table Types:
  • Transaction Fact Tables: Capture events at a specific point in time (e.g., individual medication administration, lab test result).
  • Periodic Snapshot Fact Tables: Capture the cumulative status at predefined standard intervals (e.g., end-of-month financial receivables, weekly unit census).
  • Accumulating Snapshot Fact Tables: Capture the entire lifecycle of a process with distinct milestone dates (e.g., tracking an emergency department encounter from Triage Time to Bed Placement to Provider Exam to Decision to Admit to Inpatient Bed Transfer).

2. Dimension Tables

Dimension tables contain the textual, categorical context that answers the who, what, where, when, and why of a business event. They provide the attributes used for filtering (WHERE), grouping (GROUP BY), and slicing analytical datasets.

• Surrogate Keys vs. Natural Keys: Dimension tables assign an internal, integer-based Surrogate Key (SK) (e.g., Patient_SK = 104829) as the primary key rather than relying on the operational source system natural key (e.g., MRN = 'A849201'). Surrogate keys insulate the analytical warehouse from source system key changes, support cross-system integration, and enable historical versioning.
• Slowly Changing Dimensions (SCD): Real-world dimension attributes change over time (e.g., a patient moves to a new ZIP code, a provider changes clinical department). Dimensional models handle these transitions using standard SCD strategies:
  • SCD Type 1 (Overwrite): The old attribute value is directly overwritten with the new value. No historical record is preserved. If Patient 101 moves from New York to Florida, past historical encounters will erroneously aggregate under Florida in geographic reports.
  • SCD Type 2 (Add New Row - Full History): When an attribute changes, the existing row is marked inactive (with an end_date and current_flag = 0), and a new row is inserted with a new surrogate key, a new start_date, end_date = NULL, and current_flag = 1. This preserves true historical lineage, ensuring past encounters remain attributed to New York while future encounters attribute to Florida.
  • SCD Type 3 (Add New Column - Previous Attribute): The existing row is retained, and a dedicated column is added to store the prior value (e.g., Current_Zip and Previous_Zip). This tracks only the most recent transition without full historical versioning.

Columnar vs. Row-Store Storage Architecture

• Row-Store Databases (OLTP): Store data sequentially on disk row-by-row ([PatientID, AdmitDate, DX, Charges], [PatientID, AdmitDate, DX, Charges]). Ideal for inserting or retrieving entire individual patient records.
• Columnar Databases (Modern OLAP / Cloud Warehouses): Store data sequentially by column ([Charges1, Charges2, Charges3...]). When an analyst queries AVG(Total_Billed_Charges) across 5,000,000 rows, the columnar engine scans only the disk blocks containing the charges column, ignoring all other attributes. Coupled with advanced column-level compression algorithms (Run-Length Encoding, Dictionary Encoding), columnar storage accelerates aggregate analytical queries by 10x to 100x.

---

4. Data Provenance, Lineage & Metadata Tracing

In healthcare data governance, establishing data provenance (the documented history of data creation and custodial chain of custody) and data lineage (the detailed pathway tracing data elements from source systems through intermediate ETL transformations to consumption endpoints) is mandatory for regulatory audits, clinical trust, and analytics reproducibility.

+---------------------------------------------------------------------------------------------------+
|                             DATA PROVENANCE & LINEAGE ARCHITECTURE                                |
+---------------------------------------------------------------------------------------------------+
  [SOURCE SYSTEMS]        [INGEST & STAGING]        [TRANSFORMATION]          [ANALYTICAL CONSUMPTION]
  - EHR Flowsheets   -->  - ODS Raw Staging   -->  - Cleansing / De-dup  -->  - EDW Star Schemas
  - LIS Lab Results  -->  - Change Data Capture--> - LOINC/ICD Mapping   -->  - Power BI / Tableau
  - Billing 837 Claims--> - Landing Zone (Lake)--> - Business Logic (CMI)--> - Regulatory Dashboards
                                                   - Risk Adj (CMS-HCC)   - ML Predictive Models
  ===================================================================================================
  METADATA REPOSITORY: Business Definitions | Technical Schema/Data Types | Operational Execution Logs
  AUDIT TRAIL LOGGING: Timestamp | User ID | Terminal IP | Action (C/R/U/D) | Pre/Post Delta Values
+---------------------------------------------------------------------------------------------------+

Forward Lineage vs. Backward Lineage

• Forward Lineage (Impact Analysis): Traces an upstream data element forward to identify every downstream table, view, ETL pipeline, dashboard, and machine learning model that relies upon it. For example, if the laboratory alters the discrete result format or units of a Cardiac Troponin assay, forward lineage reveals every sepsis dashboard and clinical quality report affected by the change.
• Backward Lineage (Root Cause & Provenance Analysis): Traces a downstream metric or dashboard KPI backward through every calculation layer, staging table, and interface engine to its original source system record. If an executive dashboard reports a sudden 25% spike in hospital-acquired pressure injury rates, backward lineage enables the data analyst to trace the aggregated metric back to the specific nursing flowsheet inputs in the EHR.

The Three Pillars of Metadata Management

Metadata—commonly defined as "data about data"—is categorized into three distinct operational domains:

1. Business Metadata: Defines the organizational meaning, clinical context, and business rules governing data elements. Includes standardized business glossary definitions, KPI calculation formulas (e.g., exact numerator and denominator logic for the CMS Hospital Readmissions Reduction Program [HRRP]), data ownership/stewardship assignments, and data classification levels (e.g., Public, Internal, Confidential, Restricted PHI).
2. Technical Metadata: Describes the physical and structural properties of data storage assets. Includes database table schemas, column names, technical data types (e.g., VARCHAR(50), DECIMAL(10,2)), primary and foreign key constraints, database indexing structures, and physical ETL mapping scripts.
3. Operational Metadata: Captures the real-time execution telemetry and operational health of data processing pipelines. Includes ETL batch start/completion timestamps, total row counts extracted vs. loaded, data latency intervals, pipeline failure alerts, CPU/memory consumption logs, and data quality check validation scores.

EHR Audit Trails & Legal Medical Record Compliance

Under the HIPAA Security Rule (45 CFR § 164.312(b)), covered entities must implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use electronic Protected Health Information (ePHI).

• Audit log design: The regulation does not prescribe one universal field list. Configure sufficient event, user or system, timestamp, object, source, outcome, and change information to support activity review, accountability, investigations, and the organization’s risk analysis.
• Clinical documentation amendments, addenda, and corrections: Follow the organization’s designated-record-set and legal-health-record policy plus applicable federal and state requirements:
  • Corrections: Preserve the original entry when required, distinguish the correction, and record sufficient author, time, and rationale metadata to support integrity and accountability.
  • Late Entries & Addenda: Documentation entered after the established timeframe must be explicitly labeled as a "Late Entry" or "Addendum," recording both the time of care delivery and the actual time of documentation entry.
  • Deletions & Retractions: Handle entries made in error under the approved record-amendment policy, preserving evidence and metadata for the applicable retention period.

---

5. Master Data Management (MDM) in Healthcare

Healthcare organizations generate fragmented data across dozens of departmental silos. Master Data Management (MDM) establishes a unified, authoritative single source of truth for core enterprise entities across disparate operational applications.

+---------------------------------------------------------------------------------------------------+
|                         HEALTHCARE MASTER DATA DOMAINS & IDENTIFIERS                              |
+-----------------------------------+-----------------------------------+---------------------------+
| PATIENT MASTER (MPI / EMPI)       | PROVIDER MASTER                   | FACILITY / LOCATION MASTER|
| - Enterprise Master Patient Index | - National Provider ID (NPI)      | - CMS Certification Num   |
| - Deterministic Matching          | - Type 1: Individual Practitioner |   (CCN / Provider Number) |
| - Probabilistic (Fellegi-Sunter)  | - Type 2: Organizational Entity   | - Billing NPI (Facility)  |
| - Duplicate/Overlay/Overlap Mgmt  | - NUCC Provider Taxonomy Codes    | - Physical Geocoding / GL |
+-----------------------------------+-----------------------------------+---------------------------+

1. Patient Master & Enterprise Master Patient Index (EMPI)

The Enterprise Master Patient Index (EMPI) is an enterprise database that cross-references and links patient identifiers across all internal and external source systems, assigning an authoritative Enterprise Master ID (Enterprise Person ID).

• Identity Resolution Algorithms:
  • Deterministic Matching: Relies on exact character-by-character matching across a combination of high-specificity identifiers (e.g., Social Security Number exact match, or First Name + Last Name + Date of Birth exact match). While yielding virtually zero false positives, deterministic matching fails when typographical errors, nicknames, hyphenated names, or missing data occur.
  • Probabilistic Matching (Fellegi-Sunter Methodology): Calculates statistical weights and likelihood ratios for agreement and disagreement across multiple demographic attributes (First Name, Last Name, Middle Name, DOB, Biological Sex, Street Address, ZIP Code, Phone Number). Incorporates string similarity algorithms (e.g., Jaro-Winkler, Levenshtein Distance) and phonetic encoding (Soundex, Metaphone) to accommodate misspellings. Encounters with composite match scores above a high threshold are automatically merged; scores falling in an intermediate review band are flagged for manual review by HIM data integrity specialists.
• Patient Identity Discrepancy Classifications:
  • Duplicate Record: A single individual is mistakenly assigned two or more distinct Medical Record Numbers (MRNs) within the same facility or health system (e.g., John Smith registered as MRN 1001 and J. Smith registered as MRN 2002).
  • Overlay Record: Two entirely different patients are erroneously merged into a single medical record number (e.g., Patient A's clinical documentation is filed under Patient B's MRN), creating extreme clinical patient safety hazards.
  • Overlap Record: A single patient has distinct medical records across different constituent facilities or clinics within an integrated delivery network (IDN) that have not yet been unified under an EMPI enterprise identifier.

2. Provider Master

The Provider Master consolidates credentialing, licensing, operational, and billing data for all active clinical practitioners.

• National Provider Identifier (NPI): Established under HIPAA Administrative Simplification, the NPI is a 10-digit, intelligence-free numeric identifier (incorporating a Luhn 10 check digit) issued by the National Plan and Provider Enumeration System (NPPES).
  • NPI Type 1 (Individual): Issued to individual healthcare practitioners (physicians, physician assistants, nurse practitioners, dentists, physical therapists).
  • NPI Type 2 (Organization): Issued to healthcare provider organizations and group practices (hospitals, nursing homes, group clinics, pharmacies, clinical laboratories).
• NUCC Healthcare Provider Taxonomy Codes: A standardized 10-character alphanumeric code set administered by the National Uniform Claim Committee (NUCC) that categorizes providers by provider type, classification, and area of clinical specialization (e.g., 207Q00000X for Family Medicine; 207RC0000X for Cardiovascular Disease).
• Secondary Identifiers: State medical license numbers, Drug Enforcement Administration (DEA) registration numbers for prescribing controlled substances, and Clinical Laboratory Improvement Amendments (CLIA) certificate numbers.

3. Facility & Location Master

The Facility Master establishes standardized hierarchies for physical care delivery sites, operational departments, and cost centers.

• CMS Certification Number (CCN): Formerly known as the Medicare Provider Number, the CCN is a 6-digit alphanumeric code assigned by CMS to verify Medicare/Medicaid certification. The first two digits identify the state in which the facility is located, and the subsequent four digits designate the specific facility classification type (e.g., 0001–0899 for Short-Term Acute Care Hospitals; 1300–1399 for Critical Access Hospitals; 2000–2299 for Long-Term Acute Care Hospitals; 3025–3099 for Inpatient Rehabilitation Facilities).
• Facility NPI & Taxonomy: Represents the organizational Type 2 NPI and institutional taxonomy code required on institutional billing claims (EDI 837I / UB-04).
• Departmental Hierarchy: Structures physical and logical relationships from Enterprise to Hospital Campus to Clinical Department / Cost Center to Nursing Unit to Room to Bed.