Healthcare organizations rarely have “transformational” opportunities, but revisiting the Chart of Accounts (CoA) allows your organization to reassess and enhance your business requirements. Designing a new CoA has the potential for creating more positive, transformative change than other aspects of a modern Enterprise Resource Planning (ERP) system. The CoA is pervasive throughout both health and departmental systems that drive the business, from transactional systems for managing revenue and expense, to defining and managing budgets, people, and organizational structures, to tracking and managing assets and facilities, and many other areas.
The CoA also facilitates integration, communication, policies, and procedures across organizations both within and outside the healthcare organization. More people within a hospital organization will interact with the CoA daily (knowingly or unknowingly) than any other part of the business and its systems. In many ways, it contributes to the sense of identity people have within the health system as it drives “standardization.”
Now consider that the corporate income of a healthcare organization is increasingly determined by patient treatment activities and, ultimately, by patient treatment outcomes. Healthcare providers must understand their overall profitability so they can recognize which treatments will likely make money and which treatments, products, and service lines will break even or lose money. This recognition should be at an operational level (e.g., is a patient going to exceed the reimbursement on their current treatment?), but also at a planning and forecasting level so that management can understand the profitability of both departments and the entire organization across mixed-case scenarios.
Many of these considerations have traditionally been addressed via the health system’s Decision Support Systems and/or the Cost Accounting solution by addressing the following:

  • Cost method, amount of physician time, clinician time, supplies, fixed overhead, variable overhead, and waste
  • Groupings of CPT ranges, diagnostic procedures, laboratory codes, office surgeries, and hospital services codes (individual breakdowns may still be required to track the frequencies of each service for actual calculations)
  • Overhead costs (including external costs such as exposures for at-risk contracting)
  • Salaries and related costs of nurses and other clinical staff (who typically split time among numerous clinical activities) considered among groupings of services or total costs (e.g., salary, payroll taxes, fringe benefits, retirement, education, uniforms) for each clinical staff computed/converted to per-hour amounts
  • Calculated time staff requires to perform clinical tasks, such as conducting patient traffic, taking vital signs, working up patients, attending the physician, taking EKGs, drawing blood, and similar functions

A structured General Ledger organizational string (e.g., Entity, Hospitals, Departments and Cost Centers) takes on a whole new world in the age of healthcare reform, new Payment Models (Bundle Payments), Accountable Care Organizations, Risk Sharing, and the like. Understand that today’s healthcare CoA are primarily based on GAAP & GASB structure supported on transactional systems that were never intended to be data warehouses for today’s Business Intelligence (BI) needs. Currently BI fundamental needs require that enterprise Key Performance Indicators (KPIs) are based on a common data dictionary.

So how do we maximize a CoA redesign project to make it transformational? We start by understanding the concept of a multidimensional data model (something like MS Excel pivot tables) or a traditional x-, y-, and z-axis view of data. Here, any “slicing and dicing” of financial data is limited to the logical parsing of the GL Account String via moving all GL Account String intelligence into distinct fields (e.g., XXX-XXX-XXX-XXX where the first three characters represent one level of data followed by the next three characters). In other words, leverage the GL Structure in conjunction with the Natural Accounts to revise the available data for actionable information via the CoA. During redesign, considerations for product and service lines can be addressed, along with data available in sub-modules, to provide multidimensional or pivots of traditional transaction data. Check out Sierra-Cedar’s Chart of Account Design Approach: this document defines the approach that will be used to conduct the Chartfield design. The activities in the approach are deliberately put in a particular sequence. This sequence is intended to gather background information and strategic vision early in the design process when it is still possible to preserve open-minded thinking that is unencumbered by constraints that naturally come when the structure of the PeopleSoft system is better understood. It is expected and intended that information gathered will transcend the specific needs of the CoA design process.

Next, we leverage GL Statistical Accounts (Stat Codes) for Healthcare, Cost Accounting, and Quality Outcome Reporting requirements. Stat Codes allow General Ledger journal lines to be posted with both an amount and a statistical amount to the same regular (non-statistical) account. For example, post both the hours and dollars for payroll on the same line (e.g., use the Stat Code and Stat Amount on certain Outside Service expense accounts) in order to easily report hours related to expenses that will be included in the Wage Index for cost reporting.

Statistical Accounts

  • Establish units of measure
  • Interface payroll hours and other stat accounts from other ancillary systems along with patient financial system stats
  • Create accrual ledgers; many use the accrual allocations for payroll info
  • Join stat hours with the payroll dollars in the stat amount field using the same account number. (i.e., use Journal Entry (JE) Import to create Stat JEs for other statistics using “STAT” accounts starting with S1xxx sequence)
  • Report GL Stat fields via PeopleSoft nVision
  • Function specific to STAT needs in special ledgers:
    • Multiple ledgers to allow better control over open periods
    • STAT ledgers capture statistical information not directly associated with dollar amounts. (e.g., visits, days, etc.); on the STAT ledger, use 9xxxxx series stat accounts
      Note: For hours related to payroll dollars and hours related to outside service contractors, use the STAT CODE, STAT AMT, UOM, fields to capture the hours related to the dollars on the same line as the expense dollars. It does not require a statistical account. You can post stat amounts to regular expense accounts using the stat code, stat amount, and unit of measure fields.

