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
IG Version & Stack Compare
Analysis-only
One guide: IG Version CompareA whole stack: IG Stack Compare
- What
- Compare implementation guides without validating a payload: one guide across its published versions, or a whole stack of guides for dependency pins, overlapping profiles and maturity.
- Why
- IG versions change in ways the release notes don't spell out. Real systems run several guides at once, and they don't always agree.
- How
- Checking what a version bump really changes before I plan work. Spotting conflicts across a CRD, DTR and PAS stack.
- What
- Inspect, analyze, and validate FHIR payloads against implementation guides and operational expectations.
- Why
- A validator tells you what failed. I wanted the reason, and the workflow impact, right next to it.
- How
- The first place a payload goes when someone asks me why it was rejected.
Adaptive Exchange Replay
Recorded exchange · no operation is invoked
- What
- 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.
- Why
- An adaptive form is a conversation, and it reads best as one.
- How
- Walking through adaptive questionnaires without a live payer.
Lab tools 4
Scenario Library
Fixture-backed · paste-out only
Browse synthetic PAS fixtures and open them in Analyze, Build, or Compare.
- Why
- Good examples are the fastest way into a guide.
- How
- The starting point for every demo: pick a scenario, open it anywhere.
Compare
Client-side only · no network
Compare two FHIR payloads side-by-side. Fully client-side — payloads never leave your browser.
- Why
- Most prior-auth problems I've chased were a difference nobody had lined up side by side.
- How
- Before-and-after checks when a requirement or a payload changes.
Payload Washer
Client-side only · not HIPAA de-id
Wash production-shaped FHIR into synthetic test data in your browser. Payloads never leave your machine.
- Why
- Realistic test data shouldn't mean real patient data.
- How
- Turning production-shaped examples into fixtures I can share.
Workbook
Client-side only · no network
Step a whole prior-auth request/response cycle in one place, then hand the cells off to Postman, curl, or your own API client.
- Why
- The exchange is what people actually debug, not a single payload.
- How
- Walking a full PAS cycle before I wire it into a real client.
Simulators 4
SMART Launch Simulator
Teaching simulator · no live launch
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.
- Why
- The launch relay is hard to picture from the spec alone.
- How
- Teaching the launch sequence one hop at a time.
CDS Hooks Card Simulator
Teaching simulator · no live launch
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.
- Why
- Seeing the card is when a CDS Hooks response clicks.
- How
- Showing teams what a payer's response looks like at the point of care.
CQL Simulator
Teaching simulator · curated ELM only · lives at DTR hop
Execute curated teaching CQL (as pre-translated ELM) against synthetic patient bundles. Education only — not payer logic on real patients, zero network.
- Why
- CQL is easier to trust once you've watched it run.
- How
- Explaining DTR pre-population with logic people can see.
DTR Forms Lab
Teaching form · synthetic Questionnaires · nothing is submitted
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.
- Why
- Filling the form yourself shows what DTR asks of a clinician.
- How
- Demonstrating the QuestionnaireResponse and how it's checked.
Guides 6
Plain-language explanations of the validator's findings, each with a provenance badge, marked unverified until reviewed.
- Why
- A finding needs plain words, and an honest source for them.
- How
- Translating a validator message for someone outside FHIR.
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
- The wrong code system is a common, quiet failure.
- How
- Answering "which codes go here?" in seconds.
Four Da Vinci DTR mechanisms for questionnaire flow and pre-population, compared with citations.
- Why
- Four mechanisms overlap, and teams pick the wrong one.
- How
- Choosing between enableWhen, $next-question, CQL and client logic.
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
- A ClaimResponse should answer "is it approved?" in plain words.
- How
- Reading an inquiry response without decoding it by hand.
What actually changed between two published versions of a FHIR implementation guide, computed from the packages themselves.
- Why
- A diff computed from the packages beats reading two specs side by side.
- How
- Seeing exactly what moved between versions.
Every RFC-2119 keyword line in the CMS Aligned Network Specification draft, classified for testability, never for conformance.
- Why
- A requirement is only useful if someone can test it.
- How
- Sorting a draft's requirements by how they could be tested.
StandardsHL7® FHIR® · USCDI · ASTP/ONC certification · CMS interoperability and prior authorization · TEFCA · Da Vinci
AcrossPayers · Providers · EHR platforms · HIEs · QHINs · Data aggregators · Health technology