VAREXIS-INDEX ยท Free evidence

FHIR R5 administrative evidence

33 dated FHIR R5 documentation reviews covering audit observations, task authority, claim processing, document references, batch results and subscription delivery. Administrative evidence does not establish clinical conclusions, insurance coverage, settlement or live authorization. Check the applicable version, resource profile and independent outcome; documentation is not verified deployment behavior.

Catalogue additions are available free through the exact HTTP JSON links below. Enhanced natural-language discovery is not yet qualified for these records. They are outside MCP search, MCP preview and paid saved retrieval. No search qualification, executable capability or entitlement is added.

Complete exact-ID manifest · Full catalogue · Existing MCP coverage

FHIR R5 multiple audit observers

Do multiple FHIR AuditEvent records necessarily mean that the same action was executed repeatedly?

FHIR R5 expects participating actors to record an auditable event, so one activity can produce several AuditEvent records. These observations can support cross-system comparison, including finding missing actors or conflicting attributes. Counting the records alone does not establish how many times the underlying action executed.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 success and transfer completeness

Does a successful FHIR AuditEvent outcome establish that an entire transfer completed?

The R5 AuditEvent outcome definition allows a success indication to cover a partial or interrupted transfer for accountability purposes. A successful audit status therefore does not establish that every expected item arrived. Reconcile the operation-specific scope and receiving evidence before marking the transfer complete.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 unknown event initiator

Should an auditor infer the FHIR event initiator from the first listed agent?

R5 AuditEvent.agent.requestor identifies the initiator, with false as the meaning when it is absent. The specification says not to select an initiator when that identity is unclear. Agent order or mere participation does not resolve an unknown initiator; preserve that uncertainty in the reconstruction.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 activity time versus recording time

Does FHIR AuditEvent.recorded establish when the underlying action occurred?

R5 AuditEvent distinguishes the optional occurred time or period from the mandatory recorded instant. A late-recorded event can therefore have a different activity time. Compare the two with the systems clock evidence; a recording timestamp alone proves neither the activity time nor clock accuracy.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 query decoding context

Can an auditor interpret a FHIR AuditEvent query blob without its originating query format?

R5 AuditEvent.entity.query stores query input in a base64 container whose meaning depends on the originating event and query format. An audit consumer must understand that format before interpreting it. The encoding does not make the query self-describing or establish that its contents are safe for unrestricted disclosure.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 provenance target version

Does a FHIR Provenance target always identify one exact resource version?

R5 Provenance targets are usually version-specific, but the definition permits cases where a version is not assigned or the provenance belongs to a maintained document. A target reference can also cover several resources. Resolve the intended resource version before treating the assertion as evidence about one exact artifact.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 recorded delegation versus verified authority

Does FHIR Provenance.onBehalfOf independently verify the recorded delegation?

R5 Provenance.agent.onBehalfOf records the agent that delegated authority to the acting agent. Defined identity constraints prohibit specified self-delegation patterns, but structural validity is not independent verification of the delegation or its permitted scope. Retain the underlying authority evidence for the administrative action.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 task authority and action target

Are FHIR Task.basedOn and Task.focus interchangeable references to the work being fulfilled?

R5 Task.basedOn references higher-level authorization that triggered a task, while Task.focus identifies the request being fulfilled or resource being acted on. The specification distinguishes these references. Replacing one with the other can lose either the authority context or the actual target of the proposed work.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 task ownership and actual performer

Does a FHIR Task owner identify who actually performed the task?

R5 Task separates the owner responsible for managing execution, the requested performer and the entity reported as having performed the task. A task may be created before its owner is identified. An assignment or requested role is therefore not evidence that the named party actually performed the work.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 separate resource completion tracking

Can one FHIR Task focus identify several resources whose completion needs separate tracking?

R5 Task.focus identifies at most one resource. Its definition directs implementations to use subtasks when multiple resources need manipulation so their statuses can be tracked independently. A parent task status should not be substituted for the missing completion evidence of each resource-specific operation.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 business status versus lifecycle status

Can a FHIR Task businessStatus replace its required workflow status?

R5 Task.status is a required coded lifecycle state. Task.businessStatus is optional and carries workflow-specific detail. A local business label therefore does not replace the standard state or establish a meaning shared by every receiving system; retain both the lifecycle state and the local code definition.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 fulfilment period within authorization

Can a FHIR fulfilment Task restriction period extend beyond its referenced request authorization?

R5 Task.restriction.period bounds the fulfilment sought and must fall within the overall period authorised by the referenced request. A task-local interval does not enlarge that authorization. Compare the requested interval with the applicable request before treating work outside its period as permitted.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 preauthorization versus payment

Does a FHIR preauthorization response mean that payment has been made?

R5 ClaimResponse distinguishes preauthorization from an actual claim. A preauthorization response does not itself make a payment, although funds may be reserved for a claim submitted later. Preserve the later claim and financial outcome rather than recording reserved or authorised benefits as money received.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 predetermination and later benefit

Does a FHIR predetermination guarantee the later claim will receive the same benefit?

R5 predetermination describes a hypothetical adjudication. It makes no payment and does not assure that a later claim will receive the same result; available funds may change. A buyer should retain the date and conditions of the estimate and obtain the later actual adjudication.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 partial adjudication without detected errors

Does FHIR ClaimResponse outcome partial mean that processing errors were found?

R5 ClaimResponse.outcome distinguishes queued, error, partial and complete processing. Partial means that some adjudication has occurred without detected errors, while complete means all adjudication processing completed without errors. Do not import a generic partial-failure meaning; inspect what processing remains and the reported adjudication.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 payor-added adjudication lines

