0.4.4 - ci-build
StandardPatientHealthRecordIG - Local Development build (v0.4.4). See the Directory of published versions
A complete longitudinal patient health record may feasibly span 100 years or more. This presents numerous challenges, espcially considering that the earliest EMR systems were only first written in the early 1970s. Statue of limitations require 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 life expectancy. 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 medium.
As such, this implementation guide concerns itself with this specific 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 compact disks, digital video disks, thumbdrive, and other storage devices for bulk data; and how that would be imported into the another system.
Note: The only portion of this Implementation Guide that is required for conformance testing is the ability to import/export the .sphr filetype. All other parts of this implementation guide are optional, and are provided to assist the implementor in modeling patient histories in FHIR format.
A useful way to think of data storage is in terms of slow-motion data transfer. The earliest electronic data storage devices were actually cathode ray tubes, the same devices used in computer monitors for decades. As such, there isn’t as much difference as one may think between the devices that store bits and the devices that transmit data to a person’s eyes or transmits data over the wire. These things are actually quite similar, if one considers the storage device as similar to an actor on the wire that can send or receive data. In this sense, 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.
.sphr
extension. Such files may include multiple FHIR resources, as is typical in a Bundle resource..Observation.fhir
The .sphr
container should 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 a DocumentManifest file, which acts as a manifest and table of contents of the container.
Files containing patient health information MAY be zipped, with either a .fhir.zip
or .fhir.gz
extension. When using compression, systems SHOULD use the DEFLATE algorithm. DEFLATE is supported by both ZIP and GZIP compression utilities.
TBD
Should use NDJSON format and save to a password encrypted zip file. Please see Bulk Data Access IG more additional design guidance.
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.
Systems MAY wish to implement standard APIs for generating a .phr
or .sphr
file. Standard API queries that have been used in other systems are listed below.
# export everything from a single-user system as a FHIR Bundle
GET /Bundle/$export
# export everything from a single-user system as an NDJSON Bulkd Data file
GET /Bundle/$export?outputFormat=ndjson
# export everything from a single-user system as a PHR file
GET /Bundle/$export?outputFormat=phr
# export everything from a single-user system as a SPHR file with security
GET /Bundle/$export?outputFormat=sphr
# export everything from a specific date to current from a single-user system
GET /Bundle/$export?start=2010
# export everything in a specific date range from a single-user system
GET /Bundle/$export?start=2010&end=2020-06
# export everything for a specific patient in a multi-user system
GET /Bundle/$export?patient=Patient/12345
# post a record to another system to be imported (NDJSON format)
POST /Bundle/$import
Systems MUST post the API endpoints they use in the system’s CapabilityStatement.
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 flows below is based on encrypting files with PGP/GPG utilities, which support asymmetric cryptography algorithms and X.509 certificates.