Skip to content

Instantly share code, notes, and snippets.

@christophergraber
Last active November 30, 2021 23:24
Show Gist options
  • Save christophergraber/2f5b6522f0c48693b9da5ce684e3f673 to your computer and use it in GitHub Desktop.
Save christophergraber/2f5b6522f0c48693b9da5ce684e3f673 to your computer and use it in GitHub Desktop.
Past project summary

ClearBalance Summary

clearbalance.org

Position Introduction

Software Engineering Manager (9 years) - The proprietary account servicing system (Fundman) processed over 2 million records annually, integrating with major credit bureau data infrastructure to make real-time credit decisions based on individual customer risk criteria. At its height the Fundman system drove loan funding of over $150 million annually. The software continued successfully for multiple years after my departure. Worked closely with CEO, CFO, IT Director, Funding Director, Call Center Director, and Accounting Department.

About ClearBalance Healthcare

Leading provider of consumer-friendly patient financing programs to U.S. hospitals and health systems. Serving 4.5 million patient accounts at over 200 healthcare organizations nationwide, ClearBalance brings its healthcare partners improved operating margins, reduced bad debt expense, and accelerated cash.

Accomplishments

  • Startup environment, rapid growth. Involved in all aspects of overhauling IT systems. Created a robust, secure architecture and provided 24/7/365 support for critical transactions.
  • Mentored 2 junior software engineers and managed remote database administrator. Managed 10 person offshore programming team for account servicing system code customizations.
  • Created custom intranet application (Fundman) responsible for processing millions of dollars of hospital debt per month.
  • Created daily automated reports for financial teams, pulling from multiple databases (DB2 primary, SQL Server 'datamart') and feeding to customized Excel, PDF, and Crystal Reports.
  • Securely interfaced with Equifax and TransUnion credit reporting agencies, realtime credit reports.

Technology Components:

  • “Fundman” intranet application (processing incoming accounts)
  • Secure portal (hospital staff access existing accounts)
  • “Intelec” loan servicing system (account aging, call center access, letters, payments)
  • “Datamart” SQL Server (complex financial reports w/Crystal Reports)

Fundman Tech Stack:

VMware ESXi and RHEL (dev/prod).

  • Apache
  • IBM DB2 8.x
  • PHP 7.x
  • Perl

Other: HTML/JavaScript/jQuery/CSS, Subversion

Fundman Responsibilities:

  • Customizable platform able to rapidly handle new hospital clients, funding programs, inputs/outputs, financial reporting.
  • Daily incoming patient account files processed by multiple funding analysts (Perl parsers: file formats CSV/XML/Excel/TXT.
  • Processing and screening incoming hospital patient account records: complex logic for payment analysis (current, past due), new balance vs existing balance, balance and credit score ranges for custom financing programs.
  • Real time credit reporting with Equifax & TransUnion (Perl scripts following their APIs, https/ssh connections).
  • Daily “funded accounts” or “deferred accounts” uploads to Intelec loan servicing system.

Fundman Automation:

  • Cron jobs for pulls/pushes to SFTP sites @ hospitals (incoming files, outgoing 835/autopost files - various formats) (weekly schedule).
  • Job for Intelec account servicing data import (nightly).
  • Financial reports (Excel) for management/accounting/etc created with Perl scripts (daily/weekly/monthly).
  • Database backups (daily).

Disaster Recovery:

  • Implemented hosting across multiple physical regions (across states).
  • Documented processes for efficient disaster recovery with Database Administrator.
  • Regularly scheduled recovery process reviews. Included validation for code rollouts and upgrades, database health, and overall system performance on VMware instances.

Security Considerations:

  • HIPAA compliance considerations including audits by our banking partners.
  • Fundman intranet application only accessible in San Diego office location. IT Director set up limited access, and tunnels to access external SFTP sites.
  • Funding analyst Fundman access: Login password hashed, session variables w/timeouts.
  • Hospital client lead Fundman access: Similar, with limits on their “client numbers”.

Testing:

  • All code tested in the development environment. At the time, automated CI/CD systems were not commonplace; as such, we wrote and performaned manual testing processes to validate that new releases were functionally complete: monitor log files, server load, database performance.
  • Production deployments happened every few days.

Documentation:

  • High level Word documents explaining system setup, processes.
  • Thorough documentation in code.
  • Disaster recovery process documentation.

Possible Fundman Improvement suggestions:

  • PHP framework, move from procedural to OO (was looking into CakePHP, etc, at the time)
  • Improved automated testing
  • Better CI/CD processes: Leverage the modern automated processes which allow code repositories like git to integrate with automated tests
  • Move from Perl to Python
  • Table locking during large account file uploads, for consistent db id’s
  • Improved error handling and log files
  • Integrate capabilities of SQL Server Datamart, for advanced financial aging reports

Fundman Database (IBM DB2):

IBM DB2 chosen to most easily interface with Intelec data. Utilized many stored procedures, indexes, views.

ACCOUNT (hospital patient account)
account_id integer PK
client_id integer
batch_id integer
guarantor_id integer
funding_id integer
current_debt decimal 9.2
net_present_value decimal 9.2
payment decimal 9.2
date_added date
reject_code varchar
(and various other fields)

BATCH (can be multiple per transaction)
client_id integer
batch_id integer
transaction_id integer
amount_parsed decimal 9.2
date_added date

CLIENT (individual hospital)
client_id integer PK
client_name varchar(200)
parser varchar(200)
company integer
date_added date

CLIENT_TRANCHE (parameters of a funding program, for an individual hospital facility)
tranche_id integer PK
client_id integer
client_tranche_class integer
tranche_name varchar

CLIENT_TRANCHE_CLASS (high level program settings: A (fund immediately), B (deferred funding), C (deferred funding, high balance)…)
client_tranche_class integer PK
client_id integer
tranche_letter char
min_balance decimal 9.2
max_balance decimal 9.2
min_payment decimal 9.2
min_credit_score decimal 9.2
max_credit_score decimal 9.2
is_deferred char
date_added date

CREDIT_REPORT (holds credit report data, score - for a guarantor, through time)
credit_report_id integer PK
guarantor_id integer
report_contents blob
credit_score varchar
report_company varchar
report_date date date

FUNDING (accounts passed tests and will become a bank loan)
client_id integer
funding_id integer
funding_amt decimal 9.2
funding_date date

FUNDING_ANALYST (internal employee logins)
analyst_id integer PK
login_id integer
full_name varchar
username varchar
password varchar (sha1 format)
session_timestamp timestamp
active char
date_added date

GUARANTOR (hospital account owner - a person)
guarantor_id PK
first_name varchar
last_name varchar
ssn varchar
date_added date
(and various demographics fields)

HOSPITAL_ANALYST (hospital employee logins)
hospital_employee_id integer PK
login_id integer
full_name varchar
username varchar
password varchar (sha1 format)
active char
date_added date

LOGINS (track state of hospital employee login)
login_id integer PK
user_id integer
login_date datetime
session_timestamp timestamp
(other tracking fields)

REJECT_REASON (for accounts not accepted/funded)
reject_id PK
reject_code char
reject_reason varchar

TRANSACTION (where accounts are collected, in sub batches)
client_id integer
batch_id integer
transaction_id integer
date_added date

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment