checkin-client

How a check-in runs

Try the demo

The demo is a fictional clinic's check-in page running the real protocol stack. Pick a scenario from the demo bar (insurance card, new-patient summary, day-of PHQ-2, allergy review, med list), press Check in with your health app, and watch the response come back, get verified, and post to a public test FHIR server. Every technical artifact — the SMART request, the wallet's response, the FHIR transaction, the server's reply — is one click away in the Developer detail section.

• No wallet-equipped phone? Switch the responder in the demo bar to demo wallet app — a wallet tab opens with a real consent screen where you choose what to share: demo/#wallet=app. There's also an automatic mock that answers instantly with no consent screen, for scripted testing: demo/#wallet=auto&submit=dry-run. Both run the real CBOR/COSE/HPKE pipeline over fabricated records.
• The autofill pattern: the allergy-review example shows a provider form literally prefilled from the patient's app — and then asking only for what the shared record doesn't carry. US Core requires the substance but not the reaction, so records routinely arrive as "Latex, and nothing else"; the form flags exactly those and elicits the symptoms and severity from the person who knows, marking them newInformation for the care team.
• Framework bindings are trivial because the core is a plain async function: the same flow in React (a ~25-line hook), with an Angular service shown alongside it.
• Everything is a URL. The whole configuration — scenario or full request object, patient, FHIR target, return leg — lives in the URL fragment, so any test case is a shareable link (grammar).

Quick start for EHRs and portals

The kit does exactly one thing: hand your code a validated response, on your page. Everything after that is yours. The URLs below point at this deployment's hosted builds, so the snippets work as-is for experimentation; vendor a pinned copy for anything real.

1. Ask, await, prefill. Define the request inline (the kit fills in protocol boilerplate), await the patient's validated response, and populate your own form — no submission, your code stays in control:

<script type="module">
  import { requestCheckin }
    from "";

  const response = await requestCheckin({
    purpose: "Review your allergy list before your visit",
    items: [{
      id: "allergies",
      title: "Allergies and intolerances",
      content: {
        kind: "selection.fhir",
        profiles: ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-allergyintolerance"],
      },
      accept: ["application/fhir+json"],
    }],
  });
  // response.artifacts → prefill your intake form inline
</script>

2. Then do whatever your workflow needs. The kit stops at the response — it has no notion of a FHIR server, your auth, or your next screen. Writing records is ordinary code you already own; an optional helper is there if you want the mapping done for you:

import { buildCheckinBundle, postCheckinBundle }
  from "";

const bundle = buildCheckinBundle({ request, response,
  context: { patient: "Patient/123", appointment: "Appointment/456" } });

await postCheckinBundle(bundle, { fhirBase: myFhirBase });   // or use your own client
location.assign("/checkin/payment");

Keeping submission out of the kit is deliberate: where patient-supplied data lands, under whose authorization, with what review, is deployment policy — not something a protocol library should decide for you.

The full walkthrough — attributes, events, the JS API, auth wiring, and the production checklist — is in the integration guide.

Status

Working draft. Request construction, SessionTranscript, HPKE, and COSE signature verification are implemented and byte-verified against real Chrome/Android captures in the conformance fixtures, and the demo runs end-to-end against a public test FHIR server today. Still open: a server-owned key-custody reference, production trust anchors, and iOS/Safari support for the underlying browser API.