Inspiration

PulseLine began with a belief: your ZIP code should not determine the quality of care you receive. We wanted to explore how clearer information could support the people reviewing rural hospitals.

Hospital financial records contain useful information, but individual numbers can be easy to misinterpret. We focused on helping healthcare reviewers understand historical reports, explore assumptions, and identify what still needs investigation.

What we built

PulseLine brings historical financial figures, transparent what-if scenarios, and evidence gaps into one browser workflow.

Users can choose a Kentucky hospital, examine its available reports, adjust revenue and expense assumptions, and ask supported questions about the selected hospital. Answers include reporting periods, sources, and limitations.

The prototype covers five hospitals: three with historical financial records and two with evidence-only coverage. Missing financial information stays missing rather than becoming an invented figure or score.

How we built it

We built PulseLine with React, TypeScript, and Vite, and deployed it through GitHub Pages. The core application runs in the browser without an account, application server, or database.

The data pipeline adapts stored CMS cost-report extracts, validates records, and preserves original fields and missing values. Shared financial calculations support the charts, report comparisons, scenarios, and question-and-answer workflow.

We also integrated an optional on-device model through WebLLM. Core answers and arithmetic remain deterministic; the model cannot introduce new financial facts into displayed answers.

What we learned

A major lesson was that responsible financial analysis depends on understanding what a number represents. A patient-service result is not the same as overall profit, a fiscal period is not a publication date, and missing information is not zero.

We also learned that a useful prototype needs clear boundaries. PulseLine supports historical review and illustrative scenarios; it does not predict hospital closures or recommend acquisitions. Testing with prospective users remains an important next step.

Challenges we faced

Our main challenges involved inconsistent reporting information, missing values, unusual published balances, and unresolved questions about hospital identity and reporting scope.

We addressed these by preserving source values, explaining exclusions, separating documented events from financial indicators, and making evidence gaps visible. Code review also identified areas requiring further improvement, including comparison handling and interface edge cases.

PulseLine’s goal is to give reviewers a clearer starting point: what the records show, how assumptions affect a simplified scenario, and what to investigate next.

Built With

• css
• github
• github-actions
• jspdf
• llama-3.2-1b-instruct
• react
• svg
• typescript
• vite
• webllm