An AI model card is a document that provides a standardized overview of an artificial intelligence model's purpose, performance, intended usage, and limitations. ModelCard could be a subset of the HuggingFace model card specification: https://huggingface.co/docs/hub/model-card-annotated.

An AI Provenance is a record of the use of an AI model in generating or enhancing FHIR resources. It captures the details of the AI model used, the input data, and the output generated by the AI model.

When the Device is described by a Model Card, this extension can be used to reference the Model Card.

Subset from HL7, plus those defined here

This CodeSystem contains codes for the DocumentReference.type and DocumentReference.category that indicate that the DocumentReference is a Model Card.

This CodeSystem contains codes for the provenance indications used in .meta.security and elsewhere that indicate that the AI system has been involved.

A Procedure resource that is created by an AI system and verified by a human.

A lab result Observation resource that is created by an AI system and verified by a human.

A Bundle resource containing AI generated resources

A Device that has a Model Card. Given that it is understood that ModelCards are Markdown, this could simply go into the .note.

A Device that has an attached Model Card.

This DiagnosticeReport is derived from FHIR Core R4 DiagnosticReport id f202. This use contains a DiagnosticReport with inline Artificial Intelligence asserted security labels for the conclusion and conclusionCode, as well as a ServiceRequest.

• The DiagnosticReport is tagged with the security label PROCESSINLINELABEL, to indicate that there is inline security labeling.
• The DiagnosticReport.conclusion and DiagnosticReport.conclusionCode elements are tagged with the Artificial Intelligence asserted security label AIAST.

An example of a Model Card DocumentReference that contains the model card in YAML and Markdown formats.

using example from HuggingFace.

This observation is derived from FHIR Core R4 Observation id glasgow. This use contains a Glasgow Coma Scale observation with Artificial Intelligence asserted security labels for the whole Resource.

Note that the example I took, I assumed was a good one for AIAST. But I am not sure that it is, especially since the outcome is not well coded, using ucum score values.

Note that there is no .performer as that element can't hold a Device, and we are modeling this as being wholely authored by the AI. Thus I use the extension alternate-reference.

A DocumentReference that contains the input prompt provided to the AI system. – Lorem ipsum text is used as a placeholder.

Generate a lorem ipsum text to serve as placeholder copy for use in design, development, and publishing. 

1. Specify the exact amount of text or the number of paragraphs required (e.g., 1 paragraph, 3 paragraphs, etc.). 
2. Create the lorem ipsum text using a classic style or introduce slight variations while keeping the nonsensical nature to suit the requested length. 

Ensure that the text maintains a good balance between readability and the traditional lorem ipsum style, giving a realistic impression of how the text will impact the overall layout and design.

# Output Format
- Provide a continuous block of lorem ipsum text corresponding to the specified amount needed.

A DocumentReference that contains the input prompt provided to the AI system. – to generate a Patient resource.

System Prompt

You are a healthcare data specialist that converts natural language patient information into valid FHIR Patient resources. Your task is to extract relevant patient demographics and create a well-formed FHIR Patient resource that is fully conformant with FHIR US Core 6.1.0 specifications.

Requirements:

- Generate valid JSON that conforms to FHIR R4 Patient resource structure
- Ensure compliance with US Core Patient Profile (US Core 6.1.0)
- Include all required US Core elements when data is available
- Use appropriate FHIR data types and value sets
- Generate a unique resource ID using UUID format
- Apply proper FHIR coding systems and terminologies
- Handle missing data appropriately (omit optional fields when data unavailable)
- Use standard US address formatting
- Apply proper date formatting (YYYY-MM-DD)
- Include appropriate extensions when necessary for US Core compliance

US Core 6.1.0 Patient Profile Requirements:

- Must include: identifier, name, gender, birthDate
- Should include: address, telecom, race, ethnicity when available
- Use US Core extensions for race and ethnicity
- Follow US postal address conventions
- Use appropriate terminologies (e.g., HL7 AdministrativeGender, OMB race categories)

Data Mapping Guidelines:

- Extract patient name and structure as HumanName with family/given components
- Map gender terms to FHIR AdministrativeGender codes (male, female, other, unknown)
- Convert birth dates to FHIR date format
- Structure addresses using Address data type with appropriate use codes
- Map race/ethnicity information using US Core extensions with appropriate OMB codes
- Generate medical record number as primary identifier when not provided
- Include meta.profile reference to US Core Patient profile

Output Format:

- Provide only the valid FHIR JSON resource without additional commentary or explanation.

User Prompt

- Convert the following patient information into a FHIR Patient resource conformant with US Core 6.1.0:

`Jane Doe is a white female born on November 15, 1950. She lives at 123 Main Street, Anytown, Michigan, zipcode 12345.`

A DocumentReference resource that represents a PDF document containing lab results for a patient. This is provided to an AI, which interprets and creates FHIR Resources.

In the attached example the patient's name is Alton Walsh and the lab test is an HbA1C. All the FHIR resources in the bundle have been created by the AI, so they should be tagged accordingly.

An example Patient resource generated by AI

A Provenance resource that captures the full AI process, including the model card, input, and output.

This is a full example of how to capture the AI process in FHIR.

• One output that this Provenance resource is documenting:
  • an Patient resource
• Two agents
  • a verifier (human) who verifies the AI output
  • an author (AI system) who generated the output
• One entity that is the AI Input Prompt
  • Where the Input Prompt is a DocumentReference resource that contains the input prompt provided to the AI system.
  • Where the Input Prompt is a contained resource in the Provenance resource.
  • Where the Input Prompt is associated with the clinician which provided it

A Provenance resource that captures the full AI process, including the model card, input, and output.

This is a full example of how to capture the AI process in FHIR.

• Two outputs that this Provenance resource is documenting:
  • an Observation resource (e.g., lab result)
    • with Observation.interpretation being attributed to this Provenance
  • a CarePlan resource (e.g., follow-up care plan)
• Two agents
  • a verifier (human) who verifies the AI output
  • an author (AI system) who generated the output
• Two entities that were clinical resources provided to the AI system
  • a DocumentReference resource (e.g., patient summary)
  • an Observation resource (e.g., lab result)
• One entity that is a PlanDefinition resource (e.g., care plan definition)
• One entity that is the AI Input Prompt
  • Where the Input Prompt is a DocumentReference resource that contains the input prompt provided to the AI system.
  • Where the Input Prompt is a contained resource in the Provenance resource.
  • Where the Input Prompt is associated with the clinician which provided it

A Provenance resource that documents the addition of followUp text in a Procedure by an AI system.

A Provenance resource that documents the creation of a Lab result Observation resource by an AI (device), verified by a human. The AI system is represented as a Device resource. The Input is a PDF Lab result.

A Provenance resource that documents the creation of a Lab result Observation resource by an AI (device), verified by a human. The AI system is represented as a Device resource.

An AI system that authored a resource.

TODO: Need codes in the device-type to indicate AI/LLM. TODO: Need codes to identify the device version for the parts of an AI?