Aternex

Healthcare, physician services

A clinical analytics dashboard, built from scratch over HL7

Industry
Healthcare, physician services
Engagement
Contract, lead developer
When
2025 to 2026
Stack
  • C#
  • .NET
  • Vue
  • Next.js
  • SQL Server
  • InterSystems IRIS
  • Oracle
  • HL7
  • Hangfire
  • Okta
  • Azure Pipelines

The challenge

A national physician services company took HL7 messages from many facilities into InterSystems IRIS, fed by Oracle. Across years of data, about 2 billion records, every facility sent its data a little differently, so a value that reporting and billing expect in one field can arrive in another. When a new facility came on, nobody could easily see which fields it actually filled, which were wrong, and how complete its data was, and that fed straight into reporting and billing.

The approach

  1. Built a field check for every facility: for each field reporting and billing rely on, an operations manager sees that facility's three most recent values and marks the field verified or needs review, separately for HL7 and flat-file feeds, with the reviewer recorded. At a glance they can say: this facility is sending the value we need, but in a different field than we expect.
  2. Everything else grew out of that check. Tagged every field as billing, analytical or other, and measured each facility every day: how complete its billing, analytical and other fields are, HL7 against flat-file completion, how many populated fields are verified, and the verification rate.
  3. Built an archive job that copies HL7 from IRIS into SQL Server in batches of 25,000 rows and records every run, so the analytics never query the source system.
  4. Wrote an HL7 parser that labels every field from a schema dictionary kept in the database, rather than hard-coding one message layout.
  5. Defined the operational metrics alongside them: admissions, discharges, ER visits, length of stay, ER wait, time to provider and door to decision.
  6. Rolled the metrics up daily, weekly, monthly, quarterly and yearly, recalculating only the periods that changed, with retention rules for raw and rolled-up data.
  7. Stored the full messages but kept patient details off the dashboard, and limited every screen to the Okta groups allowed to see it.
  8. Split the work into 6 .NET 10 APIs on a shared framework behind a Vue 3 dashboard, started its rewrite in Next.js, and load-tested it with 6 million generated records, 100,000 per facility across 60 facilities.

The result

A field check for every facility and daily completeness metrics over about 2 billion records, built across the engagement, with no patient details on screen.

Follow a message

From HL7 message to facility metric

  1. OracleFeeds the store of HL7 messages
  2. InterSystems IRISHolds the HL7 messages from every facility
  3. SQL ServerReceives copies in batches of 25,000 rows
  4. 6 .NET 10 APIsParse each field against a schema dictionary and compute the metrics
  5. Vue 3 dashboardShows facility metrics, behind Okta group access
  • Daily
  • Weekly
  • Monthly
  • Quarterly
  • Yearly

The stages as the code builds them. Full messages are stored; patient details stay off the dashboard.

Have a system that needs this kind of work?

Tell me what is slow, fragile or missing, and I will tell you how I would measure it first. I reply within two business days.