Healthcare IT professional.
Software that supports care.

VCU's price file is 648 MB; reading it whole would exhaust the heap. A token-by-token Jackson streaming parser walks to the charge array and reads one item at a time, filtering to the ~22 shoppable procedures — bounded memory regardless of file size.

HCA and VCU publish the identical CMS v3.0.0 JSON shape, so one JSON parser plus one CSV parser (Bon Secours) cover every system. The tedious per-hospital normalization is the moat — funded players stay shallow nationally; Phanera goes deep on one metro.

Raw files hold tens of thousands of rows (every screw, drug, supply). Keeping only rows whose CPT/HCPCS code is a shoppable procedure means the database holds a few thousand useful rows, not millions.

Real EHR analyst tools are server-rendered for performance and accessibility. Thymeleaf + Spring keeps the codebase tight and renders the dashboard in under 100ms even with thousands of rows — no client-side hydration cost.

Wait time, no-show rate, and visits-per-day are calculated with native GROUP BY queries against H2 (in PostgreSQL mode). The same SQL would run unchanged against a real Postgres or Oracle EHR data warehouse — which is what hospitals actually use.

With open-in-view: false, lazy associations would throw exceptions during Thymeleaf rendering. Custom findAllWithRefs queries eagerly fetch Patient + Provider in one round-trip, eliminating N+1 queries on the visit log.

SMART on FHIR is the standard Epic and every major EHR vendor use for patient-app authorization. Using the standard means the same code would work against Cerner, Allscripts, or Athenahealth sandboxes with only a configuration change.

For browser-launched patient apps Epic requires PKCE. A static client secret can't be stored in a browser app without exposure, so PKCE provides one-time proof of possession during the code exchange.

HAPI gives strongly-typed FHIR resources (Patient, Observation, MedicationRequest) with validation built in. Faster to develop against and forward-compatible with FHIR R4 → R5.

Medical images are protected health information. Parsing, windowing, and rendering every pixel locally means there is no server to store or leak data, the safe default for anything imaging-related.

Reading the header directly (group/element tags, value representations, the transfer-syntax switch, sequence skipping) is the clearest way to show I understand the DICOM data model that PACS, VNAs, and Epic Radiant are built on.

Stored pixels are first rescaled to Hounsfield units (slope and intercept), then windowed with the DICOM VOI LINEAR formula. That is the exact order a diagnostic viewer uses, which is why the Brain, Bone, and Lung presets land on the right tissues.