For those venturing into the new world where a CoA will support quality outcomes and actionable KPIs and metrics, consider the following lessons learned:

  • The new CoA should serve as the primary financial reporting tool across all healthcare entities, so consider both fiscal, statistical and outcomes reporting requirements:
    • Vision scorecards and dashboards
    • Data collection at the desired detail level
  • Don’t rely too heavily on the current CoA and reports to determine requirements for the new CoA; consider “Outcomes” reporting and fiscal management objectives, those tied to KPIs. Exhaustive requirements gathering is likely not necessary. Understand needs to a sufficient level to support development of a CoA prototype. The proof of concept, value development, and mapping exercises will provide additional opportunity to assess needs, so focus on the following considerations:
    • Is this going to be a transformational opportunity?
    • Healthcare entities only get this opportunity during re-implementation (significant upgrade) or during replacement/conversion of current financial system:
      • Look at the new financial system implementation as the catalyst for change management required as part of a new CoA.
      • Address data needs during pre-system selection project activities.
    • Initiate a CoA pre-implementation project to create the foundation for the ERP implementation so that all stakeholders can focus on the key foundational design components.
    • Update existing sub and ancillary applications to leverage the redesign.
    • Address functional limitations of existing chart of accounts and transition old CoA structures to new system:
      • Reporting/fiscal management limitations
      • Functional module/application additions
  • Understand the functionality delivered in subsidiary systems and ledgers—it’s typically not necessary to duplicate detail in the CoA.
  • Don’t underestimate the change management effort.
  • Stay focused on the health system’s Enterprise Data Warehouse (EDW) strategy.
  • Leverage the CoA project to migrate to “Best Practices” and change the foundation of who and why financial (transactional) data is collected. Consider the following questions:
    • Is CoA customer centric and focused on service delivery?
    • Is this a Single System of Record? Note that this system of record may be different for different data types (Financial Balances, Payroll, Patient data) and how those systems interact with the CoA.
    • Is the “Internet of Things” anywhere, anytime, and entity-wide?
    • Will it support “Initial Hire to retire” needs?
    • Will it be Single Point of Access?
    • Will it support paperless workflow-based objectives?
    • Does it support Electronic Interfaces through the healthcare’s enterprise strategy?
    • Does it support power at the mobile platform and can it support modeling?
  • Security Considerations
    • Implement a Row-level Security model in PeopleSoft Financials and secure access to data within the assigned GL Structure at these levels:
      • User ID
      • Role
      • Business Unit
      • SetID
      • Ledger
      • Other select fields
    • Design a Tree Security model based on KPI data access needs, but provide the business with actionable data:
      • Object-based security on individual trees
      • Increased complexity options to filter confidential data
    • The security tools and capabilities within PeopleSoft FIN should consider data access and security capabilities in other systems using and/or accessing that data:
      • External systems creating financial transactions
      • Data warehouse/BI systems
      • HR/Payroll data access
    • Balance the need for security:
      • Capabilities across systems throughout the full life-cycle business process
      • Ease of use and the end-user experience

Traditional Healthcare CoA Models

  • Financial consolidations occur at or on the Sub Code CoA alone
    Note: in PeopleSoft Financials, Sub Code concepts can be effectively addressed via several different data elements and tools. Some of these related to the CoA, but other tools throughout PeopleSoft can address these business needs equally well.
  • Address budget development not flex budgeting, management, and operational reporting
  • CoA number schema embeds different reporting attributes in the same field (e.g., Department/Cost Center, Capital Project/WIP, or Encumbrance Accounting)
  • Lack “best practice” business process and reporting
  • Reporting capabilities do are not expanded to include “actionable” KPIs
  • Have naming/numbering conventions (Intelligence in the account number uses strings)
  • Do not embraces capabilities of different CoA for different reporting needs

Finally, consider the EMR and Physician Practice CoA requirements by considering the following lessons learned as you embark on your CoA redesign project:

EMR Physician Practice
  • Synchronize EMR GL structure and Finance GL finance department to break down the general ledger account string for each type of transaction (charge, payment, adjustment)
  • Document the components that make up a GL string (e.g., charges have a 10-digit string).
  • Consider a CoA that includes business units, account types, and naming/definitions.
  • Design file format and general ledger structure format for premium billing charges, payments, and adjustments.
  • Build the following professional billing tasks and items into CoA structure:
    • Premium billing accounts and current balances
    • AP system requirements for EDI transactions
    • Payment codes used to differentiate between types of payments
    • AR codes used for refunds and reports
    • AR codes used for adjusting balances (both debit and credit adjustments)
  • All physician practices should share
    • Job codes
    • Benefit programs (different benefit programs require additional eligibility rules and new text strings for eBenefits)
    • Rates for benefit deductions (different rates for each practice would require different benefit programs for each)
    • Paygroup
      • Large numbers of paygroups degrade payroll processing performance
      • Additional paygroups may require additional benefits eligibility rules
  • Payroll frequency should be the same for all physician practice employees: biweekly on the same schedule as the Health system. If physicians were to be paid monthly
    • This could add two pay runs per month to payroll’s already crowded processing schedules.
    • The health system could recommend setting up a separate benefit program for them
  • CoA for the physician practices should be the same as for all paygroups, including the method of fringe expense calculation (differences in accounting versus existing practice could require significant additional effort to modify the master financial data process).
  • Existing COBRA participants, if any, should be converted as non-employee COBRA participants.