mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-23 08:55:52 -05:00
135 lines
6.1 KiB
Markdown
135 lines
6.1 KiB
Markdown
NIP-82
|
|
======
|
|
|
|
Medical Data
|
|
-----------------
|
|
|
|
`draft` `optional` `author:vitorpamplona`
|
|
|
|
This NIP defines `kind:32225` (a parameterized replaceable event according to NIP-33) to carry secret-encrypted medical information in the form of individual FHIR Resources and a `kind:32226` to allow authorized users to share the secret to decrypt the information forward.
|
|
|
|
### FHIR and Medical Information
|
|
|
|
In FHIR, a Resource is a common base class for all types of medical information. Health care data is broken down into categories such as [patients](https://www.hl7.org/fhir/patient.html), [medication](https://www.hl7.org/fhir/medication.html), and
|
|
[insurance claims](https://www.hl7.org/fhir/claim.html), among many others. Each of these categories is represented by a FHIR Resource, which defines the component data elements, constraints on data, and data relationships that together make up an exchangeable patient record.
|
|
|
|
The following json is how a [Patient](https://www.hl7.org/fhir/patient.html) entry is represented as a Resource:
|
|
|
|
```json
|
|
{
|
|
"resourceType": "Patient",
|
|
"id": "patient:0",
|
|
"active": true,
|
|
"name": [
|
|
{
|
|
"family": "BROOKS",
|
|
"given": [ "ALBERT" ]
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
These resources can be modified by EHRs at any time and are found by the local id (`ihe-pcd` in the example).
|
|
|
|
An [immunization](https://www.hl7.org/fhir/immunization.html), for instance, is represented as another FHIR Resource as follows:
|
|
|
|
```json
|
|
{
|
|
"resourceType": "Immunization",
|
|
"id": "resource:2",
|
|
"status": "completed",
|
|
"vaccineCode": {
|
|
"coding": [
|
|
{
|
|
"system": "http://hl7.org/fhir/sid/cvx",
|
|
"code": "207"
|
|
}
|
|
]
|
|
},
|
|
"patient": {
|
|
"reference": "Patient/patient:0"
|
|
},
|
|
"occurrenceDateTime": "2021-01-29",
|
|
"lotNumber": "0000007",
|
|
"performer": [
|
|
{
|
|
"actor": {
|
|
"display": "ABC General Hospital"
|
|
}
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
### 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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
```json
|
|
{
|
|
"kind": 32225,
|
|
"created_at": 1675642635,
|
|
"content": "secret-encrypted-single-fhir-resource(Resource)",
|
|
"tags": [
|
|
["d", "resource_id"]
|
|
["e", "acfd0487aea5a7450b3481c60b6e4f87b3e392b11f5d4f28321cedd09303a748", "wss://relay.example.com", "author", "receivers-pubkey-encrypted-secret"]
|
|
["e", "acfd0487aea5a7450b3481c60b6e4f87b3e392b11f5d4f28321cedd09303a748", "wss://relay.example.com", "subject", "receivers-pubkey-encrypted-secret"],
|
|
["e", "b11f5d4f28321cedd09303a748acfd0487aea5a7450b3481c60b6e4f87b3e392", "wss://relay.example.com", "practitioner", "receivers-pubkey-encrypted-secret"],
|
|
...
|
|
],
|
|
"pubkey": "...",
|
|
"id": "..."
|
|
}
|
|
```
|
|
|
|
The collection of such event kinds will assemble a medical record.
|
|
|
|
### Additional Secret-Sharing Event
|
|
|
|
If the patient wishes to share it's record with another Nostr user (say another provider or a family member), the client must assemble a Kind `32226` event. This Secret-Sharing nostr event allows any secret-holder to share it forward.
|
|
|
|
The `.content` of the secret sharing event is the encrypted secret using the public key of the receiver. The `a` references the resource the receiver is obtaining access to and the `e` tag contains the receiver's public key.
|
|
|
|
```json
|
|
{
|
|
"kind": 32226,
|
|
"created_at": 1675642635,
|
|
"content": "receivers-pubkey-encrypted-secret",
|
|
"tags": [
|
|
["a", "32225:...:resource_id"]
|
|
["e", "b11f5d4f28321cedd09303a748acfd0487aea5a7450b3481c60b6e4f87b3e392", "wss://relay.example.com", "practitioner"],
|
|
...
|
|
],
|
|
"pubkey": "...",
|
|
"id": "..."
|
|
}
|
|
```
|
|
|
|
### Security
|
|
|
|
Relays don't have access to private key and thus cannot see the contents of this type. Client apps however, have a responsibility to NEVER display the secret in the UI and do not allow users to copy it. In order to share with a new person, that new person must have a Nostr key and receive the event via relays.
|
|
|
|
It is expected that Health Information will be kept in specialized relays due to the nature of health data-regulations. By knowing the event kind, the relay operator knows this package contains health data and may accept or reject accoding to its authorized activitiy.
|
|
|
|
### Editability of Content and Secrets
|
|
|
|
The author of a kind `32225` can not only change the resource at any time, but it can also change the secret that encrypts the content. If the secret leaks to unauthorized parties, the owner of the data can always individually reset the access to it.
|
|
|
|
It is expected that some jurisdictions require author to periodically rotate these secrets while maintaining access to the relevant people. Receivers of kind `32226` must receive a new event with the new secret to keep access to a record.
|
|
|
|
### Linking
|
|
|
|
The FHIR Resource may be linked to using the NIP-19 `naddr` code along with the `"a"` tag (see NIP-33 and NIP-19).
|
|
|
|
## Example Event
|
|
|
|
```json
|
|
TBD
|
|
```
|