Meadowlark Care
One chart. The right lens.
One clear view of a patient, the facility and its obligations for a small behavioral-health facility, read-only over the record system it already runs.
Status
- State
- Live
- Address
- meadowlarkcare.app
- Measured
- 748 automated tests passing, 20 September 2026
What it is
Meadowlark Care is three applications, behind one shared front door, that give a small behavioral-health facility one clear view of a patient, of the facility, and of the obligations that come with running it. Each is built for the person who has to answer a question: the clinician with a nine o'clock, the director who needs to know how the facility is doing, the compliance lead with an audit in October.
It reads the record system the facility already runs. Nothing is written back, and nothing here touches billing or claims.
What it sits on top of
What's inside
- Front door
- One sign-in for the three applications, one session behind all of them, and a status page that shows whether each one is answering.
- Patient 360
- One person's record assembled for the role reading it: timeline, treatment, goals, care team, record search. A lens changes what the page asks for and what it folds away; it never changes what a person is allowed to see.
- Org 360
- The state of the facility: programs, clinicians, population and access over a trailing window, and the mix of care delivered.
- Governance
- Ten standing obligations, a reporting calendar, four statistical data-quality detectors, and audit readiness by program.
What it refuses to do
- It never writes to the record. Every query passes a read-only guard in code before it reaches the source, rather than relying on convention.
- It has no opinion on billing, claims or receivables. The payer mix it shows is the mix of care delivered, never a balance.
- It has no user accounts or passwords. A token is a door key, not an identity, and a role lens is a view, not a permission.
- It never lets a restricted record reach a page. Substance-use records protected under 42 CFR Part 2 are filtered inside the source, before anything is summarized or returned.
- It never confirms what it will not show. A patient that does not exist and a patient the viewer may not see get the identical answer.
- Its one generated summary is off by default. When it is on, it sends only a de-identified subset of the record, and any line that cannot cite its source is dropped on the server before the page sees it.
How it shows its work
Every figure carries its caveats. Where the data is sparse, capped, or structurally unable to show a case, the page says so next to the number, not in a footnote. The reporting calendar marks each filing as sourced, inferred, or not found, rather than guessing a cadence nobody stated.
Built and secured
Built
- Nine role lenses (clinician, prescriber, care coordinator, front desk, crisis, nurse, substance-use counselor, peer specialist, full chart), enforced on the server, not in the browser.
- Four services, one container each, one domain each. The three consoles never call one another; they share a session, not a database.
- TypeScript throughout, on one shared design system. Typecheck, test and build run in CI on every code change to main.
- 748 automated tests passing, as reported by the suite on 20 September 2026.
Secured
- Read-only by a guard every query passes: one SELECT or WITH statement, no write keywords, refused before it reaches the source.
- 42 CFR Part 2 records filtered in the source, so a viewer without access never receives them in the first place.
- One door: a server-side session and an opaque, HTTP-only cookie, nothing else in the browser. Revoking a token ends every session it opened across the consoles within about 40 seconds; on the hosted service, revoking takes a front-door redeploy.
- Content Security Policy with no third-party host and no framing (inline styles allowed), origin checks on every state-changing request, rate-limited sign-in.
- The builder's own hardening pass on 20 September 2026 found no critical issue in the code, no committed secrets and no known-vulnerable dependencies. Its three high-rated findings were deployment settings; all three were checked on the live service on 7 October 2026, and the one found wrong was corrected that day.
Care is the product with the most facility experience behind it, which is why it has a Governance console at all. The documentation page carries the shape of the build; the About page carries the rest.