Data / Business Analyst
SAS, SQL, Power BI, Data Analytics
I turn raw business data into validated analytical datasets, interactive dashboards, and actionable business insights.
Also: MS Access, Microsoft Office Suite (Excel, Word, PowerPoint, Outlook), SQL Server, DB2, Oracle Database, IDR, Adobe Creative Suite, Linux (command line)
A portfolio project that follows one business question from raw claims data to a filterable Power BI dashboard: how is the practice performing on claims volume, revenue, collections, denials and payment speed?
This is a portfolio project built on synthetic data. It is not a client engagement, and no real patients, providers or protected health information are represented.
Static screenshot
Business problem, analytical process, technical implementation, insight.
NorthStar's leadership needs one place to see how money moves from a claim being billed to a claim being collected, and where it gets stuck. In plain terms: how many claims are we sending, how much do we bill, how much do we actually collect, how much is still owed, how often do payers say no, and how long do they take to pay?
Leadership needs visibility into:
Managers should be able to slice the same numbers by:
Source: project requirements document. Data covers .
Select a stage to see what happened there.
An Excel workbook with five sheets: claims ( rows, 14 columns), patients, providers, payers and a calendar. The claims sheet arrives with realistic problems: repeated claim IDs, blank payment days, inconsistent text casing and spacing.
Imports the workbook, inspects structure and value distributions, profiles missing values, tests the financial logic, and builds a sorted table with one row per Claim ID.
PROC SQL queries aggregate and group the claims to produce status mix, financial totals, outstanding balance by status, denial rate, and reconciliation checks. These give an independent answer key to compare the dashboard against.
One clean, analysis-ready table. It adds Outstanding_Balance, year and month, a corrected service date, and 0/1 status flags (denied, paid, pending, in review) so Power BI can count and sum them directly.
A star schema: one fact table (FACT_CLAIMS) joined many-to-one to four dimensions: payer, provider, service category and date. Slicers filter the fact table through those dimensions.
KPI cards, a monthly claims trend, a claim status donut and an outstanding balance chart, all controlled by five slicers.
The numbers are turned into statements a manager can act on: where revenue is stuck, how much sits in denials, and how reliable the data is.
This project is built to show analytical thinking, not only tool use. Each stage has a distinct job and a distinct output.
Selected excerpts from NorthStar.sas. Each block explains the analytical decision, not only the syntax.
claims_sorted, sorted by Claim_ID with repeated IDs removed.PROC SORT ... NODUPKEY keeps the first record for each key and is the standard way to enforce one row per claim./ missing option shows blank categories instead of hiding them. PROC MEANS reveals ranges that point to bad values.SQL (SAS PROC SQL) turns claim rows into the summary answers leadership asks for, and serves as an independent check on the dashboard.
calculated reuses an alias instead of repeating the sum.CASE gives denied claims and denial rate without a separate filter step.Payer, provider and payment-turnaround views are handled in the Power BI report through slicers. Payment turnaround is summarised in SAS with PROC MEANS.
From the analytical table to an interactive report.
The report uses a star schema. FACT_CLAIMS holds the claim-level numbers (billed, allowed, paid, days to payment, status, denial reason, year, month, Is_Denied). Four dimension tables each connect to it with a many-to-one relationship:
Because filters flow from dimensions to the fact table, one slicer click changes every visual consistently.
Five cards in one row: total claims, total billed, total paid, collection rate and outstanding balance. They follow the order of the revenue cycle, from volume to money billed to money collected to money still owed.
Year and month, payer ID, provider ID, service category and claim status. They sit across the top so filters are visible before the numbers.
An area chart for claims by month (trend over time), a donut for claim status (parts of a whole with four categories), and a column chart for outstanding balance by status (comparing amounts).
Nine measures sit on top of the fact table. Totals are simple sums; ratios use DIVIDE, which returns blank instead of an error when the denominator is zero. Rates are formatted as percentages in Power BI rather than multiplied by 100 in the formula.
CALCULATE changes the filter context to Denied claims only, so the same measure responds to every slicer.Every figure below is taken from the Power BI dashboard or calculated directly from the source workbook.
Item 2 interprets the numbers. The dataset does not say why paid claims carry a balance, so treat that explanation as a hypothesis to check.
Results of the SAS validation checks on the raw claims sheet ( rows). Each check protects a number on the dashboard.
extra rows share a Claim ID with another row ( unique IDs). are exact copies.
Prevents double-counting claims and revenue.
blank values. belong to denied, pending or in-review claims, where no payment exists yet. are on Paid claims and need source follow-up.
Keeps average days-to-payment from being calculated on claims that were never paid.
0
claims with billed below allowed, allowed below paid, or paid above billed.
Confirms revenue fields follow billing logic before totals are trusted.
rows have inconsistent spacing or casing in Claim_Status_Raw (for example " PAID"). The standardised Claim_Status column matches it on every row, and all four statuses are valid.
Stops one status from splitting into several categories in charts and slicers.
/
denied claims carry a reason. No non-denied claim has one. reasons differ only by letter case.
Makes denial-reason analysis reliable. The remaining denied claims without a reason are a data-capture gap.
0
missing Claim ID, Patient ID, Payer ID, Provider ID, service date, service category, amounts or status. Missing counts were checked on all 12 fields.
Ensures every claim can be filtered by every slicer.
Denial-reason counts after standardising letter case:
How the pieces connect, from source file to decision.
I am an early-career Data / Business Analyst with a background in Information Systems. I enjoy the unglamorous part of analytics that makes results trustworthy: profiling data, finding what is wrong with it, and proving the final numbers add up.
My resume lists internship experience preparing and validating Medicare/Medicaid and health-insurance claims data with SAS, and certification as a SAS Certified Specialist in Base Programming for SAS 9.4. The NorthStar project is where I brought SAS, SQL and Power BI together in one workflow.