OpenClinAI home / WA Health Summary / Design & Architecture Dashboard
Interactive UX Word report
01 / OVERVIEW

WAHS and OpenClinAI

How our experience can help people review their health records—and what a small pilot could teach us.

Recommended direction

Explore how AI and people can resolve conflicts together

AI flags a possible conflict, a person adds context, and they refine a proposed resolution together. Explore that cycle on a few example cases, keeping sources visible and the person in control. Our methods can transfer before choosing shared tools or code.

Explore pilot ideas
EXPERIENCE WE CAN APPLY

Make answers traceable

ChartSearchAI shows supporting chart entries. Our tooling records model work and checks so reviewers can inspect what happened.

Explore the transfer options →
A WORKFLOW TO EXPLORE

Keep people in control

Discuss a flagged difference, revise the proposed resolution and record a decision. Unresolved differences can stay visible.

Walk through the interaction →
WHAT WE COULD LEARN

Learn from each decision

Study missed disagreements, incorrect combinations, useful corrections and whether people understand AI labels.

Explore research questions →

The key findings

What we know → what it suggests
01

Source references are a useful starting point

ChartSearchAI identifies supporting records. The AI Transparency guide adds a way to share which AI helped produce a result, what it changed and what human involvement was recorded.

See the distinction ↗
02

Catalyst offers a way of working

Its review-before-action approach can guide WAHS design without using Catalyst code. Decisions about patient records, corrections and sharing still belong to WAHS.

See the workflow ↗
03

Check the actual size before choosing tools

The discussion suggests fewer than a dozen records per person. One record could still contain many entries. Inspect examples before deciding how much information a model can read at once.

See open decisions ↗

The wider opportunity

The updated discussion covers four patient-facing needs: resolve conflicting records, build a useful sharing summary, find information through questions, and show AI involvement. Smaller models, record preparation and shared computing support those needs.

Finding useful entries →   AI history and human review →   Models and shared computing →

A proposal for discussion. This report connects WAHS needs with OpenClinAI experience. It does not represent an agreed partnership, approved WAHS roadmap or completed pilot. What was checked
02 / HOW OUR EXPERIENCE TRANSFERS

Useful at several levels

The first contribution can be a better method or a shared review session. Using OpenClinAI software is an option, not a condition.

1 · METHODS

Apply what we have learned

Show original sources, distinguish dates, review ambiguous cases and record why a decision was made.

No code reuse needed
2 · EXPERIENCE DESIGN

Adapt the way people work

Use Catalyst’s review-before-action approach to sketch a WAHS workflow that supports correction and unresolved differences.

No code reuse needed
3 · SHARED TESTING

Use tools to learn faster

Use the evaluation harness and Med Agent Hub to run the same cases and inspect outputs, errors and reviewer decisions.

A small pilot runner is needed
4 · PRODUCT INTEGRATION

Connect selected components

Consider record-reading, search or AI-history components once sample data and the intended workflow make the benefit clear.

Compatibility must be tested

Where this applies

Existing foundation and proposed use
9 opportunities
Existing experience, how it could help WAHS, and the work needed
OpportunityOur foundationHow it could help WAHSFirst useful step
Answers with sourcesCode reviewed

ChartSearchAI and Hub retain supporting record references and checks.

Teach and test the habit of showing the exact entry behind a statement.
Evidence and limits

A reference helps inspection. It does not guarantee that the answer interprets the record correctly.

Source-handling code →
Methods first
Ask questions about recordsCode reviewed

QueryStore prepares and searches OpenMRS entries; ChartSearchAI uses retrieved records to support answers.

Explore a question-and-answer view that opens the supporting entries.
What transfers first

First test what information must stay visible and whether search misses relevant entries. A WAHS connection is additional work.

How the search approach works →
Examples, then search
A read-only record viewCode reviewed

QueryStore offers patient records, search, dates and version markers through OpenMRS.

Give people and models a stable view of the same entries while keeping the original system authoritative.
Where QueryStore fits

Direct use fits an OpenMRS test source. For WAHS exports, start with the same read-only approach; a connector or separate reader would be needed.

Explore the read-only option →
Methods or tools
Resolving disagreementsExperience to adapt

Record-level evidence review and Catalyst’s inspect-before-action approach.

Flag a difference, exchange context and refine a proposed resolution until a person accepts it or leaves it unresolved.
What must be designed

Patient statements, clinical decisions and sharing permissions need distinct treatment. No WAHS reconciliation engine was verified.

Review workflow →
Walk through cases
A useful sharing summaryExperience to adapt

Answers tied to chart records and review of generated work.

Choose who the summary is for, inspect what it includes and catch important omissions.
What remains open

The recipient, purpose and handling of unresolved differences need agreement with WAHS.

People and sharing →
Sketch and review
Clear AI historyRelated foundation

Source references and internal records of model work.

Show what AI contributed and what human involvement was recorded. Exchange that history using the FHIR guide.
Additional work

Reading and writing the guide’s labels and linked history is new work. Existing internal evidence does not establish compatibility.

Three kinds of evidence →
Inspect one example
A repeatable pilotCode reviewed

Harness run records and Hub model calls.

Run small examples, preserve inputs and outputs, and compare them with human judgments.
Additional work

Add the WAHS case format, a runner and review notes. The general Hub endpoint does not provide all of the richer Catalyst request records.

Pilot ideas →
A small runner
Model and context choicesMethods to apply

Experience with local models, limited input space and comparative runs.

Measure errors, response time and information needs on the actual task before choosing infrastructure.
What evidence is needed

Performance on clinical queries does not establish performance on record reconciliation.

Research questions →
One model, then compare
An understandable patient viewResearch direction

Language and participation questions in the research programme; dashboard design experience.

Test wording and correction with intended users. The updated notes place multilingual support in a future discussion; reading, search and translation will each need testing.
Evidence still needed

Neither translation quality nor patient understanding was measured in this report. Catalyst’s analytics dashboard serves a different purpose.

Research scope →
Review with users

“Code reviewed” means the named behavior was found in the cited source. It does not mean it has been tested with WAHS.

QueryStore: a quick way to read and inspect records

Its most useful lesson is to keep the original record intact. A read-only source view can serve both a person and a model while draft resolutions, comments and accepted decisions are recorded separately.

WITH AN OPENMRS TEST SOURCE

Try the existing read interface

QueryStore can return a patient’s indexed entries as readable text with source identifiers and clinical dates. It supports full-chart pages and searches. The harness could capture a view and pass selected entries to Hub.

Use the complete available view as the first comparison. Search can be a later experiment.

See the verified interface →
WITH WAHS EXAMPLE EXPORTS

Apply the approach first

A simple file reader can expose entries with their source, date and original content. That may be enough for a small pilot.

The current QueryStore module is built for OpenMRS. Support for arbitrary WAHS FHIR exports would need to be designed and tested.

Keep the limits visible. A searchable copy can be incomplete or out of date. Version markers help detect changes; a result count does not prove completeness. Patient access controls need their own design. QueryStore also has maintenance operations, so the pilot should expose only the intended reading functions. Its index repair is different from reconciling clinical meaning.

Choose the model after defining the task

SHARED TESTING

Start with one model and known examples

Med Agent Hub offers configured model calls and reusable prompts. The harness helps preserve the inputs, outputs and test conditions. Compare record-finding, answer quality and response time separately.

Some Hub workflows let a model request an available specialist tool. Other steps remain fixed by the application. A WAHS review loop still needs its own task instructions and human decisions.

Verified model and workflow boundaries →
COMPUTING DISCUSSED

Explore a shared local model service

The notes describe a planned shared GPU allocation for DIGI. OpenMRS could call a model service over an API while remaining on its existing host.

Availability, access and model performance still need confirmation. A locally hosted model can support private deployment, but operation without internet access needs an end-to-end check.

What is planned and what is verified →

Keep multilingual support as a separate follow-up. Test finding records, answering and user understanding in each intended language; translating the screen alone is not enough.

03 / HUMAN REVIEW WORKFLOW

Review, decide, then review again

Adapt Catalyst’s iterative review approach: AI and a person work through a flagged conflict together, revising the proposed resolution as context becomes clearer. Keep the original records and the history of decisions.

Proposed workflow · to explore with WAHS
  1. 01

    Flag

    AI identifies a possible conflict and shows its sources.

  2. 02

    Discuss

    The person adds context, asks questions or corrects an assumption.

  3. 03

    Propose

    AI suggests a resolution and explains what it would change.

  4. 04

    Refine

    The person and AI revise the proposal as often as needed.

  5. 05

    Decide

    The person accepts, edits, rejects or leaves it unresolved.

Return to the sources and discussion whenever a proposal needs more context. Record an accepted resolution separately from the originals, with its explanation and human decision. Unresolved is a valid outcome. Previewing and sharing the resulting view is a separate step.

ILLUSTRATIVE CASE

Two medication entries disagree

Source AEarlier dose recordedOriginal entry retained
Source BDifferent dose recordedOriginal entry retained

The difference may be a dose change, a duplicate import, or a real disagreement. A patient can state what they currently take. That statement does not silently replace the prescription. AI might then propose treating the entries as a change over time, if the dates and supporting records justify it. The person can correct that interpretation, request another revision or leave the difference unresolved.

Concept illustration; not a patient record or clinical recommendation.

DESIGN REQUIREMENTS TO AGREE

Keep the person in control

  • Make the proposed change and affected fields visible.
  • Let the person add context and request another revision.
  • Retain accept, edit, reject and defer as distinct decisions.
  • Keep the original entry and the version the person reviewed.
  • Ask for a fresh review if relevant information changes.
  • Preserve user input when a save fails.
  • Preview sharing separately from editing.
Research on correction and explanation →

Three things people need to understand

Read the guide ↗
Existing foundation

Supporting records

Which record supports this answer?

Links to chart entries and checks of their use.
FHIR addition

AI involvement

Which system affected this output?

AI system, degree of involvement, input sources and affected entry or field.
Workflow addition

Human participation

Who reviewed or changed it?

A patient statement and a clinician’s review are different kinds of input.
Do not collapse these into one “verified” badge. An automated check is not a human review. An explanation or model card does not establish clinical correctness. When involvement or review is not recorded, show that uncertainty.

In FHIR, this linked history is called Provenance. A model card describes the model and its intended use. Agree the guide version with the receiving system. Profile and diagram

WHEN WAHS PRODUCES A RESULT

Carry the history with it

An AI-assisted reconciled view or sharing summary would make WAHS an AI data producer. Link the new output to its sources and recorded AI and human contributions.

For an International Patient Summary, agree how this history is included in the shared FHIR bundle. One reconciled view can still contain several resources and unresolved differences.

WHEN WAHS READS A RESULT

Make the history understandable

As an AI data consumer, show whether AI was involved, how much it contributed and whether human review is recorded. Distinguish a label on a whole entry from one on a single field.

The connectathon display opportunity

The supplied Scenario 1 criteria ask a reviewer to determine these facts without reading raw data. An optional extension is opening the model card from a Device attachment, Device note or linked DocumentReference. These technical forms should lead to a simple “About this model” action.

Use a partner-provided example and the agreed guide version. This report has not demonstrated those exchange paths.

Scenario criteria →
04 / RESEARCH OPPORTUNITIES

Learn from the review process

WAHS offers a practical setting for questions already present in the research programme. The contribution could be a method, a set of cases or evidence about a design choice.

Can AI make fragmented records easier to review while preserving their meaning and people’s control?

A useful pilot can inform this question. A publishable study would also need a literature review, a study plan and suitable participants.

Which information should the model see?Apply our experience with context and retrievalMethod transfer

Try: Give the model all entries in a small case. Compare that with selected entries only when size becomes a problem. QueryStore can support a search comparison for OpenMRS sources.

Learn: Whether selection hides a relevant disagreement, and how much time and input space each approach uses.

Research return: Cases that expose the trade-off between a complete view and a focused view.

Related research →
When should the model choose its next step?Compare a fixed sequence with tool-assisted explorationStudy opportunity

Try: Begin with a guided cycle: read, flag, discuss, propose, revise and decide. If a case needs more information, compare it with a model that can request another read or an available specialist tool.

Learn: Whether flexible steps find better evidence, introduce new errors or increase time and cost. Keep the same source cases and human authority in both approaches.

Research return: Evidence about when orchestration helps. Existing Hub tool use is a starting example, not a general WAHS agent system.

Reviewed Hub behavior →
When do suggestions help?Apply our approach to checking individual decisionsMethod transfer

Try: Follow a conflict from the initial flag through human input and revised proposals to an accepted resolution or an unresolved decision. Inspect how corrections change the next suggestion.

Learn: Missed disagreements, incorrect resolutions, useful corrections, and whether later suggestions honor the person’s input.

Research return: A review method that distinguishes computer checks, patient knowledge and clinical judgment.

Related research →
Does the application honor people’s decisions?Adapt the review-before-action approachDesign transfer

Try: Reject a suggestion, correct an entry or change the sharing purpose. Check what appears in the next draft.

Learn: Whether rejected or outdated suggestions reappear, whether edits survive a failure, and whether unresolved items stay visible.

Research return: Repeatable examples for studying control over AI-assisted work.

Related research →
Do people understand sources and AI involvement?Study explanation and review labelsStudy opportunity

Try: Ask readers to identify the source, what AI changed and who reviewed it, using a concise display with expandable details.

Learn: What readers interpret correctly, where they become too confident, and which wording helps them correct a mistake.

Research return: Evidence about an understandable way to display AI history. A label alone does not establish understanding.

Design research →
What can small local models do well?Reuse the testing approach and, where useful, the toolsTool and method transfer

Try: After the first workflow is useful, run the same reviewed cases on a second model with the same instructions and inputs.

Learn: Which cases succeed, when a model admits uncertainty, and the time and computing resources needed. Test local and disconnected use explicitly if those are requirements; assess languages separately.

Research return: Task-specific evidence for model choice. A small demonstration cannot establish deployment readiness.

Existing evaluation plan →
Keep the original research question visible. The existing dissertation focuses on adapting WHO SMART Guidelines for HIV care. WAHS could test whether its methods transfer to a different problem. It would need its own study questions and measures. Research scope
05 / SMALL PILOT IDEAS

An iterative conflict-resolution pilot

A short abstract for exploring how AI and people can flag and resolve conflicting records together. Search and AI history are supporting opportunities.

Lead pilot for discussion. Explore the full cycle of flagging, discussion, proposed resolution and human revision. Begin with a few fictional examples; agree the practical scope with WAHS.
1
Lead pilot

Flag and resolve conflicts together

Explore an iterative conversation around a few fictional medication histories. AI flags a possible conflict and shows the source entries. A person adds context or challenges the interpretation; AI proposes and revises a resolution in response. The person can accept, edit, reject or leave it unresolved. Preserve the originals, label patient comments and record the reasoning behind each decision.

What we could learn: Whether the back-and-forth improves resolutions, catches mistaken assumptions and respects human corrections without forcing agreement.

What we bring: ChartSearchAI’s source references, Catalyst’s iterative review approach, and optional use of the harness and Hub to inspect successive proposals and decisions.

Related review approach →
2
Supporting idea · search

Find the records behind an answer

Explore a simple question-and-answer view over a few example records. Let a reader open the entries supporting each answer. Compare reading a small case in full with selecting relevant entries when search would be useful.

What we could learn: Whether the right information is found, what search leaves out and whether readers can check an answer.

What we bring: ChartSearchAI and QueryStore retrieval experience, reusable case-review methods and optional shared evaluation tools. Direct QueryStore use fits an OpenMRS source; WAHS data access would need separate work.

Related search approach →
3
Supporting idea · AI history

Make incoming AI history easy to understand

Use a partner’s example to explore a display of whether AI was involved, how much it contributed and what human review is recorded. Compare labels on a whole entry and on one field, with model information available on request.

What we could learn: Whether a reader can understand the supplied connectathon facts without inspecting raw data.

What we bring: Experience showing sources and review evidence, plus a clear distinction between supporting records and the FHIR history of how a result was produced. Reading the guide’s exchange formats would be new work.

Related attribution approach →

Enough detail for the next discussion

Use the lead abstract to agree a useful example and who will review it. Discuss what counts as a helpful resolution and when a conflict should remain open. Keep effort and implementation choices for that conversation.

A source-linked sharing summary could also be a useful variant. Shared computing, model comparisons and multilingual support can follow the chosen question. These ideas can contribute methods, examples and research findings even when no OpenClinAI code is reused.

06 / APPENDIX

Sources and confidence

See what supports the report, what is proposed and what still needs to be tested.

Coverage. Reviewed on 9 September 2026. The WAHS meeting page, supplied transcript and updated notes, OpenClinAI and QueryStore sources, model documentation, and research repository inform this report. WAHS implementation code and real patient exports were not inspected. The connectathon page could not be fetched; its criteria come from the supplied excerpt. No live interoperability or patient usability result is claimed.

Most code and standards links are public. Meeting and research links require the relevant team permissions; each has a summary here.

WAHS needs and timingMeeting notes, transcript and updated discussion notesProject context

Meeting page version 5, updated 1 September 2026. It records workstreams and open design questions. A generated feature appendix is a discussion aid, not an approved specification. The updated notes supplied on 9 September add search-assisted answering, record preparation, local model assessment, shared GPU plans and a later multilingual discussion. Timing and the meaning of “record” need partner confirmation. Access requires the team’s Confluence permissions.

Meeting notes · team access ↗
ChartSearchAI sources and checksMed Agent Hub source at 939720eCode reviewed

In the configured Hub path, each supporting record keeps its identity, dates and text; available source details are retained. The engine records checks of how an answer uses those records. This is evidence of code behavior, not a WAHS integration result.

Evidence mapping ↗ · Grounding records ↗
QueryStore read-only accessOpenMRS module · revision 8dc6ef9Code reviewed

The patient-record GET interface delegates to the existing read service. It supports chart pages, searches, source identifiers, clinical dates and version markers. It requires OpenMRS read privileges. Reading the index does not establish that every source entry is present.

This module is tied to OpenMRS; no arbitrary WAHS FHIR import was verified. Index repair operations have separate administrative privileges. The pilot must distinguish access to a patient’s own data from broader staff access.

Read interface and limits ↗ · Request handler ↗
Reusable prompts and model settingsHub at 939720e · scope of reuseCode reviewed

Hub has reusable prompts, configured model calls and bounded specialist tool use. Its application also controls fixed steps, including preparing evidence before that tool loop. This is a useful pattern for collaboration, but a WAHS task and review workflow still need implementation.

Model requests use explicitly supported options. A YAML file does not guarantee that every Ollama or vLLM setting will be forwarded or honored. The reviewed Hub maps a profile’s “dry” setting to “dry_multiplier”; the note’s intended setting and chosen server still need confirmation. Check sampling controls against both Hub and that server.

Prompts ↗ · Tool use ↗ · Supported settings ↗
Shared GPU and local hosting discussionPlans described in the supplied notesAvailability unconfirmed

The notes describe provisioning a shared GPU service, with a proposed H200 MIG 1g.18gb allocation for DIGI. NVIDIA documents that profile; this confirms the option exists, not that the allocation is ready or that a particular model will fit the intended workload.

Docker Model Runner and an OpenAI-compatible HTTPS API were discussed as serving options; the endpoint and exact configuration remain open. CNICS data was mentioned as a possible future research direction, not as an available or approved pilot dataset. The first pilot here uses fictional examples.

NVIDIA H200 profiles ↗
Attribution on DisplayScenario 1 · supplied September connectathon criteriaSupplied criteria

The supplied excerpt requires a readable display of AI involvement, degree of involvement and recorded human review, with whole-resource and element-level labels distinguished. Opening model information is an optional extension. The scenario page could not be fetched independently.

Connectathon scenario ↗
Model calls and their recordsMed Agent Hub source at 939720eCode reviewed

The general /v1/hub/generate endpoint runs a model and returns its text. The separate Catalyst query-role path records the exact request and settings, plus size measurements when the server provides them; missing measurements are reported. A WAHS runner must record its own evidence; it cannot assume the general endpoint returns that richer record.

Request evidence code ↗
Records of evaluation runsHarness code and version recordsCode reviewed

The harness can record the code version, data version, model provider and test collection for a run. WAHS cases, expected outcomes and reviewer records still need to be added.

Run manifest code ↗
What Catalyst contributesReviewed roadmap and public demonstrationDocumented behavior

Catalyst is a database query and dashboard workbench. The reviewed roadmap defines a generic SQL connection, visible checks and a person choosing the query to run. The public OpenClinAI site also presents a FHIR Data Pipes and Spark demonstration, with a newer implementation account than that roadmap snapshot. This report did not match the running demonstration to a deployed code revision or rerun its comparison. That review approach can inform WAHS, while record editing and sharing require separate design.

Catalyst roadmap ↗ · Public demonstrations ↗
AI Transparency on FHIRCurrent branch and AI Provenance profileDraft guidance

FHIR is a standard for exchanging health information. This draft guide links a result to information about AI involvement, source inputs and people involved. A simple “AI involved” label does not say how much changed or whether a clinician reviewed it. Use a recorded guide version when testing.

Requirements and diagram ↗ · AI Provenance profile ↗
FHIR documents and sharingFHIR R4 document specificationStandard

One shared FHIR document can contain several entries with their history. Corrections to an issued document create a new document instance; the original remains unchanged.

FHIR documents ↗
Dissertation scope and paper plandigging-in-research · June 2026Private research

The existing research focuses on adapting WHO SMART Guidelines for HIV care using open models. WAHS could test whether the methods work in another setting. The linked research repository is private; the summary here is sufficient to follow this report.

Dissertation scope ↗ · Paper plan ↗
Verification and small-model experimentsResearch direction · 6 September 2026Private research

The September research note proposes checking individual steps and running small experiments. This report uses those as research directions; it does not repeat its wider literature claims as established findings.

Research sitrep ↗
How a model finds relevant informationExisting research canvasPrivate research

The research compares giving a model selected information with letting it search in several steps. Small WAHS cases also permit a simpler comparison: give the model all the relevant entries.

Retrieval canvas ↗
Human instruction and execution controlInstruction-priority research memoPrivate research

The relevant question is whether the application honors a person’s current decisions even when the model proposes something else. Wider product and literature claims in the memo were not checked for this report.

Research memo ↗
Paper 2 evaluation protocolDraft preregistration · 2 June 2026Draft

This is a draft study plan for HIV guideline tasks, with choices still open. A WAHS study would need its own questions, measures and review plan.

Protocol draft ↗

UX research applied to this report

Overview before detail

The recommendation and main comparisons stay visible. Supporting evidence expands in place with descriptive labels.

NN/g · Progressive disclosure ↗

Prepared by Piotr Mańkowski with AI-assisted research and drafting. Initial report reviewed on 9 September 2026; Phase 2 prototype and evaluation added on 30 October 2026.

07 / PHASE 2 PROTOTYPE & EVALUATION

Progressive FHIR R4 condensation, clinical reconciliation and grounded Q&A

To test the pilot ideas on realistic patient exports, we implemented a 5-Tier Progressive FHIR R4 / US Core / IPS Chart Condenser and a 4-Layer Clinical Knowledge Base in Med Agent Hub, evaluated across three synthetic test charts (Byron202_Emard19, Lamar193_Beer512 and Maurice742_Auer97 — 23.6 MB total).

Interactive prototype & benchmark

Explore suggested analyses and grounded patient chat

Inspect duplicate labs and Base64 note deduplication, cross-clinic medication and condition reconciliation, longitudinal biomarker trajectories, privacy-segmented sharing (patient_self vs. external_share) and grounded Q&A with clickable [N] → FHIR resourceUuid provenance.

Launch interactive UX (wahs-demo.openclinai.org) Read Phase 2 evaluation report
5-TIER FHIR R4 CONDENSER

99.6%–99.9% token reduction

Condenses Maurice’s 84-year, 18.36 MB (7,099-entry) FHIR R4 Bundle into any target context budget (16k down to 1k tokens) while retaining 100% of the IPS clinical safety core and [N] → resourceUuid provenance.

4-LAYER CLINICAL KNOWLEDGE BASE

100% cohort code coverage

Deterministic normalizers resolve 2,629 / 2,629 clinical instances across SNOMED CT (KDIGO/ADA stage exclusivity), RxNorm (brand↔generic & statin class rules), CDC ACIP (CVX schedules) and LOINC reference ranges.

32-CASE EVALUATION RUBRIC

32 / 32 rubric pass rate

Passes all 32 evaluation cases across Use Case A (reconciliation), B-1 (encounter & longitudinal summaries, including the Nov 2023 CABG ICU stay), B-2 (0.0% sensitive SDOH leakage in external_share) and B-3 (100% abstention on unrecorded facts).

08 / RESEARCH & STANDARDS FOUNDATION

Research-based backing, clinical standards & regulatory architecture

Why patient-mediated multi-clinic summaries cannot rely on raw FHIR prompting alone—and how health interoperability standards, clinical practice guidelines, privacy law, and human-AI interaction research ground each layer of the WAHS+ architecture.

1 · LONG-CONTEXT CLINICAL NLP & IPS PRIORITIZATION

Why deterministic condensation must precede model inference

Empirical evaluations of frontier language models over long clinical documents consistently demonstrate position-bias degradation (“Lost in the Middle”; Liu et al., TACL 2024 ↗) and severe token inflation when serialized FHIR R4 JSON is supplied directly. In our synthetic cohort, an 84-year longitudinal record (Maurice742_Auer97) spans 18.36 MB and ~3.52M raw tokens—17× to 27× larger than 128k–200k context windows—where over 95% of tokens consist of repeated Base64 encounter notes, administrative claims (Claim / ExplanationOfBenefit), and serial laboratory flowsheets.

To prevent ad-hoc truncation from dropping active allergies or cross-clinic medications, our 5-Tier Condenser implements the priority hierarchy of the HL7 International Patient Summary (IPS) and ISO 27269:

  • Mandatory IPS Safety Core (Protected across Tiers 1–4): Allergies and intolerances, active medications, and active problem-list conditions are never truncated, even at the 1,024-token emergency tier.
  • SHA-256 Note Payload Deduplication: Eliminates copy-forwarded and dual-indexed Base64 clinical notes across DocumentReference and DiagnosticReport.presentedForm[] while retaining unique clinical narratives.
  • Longitudinal LOINC Trajectory Folding: Collapses thousands of serial numeric observations into canonical per-analyte chains (Initial, Latest, Min/Max, Count, and Trend Direction) with preserved member UUID lists.

HL7 FHIR IPS Implementation Guide ↗ · ISO 27269 IPS Standard ↗ · HL7 US Core (FHIR R4) ↗

2 · MULTI-SOURCE RECONCILIATION & CLINICAL ONTOLOGIES

Deterministic terminology normalization paired with LLM synthesis

When patients aggregate records across unaffiliated clinics via SMART Health Links ↗ or TEFCA patient-access exchange, semantic heterogeneity causes unassisted language models to miss critical safety conflicts: one clinic prescribes brand Plavix 75 mg while another lists generic Clopidogrel 75 mg; primary care retains CKD Stage 1, 2, and 3 simultaneously active while serial eGFR labs demonstrate progression; or retail pharmacy and state registry (WA IIS) exports report overlapping immunizations.

Our 4-Layer Clinical Knowledge Base executes deterministic ontology and guideline checks prior to narrative generation:

  • Layer 1 — SNOMED CT & Disease Stage Exclusivity: Applies KDIGO 2024 CKD Guidelines ↗ and ADA Standards of Care ↗ to detect mutually exclusive active disease stages and uncoded renal/glycemic progression.
  • Layer 2 — RxNorm & DailyMed Medication Safety: Maps brand and generic prescriptions to canonical NLM RxNorm ↗ ingredients and therapeutic classes (DailyMed / MedlinePlus ↗), flagging duplicate antiplatelet/statin/ACE-inhibitor therapy and active-vs-stopped contradictions.
  • Layer 3 — CDC ACIP & LOINC Harmonization: Cross-checks vaccine CVX codes against CDC ACIP schedules ↗ and merges blood-versus-serum LOINC ↗ codes (e.g., 2339-0 vs. 2345-7 for glucose).
3 · DATA SEGMENTATION FOR PRIVACY (DS4P) & STATE/FEDERAL LAW

Enforcing patient_self vs. external_share before condensation

Modern EHR problem lists and observation flowsheets routinely store sensitive Social Determinants of Health (SDOH), substance-use screening (NIDA DAST-10 ↗), intimate partner violence (SNOMED 706893006), and justice-involvement findings alongside medical diagnoses. If an LLM summarizes the raw bundle first and attempts to filter sensitive topics only in the output prompt, sensitive context can leak into clinical reasoning or citations.

Layer 4 of our architecture implements pre-condensation data segmentation aligned with federal and Washington state privacy frameworks:

  • 42 CFR Part 2 & Behavioral Health Confidentiality: Protects substance-use disorder screening and treatment records from unauthorized redisclosure (42 CFR Part 2 ↗).
  • Washington State My Health My Data Act (RCW 19.373): Establishes strict consumer consent requirements for sharing Washington residents’ health data (WA RCW 19.373 ↗).
  • HL7 FHIR DS4P & Gravity Project SDOH Taxonomy: In patient_self mode, sensitive items remain visible with explicit privacy badges so the patient knows what is in their chart; in external_share mode, sensitive resources are stripped deterministically before Tier 1–4 condensation, guaranteeing 0.0% token or UUID leakage (ONC Privacy Guidance ↗).
4 · VERIFIABLE AI PROVENANCE & HUMAN-IN-THE-LOOP AGENCY

Three-layer transparency and calibration of trust

Clinical decision-support research shows that fluent AI explanations can induce over-reliance unless users can verify source records directly and distinguish automated checks from human clinical sign-off. Our UX and data model synthesize three complementary standards:

  • HL7 AI Transparency on FHIR (AI-Provenance): Distinguishes (1) supporting chart records ([N] → FHIR resourceUuid), (2) the AI system and condensation tier that transformed them, and (3) recorded human review or patient annotation (HL7 AI-Provenance Profile ↗).
  • Microsoft HAX Guidelines (G9 Correction & G11 Explainability): Keeps original FHIR resources immutable, supports accept/edit/reject/defer conflict workflows, and surfaces the exact clinical rule behind each flag (Microsoft HAX Toolkit ↗).
  • Progressive Disclosure & Explicit Abstention: Following NN/g Progressive Disclosure ↗ and W3C WCAG 2.1 ↗, the interactive prototype leads users through four focused steps and abstains 100% of the time when queried about undocumented clinical facts.
09 / CRITICAL AUDIT, OPEN QUESTIONS & PHASE 3 TECHNICAL ROADMAP

Candid review of Phase 2, modern evaluation methodology & next target areas

To guide Phase 3 of the WA Health Summary collaboration, we conducted a critical audit of our Phase 2 demo data, rule engine, and evaluation suite, and synthesized concrete engineering plans across evaluation methodology, messy synthetic/anonymized data generation, GPU server execution, model selection, multi-agent KB orchestration, hybrid full-chart retrieval, cryptographic FHIR privacy, and patient-centered scenario design.

9.1 Candid Audit of What We Built & Up-to-Date Evaluation Methodology

CRITICAL AUDIT OF PHASE 2

Four methodological gaps in our current prototype & benchmark

  • Deterministic Verification vs. Live Generative LLM Evaluation: Our Phase 2 evaluator (wahs_analyzer.py) tests deterministic Python normalization and structured templates over condensed FHIR ledgers rather than live open-weight LLM generation (Gemma 4, Qwen 3, MedGemma). Thus, the 99.4 / 100 headline score validates our pre-LLM condensation and rule engine, not generative model fidelity. Meanwhile, the 61.2 / 100 Opus 5.5 row is a reconstructed reference baseline from Phase 1 observations over manually sliced JSON rather than a live side-by-side harness run over all 32 prompts.
  • Co-Designed Perturbations & Rule Tables (Ceiling Effect): The 15 multi-clinic conflicts in Set B and the 4-Layer lookup tables were co-designed in the same sprint over the exact SNOMED/RxNorm/CVX/LOINC codes present in the three test bundles. Because generator and detector share a finite code vocabulary, recall hits 100% by construction.
  • Clean Synthea Regularity & Tiny Cohort (N = 3): Three clean Synthea patients have 100% coded entries (2,629 / 2,629). Real multi-EHR patient exports and Epic EHI dumps contain uncoded free-text problems, local charge codes, OCR/scanned PDF notes, and garbled sig strings where deterministic lookup alone drops sharply.
  • Evaluator Schema Drift & Jargon: An audit between our in-process report script (32 / 32) and standalone HTTP harness runner (summary.json, 81 / 96 cells) exposed a field-name mismatch (abstained vs. abstains) and a substring false positive where the redaction banner triggered the forbidden-term check. We also remediated opaque metrics (e.g., “4-Layer KB Code Coverage” → Medical Code Recognition Rate) across the published evaluation report.
