> ## Documentation Index
> Fetch the complete documentation index at: https://medlogprotocol.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Example record

> An annotated, real MedLog record from the SEP-1 abstraction pilot in San Diego.

This is a real (de-identified) MedLog record generated during the SEP-1 abstraction pilot at UC San Diego
Health. It captures one LLM call within a multi-step sepsis quality-reporting workflow — note the shared
`run_id` linking it to the other calls in the same abstraction run.

```json theme={null}
{
  "header": {
    "medlog_version": "0.0.1",
    "event_id": "551b1676-1837-4278-988d-59ba3166b83e",
    "timestamp": "2026-01-10T05:31:19.805482+00:00",
    "system_info": "SEP-1 Abstraction AI",
    "run_id": "492dac48-dd7d-485e-8991-1325e814e73e"
  },
  "model_instance": {
    "model_id": "Llama-3.1-8B-Instruct",
    "model_version": "2024-07-18"
  },
  "user_identity": {
    "process_id": 3023
  },
  "target_identity": {
    "MRN": "XXXXXXXX",
    "CSN": "XXXXXXXX"
  },
  "inputs": {
    "prompt": "You are a CMS quality abstractor. Your task is to review patient's medical note and answer the given sepsis compliance question following the abstraction instructions. Generate clear rationale to your answer by thinking step-by-step. [...] QUESTION: Does the note contain an explicit mention that the patient has already been discharged? Do not infer under any circumstances. [...]"
  },
  "internal_artifacts": {
    "chain_of_thought": "The note does not explicitly mention that the patient has already been discharged. The note only mentions that the patient left the ICU at 0000, which implies they were transferred to another location, but does not confirm discharge.",
    "extracts": [
      "Pt left ICU at 0000"
    ]
  },
  "outputs": {
    "option": "N"
  },
  "outcomes": {
    "category": "E - In-Numerator Population"
  },
  "user_feedback": {
    "qps_analyst": "Agree, case passes."
  }
}
```

## Field-by-field

<AccordionGroup>
  <Accordion title="header" icon="fingerprint">
    The [Header](/specification/header): the protocol version, a stable `event_id`, the invocation
    `timestamp`, system info, and a `run_id` that links this call to the other LLM calls in the same
    SEP-1 abstraction run.
  </Accordion>

  <Accordion title="model_instance" icon="microchip">
    The [Model instance](/specification/model-instance): `Llama-3.1-8B-Instruct`, version `2024-07-18`.
  </Accordion>

  <Accordion title="user_identity" icon="gears">
    The [User identity](/specification/user-identity). Here the caller is an automated process
    (`process_id: 3023`) — the abstraction pipeline, not a human.
  </Accordion>

  <Accordion title="target_identity" icon="crosshairs">
    The [Target identity](/specification/target-identity): the patient, referenced by de-identified EHR
    identifiers (`MRN`, `CSN`).
  </Accordion>

  <Accordion title="inputs" icon="keyboard">
    The [Inputs](/specification/inputs): the full prompt, including the abstraction instructions and the
    specific SEP-1 compliance question posed to the model.
  </Accordion>

  <Accordion title="internal_artifacts" icon="diagram-project">
    The [Internal artifacts](/specification/internal-artifacts): the model's chain-of-thought and the
    supporting `extracts` it pulled from the note. Trace-level analysis of this field is what revealed
    the model's confusion between intra-hospital transfers and true discharges.
  </Accordion>

  <Accordion title="outputs" icon="comment-dots">
    The [Output](/specification/outputs) shown downstream: the answer `N` to the discharge question.
  </Accordion>

  <Accordion title="outcomes" icon="flag-checkered">
    The [Outcome](/specification/outcomes): the resulting SEP-1 population category for this case.
  </Accordion>

  <Accordion title="user_feedback" icon="comment-check">
    The [User feedback](/specification/user-feedback): the quality-and-patient-safety (QPS) analyst's
    adjudication — "Agree, case passes."
  </Accordion>
</AccordionGroup>

<Note>
  This record uses the protocol's conceptual field names. The [API reference](/api-reference/overview)
  defines the concrete event payloads a collector accepts (for example, `system_metadata`,
  `caller_type`/`caller_id`, and the typed `artifact` / `output` / `outcome` objects). The conceptual
  model and the wire format describe the same nine fields.
</Note>