<?xml version="1.0" encoding="utf-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-singh-apex-psi-08-01" ipr="trust200902" submissionType="IETF" version="3" xml:lang="en">
<front><title abbrev="PSI-08">PSI-08: Receipts for Health Record Access Events</title>
<seriesInfo name="Internet-Draft" value="draft-singh-apex-psi-08-01"/>
<author fullname="Kawaljeet Singh" initials="K." surname="Singh"><organization>APEX Infrastructure</organization>
<address><postal><city>Melbourne</city><region>Victoria</region><country>Australia</country></postal>
<email>kawaljeet.singh3008@gmail.com</email><uri>https://ai-governance-standard.com</uri></address></author>
<date year="2026" month="October" day="13"/>
<abstract><t>This document defines PSI-08, a domain profile of Proof of Stateful Integrity (PSI) for access events on health records, recording that an access occurred, by which role, and for what stated purpose.  Each record is sealed as a PSI receipt so that later alteration, reordering, or removal is detectable.  Only digests are sealed.  PSI-08 shows integrity and ordering only; it does not show that an access was authorised, appropriate, or lawful.</t>
<t>Revision 00 carried this title over an abstract describing predicate chains. This revision makes the body match the title.</t></abstract></front>
<middle>
<section><name>Introduction</name><t>This profile applies the receipt format of <xref target="PSI"/> to one record type.  The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>SHOULD</bcp14>", and "<bcp14>MAY</bcp14>" in this document are to be interpreted as described in BCP&#160;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t></section>
<section><name>Record Profile</name><t>A record is a JSON object that MUST contain the following members and MAY contain others:</t><ul><li>patient_ref and accessor_ref, opaque pseudonymous identifiers that MUST NOT be names or government identifiers</li><li>purpose_code</li><li>prev_event_hash, the digest of the previous event for the same patient_ref</li><li>salt, at least 128 bits of randomness</li></ul>
<t>The record holder computes the record digest per <xref target="PSI"/> and submits only the digest for sealing.  Records SHOULD NOT contain personal data.</t></section>
<section><name>Verification</name><t>A verifier given a record and its receipt verifies the receipt per <xref target="PSI"/>.  Verification reports digest match and signature validity only.</t></section>
<section><name>Security Considerations</name><t>The considerations of <xref target="PSI"/> apply.  A record that was false when sealed remains false; a record that was never sealed is not detected as missing unless records are chained.</t></section>
<section><name>IANA Considerations</name><t>This document has no IANA actions.</t></section>
</middle>
<back><references><name>Normative References</name>
<reference anchor="PSI" target="https://datatracker.ietf.org/doc/draft-singh-psi/"><front><title>Proof of Stateful Integrity (PSI): Signed, Merkle-Committed Receipts for Digital Records</title><author initials="K." surname="Singh"/><date year="2026" month="October"/></front><seriesInfo name="Internet-Draft" value="draft-singh-psi-02"/></reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119"><front><title>Key words for use in RFCs to Indicate Requirement Levels</title><author initials="S." surname="Bradner"/><date year="1997" month="March"/></front><seriesInfo name="BCP" value="14"/><seriesInfo name="RFC" value="2119"/></reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174"><front><title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title><author initials="B." surname="Leiba"/><date year="2017" month="May"/></front><seriesInfo name="BCP" value="14"/><seriesInfo name="RFC" value="8174"/></reference>
</references></back></rfc>