MODERN EVALUATION METHODOLOGY

Grounding Phase 3 in AI research, industry rubrics & shared tooling

  • OpenAI HealthBench (2025) Weighted Physician Rubrics: Replaces binary pass/fail keyword checks with instance-specific, clinician-authored rubric criteria carrying positive weights for required clinical context/actions and negative penalties for dangerous omissions, false reassurance, or clinical jargon in patient answers (OpenAI HealthBench ↗).
  • Stanford MedHELM & MedAgentBench: Evaluates real-world EHR decision-support and multi-step FHIR agent workflows rather than multiple-choice licensing exams (Stanford MedHELM ↗).
  • VeriFact (2025), FActScore & MiniCheck Atomic Entailment: Decomposes every LLM response into atomic clinical propositions and verifies via Natural Language Inference (NLI) that each cited [N] → FHIR resourceUuid actually entails the claim—catching citation distortion where a model cites a real lab or note while misstating its value or date.
  • Shared Open Tooling & OpenClinAI Blind Judging: Integrates Promptfoo ↗ (declarative prompt/model matrices & red-teaming), DeepEval / Ragas ↗ (faithfulness & context recall), and our blind multi-judge protocol (Claude Opus 5.5 + GPT-6-Astra with stripped check labels).

9.2 Generating Realistic, Messy Multi-EHR Synthetic & De-Identified Patient Data

To stress-test condensation, reconciliation, and LLM reasoning under realistic clinical messiness, Phase 3 expands our test corpus from 3 clean Synthea files to 8 patient personas (25–50 longitudinal bundles) using a 3-prong data pipeline:

8 TARGET PATIENT PERSONAS

Diverse clinical trajectories & multi-portal fragmentation

  • P1 · Older Adult Multimorbidity & Post-ICU Transition (Maurice expansion: CHF, CKD 3b→4, T2DM, post-CABG anticoagulant + statin conflicts).
  • P2 · Pediatric / Adolescent Split-Custody & School/IIS Registry (Byron expansion: urgent care + school clinic + WA IIS immunization interval conflicts).
  • P3 · Severe Atopy, Anaphylaxis & Specialty Biologics (Lamar expansion: missing rescue epinephrine + unmerged surgical latex allergy).
  • P4 · Maternal / Perinatal High-Risk Care (Gestational diabetes, preeclampsia monitoring, postpartum blood pressure & OB vs. PCP handoff).
  • P5 · Oncology Survivorship & Multi-Center Infusion (Academic cancer center chemo/immunotherapy + community ED febrile neutropenia + cardiotoxicity monitoring).
  • P6 · Dual-Protected Behavioral Health, Chronic Pain & SDOH (42 CFR Part 2 buprenorphine/SUD + IPV screening + WA MHMDA reproductive health segmentation).
  • P7 · Rural-to-Urban Transfer & Bilingual Caregiver Navigation (Critical access hospital ED + urban tertiary referral + Spanish/English caregiver summary needs).
  • P8 · Rare / Autoimmune Diagnostic Odyssey (3+ rheumatology/GI portals, conflicting working diagnoses, biologic washout periods, normal/negative abstention probes).
6-LAYER EHR MESSINESS INJECTOR & REAL CORPS

Simulating real-world health-system entropy

  • 1. Terminology & Code Stripping (30–40% of entries): Drops standard SNOMED/RxNorm/LOINC codes from a subset of entries, leaving only local hospital codes or raw code.text (e.g., “T2DM w/o comp”, “lasix 40 po qd”).
  • 2. Conflicting & Free-Text Sig Instructions: Injects clinician notes saying “Hold lisinopril until potassium rechecked” while MedicationRequest.status remains active.
  • 3. Copy-Forwarded & Stale Note Bloat: Injects 10–15 sequential progress notes with 85% copy-pasted physical exam text where one buried line changes a medication dose.
  • 4. OCR & Scanned Document Noise: Simulates faxed outside discharge summaries and scanned lab PDFs inside DocumentReference attachments.
  • 5. Partial C-CDA-to-FHIR & Epic EHI Artifacts: Simulates lossy C-CDA conversions (MedicationStatement with missing requester/dates) and raw EHI export tables.
  • 6. De-Identified Real Clinical Anchors: Supplements synthetic cohorts with PhysioNet MIMIC-IV-on-FHIR v2.1 (real ICU/ED stays paired with MIMIC-IV-Note discharge summaries) and public SMART Sandbox / Sync for Science multi-vendor bundles.

9.3 CIRG GPU Server Execution Plan & Candidate Open-Weight Model Inventory

We inspected the UW CIRG GPU server configuration (uwcirg/llm-configs#2 ↗ & #3 ↗) running Traefik + LiteLLM + Ollama/vLLM on NVIDIA H200 hardware (141 GB HBM3e full GPU or MIG 1g.18gb / 2g.35gb slices), alongside our local 64 GB unified-memory Mac llama-router setup.

Key server configuration findings from uwcirg/llm-configs: (1) Raise OLLAMA_MAX_LOADED_MODELS from 2 to 3–4 (or pin one model per stage) so concurrent calls to embed/nomic-embed-text + writer + reviewer do not thrash VRAM; (2) explicitly pass num_ctx: 16384 or 32768 per API call so Ollama does not silently truncate condensed charts at its 2k/4k default; (3) enable OLLAMA_FLASH_ATTENTION=1 and OLLAMA_KV_CACHE_TYPE=q8_0 (or deploy vLLM with --enable-prefix-caching so repeated Q&A and rubric checks over the same patient ledger reuse the KV cache at >80% prefill speedup); and (4) enforce turn_off_message_logging: true in LiteLLM for zero PHI persistence.
Candidate open-weight models from 1B edge to 70B server tiers for WAHS Phase 3 screening
Tier & Target Hardware Candidate Open-Weight Models VRAM Footprint (Quantization) Primary Role in WAHS+ Architecture
Tier S · Edge / Browser / Mobile
0.3B – 4B · WebGPU / Laptop / CPU		 MedGemma 1.5 4B-IT · Gemma 4 E4B · Qwen 3 1.7B / 4B · Llama 3.2 3B · MiniCheck-Flan-T5-Large (770M) 1.5 – 4.5 GB (Q4_K_M / Q8_0) Zero-server client-side summarization over Tier 3/4 condensed capsules (≤ 4k tokens); fast claim-level NLI entailment verification (MiniCheck); query intent routing.
Tier M · Single MIG Slice / Workhorse
7B – 14B · H200 MIG 1g.18gb (18 GB)		 Gemma 4 12B-IT (Q8_0) · Qwen 3.5 9B (Q8_0) · IBM Granite 4.2 8B · Ministral 3 14B · DeepSeek-R1-Distill-Qwen-14B 6.5 – 14.5 GB (fits in 18 GB slice with 16k KV cache) Primary production workhorse for Tier 2/3 chart summarization, cross-clinic conflict explanation, and cross-family label-only review (single-12b-xcheck).
Tier L · Dual-MIG / Half-GPU Specialist
24B – 35B · MIG 2g.35gb / 3g.71gb		 Gemma 4 31B-IT (Q4_K_M) · MedGemma 27B-Text-IT · Qwen 3.8 27B · Qwen 3.6 35B-A3B (MoE, 3B active) · Nemotron 3 Nano 30B-A3B 16 – 22 GB weights + KV cache High-accuracy multi-source reconciliation, complex ICU/longitudinal narrative synthesis, and fast MoE specialist verification (3B active parameters per token).
Tier XL · Full H200 Server Ceiling / Judge
70B – 120B+ · Full H200 (141 GB HBM3e)		 Llama 3.3 70B-Instruct · Qwen 2.5/3 72B-Instruct · OpenBioLLM-70B 42 – 75 GB (Q4_K_M / FP8) Local open-weight reference ceiling, gold-standard synthetic perturbation authoring, and local LLM-as-a-Judge calibration.

3-Stage Screening Funnel: Stage 1 (Deterministic Gate, N=10 cases): reject any model with <95% citation formatting compliance, >0 SDOH privacy leaks, or <90% abstention accuracy. Stage 2 (Throughput & Tier Sensitivity, N=32 cases × 3 budgets): measure TTFT, tokens/sec, and recall degradation from 8k → 2k tokens. Stage 3 (Full Multi-Persona Blind-Judged Benchmark, N=100+ cases): dual-judge HealthBench + VeriFact scoring.

9.4 Prompt Engineering & Orchestrated Agent Teams for KB-Based Queries

PROMPT ENGINEERING FOR SMALL/MIDSIZE MODELS

Five empirically validated prompting levers

  • 1. Pre-Injected Temporal & Reference-Date Anchor: Always supply the chart’s reference date and pre-computed relative intervals (e.g., [2023-11-20 · 2y 11m ago]) so 4B–14B models never perform raw calendar arithmetic.
  • 2. Deterministic KB Fact Sheet Pre-Attachment: Inject matched 4-Layer KB findings (RxNorm ingredient matches, KDIGO eGFR stage rules, ACIP intervals) as an explicit [CLINICAL RULE ALERTS] block above the condensed ledger so the LLM explains verified findings rather than memorizing ontology tables.
  • 3. Constrained [N] Bracket Citation Grammar: Require every clinical assertion to carry an inline [N] index from the condensed ledger or explicitly state “Not documented in the provided health summary.”
  • 4. Evidence-First Ordering & Sampling Control: Place the condensed ledger at the top of the prompt (maximizing prefix-cache hits), repeat the user question at the bottom, and disable aggressive repetition penalties (dry_multiplier = 0, temperature = 0.0–0.2) that corrupt medication lists.
  • 5. Audience Dual-Register Prompting: Separate Patient Mode (6th–8th grade plain English, empowering questions to ask the care team) from Clinician Mode (problem-oriented assessment & plan with LOINC/RxNorm codes).
ORCHESTRATED AGENT TEAM EXPERIMENTS

When do multi-agent teams beat a single model on KB queries?

Drawing on our med-agent-hub findings (specs/checked-answers.md), letting a second agent blindly rewrite a draft often deletes valid clinical details (verifier over-rejection). Instead, Phase 3 tests four controlled architectures on KB-heavy queries:

  • Arm 1 — Single Model + Raw Condensed Ledger: Baseline single pass without KB rule pre-injection.
  • Arm 2 — Single Model + Deterministic 4-Layer KB Pre-Injection: Single LLM call augmented with deterministic RxNorm/SNOMED/ACIP/LOINC rule outputs.
  • Arm 3 — Cross-Family Label-Only Checked Pipeline (single-12b-xcheck): Writer (Gemma 4 12B) drafts the answer; a cross-family Reviewer (Qwen 3.5 9B or Granite 4.2 8B) and narrow Entailment Grounder check each claim against the KB and cited FHIR records, attaching verification badges or triggering a single targeted repair pass.
  • Arm 4 — Orchestrated Specialist KB Team (team-wahs-kb): A lightweight Router dispatches parallel domain specialists—Medication & RxNorm Specialist, Lab & KDIGO/ADA Trend Specialist, and ACIP Immunization & Care-Gap Specialist—followed by a Synthesizer and Privacy/Provenance Gatekeeper.

9.5 Evaluating Condensation Tiers & Keeping the Full Chart Queryable

Condensing an 18.4 MB chart down to 2k–8k tokens guarantees that the IPS Safety Core (active allergies, active meds, active problems, recent labs) is always in context, but aggressive condensation (Tier 3/4) intentionally drops older encounters, historical stopped medications, and full free-text clinical notes. To evaluate information loss across tiers and keep 100% of the full chart queryable even for small-context models, Phase 3 introduces a Two-Tier Hybrid Memory Architecture:

HYBRID FULL-CHART QUERYABILITY

Always-On IPS Core + On-Demand Tier 0/1 Retrieval Tools

  1. 01

    Always-In-Context Safety Core (1k–4k tokens)

    Every prompt includes the Tier 3/4 condensed IPS summary so the model never misses an active allergy, active drug conflict, or chronic condition.

  2. 02

    Scoped MCP / Function-Calling Chart Tools

    When a question asks about historical details omitted from the condensed view (e.g., “Why was Furosemide stopped in 2022?” or “What did my 2019 cardiology note say?”), the model calls read-only FHIR retrieval tools: search_chart_entries(query, resource_types, date_range), get_lab_history(loinc_code), and read_clinical_note(document_uuid).

  3. 03

    Ephemeral Client/Server Embeddings

    Indexes Tier 0/1 overflow entries in an ephemeral in-memory vector index using nomic-embed-text (on the CIRG LiteLLM endpoint) or browser-side Transformers.js, returning top-k historical FHIR entries with exact [N] → resourceUuid provenance.

5×4 CONDENSATION ABLATION EXPERIMENT

How condensation interacts with model selection

We will evaluate a 5 (Condensation Configurations: Tier 1 16k, Tier 2 8k, Tier 3 4k, Tier 4 2k static, and Tier 4 2k + On-Demand Retrieval) × 4 (Model Classes: 4B, 9B–12B, 27B–31B, 35B-A3B MoE) factorial matrix across four question horizons:

  • Current Active State Queries: Expected flat performance from Tier 1 to Tier 4 (100% answered from the IPS Safety Core).
  • 24-Month Trend & Conflict Queries: High accuracy at Tiers 1–3; slight dip at static Tier 4 recovered by Hybrid Retrieval.
  • Deep Historical Queries (>2 Years Ago): Sharp drop at static Tiers 3–4 (by design), testing whether Tier 4 (2k) + On-Demand Tool Retrieval recovers >95% of full-chart recall at one-fifth the token cost.
  • Model Selection Implication: Static Tier 3/4 summaries only require strong reading comprehension (enabling 4B–8B models), whereas Hybrid Full-Chart Queryability requires reliable tool-calling (favoring Qwen 3 8B/27B, Gemma 4 12B/31B, or Granite 4.2 8B).

9.6 Privacy Implementation & Encrypting/Obfuscating Specific Parts of a FHIR Bundle

How does WAHS+’s privacy segmentation connect to prior cryptographic FHIR privacy work across UW DIGI and CIRG? Our review links three complementary mechanisms—including Ian Bacher’s proof-of-concept in DIGI-UW/ips-selective-disclosures (sd-fhir) ↗ and uwcirg/shl-ips ↗—into a unified Three-Layer FHIR Privacy & Selective-Disclosure Architecture:

PRIOR UW DIGI & CIRG CRYPTOGRAPHIC WORK

Element- & Entry-Level Obfuscation via sd-fhir (SD-JWT) and SHL (JWE)

  • 1. IETF SD-JWT Selective Disclosure on FHIR (DIGI-UW/ips-selective-disclosures): In Ian Bacher’s sd-fhir package, any sensitive FHIR resource in Bundle.entry[] or primitive field (e.g., Patient.address, Patient.telecom, or a sensitive Condition) marked with extension http://smart.who.int/icvp/StructureDefinition/SelectiveDisclosure is extracted by buildDisclosureFrame(). In the shared FHIR JSON, the sensitive element is replaced in-place by a salted SHA-256/SHA-512 cryptographic digest stored inside an http://smart.who.int/icvp/Extension/sd-hash extension (valueBase64Binary), while the underlying [salt, key, value] disclosures travel separately in a companion fhirR4.Parameters resource. This keeps the redacted FHIR Bundle 100% schema-valid and allows an issuer’s signature to be verified without revealing the obfuscated entries!
  • 2. SMART Health Links Payload & Sub-Bundle Encryption (uwcirg/shl-ips): Uses JSON Web Encryption (JWE, RFC 7516, A256GCM) where the 256-bit decryption key is carried in the client-side URL fragment (shlink:/...) and never sent to the hosting server. High-sensitivity resources can also be wrapped in a separately encrypted JWE sub-bundle or _extension unlocked only with a secondary recipient key or patient passcode.
  • 3. QueryStore Read-Projection Redaction & HL7 DS4P: Aligns with QueryStore’s defense-in-depth read-boundary projection and HL7 FHIR Data Segmentation for Privacy (meta.security labels for 42 CFR Part 2, SDOH, and WA MHMDA).
UNIFIED WAHS+ PRIVACY PIPELINE

How all three layers work together in Phase 3

  1. 01

    Tag (DS4P + 4-Layer KB)

    Automatically tag sensitive FHIR resources and fields (SDOH, IPV, substance use, behavioral/reproductive health) with meta.security and SelectiveDisclosure extensions.

  2. 02

    Gate Before LLM Inference

    In external_share mode, strip withheld resources before Tier 1–4 condensation and LLM prompting so sensitive facts never enter model context or embeddings.

  3. 03

    Obfuscate in Exported FHIR (sd-fhir)

    Replace withheld Bundle.entry[] resources or fields with salted sd-hash extensions so the exported IPS Bundle remains FHIR-valid and cryptographically verifiable without exposing the hidden text.

  4. 04

    Encrypt for Sharing (SHL JWE)

    Package the selective-disclosure IPS Bundle into a JWE-encrypted SMART Health Link (uwcirg/shl-ips) with recipient-scoped disclosure parameters.

9.7 Patient-Centered Scenario Design (Primary) vs. Provider Insight (Secondary)

Grounded in OpenNotes / patient-portal research and the WAHS team’s design discussions, our scenarios and interactive examples prioritize what patients and caregivers actually need to understand, verify, and ask when navigating care across clinics—treating clinician/informatics framing as a secondary toggle:

Six patient-centered question categories contrasted with secondary provider views
Patient Need Category Primary Patient-Centered Question (Default UX Framing) What the Patient Needs in the Answer Secondary Provider / Clinical View (Toggle)
1 · Medication Safety & Pill-Bottle Clarity “Two different clinics gave me pill lists—am I accidentally taking two blood thinners or two cholesterol pills that do the same thing?” Plain-language brand↔generic matching (Plavix = Clopidogrel), clear warning not to stop a heart medication without calling the prescriber, and the exact clinic/date of each prescription. RxNorm ingredient/class conflict alert, P2Y12 / HMG-CoA duplication rule ID, and source MedicationRequest UUIDs.
2 · Understanding Lab Trends & New Diagnoses “My kidney lab numbers (eGFR) have been changing over the last two years—what do they mean, and why does my chart list three different stages of kidney disease?” Simple explanation of what eGFR measures, visual trend over time, why old problem-list labels stick around, and what to ask at the next visit. KDIGO 2024 G-stage exclusivity check, serial LOINC trajectory table, and uncoded G4 progression flag.
3 · Making Sense of a Hospital / ICU Stay “What actually happened during my November 2023 heart surgery and ICU stay, and what changed in my care afterward?” Clear timeline of why they were admitted, what surgery was performed, what devices (stent/valve) were placed, and what medications changed at discharge. Episode-grouped inpatient encounter summary with SNOMED procedure codes, ICU diagnoses, and discharge reconciliation.
4 · Preparing for an Upcoming Appointment “I’m seeing a new specialist next week—what are the top 3 questions or chart errors I should bring up with them?” Actionable, printable checklist of unresolved medication discrepancies, missing emergency prescriptions (e.g., EpiPen), or overdue follow-ups. Pre-visit clinical gap & reconciliation brief with linked FHIR provenance.
5 · School, Camp & Immunization Readiness “Is my child up to date on vaccines for school, and why does the state registry show a problem with one of his shots?” Clear vaccine status table, plain explanation of why a dose given too early may need to be repeated, and which clinic recorded each shot. CDC ACIP CVX minimum-interval validation and WA IIS deduplication log.
6 · Sharing Safely & Protecting Personal Privacy “If I share this summary link with a physical therapist or school nurse, what personal or social history is hidden, and what stays visible?” Side-by-side preview of what is kept vs. removed (with sd-hash selective disclosure), reassuring the patient that active allergies and meds remain intact. 42 CFR Part 2 / WA MHMDA / DS4P segmentation manifest and cryptographic sd-hash verification.