diff --git a/input/pagecontent/conformance.md b/input/pagecontent/conformance.md old mode 100644 new mode 100755 index 14fe0fa3..8cf84975 --- 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 old mode 100644 new mode 100755 index 71f46555..2fd3aee8 --- 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)
[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 old mode 100644 new mode 100755 index 919d96c2..40681263 --- 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 old mode 100644 new mode 100755 index 0bcbedb3..31bdf09b --- 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 deleted file mode 100644 index 1fe40ff5..00000000 --- a/input/pagecontent/recordlifecycle.md +++ /dev/null @@ -1,52 +0,0 @@ - -Record lifecycle management involves overseeing records from their creation to their final disposal. This process ensures that records are handled consistently and securely at every stage. Managing the lifecycle of records includes activities such as creating, updating, accessing, storing, archiving, and deleting records. - -#### Record Lifecycle Events - -| Section | Header Name | -| ---------- | :-------------------- | -| RI.1 | Record Lifecycle and Lifespan | | | -| RI.1.1 | Record Lifecycle | | | -| RI.1.1.1 | Originate/Retain Record Lifecycle Event | | | -| RI.1.1.2 | Amend (Update) Record Lifecycle Event | | | -| RI.1.1.3 | Transform/Translate Record Lifecycle Event | | | -| RI.1.1.4 | Attest Record Lifecycle Event | | | -| RI.1.1.5 | Access/View Record Lifecycle Event | | | -| RI.1.1.6 | Report (Output) Record Lifecycle Event | | | -| RI.1.1.7 | Disclose Record Lifecycle Event | | | -| RI.1.1.8 | Transmit Record Lifecycle Event | | | -| RI.1.1.9 | Receive/Retain Record Lifecycle Event | | | -| RI.1.1.10 | De-Identify (Anononymize) Record Lifecycle Event | | | -| RI.1.1.11 | Pseudonymize Record Lifecycle Event | | | -| RI.1.1.12 | Re-identify Record Lifecycle Event | | | -| RI.1.1.13 | Extract Record Lifecycle Event | | | -| RI.1.1.14 | Archive Record Lifecycle Event | | | -| RI.1.1.15 | Restore Record Lifecycle Event | | | -| RI.1.1.16 | Destroy/Delete Record Lifecycle Event | | | -| RI.1.1.17 | Deprecate Record Lifecycle Event | | | -| RI.1.1.18 | Re-activate Record Lifecycle Event | | | -| RI.1.1.19 | Merge Record Lifecycle Event | | | -| RI.1.1.20 | Unmerge Record Lifecycle Event | | | -| RI.1.1.21 | Link Record Lifecycle Event | | | -| RI.1.1.22 | Unlink Record Lifecycle Event | | | -| RI.1.1.23 | Add Legal Hold Record Lifecycle Event | | | -| RI.1.1.24 | Remove Legal Hold Record Lifecycle Event | | | -| RI.1.1.25 | Verify Record Entries | | | -| RI.1.1.26 | Encrypt Record Entries | | | -| RI.1.1.27 | Decrypt Record Entries | | | -| RI.1.2 | Record Lifespan | | | -| RI.1.2.1 | Manage Record Entries | | | -| RI.1.2.2 | Manage Record Entries for Legal Hold | | | -| RI.1.3 | Record States | | | -| RI.1.3.1 | Manage Record Pending State | | | -| RI.1.3.2 | Manage Record Entry Amended, Corrected and Augmented State | | | -| RI.1.3.3 | Manage Record Entry Succession and Version Control | | | -| RI.1.3.4 | Manage Record Entry Retraction | | | -| RI.1.4 | Record Completeness | | | -| RI.2 | Record Synchronization | | | -| RI.3 | Record Archive and Restore | | | - - -### References - -[Personal Health Record System Functional Model](https://www.hl7.org/implement/standards/product_brief.cfm?product_id=88) \ No newline at end of file diff --git a/sushi-config.yaml b/sushi-config.yaml old mode 100644 new mode 100755 index f5089816..0cd14990 --- 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: