What the export is for
A governed way to share one case across review, collaboration, and interoperability without exposing the entire app workflow as the external source of truth.
Interoperability
A plain-English guide to the QbitQure case export package.
This page explains the main artifacts inside a QbitQure reviewer case export. It is written for collaborators who want to understand what the package contains without needing prior FHIR knowledge.
Important boundary
The export package is a governed collaboration artifact. It does not convert QbitQure into an autonomous clinical decision maker.
Plain-English terms
You do not need to be fluent in FHIR to understand the package.
These are the main terms collaborators are likely to see when the export package is discussed.
FHIR
A common healthcare data standard. It helps systems describe patients, encounters, observations, and workflow in a more interoperable way.
Bundle
A container that groups related healthcare records together so they can be moved or inspected as one package.
Task
A workflow object. In QbitQure it helps describe ownership, coded review state, handoff, and sign-off in a standards-shaped way.
Provenance
A trace of where something came from or who changed it. In this context it helps show the audit trail and workflow transitions behind review actions.
Package contents
The export package contains five main artifacts.
Each artifact serves a different purpose. Together they make the case easier to inspect, discuss, and share responsibly.
FHIR Bundle
Clinical bundle
This is the structured clinical record for the case. It groups the patient, encounter, observations, and related clinical data into one portable package.
Why it helps: A collaborator can see the case in a standards-aware format instead of only reading free text or screenshots.
Task + Provenance style bundle
Workflow projection
This is the read-only workflow view. It shows coded Task status and business status, who owns the review, and which Provenance-style audit events were recorded while the case moved through handoff and sign-off.
Why it helps: A collaborator can understand the review process and governance layer, not just the clinical content.
Full reviewer event trail
Audit timeline
This is the complete visible reviewer history from the composite workflow read, including whether the export used append-only history or row-cache fallback.
Why it helps: A collaborator can trace what happened over time and see how fresh the workflow history source was when the package was generated.
Plain-English handoff summary
Clinician handoff
This is the compact human-readable summary for supervisor review, MDT discussion, or sign-off conversations.
Why it helps: A collaborator does not need to inspect raw JSON first to understand what happened and what action is needed next.
Bounded pathway review outputs
Accepted pathway snapshots
These capture the accepted PGx pathway interpretation that was linked to the case, including prompts, rationale, and pathway-specific notes.
Why it helps: A collaborator can see what pathway logic was actually attached to the review without confusing it for autonomous prescribing.
Visual map
The five artifacts feed one governed export package.
This is the simplest way to think about the relationship. QbitQure gathers five different views of the same case, then packages them together for review, collaboration, and interoperability.
Clinical bundle
Structured clinical record
Workflow projection
Task and Provenance style view
Audit timeline
Full reviewer event trail
Clinician handoff
Plain-English review summary
Pathway snapshots
Accepted PGx review outputs
Combined into one governed case package
Reviewer case export package
One governed interoperability artifact
This combined package can then be shared for supervisor review, MDT discussion, collaboration, or standards-aware inspection without exposing the whole live application as the external source of truth.
Reading order
The easiest way to inspect the package is to read it in five steps.
This keeps the human summary, workflow governance, audit history, structured bundle, and bounded PGx interpretation in the right order.
Step 1
Clinician handoff first
Start with the plain-English handoff to understand the case, next action, and governance state before opening any JSON.
Step 2
Workflow projection second
Use the Task and Provenance style workflow bundle next if you need coded workflow status, ownership, or audit-history context.
Step 3
Audit timeline third
Open the full audit timeline when you need the complete event trail and source freshness behind the workflow projection.
Step 4
Clinical bundle fourth
Open the clinical bundle when you need the underlying structured patient, encounter, observation, and consent records.
Step 5
Pathway snapshots fifth
Review the accepted pathway snapshots after the workflow and bundle so the bounded PGx interpretation stays anchored to the rest of the case.
What stays app-native
The export is useful, but it is not the whole internal app.
QbitQure still runs on its own internal reviewer workflow model. The workflow projection in the export package is derived from that internal state rather than replacing it.
That keeps the live app simpler and safer while still giving collaborators a standards-aware artifact they can inspect.
Boundaries
The workflow layer is exported as a read-only standards-aligned projection rather than as the live source of truth for app behavior.
The workflow bundle carries coded Task/business-status and Provenance-style mappings, but it is not yet a standalone FHIR Task service.
The package is available only for cases that are completed and governance-ready.
The package is intended for review, interoperability, and collaboration, not autonomous clinical action.