ImOnFHIR
Interoperability. Simplified. Impactful.
ImOnFHIR is my personal platform for making healthcare interoperability simpler to understand and more useful in practice. I've been a bedside nurse, a nurse informaticist, a software engineer, a solution architect, an AI strategist, and a patient. I build here for the people who do this work: clinicians, implementers, and the community that keeps the standards moving.
Engineering portfolio
What I've built, and why
In the lab
FHIR Analysis Workbench
Inspect, analyze, and validate FHIR payloads against implementation guides and operational expectations.
- Why I built it
- A validator tells you what failed. I wanted the reason, and the workflow impact, right next to it.
- How I use it
- The first place a payload goes when someone asks me why it was rejected.
In the lab
Scenario Library
Browse synthetic PAS fixtures and open them in Analyze, Build, or Compare.
Fixture-backed · paste-out only
- Why I built it
- Good examples are the fastest way into a guide.
- How I use it
- The starting point for every demo: pick a scenario, open it anywhere.
In the lab
Compare
Compare two FHIR payloads side-by-side. Fully client-side — payloads never leave your browser.
Client-side only · no network
- Why I built it
- Most prior-auth problems I've chased were a difference nobody had lined up side by side.
- How I use it
- Before-and-after checks when a requirement or a payload changes.
In the lab
Payload Washer
Wash production-shaped FHIR into synthetic test data in your browser. Payloads never leave your machine.
Client-side only · not HIPAA de-id
- Why I built it
- Realistic test data shouldn't mean real patient data.
- How I use it
- Turning production-shaped examples into fixtures I can share.
In the lab
Package Compare
Compare implementation-guide package requirements across published versions of the IGs in this site's catalog — without payload validation.
Analysis-only · no sidecar warm
- Why I built it
- IG versions change in ways the release notes don't spell out.
- How I use it
- Checking what a version bump really changes before I plan work.
In the lab
IG Stack Compare
Compare a multi-IG stack for dependency pin, overlapping profile, and maturity divergences.
Analysis-only · localStorage stack
- Why I built it
- Real systems run several guides at once, and they don't always agree.
- How I use it
- Spotting conflicts across a CRD, DTR and PAS stack.
In the lab
Workbook
Step a whole prior-auth request/response cycle in one place, then hand the cells off to Postman, curl, or your own API client.
Client-side only · no network
- Why I built it
- The exchange is what people actually debug, not a single payload.
- How I use it
- Walking a full PAS cycle before I wire it into a real client.
Simulator
SMART Launch Simulator
Walk the CRD→DTR SMART App Launch relay step by step — a static teaching reproduction. No OAuth, no network, not validated against a live EHR.
Teaching simulator · no live launch
- Why I built it
- The launch relay is hard to picture from the spec alone.
- How I use it
- Teaching the launch sequence one hop at a time.
Simulator
CDS Hooks Card Simulator
Render a CDS Hooks response as cards for teaching — shape-parse only. No hook is called, and no card represents a real payer coverage decision.
Teaching simulator · no live launch
- Why I built it
- Seeing the card is when a CDS Hooks response clicks.
- How I use it
- Showing teams what a payer's response looks like at the point of care.
Simulator
CQL Simulator
Execute curated teaching CQL (as pre-translated ELM) against synthetic patient bundles. Education only — not payer logic on real patients, zero network.
Teaching simulator · curated ELM only · lives at DTR hop
- Why I built it
- CQL is easier to trust once you've watched it run.
- How I use it
- Explaining DTR pre-population with logic people can see.
Simulator
DTR Forms Lab
Fill a synthetic DTR Questionnaire and emit the QuestionnaireResponse, then hand it to Analyze and watch the workbench judge your own answers. Gating is live; expressions, CQL and terminology are recorded and refused, never evaluated.
Teaching form · synthetic Questionnaires · nothing is submitted
- Why I built it
- Filling the form yourself shows what DTR asks of a clinician.
- How I use it
- Demonstrating the QuestionnaireResponse and how it's checked.
Simulator
Adaptive Exchange Replay
Step through a recorded $next-question transcript turn by turn and watch the item set accumulate. The exchange is committed and synthetic — no operation is invoked and no payer is contacted.
Recorded exchange · no operation is invoked
- Why I built it
- An adaptive form is a conversation, and it reads best as one.
- How I use it
- Walking through adaptive questionnaires without a live payer.
Guide
Explain a finding
Plain-language explanations of the validator's findings, each with a provenance badge, marked unverified until reviewed.
- Why I built it
- A finding needs plain words, and an honest source for them.
- How I use it
- Translating a validator message for someone outside FHIR.
Guide
Terminology explorer
Pick a FHIR field and see the code-system family that belongs there: ICD-10-CM or SNOMED, CPT or HCPCS, RxNorm or NDC, LOINC.
- Why I built it
- The wrong code system is a common, quiet failure.
- How I use it
- Answering "which codes go here?" in seconds.
Guide
CQL or flow logic?
Four Da Vinci DTR mechanisms for questionnaire flow and pre-population, compared with citations.
- Why I built it
- Four mechanisms overlap, and teams pick the wrong one.
- How I use it
- Choosing between enableWhen, $next-question, CQL and client logic.
Guide
Where's My Auth?
Paste a PAS inquiry response and get a plain-language prior-authorization status, with the evidence it came from. Synthetic data only; not a live payer lookup.
- Why I built it
- A ClaimResponse should answer "is it approved?" in plain words.
- How I use it
- Reading an inquiry response without decoding it by hand.
Guide
IG version differences
What actually changed between two published versions of a FHIR implementation guide, computed from the packages themselves.
- Why I built it
- A diff computed from the packages beats reading two specs side by side.
- How I use it
- Seeing exactly what moved between versions.
Guide
CAN-spec testability register
Every RFC-2119 keyword line in the CMS Aligned Network Specification draft, classified for testability, never for conformance.
- Why I built it
- A requirement is only useful if someone can test it.
- How I use it
- Sorting a draft's requirements by how they could be tested.
Beyond the site
Payload Intelligence App
A local Mac workbench that measures how an AI host reasons about a healthcare payload's structure without giving it the values. Synthetic data only; not a validator.
Experimental developer preview · Apache-2.0
- Why I built it
- My first model failed its own holdout, because no expert-corrected answers existed. So I built the instrument first.
- How I use it
- Built for one loop: you approve a structural summary, an AI host answers in closed codes, and an expert corrects it.
StandardsHL7® FHIR® · USCDI · ASTP/ONC certification · CMS interoperability and prior authorization · TEFCA · Da Vinci
AcrossPayers · Providers · EHR platforms · HIEs · QHINs · Data aggregators · Health technology