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.

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.

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.

The reviewed module prepares readable text and structured metadata, retains source identities, and supports configurable embedding providers. Elasticsearch is one supported search backend. The notes’ “stripped-down JSON” and “numeric identifiers” are shorthand, not a full description of this code.

The E5-base-v2 model card describes English-only support and a 512-token input limit. The notes identify that model, while the harness configuration names MiniLM by default; neither source establishes the active configuration on another server.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.