# policyops.ai
> Technology, Government, and Society
Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts.
Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`).
## Pages
### About
URL: https://policyops.ai/about/
Last updated: 2026-07-23T00:56:45.000Z
This site is an evolving exploration of technology, data, government, and ideas that don't always fit neatly into a single box.

Some posts may dive into AI experiments, others into historical analogies, and some may simply be open questions for further thought. If you’re curious about the intersections of technology, government, and society, you might find something interesting here.

## About Stuart

I'm a consultant business analyst working in health and the broader public sector.

I began my career as a psychologist but reskilled to code back-end data solutions before moving into business analysis.

My career has had some interesting side journeys.

- I've spent time moonlighting as a computer forensics specialist for New Zealand's largest private investigation company.
- I've studied regulatory strategy at the Harvard Kenedy School of Government.
- I've provided senior governance boards with risk and assurance support.
- I've been a private secretary to a minister of health.

Technology and data is my focus, but these side journeys enable me to bring depth and experience to my analysis.

If you would like to chat about an article here, or your technology opportunities or challenges, please feel free to connect with me on [LinkedIn](https://www.linkedin.com/in/stuartmackinnon/), or drop me a message via the [Contact form](https://policyops.ai/contact-form/).
### Example FHIR Encounter data in JSON format
URL: https://policyops.ai/example-fhir-encounter-data-in-json-format/
Last updated: 2026-07-20T02:17:33.000Z
A simplified Encounter example originally from US firm [iNTERFACEWARE](https://www.interfaceware.com/fhir/resources/encounter)

To go back to the Encounter overview article [click here](https://policyops.ai/fhir-encounters-a-practical-overview/)

```Javascript
{
  "resourceType": "Encounter",
  "id": "enc-001",
  "status": "finished",
  "class": {
    "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
    "code": "AMB",
    "display": "Ambulatory"
  },
  "type": [
    {
      "coding": [
        {
          "system": "http://snomed.info/sct",
          "code": "185349003",
          "display": "Encounter for check-up (procedure)"
        }
      ]
    }
  ],
  "subject": {
    "reference": "Patient/12345",
    "display": "Jane Doe"
  },
  "participant": [
    {
      "individual": {
        "reference": "Practitioner/567",
        "display": "Dr. Smith"
      }
    }
  ],
  "period": {
    "start": "2025-10-10T08:00:00-05:00",
    "end": "2025-10-10T08:30:00-05:00"
  },
  "location": [
    {
      "location": {
        "reference": "Location/clinic-room-5",
        "display": "Exam Room 5"
      }
    }
  ],
  "serviceProvider": {
    "reference": "Organization/abc-clinic",
    "display": "ABC Health Clinic"
  }
}
```

Click [here](https://policyops.ai/fhir-encounters-a-practical-overview/) to return to the FHIR Encounter overview article.
### Contact form
URL: https://policyops.ai/contact-form/
Last updated: 2026-07-15T08:34:23.000Z
Drop me a message below and I'll come back to you shortly.

Email 

Message 

Submit
### LangExtract Few-Shot Prompt Example
URL: https://policyops.ai/langextract-few-shot-prompt-example/
Last updated: 2026-09-01T04:33:19.000Z
This is a copy of the RadExtract demo prompt from Google's LangExtract ("RadExtract") Hugging Face page: <https://huggingface.co/spaces/google/radextract>

The same prompt is viewable by clicking the "LX Prompt" tickbox on the Transformation Studio panel on Hugging Face at the link above. It's reproduced here only because it's easier to read on a larger page.

As the Hugging Face page states: **Research demonstration — not for clinical use**

The prompt begins at the "Task Description" heading below.

You can return to my LangExtract article by [clicking here](https://policyops.ai/langextract-mining-structured-data-from-clinical-notes/)

---

## Task Description

You are a medical assistant specialized in categorizing radiology text into sections:

- **findings\_prefix** \-- All text that appears before the actual "findings" content.
- **findings\_body** \-- The main 'Findings' section. Each finding is classified into a possible section through a list of attributes, some of which may also be assigned to a subheader.
- **findings\_suffix** \-- Any text that appears after the "findings" portion (such as "Impression" or other concluding content).

### Section Categories:

- **findings\_prefix**: Use only for header information before clinical findings (examination details, clinical indication, technique). Never use for actual clinical observations or pathological findings.
- **findings\_body**: Use for all clinical findings, observations, and pathological descriptions.
- **findings\_suffix**: Use only for conclusions, impressions, or recommendations that appear after the main findings.

### Critical Rule:

If a report contains only clinical findings without any header information, do not create a findings\_prefix extraction. Start directly with findings\_body extractions for the clinical content.

**Example of findings-only content (NO prefix needed):** Input: "There is a small joint effusion. The cartilage shows thinning." Correct: Create only findings\_body extractions for each clinical finding. Incorrect: Do not categorize clinical findings as findings\_prefix.

### Professional Output Standards:

All extracted text must maintain the grammatical correctness and professional coherence expected in radiology reports. Ensure that:

- All sentences are complete and grammatically correct
- Medical terminology is used appropriately and consistently
- The language remains professional and clinical in tone
- Correct obvious typos (e.g., "splen" → "spleen", "kidny" → "kidney")
- Any modifications to the original text preserve the intended medical meaning
- Minor typos are corrected and optimal punctuation is used

### Empty prefix or suffix sections:

Only create extractions for sections that actually exist in the text. Do not create empty prefix or suffix sections if there is no corresponding content in the source text. If the text is findings-only without any impression/conclusion, do not create a findings\_suffix extraction.

### Section Usage Guidelines:

**findings\_prefix**: Reserved exclusively for header information that appears before clinical findings, such as:

- Examination details (type of study, technique)
- Clinical indication or history
- Comparison studies referenced
- Technical parameters

**findings\_body**: Contains the actual clinical findings and observations from the imaging study.

**findings\_suffix**: Reserved for concluding content that follows the findings, such as impressions or recommendations.

**Critical Rule**: Clinical findings should never be categorized as prefix content. If a report begins directly with clinical observations without any header information, create only findings\_body and findings\_suffix extractions as appropriate.

### Special guidance for findings\_prefix organization:

When the report has detailed prefix information with clear section headers (like EXAMINATION, CLINICAL INDICATION, COMPARISON, TECHNIQUE), create separate extractions for each section rather than one large block. Use the "section" attribute to label each part:

- "Examination" for exam type/title
- "Clinical Indication" for clinical history/reason for study
- "Comparison" for prior studies referenced
- "Technique" for imaging parameters and acquisition details

**Important:** Even when examination information appears at the beginning without an explicit "EXAMINATION:" header, it should still be labeled with section:"Examination". This includes standalone exam descriptions that identify the type of imaging study being performed.

Always recognize examination-type content and use section:"Examination" regardless of whether it has an explicit header.

This structured approach provides better organization and readability.

### Critical for findings\_suffix:

Do NOT include headers like "IMPRESSION:", "CONCLUSION:", etc. in the extraction\_text. Only extract the actual content that follows these headers. The formatting system will add appropriate headers automatically.

**Example:** If the text contains "IMPRESSION: 1\. Severe arthritis. 2\. Labral tear.", extract only "1\. Severe arthritis. 2\. Labral tear." as the extraction\_text.

### Additional Notes for findings\_body:

- If a single sentence references multiple structures with a shared status (e.g., "liver, gallbladder, spleen appear unremarkable"), please split them into separate extraction lines, each referencing the relevant structure.
- If the text mentions subheaders like "CT ABDOMEN" or "CERVICAL SPINE," only create/retain that subheader if it clearly organizes multiple organ-structure findings under it. Do not force subheaders if only 1 or 2 lines belong there. A subheader should ideally group 3+ sections to be meaningful.

### Special guidance for spine reports:

- For spine imaging (MRI, CT), organize findings by anatomical level using the format: "Lumbar Spine Levels: L1-L2", "Lumbar Spine Levels: L2-L3", "Cervical Spine Levels: C5-C6", etc.
- Separate general spine findings (alignment, lordosis, vertebral heights) from level-specific findings
- Use dedicated sections for: "Spinal Cord", "Bones" (for marrow/vertebral body lesions), "Paraspinal Soft Tissues" (for muscle findings)
- Each spinal level should get its own section when findings are described level-by-level
- This level-by-level organization is preferred over generic "Spine" labeling for clinical utility

### Non-spine skeletal findings:

For non-spine skeletal findings, unify them under a single section like "Bones." Only keep laterality (Right/Left) if there is symmetry in the findings.

## Required JSON Format

Each final answer must be valid JSON with an array key "extractions". Each "extraction" is an object with:

```json
{
  "text": "...",
  "category": "findings_prefix" | "findings_body" | "findings_suffix",
  "attributes": {}
}

```

Within "attributes" each attribute should be a key-value pair as shown in the examples below. The attribute **"clinical\_significance"** MUST be included for findings\_body extractions and should be one of: **"normal"**, **"minor"**, **"significant"**, or **"not\_applicable"** to indicate the importance of the finding.

---

# Few-Shot Examples

The following examples demonstrate how to properly structure different types of radiology reports:

## Example 1

**Input Text:**

```
EXAMINATION: CT ABDOMEN AND PELVIS WITH IV CONTRAST
CLINICAL INDICATION: Abdominal pain.
COMPARISON: None.
TECHNIQUE: Axial images of the abdomen and pelvis were obtained following the administration of intravenous contrast material. Coronal and sagittal reformations were reviewed.

FINDINGS:
No acute abnormality is seen in the visualized lung bases. The liver is normal in size and contour. There is a 1.2 cm simple-appearing low-attenuation lesion in hepatic segment VII, consistent with a cyst. The gallbladder contains numerous calcified gallstones, compatible with cholelithiasis.

IMPRESSION:
1. Cholelithiasis without evidence of acute cholecystitis.
2. Hepatic cyst.