Can every FHIR adjudication line be matched by position to the originally submitted claim?

R5 ClaimResponse permits payors to add lines or repackage submitted products and services. The addItem structure can link those lines to submitted item, detail or sub-detail identities. Matching response lines by position alone can lose that relationship; retain the explicit links before reconciling an adjudicated amount.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 payment adjustments outside the claim

Can a FHIR claim payment adjustment be assumed to arise from that claim adjudication?

R5 ClaimResponse.payment.adjustment describes adjustments not arising from the current claim adjudication, such as recovery of an earlier overpayment. A difference between benefit and payment can therefore have another origin. Reconcile the adjustment and its reason separately from the current claim amount.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 focal coverage and coordination order

Does listing several FHIR claim coverages request adjudication from all those policies?

R5 Claim.insurance identifies one focal coverage for adjudication of that claim. Other listed coverages have a coordination sequence, and claims against them are separate. Listing several policies does not request or establish successful adjudication against all of them, nor verify that any policy remains effective.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 reference currency versus final content

Does a current FHIR DocumentReference mean its underlying document is final?

R5 DocumentReference.status describes the reference object; docStatus describes the underlying document lifecycle. A current reference can point to a document with another lifecycle state. Read both rather than treating current metadata as evidence that the content is final, approved or unchanged.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 append document completeness

Can a FHIR document that appends another document be reviewed as a complete standalone record?

R5 DocumentReference identifies relationships between documents. Where a document appends another, the definition says it cannot be fully understood without the referenced target. A standalone export of the appended material may therefore omit required context even when its own file is complete.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 metadata and content security labels

Do DocumentReference.meta.security labels necessarily describe the referenced document sensitivity?

R5 distinguishes DocumentReference.meta.security, describing the reference metadata, from DocumentReference.securityLabel, describing the referenced document. Their sensitivity can differ. A receiver should not infer that access appropriate for the metadata is also appropriate for the document content.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 reference and document provenance

Does provenance of a FHIR DocumentReference establish who created the underlying document?

R5 describes two provenance histories: the underlying document and the DocumentReference that points to it. Another actor may create the reference later, and its metadata describes that reference history. Preserve the document origin separately rather than attributing authorship of the content to whoever created its reference.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 batch HTTP status and individual outcomes

Does HTTP 200 for a FHIR batch mean every requested change succeeded?

FHIR R5 batches process entries independently. HTTP 200 means the batch was processed correctly, even when individual operations failed; their response entries carry the relevant statuses. A transaction has different all-or-nothing rules. Inspect the bundle type and every entry before marking work complete or deciding what to retry.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 dependent changes need transaction semantics

Can a FHIR batch create one resource and rely on another entry referencing that new resource?

FHIR R5 requires batch changes to be independent. References from one batch entry to a resource being created by another are non-conformant. Linked changes need the appropriate transaction and server-support contract; merely putting them in one HTTP request does not establish atomic execution.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 bundle identity and resource version

Does a FHIR Bundle fullUrl uniquely identify the version of every included resource?

R5 Bundle.fullUrl is version-independent and must not contain a history-version reference. Subject to the documented bundle rules, entries can share a fullUrl when their resource versions differ; history bundles have their own exception. Retain the resource version and bundle context before treating the URL as an exact artifact identity.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 warnings versus failed operations

Does a FHIR Bundle entry response outcome always represent an operation failure?

R5 Bundle.entry.response.outcome carries hints or warnings for an entry. It is not the error location for every failed operation: batch failures are represented in the entry response, while a failed transaction returns a single OperationOutcome instead of a response bundle. Interpret the status and response structure together.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 generated events versus delivered notifications

Does FHIR eventsSinceSubscriptionStart count only successfully delivered notifications?

R5 SubscriptionStatus.eventsSinceSubscriptionStart counts generated events whether or not they were successfully communicated. Handshake and heartbeat notifications do not increment it. The counter therefore cannot be used directly as a count of delivered notifications or completed consumer processing.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 event numbering depends on the channel

Is a FHIR subscription event number always a global monotonically increasing sequence?

R5 subscription event numbering depends on channel guarantees. For channels without guaranteed delivery, it is unique and increasing within the subscription; guaranteed-delivery channels may use a relative index within the notification. Interpret gaps or repeats with the channel and subscription context, not as globally unique event numbers.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 notification content coverage

Does every FHIR subscription notification contain the complete resource content?

R5 Subscription.content can request empty, identifier-only or full-resource payloads. A notification therefore does not always carry the resource content needed for a saved evidence snapshot. Check the configured mode and actual payload; any follow-up retrieval has its own access and version context.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review

FHIR R5 event limit versus bundle entries

Does FHIR Subscription.maxCount limit the total number of entries in a notification bundle?

R5 Subscription.maxCount limits the number of events grouped in a notification. It is not a strict limit on the total number of bundle entries, because dependent resources can also be included. Count events using their event structure rather than truncating or rejecting a bundle solely by its entry count.

Documentation reviewed 2026-10-25. Primary source.

Boundaries
  • No clinical advice, patient-safety validation, legal compliance or confirmation of insurance cover.
  • No independent proof of a live access decision, completed workflow, physical action or settled payment.
  • The published R5 definition does not establish support or conformance in a buyer implementation.
  • Buyer deployment testing, live runtime enforcement, certification or permission to act
  • Expanded capabilities or licences for existing INDEX executables

Complete record JSON · Exact free preview JSON · Source review