AuditEvent.occurredPeriod can represent the execution interval, while AuditEvent.recorded records when the audit event was logged. AuditEvent.source.observer can identify the reporting source. MedLog-specific invocation identifiers, protocol version, parent-event linkage, and other workflow context can remain in the linked MedLog payload or defined extensions.Timestamp and ObservedTimestamp can distinguish source-event and collection times. Populate trace and span identifiers only when genuine tracing context exists; use gen\_ai.conversation.id only when the MedLog run identifier has the same conversation or thread scope.Device. Device.identifier can identify the software instance, while Device.version.value can record its software version. Model-card references, training-data versions, deployment identifiers, test-time modifications, and other invocation-specific configuration can remain in the linked MedLog payload or associated documentation.medlog.model\_instance.\*. For generative AI, gen\_ai.request.model can identify the requested model and gen\_ai.response.model the responding model when independently known. These attributes do not replace model-version, deployment, or other configuration metadata.AuditEvent.agent can represent actors involved in the event. AuditEvent.agent.who.identifier can preserve a native account identifier and namespace, while AuditEvent.agent.role can record the active security role. References to Practitioner or PractitionerRole can add human, clinical-role, and organizational context. Session or login context not represented directly can remain in MedLog.medlog.user\_identity.\*. Compatible application context can additionally use user.id, user.name, and session.id. These attributes do not replace identifier namespaces, caller ordering, or other MedLog-specific provenance information.AuditEvent.patient can identify a patient whose data were involved in the event, and AuditEvent.encounter can provide encounter context. AuditEvent.entity.what can reference other relevant target or contextual resources, such as an Appointment. When provenance of a generated or updated FHIR resource is being described, Provenance.target identifies that resource.medlog.target\_identity.\*. Do not populate user.id merely because the target is a patient; being the subject of a prediction does not establish participation as an application user.Observation, DocumentReference, Condition, and MedicationRequest. Provenance.entity.what can identify source entities used in producing an output. Input versions, preprocessing state, feature vectors, prompts, or other information needed for reconstruction can remain in MedLog.gen\_ai.input.messages, while separately supplied system instructions can use gen\_ai.system\_instructions. Arbitrary feature vectors or clinical variables should not be relabeled as messages solely to fit Gen AI conventions.DocumentReference can reference stored artifacts; for example, DocumentReference.content.attachment.url can point to controlled-access artifact storage. Artifact type, format, version, and linkage to the originating invocation can remain in MedLog or explicitly defined extensions.medlog.artifact.\*. Compatible generative-AI operations can additionally use semantic conventions such as gen\_ai.tool.name and gen\_ai.retrieval.documents. Other internal artifacts remain MedLog-specific.RiskAssessment for a clinical risk prediction or DocumentReference for a generated document. Provenance.target can identify a resource generated or updated by the activity. The original model output should remain distinguishable from subsequent human edits, transformations, and presentation events.medlog.output.\*. For generative AI, corresponding model-response messages can use gen\_ai.output.messages. gen\_ai.output.type describes the output type requested by the client and should not be treated as an unconditional equivalent of a MedLog output-type field.ServiceRequest or MedicationRequest for orders, MedicationAdministration for administered therapy, Condition or Observation for clinical endpoints, and Appointment.status for attendance. Linkage between the outcome and originating AI interaction remains explicit in MedLog. AuditEvent.outcome records the success or failure of the audited event and is not itself a clinical outcome.medlog.outcome.\*. Delayed outcomes can be emitted as later records linked to the originating invocation. Clinical benefit or harm should not be represented as inference execution status, nor should an execution span remain open while awaiting clinical follow-up.QuestionnaireResponse can represent feedback collected through a defined questionnaire. Its author, subject, encounter, and questionnaire linkage can provide additional context where applicable. Other ratings or comments can remain in a linked MedLog payload. Preserve the feedback instrument and version, respondent attribution, and explicit linkage to the invocation or output.medlog.feedback.\*. Feedback explicitly evaluating a generative-AI response can additionally use gen\_ai.evaluation.name together with gen\_ai.evaluation.score.value or gen\_ai.evaluation.score.label where applicable. General comments should not be converted into an artificial score.