```

**Expected Output:**

```json
{
  "extractions": [
    {
      "extraction_class": "findings_prefix",
      "extraction_text": "EXAMINATION: CT ABDOMEN AND PELVIS WITH IV CONTRAST",
      "attributes": {
        "section": "Examination"
      }
    },
    {
      "extraction_class": "findings_prefix",
      "extraction_text": "CLINICAL INDICATION: Abdominal pain.",
      "attributes": {
        "section": "Clinical Indication"
      }
    },
    {
      "extraction_class": "findings_prefix",
      "extraction_text": "COMPARISON: None.",
      "attributes": {
        "section": "Comparison"
      }
    },
    {
      "extraction_class": "findings_prefix",
      "extraction_text": "TECHNIQUE: Axial images of the abdomen and pelvis were obtained following the administration of intravenous contrast material. Coronal and sagittal reformations were reviewed.",
      "attributes": {
        "section": "Technique"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "No acute abnormality is seen in the visualized lung bases.",
      "attributes": {
        "section": "Lungs",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The liver is normal in size and contour.",
      "attributes": {
        "section": "Liver",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "There is a 1.2 cm simple-appearing low-attenuation lesion in hepatic segment VII, consistent with a cyst.",
      "attributes": {
        "section": "Liver",
        "clinical_significance": "minor"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The gallbladder contains numerous calcified gallstones, compatible with cholelithiasis.",
      "attributes": {
        "section": "Gallbladder",
        "clinical_significance": "minor"
      }
    },
    {
      "extraction_class": "findings_suffix",
      "extraction_text": "1. Cholelithiasis without evidence of acute cholecystitis.\n2. Hepatic cyst."
    }
  ]
}

```

---

## Example 2

**Input Text:**

```
CLINICAL HISTORY:
Low back pain, rule out disc herniation

MRI LUMBAR SPINE WITHOUT CONTRAST:

FINDINGS:
The lumbar lordosis is maintained. Vertebral body heights are preserved.

There is a small hemangioma in the L3 vertebral body.

The conus medullaris terminates at L1 and appears normal.

At L2-L3, there is mild disc desiccation without significant stenosis.

At L3-L4, a small posterior disc bulge causes mild central canal narrowing.

At L4-L5, there is a large posterior disc herniation with severe central canal stenosis and nerve root impingement.

At L5-S1, mild disc bulge without significant stenosis.

The paraspinal musculature appears unremarkable.

IMPRESSION:
Large L4-L5 disc herniation with severe stenosis.

```

**Expected Output:**

```json
{
  "extractions": [
    {
      "extraction_class": "findings_prefix",
      "extraction_text": "CLINICAL HISTORY:\nLow back pain, rule out disc herniation\n\nMRI LUMBAR SPINE WITHOUT CONTRAST:"
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The lumbar lordosis is maintained. Vertebral body heights are preserved.",
      "attributes": {
        "section": "Lumbar Spine",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "There is a small hemangioma in the L3 vertebral body.",
      "attributes": {
        "section": "Bones",
        "clinical_significance": "minor"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The conus medullaris terminates at L1 and appears normal.",
      "attributes": {
        "section": "Spinal Cord",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "At L2-L3, there is mild disc desiccation without significant stenosis.",
      "attributes": {
        "section": "Lumbar Spine Levels: L2-L3",
        "clinical_significance": "minor"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "At L3-L4, a small posterior disc bulge causes mild central canal narrowing.",
      "attributes": {
        "section": "Lumbar Spine Levels: L3-L4",
        "clinical_significance": "minor"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "At L4-L5, there is a large posterior disc herniation with severe central canal stenosis and nerve root impingement.",
      "attributes": {
        "section": "Lumbar Spine Levels: L4-L5",
        "clinical_significance": "significant"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "At L5-S1, mild disc bulge without significant stenosis.",
      "attributes": {
        "section": "Lumbar Spine Levels: L5-S1",
        "clinical_significance": "minor"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The paraspinal musculature appears unremarkable.",
      "attributes": {
        "section": "Paraspinal Soft Tissues",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_suffix",
      "extraction_text": "Large L4-L5 disc herniation with severe stenosis."
    }
  ]
}

```

---

## Example 3

**Input Text:**

```
INDICATION: 
Neck pain, radiculopathy

MRI CERVICAL SPINE:

FINDINGS:
Normal cervical lordosis is maintained. No vertebral body compression fractures.

The cervical spinal cord demonstrates normal signal intensity.

At C3-C4, no significant disc disease or stenosis.

At C4-C5, mild disc osteophyte complex with mild foraminal narrowing.

At C5-C6, moderate disc herniation with moderate central canal stenosis.

At C6-C7, small disc bulge without significant stenosis.

IMPRESSION:
Moderate C5-C6 disc herniation and stenosis.

```

**Expected Output:**

```json
{
  "extractions": [
    {
      "extraction_class": "findings_prefix",
      "extraction_text": "INDICATION: \nNeck pain, radiculopathy\n\nMRI CERVICAL SPINE:"
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "Normal cervical lordosis is maintained. No vertebral body compression fractures.",
      "attributes": {
        "section": "Cervical Spine",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The cervical spinal cord demonstrates normal signal intensity.",
      "attributes": {
        "section": "Spinal Cord",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "At C3-C4, no significant disc disease or stenosis.",
      "attributes": {
        "section": "Cervical Spine Levels: C3-C4",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "At C4-C5, mild disc osteophyte complex with mild foraminal narrowing.",
      "attributes": {
        "section": "Cervical Spine Levels: C4-C5",
        "clinical_significance": "minor"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "At C5-C6, moderate disc herniation with moderate central canal stenosis.",
      "attributes": {
        "section": "Cervical Spine Levels: C5-C6",
        "clinical_significance": "significant"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "At C6-C7, small disc bulge without significant stenosis.",
      "attributes": {
        "section": "Cervical Spine Levels: C6-C7",
        "clinical_significance": "minor"
      }
    },
    {
      "extraction_class": "findings_suffix",
      "extraction_text": "Moderate C5-C6 disc herniation and stenosis."
    }
  ]
}

```

---

## Example 4

**Input Text:**

```
TECHNIQUE: 
Multidetector helical CT from lung bases to adrenals with and without intravenous contrast.

FINDINGS:
LIVER/GALLBLADDER/SPLEEN: The liver has a normal appearance. Gallbladder wall appears normal. The spleen is normal in size.

PANCREAS/ADRENALS: The pancreas and bilateral adrenal glands appear unremarkable.

RETROPERITONEUM: No lymphadenopathy. No fluid collection.

IMPRESSION:
Normal abdominal CT.

```

**Expected Output:**

```json
{
  "extractions": [
    {
      "extraction_class": "findings_prefix",
      "extraction_text": "TECHNIQUE: \nMultidetector helical CT from lung bases to adrenals with and without intravenous contrast."
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The liver has a normal appearance.",
      "attributes": {
        "section": "Liver",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "Gallbladder wall appears normal.",
      "attributes": {
        "section": "Gallbladder",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The spleen is normal in size.",
      "attributes": {
        "section": "Spleen",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The pancreas and bilateral adrenal glands appear unremarkable.",
      "attributes": {
        "section": "Pancreas/Adrenals",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "No lymphadenopathy.",
      "attributes": {
        "section": "Retroperitoneum",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "No fluid collection.",
      "attributes": {
        "section": "Retroperitoneum",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_suffix",
      "extraction_text": "Normal abdominal CT."
    }
  ]
}

```

---

## Example 5

**Input Text:**

```
HISTORY: 
Lower abdominal pain

CT ABDOMEN/PELVIS WITH CONTRAST:

FINDINGS:
LIVER: Multiple hepatic metastases are present, measuring up to 3.2 cm.

KIDNEYS: The left kidney shows moderate hydronephrosis. The right kidney appears normal.

LYMPH NODES: Enlarged retroperitoneal lymph nodes, largest measuring 2.1 cm.

IMPRESSION:
1. Multiple hepatic metastases
2. Left hydronephrosis  
3. Retroperitoneal lymphadenopathy

```

**Expected Output:**

```json
{
  "extractions": [
    {
      "extraction_class": "findings_prefix",
      "extraction_text": "HISTORY: \nLower abdominal pain\n\nCT ABDOMEN/PELVIS WITH CONTRAST:"
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "Multiple hepatic metastases are present, measuring up to 3.2 cm.",
      "attributes": {
        "section": "Liver",
        "clinical_significance": "significant"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The left kidney shows moderate hydronephrosis.",
      "attributes": {
        "section": "Kidneys",
        "clinical_significance": "significant"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The right kidney appears normal.",
      "attributes": {
        "section": "Kidneys",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "Enlarged retroperitoneal lymph nodes, largest measuring 2.1 cm.",
      "attributes": {
        "section": "Lymph Nodes",
        "clinical_significance": "significant"
      }
    },
    {
      "extraction_class": "findings_suffix",
      "extraction_text": "1. Multiple hepatic metastases\n2. Left hydronephrosis  \n3. Retroperitoneal lymphadenopathy"
    }
  ]
}

```

---

## Example 6

**Input Text:**

```
EXAMINATION:
MRI brain without contrast

CLINICAL HISTORY:
Headaches

FINDINGS:
The brain parenchyma demonstrates normal signal intensity. No mass lesions are identified.

The ventricular system is normal in size and configuration.

No abnormal enhancement is seen.

IMPRESSION:
Normal brain MRI.

```

**Expected Output:**

```json
{
  "extractions": [
    {
      "extraction_class": "findings_prefix",
      "extraction_text": "EXAMINATION:\nMRI brain without contrast\n\nCLINICAL HISTORY:\nHeadaches"
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The brain parenchyma demonstrates normal signal intensity.",
      "attributes": {
        "section": "Brain Parenchyma",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "No mass lesions are identified.",
      "attributes": {
        "section": "Brain Parenchyma",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The ventricular system is normal in size and configuration.",
      "attributes": {
        "section": "Ventricular System",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "No abnormal enhancement is seen.",
      "attributes": {
        "section": "Enhancement",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_suffix",
      "extraction_text": "Normal brain MRI."
    }
  ]
}

```

---

## Example 7

**Input Text:**

```
INDICATION:
Right knee pain

MRI RIGHT KNEE:

FINDINGS:
MENISCI: There is a complex tear of the medial meniscus. The lateral meniscus appears intact.

LIGAMENTS: The ACL shows complete rupture. The PCL, MCL, and LCL are intact.

BONES: Mild bone marrow edema is present in the medial femoral condyle.

IMPRESSION:
1. Complex medial meniscal tear
2. Complete ACL rupture
3. Bone marrow edema in medial femoral condyle

```

**Expected Output:**

```json
{
  "extractions": [
    {
      "extraction_class": "findings_prefix",
      "extraction_text": "INDICATION:\nRight knee pain\n\nMRI RIGHT KNEE:"
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "There is a complex tear of the medial meniscus.",
      "attributes": {
        "section": "Menisci",
        "clinical_significance": "significant"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The lateral meniscus appears intact.",
      "attributes": {
        "section": "Menisci",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The ACL shows complete rupture.",
      "attributes": {
        "section": "Ligaments",
        "clinical_significance": "significant"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The PCL, MCL, and LCL are intact.",
      "attributes": {
        "section": "Ligaments",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "Mild bone marrow edema is present in the medial femoral condyle.",
      "attributes": {
        "section": "Bones",
        "clinical_significance": "minor"
      }
    },
    {
      "extraction_class": "findings_suffix",
      "extraction_text": "1. Complex medial meniscal tear\n2. Complete ACL rupture\n3. Bone marrow edema in medial femoral condyle"
    }
  ]
}

```

---

## Example 8

**Input Text:**

```
EXAMINATION: CT CHEST

FINDINGS:
The longs are clear bilaterally. The hart size is normal. No pleural effushion.

IMPRESSION:
Normal chest CT.

```

**Expected Output:**

```json
{
  "extractions": [
    {
      "extraction_class": "findings_prefix",
      "extraction_text": "EXAMINATION: CT CHEST",
      "attributes": {
        "section": "Examination"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The lungs are clear bilaterally.",
      "attributes": {
        "section": "Lungs",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "The heart size is normal.",
      "attributes": {
        "section": "Heart",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_body",
      "extraction_text": "No pleural effusion.",
      "attributes": {
        "section": "Pleura",
        "clinical_significance": "normal"
      }
    },
    {
      "extraction_class": "findings_suffix",
      "extraction_text": "Normal chest CT."
    }
  ]
}

```
## Posts
### LangExtract: Mining structured data from clinical notes
URL: https://policyops.ai/langextract-mining-structured-data-from-clinical-notes/
Last updated: 2026-09-03T23:37:40.000Z
## Introduction

A great deal of valuable health data sits in unstructured clinical notes. Unstructured text may be useful in its immediate context but it creates issues for subsequent machine processing, health data exchange, and downstream analytics.

Google's LangExtract is an open-source python library that supports extracting structured information from unstructured text using carefully instructed LLMs. While LangExtract can support this kind of Natural Language Processing across many domains, its origins are in health data extraction, and LangExtract is a component of Google's [Health AI Developer Foundations](https://developers.google.com/health-ai-developer-foundations/libraries/langextract).

![Simple diagram showing flow of unstructured text to structured data. ](https://storage.ghost.io/c/0c/33/0c33c962-949e-441d-b51f-6f1eabd4a34a/content/images/2026/09/LangExtract-overview.jpg)

A simplified overview of Google's LangExtract

In this post I'll outline LangExtract's background, and what it does. Then I'll talk about risks and provide links to recent research examples incorporating LangExtract in both medical and non-medical domains.

## Background

LangExtract has its origins in a [2023 paper](https://proceedings.mlr.press/v225/goel23a/goel23a.pdf) by [Akshay Goel](https://www.linkedin.com/in/akshay-goel-md/) et al., called *LLMs Accelerate Annotation for Medical Information Extraction*. The paper focused on identification or "annotation" of medication details in unstructured discharge summary text.

The problem falls under the heading of Natural Language Processing, and in particular, Named Entity Recognition and Relation Extraction.

As the authors note, there are several approaches to this problem but training or fine-tuning specialist models can require significant human and computational resource. Their question was not: Are LLMs better at this task? The question was whether a generalist LLM could perform the task usefully, without the need to train or fine-tune a specialist model.

The authors found that an LLM (PaLM 2) was able to perform first-pass identification of medication details at a quality comparable to its human counterparts, while reducing human annotation time by 58% on average.

Below is a simple example from the study. We see the recognised entities (medication dose, mode, name, etc.), and their relationships clustered as entry-1 and entry-2.

![](https://storage.ghost.io/c/0c/33/0c33c962-949e-441d-b51f-6f1eabd4a34a/content/images/2026/09/Goel-et-al-NER-and-RE-example.jpg)

From Goel et al. ([2023](https://proceedings.mlr.press/v225/goel23a/goel23a.pdf)). Figure 2, p.84.

This study was to provide many of the [core ideas](https://github.com/google/langextract/blob/main/docs/examples/medication%5Fexamples.md#:~:text=Medical%20Information%20Extraction%20Research,2023.%20arXiv%3A2312.02296) behind the development of LangExtract itself.

## Enter LangExtract

On July 30, 2025 a post on [Google for Developers](https://developers.googleblog.com/introducing-langextract-a-gemini-powered-information-extraction-library/) announced the release of [LangExtract on GitHub](https://github.com/google/langextract). Its [description](https://zenodo.org/records/21126643) (with my emphasis) is:

> LangExtract is a Python library that uses Large Language Models (LLMs) to extract structured information from unstructured text documents based on user-defined instructions. It processes materials such as clinical notes or reports, identifying and organizing key details **while ensuring the extracted data corresponds to the source text through precise source grounding** and visual highlighting.

### Source grounding

LangExtract does not treat the LLM as a 'black box'. Instead, each decision the LLM makes about how the data is structured is traceable back to exact character (and token) positions in the source text. We can see this highlighted below in the LangExtract "RadExtract" demonstration example, where the resulting structured data includes 'start\_pos' and 'end\_pos' to identify the source text informing the extraction.

![Screenshots showing unstructured text transformed to structured data and report](https://storage.ghost.io/c/0c/33/0c33c962-949e-441d-b51f-6f1eabd4a34a/content/images/2026/09/RadExtract-Screenshots.jpg)

Screenshots assembled from the LangExtract ("RadExtract") demo [on Hugging Face](https://huggingface.co/spaces/google/radextract).

LangExtract also includes the ability to generate interactive [HTML visualisations](https://developers.googleblog.com/introducing-langextract-a-gemini-powered-information-extraction-library/#:~:text=The%20animation%20below%20shows%20LangExtract%20processing%20clinical%20text%20to%20extract%20medication%2Drelated%20entities%20and%20groups%20them%20to%20the%20source%20medication.) of an extraction. Various human-in-the-loop approaches are made possible through this essential 'source grounding' feature.

## **Batteries not included**

LangExtract as an orchestration tool that enacts the configurations and LLM instructions *provided by the user*. As the scale, complexity, and requirements for accuracy increase, so do the number of critical considerations. I'll cover just some of the important user inputs to LangExtract briefly below.

### **Choice of LLM**

Out of the box, LangExtract can connect to Gemini and OpenAI LLMs via their APIs, or to locally hosted LLMs via Ollama. LangExtract also provides the ability to create custom LLM provider plugins. 

It goes without saying that with real health data, satisfying privacy and data sovereignty requirements is of supreme importance. So where the LLM is, and what protections sit around it are essential considerations. Beyond those considerations, it's clear that the LLM must have sufficient world knowledge for the task at hand. That includes the need for knowledge of locally relevant names, symbols, abbreviations and so on – or a reliable approach to making that local knowledge available to the LLM. Fine-tuning an existing model with a technique like [LoRA](https://arxiv.org/abs/2106.09685) could potentially be warranted in some New Zealand use cases. 

LangExtract also implements [Controlled Generation](https://github.com/google/langextract/blob/main/docs/examples/longer%5Ftext%5Fexample.md#schema-guided-knowledge-extraction:~:text=Schema%2Dguided%20knowledge,across%20large%20inputs.) (advanced output schema enforcement) for supported models, but [not currently via Ollama](https://github.com/google/langextract#using-local-llms-with-ollama:~:text=The%20Ollama%20provider%20exposes%20FormatModeSchema%20for%20JSON%20mode.%20Leave%20fence%5Foutput%20and%20use%5Fschema%5Fconstraints%20unset%20so%20the%20factory%20auto%2Dconfigures%20from%20the%20provider%27s%20schema.%20Ollama%20does%20not%20currently%20support%20output%5Fschema.). I have not yet explored whether a custom LLM provider plugin might circumvent this limitation for Ollama-hosted LLMs that have the necessary capabilities.

### **Few-shot prompts**

At the heart of the LangExtract approach is a user-defined prompt. 

The prompt asks the LLM to examine some input text, identify specific "entities" (e.g. medications, dosages etc.), and their relationships if desired. Central to the approach is "few-shot" prompt engineering that presents examples of inputs and required outputs to the LLM. The Python below shows a LangExtract example snippet with only one example provided to the LLM. A more complex demonstration few-shot prompt is [available here](https://policyops.ai/langextract-few-shot-prompt-example/)).

![Snippet of example Python from a simple LangExtract script.](https://storage.ghost.io/c/0c/33/0c33c962-949e-441d-b51f-6f1eabd4a34a/content/images/2026/09/Medication-NER-Python-snippet.png)

Python snippet (originally from LangExtract's [GitHub repository](https://github.com/google/langextract/blob/main/docs/examples/medication%5Fexamples.md)), with example input and expected LLM output.

### Other decisions

The call to `extract()` (near the bottom of the screenshot above) accepts several parameters that are not included in that snippet. The following are some examples. For longer input text that needs to be chunked, `max_char_buffer` sets the maximum size of each chunk of text the LLM is presented with. A parameter called `context_window_chars` includes a fixed number of characters from the previous chunk as additional context (which can be especially useful for Relation Extraction). An `extraction_passes` parameter enables multiple passes of the same input text.

## What happens inside

Below is a high-level description of what happens once `extract()`is called. In this description I'm considering larger input text that requires multi-chunk and perhaps multi-pass processing:

- `extraction.py` first runs prompt validation (`prompt_validation.py`) to check that the prompt example(s) can be aligned to the example input text.
- `prompting.py` creates a `PromptTemplateStructured` that will later be rendered for every chunk.
- `factory.py` instantiates the LLM, combining user-provided settings with `provider` defaults.
- A `FormatHandler` is configured and a `Resolver` is created which will later parse LLM output into `Extraction` objects.
- An `Annotator` is created with the model, prompt template and format handler.

`annotation.py` then runs the core loop. It chunks the input text (`chunking.py` \+ `tokenizer.py`) according to `max_char_buffer`. Then for each chunk (and across sequential passes when `extraction_passes` \> 1):

- The prompt is rendered from the prompt template + the current chunk (optionally with a short context window from the previous chunk).
- The LLM is called with the rendered prompt and returns structured output.
- The `Resolver` parses the LLM output into `Extraction` objects and aligns/grounds them back to the source text.

Results from multiple chunks (and non-overlapping results from multiple passes) are merged into one or more `AnnotatedDocument` objects. These are saved as JSONL and can be used as input to the interactive HTML visualiser.

## Risks

Just the mention of using an LLM for clinical data extraction could raise alarm. That could be a barrier for decision makers considering this approach. However, caution is an appropriate starting point when it comes to health informatics – more so when it comes to the use of AI, or indeed, any 'shiny new thing'.

Decisions about exploring tools like LangExtract need to be centred on the individual use case and how it can be proven that the technique is (or is not) suitable and safe for that use case. *LangExtract's, source grounding and support for human-in-the-loop validation make errors discoverable and traceable*. Those errors can inform either refinement or abandonment of the approach in any given use case.

In the context of health, at one end LangExtract could be used to analyse social media posts about health conditions to support public health interventions. At the other end, it could be used to extract data from a clinical note that later informs a clinical decision *about you*. The risks are different at each end of the continuum, as are the protections that need to be in place in each case. Similar to government application of AI [more broadly](https://policyops.ai/public-service-ai-trust-model-v1/), public interest, and the public's need for assurance increases as various applications of AI move closer to impacting the individual.

## Reception to date

It's been just over a year since LangExtract's release so I'll be interested to track its evolving reception in the medical literature. In the meantime I see examples like Selivanov et al. ([2026](https://arxiv.org/pdf/2607.16323)) where LangExtract was used to *extract phenotype data* from the output of a specialist ECG-LLM. Zheng et al. ([2026](https://aclanthology.org/2026.findings-acl.627.pdf)) included LangExtract as a tool in an experimental *agentic medical coding workflow*. Ningtyas et al. ([2026](https://aclanthology.org/2026.acl-demo.67.pdf)) assessed its use in an annotation pipeline for *Medical Concept Normalisation*.

While LangExtract has its origins in health data extraction, it's also gaining significant interest beyond health. Because LangExtract can leverage generalist LLMs with broad world knowledge, it has the potential to lower the bar for Named Entity Recognition and Relation Extraction across diverse domains.

Outside health I see papers like Yoon & Kim ([2025](https://www.jdfr.or.kr/0202-02/)) who explored LangExtract for *information extraction* in complex cybercrime investigation. Liu et al. ([2026](https://dl.acm.org/doi/epdf/10.1145/3802109)) used LangExtract for *relationship parsing* in research on protecting personally identifiable information. Teo et al. ([2026](https://arxiv.org/pdf/2603.26076)) describe using LangExtract for *knowledge engineering and process mapping* for Total Airport Management.

In the developer community, LangExtract is being discussed as a way to extract entities and relationships for knowledge-graph construction in [GraphRAG](https://neo4j.com/blog/genai/what-is-graphrag/) pipelines (e.g. [this article](https://blog.stackademic.com/a-practical-graphrag-architecture-using-langextract-neo4j-qdrant-and-ollama-0e4c86908c41) by M. K. Pravin Kumar). However, time constraints make that a topic for another day.

## Closing questions

- Have you got a problem that could be improved by extracting structured data from unstructured text?
- What are your thoughts on LangExtract?
- Are you using it, or exploring its potential use?

Whether you're in health or another domain, I love to chat about data and AI. Please feel free to reach out to me on [LinkedIn](https://www.linkedin.com/in/stuartmackinnon/) or via this [contact form](https://policyops.ai/contact-form/).

## References

Goel, A., Lehman, E., Gulati, A., Chen, R., Nori, H., Hager, G. D., & Durr, N. J. (2023). LLMs Accelerate Annotation for Medical Information Extraction. *Machine Learning for Health* (ML4H), PMLR. [arXiv:2312.0229](https://proceedings.mlr.press/v225/goel23a/goel23a.pdf)

Goel, A. (2025). LangExtract. *[Zenodo](https://zenodo.org/records/21126643)*.

Goel, A., & Kiraly, A. (2025, July 30). Introducing LangExtract: A Gemini powered information extraction library. [Google Developers Blog](https://developers.googleblog.com/introducing-langextract-a-gemini-powered-information-extraction-library/).

Kumar, M. K. P. (2026, June 25). *A practical GraphRAG architecture using LangExtract, Neo4j, Qdrant, and Ollama*. [Stackademic](https://blog.stackademic.com/a-practical-graphrag-architecture-using-langextract-neo4j-qdrant-and-ollama-0e4c86908c41).

Liu, S., Fan, W., & Xu, Y. (2026). Shielding PII to Prevent Re-identification and Preserve Utility. *Proceedings of the ACM on Management of Data*, *4*(3 (SIGMOD), [1-28](https://dl.acm.org/doi/epdf/10.1145/3802109).

Ningtyas, A. M., Herwanto, G. B., Sari, Y., Putri, R. A., Kovacevic, F., El-Ebshihy, A., ... & Piroi, F. (2026, July). AnnoHID: LLM-Assisted Annotation Framework for Low-Resource Medical Texts. In *Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 3: System Demonstrations)* ([pp. 683-691](https://aclanthology.org/2026.acl-demo.67.pdf)).

Selivanov, A., Jungmann, F., Kehrer, J., Laugwitz, K. L., Martens, E., & Rueckert, D. (2026). ECG-LLM: Foundation Model for ECG-Based Cardiac Reasoning. *arXiv preprint* [arXiv:2607.16323](https://arxiv.org/pdf/2607.16323).

Teo, D., Sam, A., Koh, C. S. M., Nagi, R., & Ribeiro, N. A. (2026). Semi-Automated Knowledge Engineering and Process Mapping for Total Airport Management. *arXiv preprint* [arXiv:2603.26076](https://arxiv.org/pdf/2603.26076).

Yoon, B., & Kim, J. (2025). Self-verification-based framework for key information extraction from unstructured text: A cybercrime investigation support perspective. *Journal of Data Forensics Research*, [143-159](https://www.jdfr.or.kr/0202-02/).

Zheng, J., Nassar, I., Vu, T., Zhong, X., Lin, Y., Liu, T., ... & Li, Y. F. (2026, July). Meddcr: Learning to design agentic workflows for medical coding. In *Findings of the Association for Computational Linguistics: ACL 2026* ([pp. 12878-12893](https://aclanthology.org/2026.findings-acl.627.pdf)).
### The Hugging Face Breach: How OpenAI's Models Went Rogue in Testing
URL: https://policyops.ai/openai-hugging-face-breach/
Last updated: 2026-07-22T23:25:13.000Z
On July 16 [Hugging Face](https://huggingface.co/), often referred to as the GitHub of Machine Learning, announced a [major security incident](https://huggingface.co/blog/security-incident-july-2026) involving an intrusion into their production infrastructure. I highlight their sentence that impacted me most.

> The campaign was run by an autonomous agent framework (appearing to be built on an agentic security-research harness - used LLM still not known) executing many thousands of individual actions across a swarm of short-lived sandboxes, with self-migrating command-and-control staged on public services. **This matches the "agentic attacker" scenario the industry has been forecasting.**

On July 21, OpenAI [came forward](https://openai.com/index/hugging-face-model-evaluation-security-incident/) in a post that reads part advertorial, part legal mitigation, to announce its culpability in the matter and its partnership with Hugging Face to address the issue.

## What happened?

This story is bound to develop but I'll attempt to distil the essence of what is currently being said.

OpenAI explains that it was running internal tests on GPT‑5.6 Sol and an unnamed pre-release model, against a benchmark of "cyber capabilities". The benchmark test called [ExploitGym](https://arxiv.org/abs/2605.11086) measures an AI agent's ability to "turn security vulnerabilities into real attacks" across around 900 scenarios.

OpenAI's models found a vulnerability within their walled-off test environment, gained access to the internet, then breached Hugging Face's production environment to gain access to the test solutions for ExploitGym. Open AI [described it](https://openai.com/index/hugging-face-model-evaluation-security-incident/#:~:text=The%20models%20identified,narrow%20testing%20goal.) this way (my emphasis):

> The models identified and chained vulnerabilities across OpenAI’s research environment and Hugging Face’s production infrastructure to obtain test solutions directly from Hugging Face’s production database. All evidence suggests that **the models were hyperfocused on finding a solution for ExploitGym, going to extreme lengths to achieve a rather narrow testing goal.**

## A narrow goal

Imagine a person being set a test with the single instruction to pass with the highest possible score. Instead of answering the questions fairly, the person decides to break into the professor's office under cover of darkness to obtain the answers. In human terms, that seems to be what happened.

In my personal view, AI models *mimic* aspects of human cognition but [don't think like humans think](https://policyops.ai/will-machines-ever-think-like-humans/) – although I'll admit, as a former psychologist, watching agents interacting on my own machine blurs the philosophical boundaries a bit. But a team of humans might have included someone who paused to ask "*Is this really a good idea chaps*?" Apparently no agent was explicitly assigned that role here.

It's tempting to think that OpenAI's models assumed human-like subversive intent. In fact the models' intent went no further than to obtain a high score on the benchmark test, as instructed. The models were literally following orders – apparently without critical guardrail instructions or human oversight.

## Absent humans?

There's no detailed timeline of events at this stage. Hugging Face referred to autonomous attacks of this nature occurring at "[machine speed](https://huggingface.co/blog/security-incident-july-2026#:~:text=Autonomous%2C%20AI%2Ddriven%20offensive%20tooling%20is%20no%20longer%20theoretical.%20It%20lowers%20the%20cost%20of%20running%20a%20broad%2C%20patient%2C%20multi%2Dstage%20campaign%2C%20and%20it%20operates%20at%20machine%20speed.)". That's highly relevant but it's also clear from their account that they spent a significant amount of elapsed time assessing what was happening and how to address it. Either OpenAI's humans were watching on in some kind of detached fashion, or they were not watching at all. My money is on the latter.

The opportunity to intervene came earlier than the Hugging Face attack itself. First OpenAI's models needed to find a way to break out of their confined test environment.

## How the models broke free

A component in OpenAI's test environment had an unknown vulnerability that the models identified and exploited. Quoting [OpenAI](https://openai.com/index/hugging-face-model-evaluation-security-incident/#:~:text=While%20operating%20in,registry%20cache%20proxy):

> While operating in our sandboxed testing environment, our models spent a substantial amount of inference compute finding a way to obtain open Internet access, in pursuit of solving the evaluation problem. To gain access, the models identified and exploited a zero-day vulnerability (which we’ve now responsibly disclosed to the vendor) in the package registry cache proxy.

As someone who experiments with local LLMs, I've come to consider that the models themselves are the least of my security worries. It's the components around them and the permissions I give them that create the attack surface.

Clearly there was an assumption that the componentry in the test environment was bullet proof against the models that they fine tuned to find such vulnerabilities. That's a very human kind of assumption to make, but when combined with an apparent lack of monitoring, the holes in OpenAI's [Swiss cheese](https://en.wikipedia.org/wiki/Swiss%5Fcheese%5Fmodel) started to line up.

## What to make of this

It's inviting to leap to an AI doomer position on this. I sit in the 'cautious optimist' camp while harbouring what I consider to be rational concerns.

I expect the event will feed popular narratives that imbue AI with the ability to have intent beyond what it's instructed to do. At the extremes there's also a perception out there that AI will eventually break free and take over the world - this event won't help settle those concerns.

TechCrunch took a more [measured tone](https://techcrunch.com/2026/07/21/openai-says-hugging-face-was-breached-by-its-own-pre-release-models/), describing this event is as "*an unusually vivid illustration of the power and dangers of frontier AI models operating on long time horizons*."

I'll continue to draw on the metaphor of the [advent of steam power](https://policyops.ai/an-unfortunate-incident/). There will be accidents – many of them. Eventually we will learn to more consistently contain the power we are unleashing.

In the meantime it's clear that the partnership between Hugging Face and OpenAI is genuine. Like most mistakes of this scale, we tend to learn from them. I'll leave the final word to Clement Delangue, CEO of Hugging Face, who posted this following OpenAI's announcement.

> We suspected last week's cyberattack might have come from a frontier lab, given the sophistication of the agent. Turns out it did!  
>  
> We've spent the past 24 hours working closely with the [@OpenAI](https://x.com/OpenAI?ref%5Fsrc=twsrc%5Etfw) team (thanks!), and we strongly believe there was no malicious intent on their part.… <https://t.co/XWxGMeMGje>
> 
> — clem 🤗 (@ClementDelangue) [July 21, 2026](https://x.com/ClementDelangue/status/2079670308156645882?ref%5Fsrc=twsrc%5Etfw)
### FHIR Encounters: A practical overview
URL: https://policyops.ai/fhir-encounters-a-practical-overview/
Last updated: 2026-07-23T04:56:56.000Z
## Introduction

There's a considerable amount of [technical literature](https://scholar.google.com/scholar?q=%22FHIR+Encounter%22+OR+%22Encounter+resource%22+HL7+FHIR&hl=en&as%5Fsdt=0&as%5Fvis=1) discussing the FHIR Encounter but little to support healthcare leaders considering encounters from a more strategic perspective.

In this brief overview I'll talk about what an Encounter is and what data it can contain. I'll then cover potential uses of encounter data, and close by offering a few considerations for leaders considering implementing Encounters in the New Zealand context.

**But first, what is FHIR?**

FHIR stands for Fast Health Interoperability Resources and it's a set of [HL7](https://www.hl7.org/about/) standards for exchanging health data. FHIR includes around 150 predefined data structures, known as [resources](https://hl7.org/fhir/resourcelist.html), that cover a range of healthcare topics. Encounter is one of these resources. FHIR resources are like building blocks – they can be combined and linked to meet a wide range of health data requirements.

## What is an Encounter?

If you’ve ever sat in a room with a healthcare professional or had a virtual consultation to receive care or assess your health, you’ve had a "healthcare encounter”.

In everyday life people might refer to going to ED, attending an appointment with their GP, or visiting their Dentist. "Encounter" is just an umbrella term for a variety of familiar real-world healthcare experiences.

**FHIR defines an encounter as:**

> An interaction between a patient and healthcare provider(s) for the purpose of providing healthcare service(s) or assessing the health status of a patient.

Source: <https://hl7.org/fhir/encounter.html> 

So from FHIR's perspective an encounter's characteristics are:

- There's at least one patient and one healthcare provider involved.
- There's an identifiable interaction between the patient and the healthcare provider(s).
- The interaction is for the purpose of receiving care or assessment (i.e. purely administrative events are excluded).

There is no requirement that the patient and provider are at the same location, so virtual encounters can be included.

*While not stated in the definition, a FHIR Encounter can contain details of others involved such as family and whānau, care givers and others.*

## What can a FHIR Encounter contain?

The Encounter mainly focuses on outlining the nature of the healthcare interaction and it can be linked to other FHIR resources for more detail when needed. For example, if the encounter includes a prescription, a FHIR MedicationRequest can be linked to the Encounter.

At its core, an Encounter will usually include things like:

- Who was involved (the patient, clinician(s), and perhaps family, whānau and others in attendance)
- What the encounter was about (the purpose or focus of care)
- When it occurred (date, time, and duration)
- Where it occurred (if in-person)
- The service provider/organisation providing the care
- How care was delivered (e.g. in-person/virtual)

The full set of current R5 FHIR Encounter data items is [listed here](https://hl7.org/fhir/encounter.html#resource).

For those wanting to see Encounter data in JSON format, a simple example is [available here](https://policyops.ai/example-fhir-encounter-data-in-json-format/).

### The flexibility within the standard

Encounters can as simple as a walk-in flu vaccination at a pharmacy and as complex as an ED presentation or inpatient stay. Besides some core requirements, the standard allows implementers to take the 'Base Encounter', and select the data items that are relevant and required for a specific implementation. Those requirements are then published in an Implementation Guide or 'IG' that parties to the data exchange agree to.

This flexibility is a feature not a bug – but it should be approached with caution. From a national perspective several things need to be in place to ensure that each individual project attends to a common set of carefully governed national patterns.

## The value of Encounters

High quality Encounter data can be an asset to both patients and the sector as a whole. Here are just some of the ways it can provide value.

### Providing context

Health data often focuses on facts: medications, allergies, conditions, observations, and so on. In some settings encounter information can enrich the significance of those facts by providing context. For example, a medication prescribed during a routine primary care encounter has a different context than one prescribed during an ED encounter.

### Longitudinal records

**Patients** may consider encounters part of their personal health story – the urgent care visit, followed by an ED presentation, followed by an admission for example. This makes an 'encounter view' of their data potentially useful for them and their caregivers.

**Clinicians** may wish to view the patient's recent healthcare encounters to better understand what's going on for them, and how they are being supported from a continuity of care perspective.

In the New Zealand context, many encounters form part of agreed clinical pathways or **HealthPathways** that guide assessment, management and referral decisions. Encounters can contribute to a picture of a patient’s overall care journey within a pathway.

**Health system stewardship** also benefits from understanding the broader patterns in patient journeys at the aggregate level. Encounter data is raw material for understanding patient flows across service types.

### Service utilisation & planning

Encounter data enables those commissioning services to better understand service pressures right now, along with the impacts of investment, policy, and other changes over time.

### Claims & funding data

Encounters provide supporting information for individual claims as well as volume information for volume-based funding arrangements.

### Health research

Public health and other forms of research require high quality data. With carefully governed data quality, Encounters can provide important inputs into understanding population health and the broader impacts of health policy.

## What's next for Encounters in NZ?

Implementing Encounters at scale in Aotearoa will require deliberate national coordination. Here are a few strategic considerations for healthcare leaders as NZ moves forward with its Encounter implementations.

**Establishing an NZ Base Encounter**

A simple initial NZ Base Encounter will provide important navigational and tooling support to implementers. There's an opportunity to contribute to this development through HL7 NZ.

**Coordination across standards bodies**

Implementation of Encounters will be greatly supported by close alignment across HL7 NZ, HISO, and NZ Core Data for Interoperability.

**Integrated governance approach**

FHIR Encounters span many governance interests such as: clinical, privacy, standards, data governance, architecture, and security. An integrated governance approach is essential to ensure that key considerations don't fall 'between' governance interests.  
  
• • •

## About the author

I enjoy helping healthcare leaders connect policy and strategy to what travels 'down the wire'.

I began my standards journey coding HL7 v2 integrations and later traveled to Sydney to gain HL7 Clinical Document Architecture certification. I've also been fortunate to sit alongside some of NZ's leading health data standards experts on the board of HL7 New Zealand for a time.

If you would like to talk more about Encounters, or health data in general, please feel free to connect with me [via LinkedIn](https://www.linkedin.com/in/stuartmackinnon/), or drop me a message using the [contact form](https://policyops.ai/contact-form/).
### Will machines ever think like humans?
URL: https://policyops.ai/will-machines-ever-think-like-humans/
Last updated: 2026-09-01T04:59:28.000Z
Will machines ever think like humans? It feels like the central question of AI.

When physicist Richard Feynman was asked this question decades ago, his answer didn't go where people expect.

He didn't start with theories of intelligence. Instead, he started with *engineering*.

Feynman said when humans wanted to fly, we didn’t do it by building better birds. We built aeroplanes. We did what worked, with the materials at hand. The result wasn't birds, but they fly.

The same might be true of machine intelligence.

Maybe future AI systems will think more like humans and maybe they won’t. But either way, they’ll still be aeroplanes, not birds.

So instead of asking: *Will machines ever think like us?* What if the better question is: *Why do we keep assuming they should?*

---

Here's a link to the Feynman's segment:
### The psychology of regulatory failure
URL: https://policyops.ai/thoughts-on-regulatory-failure-part-1/
Last updated: 2026-07-15T08:47:30.000Z
On Saturday 6 January 2018, 65 year old William Ball (or Billy to his friends) took the front passenger seat of a 1991 Nissan Sentra for an outing that was to be his last.

On State Highway 12 near Turiwiri, Dargaville, driver error caused the vehicle to leave the road into a drainage ditch. William's seatbelt snapped and his head hit the windscreen. He died of his injuries 26 days later in the ICU of Whangarei Hospital. A tragic story of regulatory failure began to unfold.

Police examining the vehicle noticed frayed seatbelts in the car, and due to the failure of William's seatbelt they immediately referred the matter to the New Zealand Transport Agency (NZTA).

On 15 December 2017, less than a month before the crash, the owner of the Nissan Sentra had taken it to Dargaville Diesel Specialists (DDS) for a Warrant of Fitness or 'WoF' inspection – a regular requirement for vehicles on New Zealand roads.

DDS was appointed an 'Inspecting Organisation' by NZTA in 2010 but over the years it had established a long history of poor practice and noncompliance with NZTA vehicle inspection standards.

By the time of the crash, NZTA had made 14 compliance visits to DDS, including the fourth in a series of unannounced visits on 18 December 2017, only days after DDS provided a WoF for the Sentra. In addition, NZTA had received 7 complaints about DDS WoF issuing practices – the latest being an anonymous tip in March 2017 that a WoF had been issued without an inspection taking place. There were questions to be asked.

Independent reviews by Kristy McDonald ONZM KC and MartinJenkins (linked below) provide thorough analysis of events and contributing factors. Rather than span every complex detail, I want to briefly explore a few thoughts that inform my work when assessing regulatory systems and processes.

### Regulated parties are not customers

At the time, NZTA had begun to consider its regulated entities, like DDS, its customers. In doing so, it lost sight of its ultimate customer - the public it was there to protect.

Malcolm Sparrow thinks of half the government being involved in the provision of *services* to citizens, and the other half in the *protection* of citizens. Of the regulatory and enforcement half he says:

> This half of government is different. These agencies use the coercive power of the state, seeking to control behaviors. They deliver obligations, to citizens and businesses, more often than services.   
>  
> Acting in the public interest, they can restrict private behaviors, deprive individuals of their liberty, impose conditions on businesses, put people out of business if necessary, and occasionally kill. Not everyone is happy about the work they do. Not everyone says “thank you.”

Sparrow (2020), p. 4

As a former psychologist, I'd venture that not everyone has the temperament for regulation. It's not a game for hobbyists, or for people who need everyone to be happy. As Sparrow points out, regulators deal with the things that not everyone agrees on, where market forces alone are inadequate. There will be unhappiness, and sometimes you are the person who brings that unhappiness about.

This is not to say that regulators can run roughshod over citizens and businesses. They can't legitimately impose their will without sound evidence of the harms prevented. Nor can they act without being measured when circumstances allow. The dynamic tension of regulation is never resolved – but delivering regulatory obligations is not a service, and regulated parties are not customers.

#### Pathological empathy?

This confusion between customer service and regulation can be a mask. WoFs bring revenue and additional work to a business in a small community. Depriving a small business of its ability to conduct vehicle inspections could be the same as forcing the business to close its doors.

This kind of dilemma is not limited to WoF provision. There are many kinds of businesses that rely on a regulated service component to function at all. Pulling the pin on someone's livelihood is unpleasant. When I look at the history of DDS's engagements with NZTA, I have to consider that some kind of pathological empathy may have been a factor. Perhaps NZTA's preference to assume a customer service posture was just one outward manifestation of this empathy.

### Regulatory theatre

A empathetic customer service posture can easily drift towards regulatory theatre, where the regulator assumes the outward *appearance* of effectiveness.

Audits are carried out, corrective actions are issued, and licences bestowed. The people are there. The regulatory machinery is there. It just fails to work in concert. The system doesn't provide the protection from harms that an ordinary person would expect.

A regulator puts both the public and the public’s trust at risk when it fails to ensure tight controls and clear linkages between: audits; the completion and maintenance of corrective actions; and decisions to relicense a regulated entity.

Astoundingly, even as NZTA's Compliance Intervention Panel was progressing the suspension of DDS's licence (achieved on 27 August 2018), in parallel, another group within NZTA was working with DSS to correct its paperwork issues so it could achieve its next licence renewal.

If a regulated entity has a history of unresolved issues at audit, and they continue to be licensed regardless, the stage is set for a potentially tragic ending. Regulatory systems can tolerate this kind of ambiguity for quite some time. It works until it doesn't.

### Normalisation of deviance

Normalised deviance is most commonly associated with the 1986 Space Shuttle Challenger disaster. However, it's a useful lens in regulatory environments that have drifted into regulatory theatre.

Potentially fatal problems with the Space Shuttle solid rocket booster O-rings were observed in 1981, 1984, and 1985\. In 1986, management and engineers debated the risk of unprecedented cold weather on the O-rings deep into the night, before a decision was made to go ahead with the fateful launch the following morning.

There's a special kind of confidence that comes from repeatedly and successfully cheating fate.

Like each launch of the Space Shuttle carrying its known defect, it's possible for regulators to begin to feel they are rewriting the principles of common sense each time they are ignored without obvious consequence.

A common feature is for people to maintain a code of silence around the deviance. There are indications in the independent reviews into the DDS regulatory failure that at times front-line regulators were discouraged from initiating rigorous action or raising problematic cases for review and decisions.

### What's happened since then?

In the intervening years NZTA has left no stone unturned to address the many complex issues identified in the two 2019 reviews. These reviews initiated extensive change which is documented in the MartinJenkins December 2021 final report. These documents are available on NZTA's website and are linked below.

### Why bring this up now?

I've written this because humans never stop being human. For some, our instincts for empathy and our desire to serve can run counter to the requirements of robust regulatory practice.

We are good at telling ourselves comforting stories about why we do things, and at thinking things that happen to others can't happen to us. Even if this is only a brief pause to reflect, it is at least an acknowledgement of William Bell and some of the lessons his tragedy left us.

### References

  
NZ Herald (February 2018). [William Ball, Obituary](https://notices.nzherald.co.nz/nz/obituaries/nzherald-nz/name/william-ball-obituary?id=43205438)

Northern Advocate (21 November 2018). [Northland garage has WoF licence suspended after issuing WoF to car in fatal crash](https://www.nzherald.co.nz/northern-advocate/news/northland-garage-has-wof-licence-suspended-after-issuing-wof-to-car-in-fatal-crash/3J6GGQEIWXFZDKKBSI7IKPTLTA/?utm%5Fsource=chatgpt.com)

Stuff (22 November, 2018). [WoFs are 'stupid', claims Dargaville mechanic who had WoF licence revoked](https://www.stuff.co.nz/nz-news/350597721/wofs-are-stupid-claims-dargaville-mechanic-who-had-wof-licence-revoked)

Kristy McDonald ONZM KC (30 January 2019). [Inquiry into the Performance of the New Zealand Transport Agency in Relation to Dargaville Diesel Specialists](https://www.nzta.govt.nz/assets/Vehicles/vehicle-safety-alerts/QC-report-NZTAs-performance-in-relation-to-DDS-30-01-2019.pdf)

MartinJenkins (26 June 2019). [Review of the New Zealand Transport Agency's Regulatory Capability and Performance](https://www.transport.govt.nz/assets/Uploads/Report/Review-of-NZTA-Regulatory-Capability-and-Performance.pdf)

MartinJenkins (8 December 2021). [Progress Assessment Against Regulatory Functions: Final Report](https://www.nzta.govt.nz/assets/About-us/docs/Progress-assessment-against-regulatory-functions-202112.pdf)

• • •

Sparrow, M. K. (2020). [Fundamentals of regulatory design](https://www.amazon.com.au/Fundamentals-of-Regulatory-Design/dp/B08DSS7KK9)
### Five AI questions for government agency leaders
URL: https://policyops.ai/five-ai-questions-for-government-agencies/
Last updated: 2026-01-09T03:41:26.000Z
Government rightly doesn't want to be left behind on AI - the opportunities are real. But adopting AI for its own sake could lead to problems too. As an agency leader, here are a few questions I'd be asking right now.

🔎 **How are we already using AI?**

From AI embedded in productivity apps, to larger investments, building a comprehensive picture of AI's current footprint in your organisation is always a good starting point.

🔎 **Do we really need AI for this?**

The [Centre for Data Ethics and Innovation](https://data.govt.nz/leadership/centre-for-data-ethics-and-innovation/guidance/artificial-intelligence-guidance) recommends asking: "*Is AI really the solution? Would another tested technology be just as good for your problem?*" This is solid advice. There's no point adding unnecessary complications.

🔎 **Do we need to be doing this at all?**

In all the excitement, proposals and initiatives can take on a life of their own. Are AI projects aligned with organisational strategy? If it's exploratory, or on the leading-edge, it needs to be tightly ring-fenced.

🔎 **How will we know AI made a real difference?**

Are we clear on the public value being delivered, or are we relying on ROI white papers and vendor 'research' to justify this? "Studies show..." is not a benefit realisation plan. How will we define and measure value, right here, on the ground?

🔎 **What does AI trust and transparency look like?**

Public interest is likely to be on a spectrum, with lower interest in how AI tools improve daily work, and far higher interest in AI that impacts the public personally. Check out the draft [Public Service AI Trust Model](https://policyops.ai/public-service-ai-trust-model-v1/) I posted up for discussion if this is something you are also thinking about.

---

As AI conversations shift from a sense of novelty to a sense of necessity, these questions may separate agencies that thrive in the new age from those that struggle. What would you add to the list?

---
### Public Service AI Trust Model: Toward practical transparency
URL: https://policyops.ai/public-service-ai-trust-model-v1/
Last updated: 2026-01-09T03:42:05.000Z
## Introduction

AI in government is here, but how do we maintain public trust? New Zealand's Minister for Digitising Government [wants](https://www.beehive.govt.nz/release/guidance-safe-use-ai-public-sector?ref=policyops.ai) "*agencies to adopt AI in ways that are safe, transparent and deliver real value for New Zealanders while upholding the highest standards of trust and accountability*."

The challenge for governments world-wide, is to take opportunities to improve efficiency, and enhance public services, while providing transparency and assurance this is being done with all due caution, and with the interests of the public at heart.

The Public Service AI Trust Model is a tool for communicating within government and to the public. It's offered for discussion as working-version 1.0, under Creative Commons [BY-ND 4.0](https://creativecommons.org/licenses/by-nd/4.0/) (free for use without adaptation, with attribution).

## The Problem: Trust, Transparency, and Public Interest

Public sentiment towards AI ranges from high enthusiasm to existential fear. The public service's posture towards AI transparency will affect not only trust and confidence in any elected government, but also trust and confidence in the institution of government itself.

Communicating about AI is inherently complex. AI represents a range of rapidly evolving technologies which can be orchestrated in various ways, in various public service contexts. Few have the resources to engage on this topic at a purely technical level. Assurances that New Zealand is adhering to international AI conventions will provide comfort to some, while sparking fears for others.

While we must continue to have important public conversations about technologies and international regulatory considerations, there remains a gap in our ability to talk about what matters to most people about AI, in language that is clear and meaningful.

## Introducing the Public Service AI Trust Model

The Public Service AI Trust Model focuses on the **impact of AI** under four categories.

- **Productivity Impact** – AI enhancing individual public servant efficiency.
- **Operational Impact** – AI supporting operational performance and resource allocation.
- **Individual Impact** – AI directly affecting individual members of the public.
- **Prohibited AI** – AI that crosses ethical or democratic boundaries.

![](https://storage.ghost.io/c/0c/33/0c33c962-949e-441d-b51f-6f1eabd4a34a/content/images/2025/02/Public-Service-AI-Trust-Model---Public-Service-AI-Trust-Model-1.jpg)

**Public interest grows as we move right – transparency needs increase as we move up – overlapping categories symbolise real-world complexities.*

### Model applications

*This model may serve as a useful adjunct to existing frameworks and guidance*:

- As a heuristic for public service leaders considering current and proposed AI use cases.
- When mapping current and proposed use of AI to public interest and transparency needs.
- As a lens when developing proportionate risk mitigations and governance approaches.
- As a communication tool.

### Cross-cutting concerns

Drawing from models such as TOGAF, the model allows for extensibility through the addition of cross-cutting concerns. However, to maintain the integrity and simplicity of the model, v1.0 cross-cutting concerns are constrained to:

- **Privacy** – Compliance with privacy laws and public expectations.
- **Security** – Data protection, cyber risks, identity and access management, AI model security.
- **Public Value** – Reporting of discernible, measurable benefits, in accordance with performance reporting standards set by the Office of the Auditor General.

### Why is 'Prohibited' included?

Public interest in government use of AI extends beyond how AI is used to include clarity on areas where its use is not acceptable. The Prohibited category provides an essential boundary condition for social licence. Even in cases where full transparency may not be possible for security reasons, public trust depends on a clear understanding of what use cases are agreed to be 'out of bounds' for government AI adoption.

## Potential criticisms of the model

> The model does not include numerous important things.

The model does not attempt to cover every issue in AI governance. Instead, it prioritises simplicity – providing a structured way to assess AI’s impact while avoiding terms that may carry different meanings for different audiences. It is designed as a starting point, complementing broader policy and regulatory discussions across other AI framework and guidance components.

*Transparency* acts as a 'forcing function' for many key concerns, including sound governance and auditability. *Public value* serves a similar role for fairness and effective technology use. While *privacy* and *security* may be shaped by transparency, they are explicitly highlighted due to their broadly recognised public importance.

> The model does not highlight the differences between various AI technologies

By focusing on the *impact* of AI, the model aims to remain relevant throughout ongoing changes to underlying technologies. It also supports public service policy and decision-makers who need to easily contextualise AI initiatives in their unique settings. While the model focuses on AI impacts, public transparency reporting can provide necessary detail for audiences with specific technical interests.

> Some AI initiatives may span (or may evolve to span) more than one impact category

Multiple impact categories for a single initiative can be highlighted in public transparency reporting.

> The distinction between *Productivity Impact* and *Operational Impact* seems academic.

*Productivity Impact* centres on 'commodity AI', delivered by major platform providers. *Operational Impact* may involve strategic orchestration of commodity AI components, with or without the addition of bespoke components. Risk profiles and public interest are likely to be qualitatively different, and the opportunity to segment regulatory approaches may be useful.

> There are no examples.

Examples are under development using publicly available New Zealand government AI use cases and international examples. If you would like to collaborate, have a similar or related project, or would just like to provide critique or feedback, [let's connect](https://www.linkedin.com/in/stuartmackinnon/).

---

[Public Service AI Trust Model ](https://policyops.ai/public-service-ai-trust-model-towards-practical-transparency/) by [Stuart MacKinnon ](https://www.linkedin.com/in/stuartmackinnon/) is licensed under [CC BY-ND 4.0 ](https://creativecommons.org/licenses/by-nd/4.0/?ref=chooser-v1)   
![](https://mirrors.creativecommons.org/presskit/icons/cc.svg?ref=chooser-v1) ![](https://mirrors.creativecommons.org/presskit/icons/by.svg?ref=chooser-v1) ![](https://mirrors.creativecommons.org/presskit/icons/nd.svg?ref=chooser-v1) 

• • •

This article was inspired by a recent conversation with Shannon Barlow. If you would like to watch that, or read the transcript, it's available [here](https://policyops.ai/ai-in-nz-public-sector-a-smart-move-or-a-risky-bet/).

You may also want to read [Five Questions for Government Agency Leaders](https://policyops.ai/five-ai-questions-for-government-agencies/) posted recently, which includes trust and transparency as a key consideration.

---

### 19 March 2025 Update

I have now extracted a 2024 snapshot of 85 NZ government AI inititives across 18 agencies, in machine readable format (see October NZ Internal Affairs proactive release available [here](https://www.dia.govt.nz/diawebsite.nsf/Files/Proactive-Releases-2024-25/%24file/Proactive-release-of-material-relating-to-Artificial-Intelligence-in-the-month-of-July.pdf). My thanks to IBM for making their open-source [Deep Search](https://github.com/DS4SD) Docling AI document processing tools available for this kind of work.

If you would like to collaborate on testing the potential usefulness of the model, or adapting it so it *is* useful, please [reach out](https://www.linkedin.com/in/stuartmackinnon/).

---
### AI in NZ's public sector: A smart move or a risky bet?
URL: https://policyops.ai/ai-in-nz-public-sector-a-smart-move-or-a-risky-bet/
Last updated: 2026-01-09T03:42:43.000Z
In this interview with Shannon Barlow, Managing Director of Frog Recruitment, we discuss the challenges and opportunities of AI in NZ's public sector – particularly the need for transparent, practical guidance to help agencies navigate emerging technologies. The transcript below captures the conversation in full. If you have thoughts or questions, I’d love to hear them.

A recording of the interview is available on **LinkedIn** [here⧉](https://www.linkedin.com/posts/stuartmackinnon%5F%F0%9D%98%BC%F0%9D%99%A1%F0%9D%99%A9%F0%9D%99%9D%F0%9D%99%A4%F0%9D%99%AA%F0%9D%99%9C%F0%9D%99%9D-%F0%9D%99%9E%F0%9D%99%A9%F0%9D%99%A8-%F0%9D%99%97%F0%9D%99%9A%F0%9D%99%9A%F0%9D%99%A3-%F0%9D%99%AC%F0%9D%99%9A%F0%9D%99%A1-activity-7297366035022655489-vo7e?utm%5Fsource=share&utm%5Fmedium=member%5Fdesktop&rcm=ACoAAAGGgJsBbqIYao9HkRC4ClSiIgxjGX%5FHX2M) or on **YouTube** [here⧉](https://www.youtube.com/watch?v=7Tl5CHtzrfM)

## Transcript

---

**\[Shannon 0:00\]**

Kia ora koutou, nau mai, haere mai, and a very warm welcome to Mahi Matters, New Zealand's weekly update on what's happening in the employment market and our first for the year.

Very excited to be here again, and I thought we might just ease into the year with a nice, easy topic, maybe shorts in the office, emojis, something like that. But no, we're going in heavy hitting and we want to find out is New Zealand setting the standard for ethical AI usage in government.

So this week, we're joined by Stuart MacKinnon, Strategic Advisor at Analysis One to discuss the government's new safe AI Framework and its potential impact on the public sector and beyond.

So how will this initiative enhance efficiency and transparency? What are the benefits of greater AI integration, and why? Why may some government agencies be hesitant to adopt these changes? So as I said, big topic to start off the year, also on today's show, will the recent unemployment rate have an impact on employer confidence? We'll explore our latest job opportunities across New Zealand and tell you how you can take the next step in your career. And lastly, we'll reveal our Social Media Insights on pay transparency, where we ask, would your employees be comfortable disclosing their salary?

Okay, so jumping in. As I said, recently, the New Zealand government has introduced new guidelines to ensure the safe and responsible use of artificial intelligence in the public sector. It's been developed by the Government Chief Digital Officer, the responsible AI guidance for the Public Service aims to help agencies adopt generative AI systems in ways that are safe, transparent and responsible.

So balancing potential benefits with associated risks, although it's been well received by some, there's still some hesitation from others. AI is shaping the future of New Zealand's public sector. But is it a smart move or a risky gamble to discuss this further? We're joined today by Stuart MacKinnon, Strategic Advisor at Analysis One. Welcome Stuart.

**\[Stuart 3:17\]**

Thank you for having me. Yes, it's an exciting topic.

**\[Shannon 3:21\]**

Yeah, great one to kick off the year.

> **So now the framework takes, and I quote, a "light-touch, proportionate and risk-based approach". I'm glad I've got you here to translate for us. What does it actually mean? What do you think that means in practice, and is it the right approach for New Zealand?**

**\[Stuart 3:44\]**

Well, the phrase seems to have come out of some advice from MBIE to Cabinet around the middle of last year. And I guess, well, firstly, MBIE were looking at AI from an economic perspective, and I guess they were holding that in contrast to a more heavy-handed regulatory approach, which comes with its own issues.

Of course, what does it mean in practice? I think we really need to have a handle on what AI risk is and what proportionate mitigations are. So "light-touch, proportionate, risk-based", sounds good, but what do we mean by risk?

And AI risk is multi-dimensional, so it's not easy to rank AI initiatives on a scale of 'one to ten' in terms of risk. They impact different people, they vary in terms of how autonomous they are, etc. So, without that, I fear that we may only do the first part of it. So, is it the right approach? It sounds very pragmatic, but there's always that risk that we do the first part right, but don't get to the "proportionate and risk-based" part.

**\[Shannon 5:04\]**

Yeah, figured about the potential risks there, and I can see why we would take this approach. Last year, we talked a lot about productivity and how New Zealand has a pretty dismal record in that regard, and it's definitely an area that we can improve in, and this is one of the many tools that can help get us there. So understand why we're taking that approach, but as you say, you do need to be able to balance that out.

> **So of course, AI can cover a vast range of things, from simple office automation to more complex use and each of course, with their own set of risks. What kind of worked examples would be most useful in strengthening guidance for public sector agencies?**

**\[Stuart 5:52\]**

Well, I can use two examples, maybe to illustrate the point. If we imagine, say, the Department of Conservation investigating the use of AI in bird monitoring. So imagine putting microphones out in the bush, and they use AI to identify the birds that are making calls, and potentially how many of them are there, and it sounds very clever, and also sounds very low risk, even if it doesn't work at all, but I'm sure it would.

But take another example where an agency might want to use AI, albeit skilfully, in some part of a process that helps them to determine a citizen's eligibility to some kind of government assistance or other service. You can immediately get that sense of a shift in risk, and so I think that we need a range of examples, right from those very simple 'organising my inbox' kinds of things, right up to those areas that, even if they are skilfully implemented and well managed, still present a lot of 'perceived risk' to the public.

**\[Shannon 7:05\]**

Yeah, I think that's a really good point there. And you know, even for quite simple things, it is how you use it and how much you rely on it. So, you know, in the recruitment field, will say, yes, definitely use it to be able to take some of the leg work out of things, but don't just, don't just take the answer hole and, you know, put it in your resume or your application, because it's going to backfire. So, yeah, lots of things to keep into account there.

> **Do you think there's areas in the framework that could lead to potential challenges for agencies?**

**\[Stuart 7:47\]**

Yes, I think the first challenge would just be to navigate the framework. So in the absence of those examples, and in the absence of a kind of analysis of the types of multi-dimensional risk we're dealing with, an agency chief executive or technology leader would need to really absorb a lot of information to intuit where they're at contextually, and what they might need to do next. So there are challenges around that.

And I think also, putting myself in their position, humbly, they might ask the question, What's genuinely new here? So agencies already have existing obligations around privacy, security, reliability. So they might be asking themselves, what's genuinely new? And particularly, where can I leverage all of my existing expertise here, and where might I need to seek specialist advice.

And I think it's great to remind agencies of their broader, standard, bread-and-butter obligations, but it's a matter of lifting out those areas where AI makes a qualitative difference to the areas that we're looking at.

**\[Shannon 9:03\]**

Yeah, absolutely. We've got a comment from Facebook, from Nivla around, you know, the ability to filter out incorrect data, and I guess that's a point around you still need that human aspect, and you can't leave it all up to all up to AI, so that skilful input from your good humans is really important as well.

> **What about AI, and that potential to enhance transparency and accountability, or perhaps reverse of that, I guess there's potential to introduce new risks in that area?**

**\[Stuart 9:44\]**

Absolutely. I could see AI supporting integrity and transparency and accountability, but I could also see it obfuscate those things.

But putting my optimist hat on for a moment, an area I've been involved in is investment monitoring for large, high-risk programs throughout the life cycle of the program. And, you know, thinking of Central Agencies like Treasury, those things are monitored through a Gateway process. It's human experts, and sometimes mountains of complex documents, and sometimes also limited time to work through those. So I think skilful application of AI – now your commenter made a really important point.

I'm not talking about taking ChatGPT, or something similar, uploading documents to it like some magic black box and saying, "What do you think, magic machine?". Quite different. There are very skilled techniques, very advanced techniques in the area of things like Retrieval Augmented Generation, which are complex to implement, but can really aid humans who are faced with large volumes of complex data.

The Auditor General is looking at new legislation around transparency and accountability in terms of performance reporting. I could see ways in which AI could support that.

Go to the flip side, and if you have people using AI in that magic black box way – you know – if you upload your job description and your CV and say, "AI, can you please help me pull this together?" it can be brilliant, but it's quite different when you're working with government policy. But in that setting, you have no idea what's going on inside the machine. You're really at its mercy, in fact. So techniques that expose the inner workings, and allow logging and auditing, etc.

In addition, you know, there are certain types of AI, proprietary AI, where there's 'secret sauce' in the AI, that's not examinable. And so we are reliant on an external vendor who's not exposing their code to me, or their weightings, etc, then that's a problem.

Also, if something goes wrong, who's liable there? Is it the person who designed the AI, or is it the user? So complexity all around.

But a final point is, transparency is also transparency about how we use AI. So I'll give you an example. Yesterday, I went to a US website where, within three clicks, I could download a machine-readable, detailed database of all of the Federal Agencies AI use cases. That's been in place since 2020, so I think in terms of transparency, we also need to be transparent about how we're using AI.

**\[Shannon 13:02\]**

Yeah, excellent point. And from LinkedIn, we've had Tim pick up a point there saying that the real challenge for the public sector and in general, is the exponential speed of AI development. So you know, we're talking about it specifically in government and the frameworks being built around that. But of course, it's everywhere, and it's happening fast, and some people adopt it well and not so much. So I think that a good point there, that this is probably the worst AI that you'll see, it's only going to get better, but also the way that we use it as well, and the lessons that we learn sometimes the hard way along the way, will be really important.

> **So Stuart, what would you like to see evolve in the next, say, year or two years, in regards to AI adoption and the framework around that?**

**\[Stuart 14:02\]**

Well, I'd really like us to address the issue of transparency. I think we need to prioritise this. If our goal is to expand the use of AI carefully and safely, to improve the efficiency and the quality of services we can offer the public, then we really need to be transparent about that. And we need social license to be able to increase our use of AI and the road, the path to social license, I like to say, passes through the valley of transparency. There are no shortcuts. So that's something I would say at the moment.

The framework uses words like "should" – it says "Agencies should be transparent". I'd like to see that evolve very rapidly to "Agencies must be transparent - and this is the file format for you to upload your detailed AI use cases into the central public register". So that's, so that's my view there.

I know that there are good relationships in New Zealand with the Australian AI Assurance Pilot, that they're testing over there. Firstly, I'm love that they're testing it, rather than just going big-bang. And with New Zealand's relationship with those Australian Federal agencies, we will have opportunities to take lessons learned from that.

And I'm also aware that, you know, this is ongoing work, and there's additional advice on its way, and I look forward to seeing what that advice is, and helping people navigate that.

**\[Shannon 15:36\]**

Yeah, fantastic. Good things to come. Now, really interesting topic, and I'm sure people are still keen to engage. So make sure to if you're watching this later, feel free to still engage in the conversation. And Stuart's details of courses, along with our own, will be on the links. Thanks so much, Stuart, that was really insightful.

**\[Stuart 16:01\]**

Thank you very much.

• • •

This conversation inspired a simple model for early discussion. If you would like read more about that, it's available [here](https://policyops.ai/public-service-ai-trust-model-v1/).

---
### An unfortunate incident
URL: https://policyops.ai/an-unfortunate-incident/
Last updated: 2026-01-09T03:43:12.000Z
Six years prior to the explosion, the community of Walsall Street, Wolverhampton, stopped to watch the arrival of a steam engine and boiler, to be installed at Benjamin Mason's workshop.

For the first time, machines could be powered by steam. Power beyond all dreams had arrived, nestled amongst the alehouse, the church, the cattle market, and the neighbouring homes. And the community was right to be excited and hopeful. The future had arrived.

Mason made fire-irons – items adorning fireplaces, used to tend open fires. Machinery, old and new, could now be steam-driven, and Mason’s artisans could focus on their art, unlimited by their strength and endurance.[\[1\]](#fn1)

It's hard to put ourselves in that time, except to say, life was often brutal and short. We owe a lot to those who came before us – those who took great risks on our behalf. But risk management of horses was quite different from steam ‘horsepower’. Perhaps compassion, rather than judgement, is the best lens for what was about to occur.

On Friday afternoon, 24 April, 1857, the unthinkable happened. An explosion so great that people almost a kilometre away felt the earth shake. And to paraphrase the saying, those closest to the boiler didn't really die of anything in the traditional sense. They just stopped being biology and started being physics.[\[2\]](#fn2)

Debris rained down across the neighbourhood, reaching as far as St George's Church and Bilston Street. The following Sunday, people met in front of the cattle market and held space for themselves, and those they once loved.

By this time, Benjamin Mason senior had retired. Benjamin Mason junior – no doubt skilled at blacksmithing, hand-driven grinders, and foot-driven lathes – was now managing the workshop.

The coroner's jury met at the Blue Ball Inn. Its principal finding was that Mason junior, since elevated to steam engineer, failed to operate the boiler correctly. They condemned what they called “*the dangerous practice of allowing unqualified persons to have the management of engines and boilers.*”[\[3\]](#fn3) Other accounts also note the second-hand boiler had been significantly modified during its life.

Sadly, there was nothing exceptional about this explosion, or its terrible consequences. It was reported in the British Parliament that in that decade there were 248 boiler explosions, 486 fatalities and 588 injuries. These numbers were to double in the following decade, before eventually declining.[\[4\]](#fn4)[\[5\]](#fn5)

• • •

Like AI, the transformative power of steam escaped those early inventor's workshops, unstoppable in its adoption. Not all boilers exploded, but the risks shaped a generation. If the steam-age metaphor holds, what lessons will shape ours?

### References

---

1. Bev Parker, *Wolverhampton History & Heritage*, archived at [Wayback Machine⧉](https://web.archive.org/web/20240724221515/http://www.historywebsite.co.uk/articles/boiler/explosions.htm). [↩︎](#fnref1)
2. u/blitzkraft (2016). What-If 141: Sunbeam. *r/xkcd*. [↩︎](#fnref2)
3. "Boiler Explosion at Wolverhampton". *London Illustrated News*, 2 May 1857, p.2(400), p.12(410). Available at [Internet Archive⧉](https://archive.org/details/sim%5Fillustrated-london-news%5F1857-05-02%5F30%5F856/mode/2up). [↩︎](#fnref3)
4. Bartrip, P. W. J. (1980). The State and the Steam-Boiler in Nineteenth-Century Britain. *International Review of Social History*, 25(1), 77–105\. [Cambridge University Press⧉](https://doi.org/10.1017/S0020859000006222). [↩︎](#fnref4)
5. Great Britain. Parliament. House of Commons. (1870). *Report from the Select Committee on Steam Boiler Explosions*. In *Reports from Committees* (Vol. 10). Available via [Google Books⧉](https://books.google.co.nz/books?id=hylcAAAAQAAJ). [↩︎](#fnref5)