Mirror/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-12 18:36:24 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Text modifications to facilitate reading.

Browse Source
This commit is contained in:
Vitor Pamplona 2023-03-12 21:37:39 -04:00
parent e4f9ba4883
commit bf98444f52
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
82.md
View File

@ -29,7 +29,7 @@ The following json is how a [Patient](https://www.hl7.org/fhir/patient.html) ent
}
```
These resources can be modified by EHRs at any time and are found by the local id (`ihe-pcd` in the example).
These resources can be modified by EHRs at any time and are found by the local id (`patient:0` in the example).
An [immunization](https://www.hl7.org/fhir/immunization.html), for instance, is represented as another FHIR Resource as follows:
@ -63,13 +63,13 @@ An [immunization](https://www.hl7.org/fhir/immunization.html), for instance, is
### Inserting FHIR Resources into NOSTR
Medical Data in NOSTR must be encrypted in a way that allows providers and patients to reshare their medical information to other individuals. The consent to access a medical record is established by having access to the individual secret that encrypts each fhir resource.
Medical Data in NOSTR must be encrypted in a way that allows providers and patients to reshare their medical information to other individuals after the event is broadcasted. The consent to access a medical record is established by having access to the individual secret that encrypts each fhir resource.
This NIP uses a **secret-encrypted** parameterized replaceable event to represent each individual FHIR Resource in the `.content` of these kind `32225` events. Similar to NIP-04, `.content` MUST be equal to the base64-encoded, aes-256-cbc encrypted JSON-serialized representation of the Resource using a newly created 64-byte secret.
This NIP uses a **secret-encrypted** parameterized replaceable event to represent each individual FHIR Resource. Encrypted content is placed in the `.content` of these kind-`32225` events. Similar to NIP-04, `.content` MUST be equal to the base64-encoded, aes-256-cbc encrypted JSON-serialized representation of the Resource using a newly created 64-byte secret.
The `d` tag must be equal to the FHIR resource id and the author of the event must be the data holder, the controller of the uniqueness of resource ids (generally a hospital or an EHR system). The provider that is filling the resource, should be included as an `e` tag. The subject of the resource (generally the patient), must be tagged with another `e` tag. Markers must be equal to the field names in the resource.
The `d` tag must be equal to the FHIR resource id and the author of the event must be the data holder, the controller of the uniqueness of resource ids (generally a hospital or an EHR system). The provider that is filing the resource, should be included as an `e` tag. The subject of the resource (generally the patient), must be tagged with another `e` tag. Markers must be equal to the field names in the resource.
A 5th parameter per `e` tag contains the secret to decode the `.content`, encrypted to the pubkey of each `e` hex. By default, the contents of a resource are available to all cited in the FHIR resource. From the sender's perspective, the secret is stored in an `e` tag with the sender's public key. Secrets are thus not saved anywhere else but in the message itself.
A 5th parameter per `e` tag contains the secret to decode the `.content`. Each secret is encrypted to the pubkey of each `e` hex. By default, a resource is accessible to all cited entities in the FHIR resource. From the sender's perspective, the secret is stored in an `e` tag with the sender's public key. Secrets are thus not saved anywhere else but in the message itself.
```json
{