HL7 · awatson1978 · Jan 29, 2026
diff --git a/input/pagecontent/conformance.md b/input/pagecontent/conformance.md
@@ -8,7 +8,7 @@ In this specification, the key words “MUST”, “MUST NOT”, “REQUIRED”,
 | --------------------- | --------  | :-------- | :-------- | 
 | [Electronic Health Information Export API](https://build.fhir.org/ig/argonautproject/ehi-api/) |   | SHOULD | MUST |
 | [Record Lifecycle](https://build.fhir.org/ig/HL7/ehrs-rle-ig/) | Medical Records | NOT APPLICABLE | MUST |
-| [Patient Data Receipt](https://open-health-manager.github.io/patient-data-receipt-ig/) | Medical Records | NOT APPLICABLE | SHOULD |
+| [Patient Data Receipt](https://open-health-manager.github.io/patient-data-receipt-ig/) (experimental) | Medical Records | NOT APPLICABLE | MAY |
 | [PHR-S Functional Model](https://www.hl7.org/implement/standards/product_brief.cfm?product_id=88)  |  | SHOULD | MAY |
 | [Argonaut Data Query](http://www.fhir.org/guides/argonaut/r2/) | Internal Medicine  | SHOULD | SHOULD |
 | [Argonaut Data Write](https://hackmd.io/@erichaas/rJVqJGmeY/%2FwTGb4Gk6R6O4NVut5yaJig) | Internal Medicine  | SHOULD | SHOULD |

diff --git a/input/pagecontent/functionality.md b/input/pagecontent/functionality.md
@@ -123,7 +123,7 @@ The section and header names for the following table can be found in the [Person
 | S.4.6.6 | Enrollment in Public Health Surveys | [Questionnaire](https://www.hl7.org/fhir/R4B/questionnaire.html) <br/> [QuestionnaireResponse](https://www.hl7.org/fhir/R4B/questionnaireresponse.html)| |
 
 #### Record and Trust Infrastructure
-RI. [Record Infrastructure](recordlifecycle.html)
+RI. [Record Infrastructure](recordkeeping.html#record-lifecycle)
 
 TI. [Trust Infrastructure](security.html)
 

diff --git a/input/pagecontent/longitudinal.md b/input/pagecontent/longitudinal.md
@@ -5,13 +5,13 @@ The core idea has been to establish a robust mechanism for bidirectional synchro
 
 #### Record Lifecycle Operations
 
-However, once we have structured data, we need to consider the details of how we construct longitudinal records from multiple sources. In doing so, we are inspired by both the SPHR-FM Record Lifecycle specifications and the Git utility (which is a distributed version control system that allows multiple users to collaborate on a project while maintaining a complete history of changes).  In Git, each record is added to a "repository" and can be "committed" with a timestamp and a message (RI.1.1.2).  The repository can be "cloned" to create a local copy (RI.1.1.9), and changes can be "pulled" from the repository and "pushed" or merged into it (RI.1.1.19).  We would draw the reader's attention to how these operations are similar to the SPHR-FM Record Lifecycle operations.  By aligning these two approaches, we can leverage the power of both acylic graphs and the SPHR-FM Record Lifecycle specifications to create a robust mechanism for managing longitudinal records.
+However, once we have structured data, we need to consider the details of how we construct longitudinal records from multiple sources. In doing so, we are inspired by both the PHR-S Functional Model Record Lifecycle specifications and the Git utility (which is a distributed version control system that allows multiple users to collaborate on a project while maintaining a complete history of changes).  In Git, each record is added to a "repository" and can be "committed" with a timestamp and a message (RI.1.1.2).  The repository can be "cloned" to create a local copy (RI.1.1.9), and changes can be "pulled" from the repository and "pushed" or merged into it (RI.1.1.19).  We would draw the reader's attention to how these operations are similar to the PHR-S Functional Model Record Lifecycle operations.  By aligning these two approaches, we can leverage the power of both acylic graphs and the PHR-S Functional Model Record Lifecycle specifications to create a robust mechanism for managing longitudinal records.
 
 ![git-like-operations](git-like-operations.png){:width="100%"}
 
 Importantly, this architecture suggests a formal record-keeping mechanism by which we can manage,  index, update,merge, and export entire medical histories from a system. This formal mechanism is known as a Directed Acylic Graphs (DAGs), which are designed to ensure data integrity and consistency. Each record is assigned a unique [SHA-256](https://www.simplilearn.com/tutorials/cyber-security-tutorial/sha-256-algorithm) hash, and the hash of each record includes the hash of the previous record in the chain. This creates a tamper-evident, immutable record of the patient's health data. 
 
-> Note:  We envision these atomic updates as eventually including the [Patient Data Receipt](https://open-health-manager.github.io/patient-data-receipt-ig/) standard.  
+> Note:  We envision these atomic updates as eventually including a [patient data receipt mechanism](https://open-health-manager.github.io/patient-data-receipt-ig/) (experimental, non-HL7 concept).
 
 #### Consolidation of Distributed Records 
 

diff --git a/input/pagecontent/recordkeeping.md b/input/pagecontent/recordkeeping.md
@@ -85,6 +85,32 @@ Public key encryption and secret key may be combined in a PGP solution.
 
 A SMART Health Links based solution will distribute the encryption key within a shareable QR which the patient can display to recipients of an SPHR file for scanning. The recipient would decrypt the linked file using the A256GCM algorithm.
 
+### Record Lifecycle
+
+Record lifecycle management involves overseeing health records from creation through final disposition. For personal health records, lifecycle events occur across multiple systems — clinical EHRs, patient apps, devices — and must be tracked to maintain data integrity and provenance.
+
+The [PHR-S Functional Model](https://www.hl7.org/implement/standards/product_brief.cfm?product_id=88) defines a comprehensive set of Record Infrastructure (RI) lifecycle events, including:
+
+- **Originate/Retain** — Creating or receiving a new record entry
+- **Amend/Update** — Modifying an existing record with tracked changes
+- **Attest** — Formally verifying record content
+- **Access/View** — Reading record entries with audit logging
+- **Transmit/Disclose** — Sharing records with other systems or individuals
+- **Archive/Restore** — Long-term storage and retrieval
+- **Merge/Link** — Combining or associating records from multiple sources
+- **Encrypt/Decrypt** — Protecting record confidentiality
+
+In the FHIR context, these lifecycle events map to standard resources:
+
+| Lifecycle Concern | FHIR Resource | Usage |
+|-------------------|---------------|-------|
+| Change tracking | [Provenance](https://www.hl7.org/fhir/R4/provenance.html) | Records who changed what and when |
+| Access logging | [AuditEvent](https://www.hl7.org/fhir/R4/auditevent.html) | Logs access, view, and disclosure events |
+| Record versioning | [Bundle](https://www.hl7.org/fhir/R4/bundle.html) history | Tracks resource version history |
+| Attestation | [Signature](https://www.hl7.org/fhir/R4/datatypes.html#Signature) | Cryptographic attestation of content |
+
+For a FHIR-based implementation of record lifecycle events, see the [EHR Record Lifecycle Events IG](https://build.fhir.org/ig/HL7/ehrs-rle-ig/). For the complete functional model specification, see the [PHR-S Functional Model](https://www.hl7.org/implement/standards/product_brief.cfm?product_id=88).
+
 
 ### Conformance Testing
 

diff --git a/input/pagecontent/recordlifecycle.md b/input/pagecontent/recordlifecycle.md
diff --git a/sushi-config.yaml b/sushi-config.yaml
@@ -93,7 +93,6 @@ menu:
     Conformance: conformance.html
     Data Model: datamodel.html
     Functional Model: functionality.html
-    Record Lifecycle: recordlifecycle.html
     Security: security.html
   Supplemental:
     History: history.html
@@ -127,8 +126,6 @@ pages:
     title: Data Model    
   functionality.md:
     title: Functional Model
-  recordlifecycle.md:
-    title: Record Lifecycle    
   annotations.md:
     title: Annotations
   security.md: