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.

The idea is to decentralize medical information. Today medical data is either in the hands of the government or in the hands of gigantic private enterprises. Patients don't have any access, or control, over their data. That has to change. And Nostr can make it happen.

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, medication, and insurance claims, 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 entry is represented as a Resource:

{
  "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 (patient:0 in the example).

An immunization, for instance, is represented as another FHIR Resource as follows:

{
  "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 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. 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 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. 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.

{
  "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.

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.

{
  "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

TBD

6.4 KiB Raw Blame History