Personal Health Records
1.0.0-ballot2 - STU 1 ballot
Personal Health Records
1.0.0-ballot2 - STU 1 ballot
Personal Health Records, published by HL7 International / Patient Empowerment. This guide is not an authorized publication; it is the continuous build for version 1.0.0-ballot2 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/personal-health-record-format-ig/ and changes regularly. See the Directory of published versions
| Page standards status: Informative |
A complete longitudinal patient health record may feasibly span 100 years or more. This presents numerous challenges, especially considering that the earliest EMR systems were only first written in the early 1970s. Statute of limitations specify that healthcare practitioners keep pediatric records until an 18th birthday, but even an 18 year storage requirement by providers falls well short of a 76yr lifespan. Anybody over 30 years of age is therefore almost guaranteed to have some records on hardcopy paper, compact disk, USB drive, floppy drive, or other storage mediums.
As such, this implementation guide is particularly concerned with this data storage challenge that is unique to patients, and does not immediately assume availability of B2B over-the-wire data interfaces. This guide differs from guides produced by other working groups, in that it is less concerned with over-the-wire workflows, and more concerned with the notion of a patient asking for a copy of their complete medical history, and how that would work with devices… be they smartphones, consumer medical devices, compact disks (CD), digital video disks (DVD), thumbdrives, and other storage devices for bulk data; and how that would be imported into the another system.
A useful way to think of data storage is in terms of slow-motion data transfer. The earliest electronic data storage devices were cathode ray tubes, the same devices used in computer monitors for decades. As such, there isn't as much difference between the devices that store bits and the devices that display data or transmits data over the wire as many people think. If one considers the storage device as an actor on the wire that can send or receive data, storage is just like any other data transfer - but with the ability to press a pause button indefinately mid-transfer.
As such, this implementation guide recommends that implementors treat storage in much the same way as over-the-wire data transfers. We simply are defining file formats, rather than wire formats. To this extent, we recommend the following principles when exporting data from their systems:
.phr and .sphr MIME types when possible.
The .phr file extension is introduced in this guide, to a) specify files which contain FHIR resources, and b) to allow 3rd party applications to identify files which contain FHIR resources. Data exports containing FHIR resources SHOULD be saved with a .phr extension, using new-line deliminated JSON (NDJSON) format, similar to the Bulk Data specification.
This format is a simple, text-based format that is easy to parse and edit. It is also a good fit for streaming data, as it is easy to append to a file without having to rewrite the entire file. And perhaps most importantly, it allows multiple .phr files to be easily 'globbed' together.
The .sphr file extension is introduced for when there are additional supporting materials, which cannot be fully expressed in FHIR format. The .sphr is a zip folder, which contains one or more FHIR resources, as well as additional supporting materials.
The .sphr file extension is intended to be used for data exports that are saved to a CD, DVD, thumbdrive, etc. Each .sphr folder should contain at least one .phr file within it, as well as additional supporting materials such as images, documents, and other media.
Per the .zip specification, the .sphr folder may be cryptographically signed.
The .sphr container MAY contain two meta data files. One of these files is a Composition record, which acts like the 'cover page' of the bundle. This record records ownership, versioning, and various other data elements necessary for parsing the record. The second file is an International Patient Summary file, which acts as a manifest and table of contents of critical documents in the record.
Files containing patient health information MAY be zipped. The .sphr file extension is an alias for .fhir.zip or .fhir.gz. When using compression, systems SHOULD use the DEFLATE algorithm. DEFLATE is supported by both ZIP and GZIP compression utilities.
Supporting media files and raw documents may be added into the .sphr directory. Such files may include DICOM files, 3D models, images, PDFs, and other media. Each record SHOULD have a corresponding FHIR DocumentReference pointer in the .phr file.
Should use NDJSON format and save to a password encrypted zip file. Please see Bulk Data Access IG more additional design guidance.
The primary difference between the Bulk Data Access format and the .phr file, is that Bulk Data exports data according to resource type. That is, all Observations get written to an Observation.ndjson file; all Condititions get written to a Conditions.ndjson file, all MedicationStatements to a MedicationStatement.ndjson file, and so forth.
Meanwhile, the .phr file is a single hetergenous .ndjson file that contains all of the data for a patient. It is a .ndjson file with mixed resource types. This is done to simplify the process of importing and exporting data. It is also done to simplify the process of querying data. It is easier to query a single file than it is to query multiple files. However, it does introduce import/export parsing requirements, that are not present in the Bulk Data Access format.
Here we describe the asymmetric cryptography algorithms to support both signing and encryption of PHR files.
Signing allows the source system of the PHR file to attest to the contents of that file and the recipient to verify authenticity and identity of the data source. If the full file is used as the message digest of a digital signature, it can allow the recipient to also verify data integrity and provides mechanism for non-repudiation.
The source system MAY provide a FHIR Signature on the PhrBundle resource or individual PhrProvenance resources. The signature SHALL be a detached signature on the canonical form of the resource in compliance with the FHIR Signature guidance.
The source system MAY sign a hash of the full and optionally compressed or encrypted PHR file and provide a JWS as a separate file to the recipient to allow the recipient to both identify the source of data and verify data integrity. The source system should use the SHA-256 hash algorithm to create a message digest of the SPHR file for signing. As with FHIR Signatures, the JWS should be a detached signature without a payload.
The recipient MAY verify the integrity of the SPHR file by verifying the signature of the provided JWS against the SHA-256 hash of the SPHR file. Note that there may be significant performance limitations in creating the hash based on size of the file.
While a verifiable signature may provide some context as to the identity of the data source, it does not ensure that that data source is a reliable actor. The recipient who wishes to verify a digital signature MAY also verify that the signer is a trusted entity as defined by participation in a mutual trust network. The recipient SHOULD assure that any trust network in which they choose to participate enforces policies and provides adequate governance to prevent unreliable data sources from entering the network.
Retrieving the source system's public keys may depend on the key formats and distribution methods inherent to the trust networks in which a recipient chooses to participate.
In an X.509 based PKI, the recipient MAY receive the source system's public key from a trusted certificate authority. If the certificate is distributed out of band, the recipient MAY verify that the root of the chain of trust is a trusted certificate authority and that the certificate is not revoked.
Files containing patient health information should be encrypted to protect the data in case of unauthorized interception.
If the PHR file is being generated for a known intended recipient, then the file MAY be encrypted using the discoverable public key of that recipient. Key distribution for the recipients public key would follow the same guidance as in "Trust and key distribution". Encryption SHOULD use the ES256 algorithm. The intended recipient would use their equivalent private key and the same algorithm to decrypt the file.
If the intended recipient is not known at time of file generation, the source system SHOULD use a unique secret key or passphrase to encrypt the file. This passphrase can be shared out of band by the patient with any recipient of their choosing.
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.
For conformance testing with this IG, the primary success critieria is that systems MUST have the ability to import/export the .sphr filetype. This entails storing FHIR records in a new-line delimited file (including a cover composition resource, a document manifest, and provenance records as needed), compressing the file with DEFLATE algorithm (as needed), and then signing with an X.509 security certificate.
The process flow below is based on encrypting files with PGP/GPG utilities, which support asymmetric cryptography algorithms and X.509 certificates.
The SPHR file format takes much inspiration from the DICOM DIR specification. Grossly speaking, the DICOM DIR format is like a manilla envelope. It is not a specification about the paper or documents within it, but rather, about the envelope that contains the documents of interest.
Similarly, SPHR seeks a mechanism whereby a patient's health record can be sent in structured, machine-readable formats; but which can also include copies of the raw data in various other formats. We can achieve this goal, by adopting a folder format that contains both a specified JSON or NDJSON data, along with elements in the folder that 'ride along' with the structured data. These ride along files, might be PDFs, photos of receipts, video recordings, or whatever other data that is relevant to the patient's health.
But to make that happen, we must clarify the details of the envelope that will contain such data.
IG © 2022+ HL7 International / Patient Empowerment. Package hl7.fhir.uv.phr#1.0.0-ballot2 based on FHIR 4.0.1. Generated 2025-04-03
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change