You are overthinking.

1. The spec has ways to reset access to their info. Read it.
2. Relays are not required to hold the data, that's why it's a specific kind just for that. They can choose if they want to take in the operational liability.
3. By that stance, Nostr doesn't provide anything to any use case, including social networks. Seriously...

1. Resetting access is not a thing because if they have the secret and the old event encrypted with that secret they can decrypt it anyway. It's only allowing you to prevent access to new data.
2. They are not. And clients are going to assume they are going to anyway. And lots of users are going to complain when these events are erased.
3. I don't see why it needs to be censorship resistant (if you are talking about censorship resistant transmission, a lot of methods exist)

About the goal: Nostr will not make this happen. What makes this happen is that either:

• laws get passed requiring patients be able to view and correct this information
• the public pressure is too high for a way to view and correct medical information

Nostr does not help achieve this goal. I believe that it makes it easier for medical records to accidentally get leaked: accidentally posted your nsec and oops... all your records are leaked

About the goal: Nostr will not make this happen. What makes this happen is that either:
laws get passed requiring patients be able to view and correct this information
the public pressure is too high for a way to view and correct medical information

I completely disagree. I think that is what people have learned to believe. Laws help, but without solutions in place, they will never achieve anything. If you live in the US for instance, you are supposed to be able to get your COMPLETE medical record from providers. The law is there. The public pressure is there. Yet, no one can get access to it. They don't have a way to do so. Software is what gives people the power to get their control back.

I believe that it makes it easier for medical records to accidentally get leaked

Then help me develop ways to reduce that risk.

I completely disagree. I think that is what people have learned to believe. Laws help, but without solutions in place, they will never achieve anything. If you live in the US for instance, you are supposed to be able to get your COMPLETE medical record from providers. The law is there. The public pressure is there. Yet, no one can get access to it. They don't have a way to do so. Software is what gives people the power to get their control back.

Better solutions should be explored.

I have explored them for the past 15 years. It doesn't work. This might.

Hi Thomas,

Nostr can't be used as a storage or backup service as @Semisol said above, or you'll need to run your own node to be sure the data is stored somewhere.

That's not the idea of the spec. We are using nostr to transmit data, not to store it. But if people want to put up a relay to store it or pay for such services with specialized relays, they can definitely do it.

All data are publicly accessible.

False.

Maybe a day, the encryption algorithm will be broken.

Then the Medical Data provider simply resets the secret that is encrypting the data and re-encrypts everything.

Maybe a day, in the panic because of his sickness, the patient will publish data publicly or directly his own private key

There is no mechanism to publish the data without encrypting it in the spec to avoid users making such mistakes.

Then the Medical Data provider simply resets the secret that is encrypting the data and re-encrypts everything.

You seem to not understand that previous versions of the event can be decrypted and even that can be pretty damaging.

There is no mechanism to publish the data without encrypting it in the spec to avoid users making such mistakes.

User revealing their public key

That's not the idea of the spec. We are using nostr to transmit data, not to store it. But if people want to put up a relay to store it or pay for such services with specialized relays, they can definitely do it.

What makes using Nostr as a transport better than using P2P?

You seem to not understand that previous versions of the event can be decrypted and even that can be pretty damaging.

I do. But finding a way to merge the correct versions of past events so that one can make sense of the information is harder than it looks.

User revealing their public key

That does not do it.

What makes using Nostr as a transport better than using P2P?

Record linking.

This looks good to me. I have no knowledge about these medical things, but I don't see why Nostr can't be used. Nostr looks like a great fit, in fact. Nostr relays can be used as "portable private cloud" servers by users as long as they are ok with that (as NIP-78 shows).

Vitor seems to be knowledgeable on the topic and the solution is very elegant at first glance, so why not?

I apologize for getting into the discussion. I am interested in the fact that if the secret key "leaked" and an event was created and sent to replace the secret, then the data encrypted with the old secret does not disappear. This means that an attacker can decrypt at least the old data. What thoughts does anyone have on how to reduce this problem? You can require relays (especially since it is proposed that these will be specialized relays) to delete old data. But it is possible that there will be relays that will purposefully collect all the events of this NIP so that even old encrypted data can be sold on a dark market at any time (just for cases when the secret key leaked).

Also, for sure, there will be a large percentage of cases when a key leak is detected too late. And also, what if the attacker is the first to create an event to replace the secret key, having the key in his hands after the leak?

P.S. Perhaps Shamir's scheme would somehow fit here. I am not an expert in cryptography, but if the secret key would be formed according to the Shamir scheme, for which the minimum threshold would be equal to minim 2, then the key replacement procedures would require at least two sides. You can even go further. The owner of his data could have two keys - one in the phone, the other on another device so that he could control the key replacement procedures himself, for example, without requiring confirmation from the other authority. And in other cases, the client could operate with one of the two keys, and the second key would be from another authority.

I apologize for getting into the discussion.

Your feedback is very welcomed.

I am interested in the fact that if the secret key "leaked" and an event was created and sent to replace the secret, then the data encrypted with the old secret does not disappear.

Relays are already supposed to delete the old event as per NIP-33. If they are bad actors, and keep it for the sake of leaking information, there might be legal liability for doing so. But keep in mind that relays don't have access to the secret unless they get a hold of the user's private keys. They will need to have a bigger operation if they want to do this dark-market business plan.

But it is possible that there will be relays that will purposefully collect all the events of this NIP so that even old encrypted data can be sold on a dark market at any time (just for cases when the secret key leaked).

Correct. This can still happen. But it can happen in any cryptographic scheme. If your keys leak, whoever has access to it can save them forever. That happens in P2P as well as with current healthcare systems. I am not sure if there is anything that can protect info AFTER the key has leaked.

The spec makes it a little harder to assemble the information because each little FHIR Resource has its own secret. And alone they don't represent much. Each secret is not saved anywhere but in the event itself. So, the only way to assemble somebody's data is to have all secrets (access to the authorized user`s private key directly).

Also, for sure, there will be a large percentage of cases when a key leak is detected too late. And also, what if the attacker is the first to create an event to replace the secret key, having the key in his hands after the leak?

Health data providers will likely rotate secrets, and potentially the keys themselves, frequently (every 3 mo or so). We will need to manage that rotation separately.

I am not an expert in cryptography, but if the secret key would be formed according to the Shamir scheme, for which the minimum threshold would be equal to minim 2, then the key replacement procedures would require at least two sides.

I expect the use of multi sigs from health providers, but done directly in the Nostr event (sum of public keys is the pubkey of the event). I am not sure if other methods would add much.

Better solutions should be explored.

Go for it!

Relays are already supposed to delete the old event as per NIP-33. If they are bad actors, and keep it for the sake of leaking information, there might be legal liability for doing so. But keep in mind that relays don't have access to the secret unless they get a hold of the user's private keys. They will need to have a bigger operation if they want to do this dark-market business plan.

What prevents someone from stockpiling encrypted events to compromise them for one point? They can request all of them, or all the ones that could be related to their target

Key rotation times are also not instant most of the time so there is still a window between key leaked and user discovers and key changed to every relay deleted it

I think incentives for medical relays could be aligned. Hospitals / medical providers / insurance companies would need to subscribe to them. Medical relay operators could expect to charge a higher operational premium, particularly if they provide record storage for subscribers. Medical data is becoming quite expansive in size due to genomics, high resolution imagery, and other large data set diagnostics.

This could very much work, but will take large investment and require coordination across the medical industry, and require alignment of local, regional, and federal municipalities on a standard of record keeping.

If I was pitching to medical companies, the selling point would be data storage and regulatory compliance. Their costs go down (data storage and data security compliance), when someone else takes responsibility for storing and safeguarding patient data.

What prevents someone from stockpiling encrypted events to compromise them for one point? They can request all of them, or all the ones that could be related to their target

Yep, they can. In the same way they can download all dms today. We can make it harder by adding an additional off-relay password if you want.

Key rotation times are also not instant most of the time so there is still a window between key leaked and user discovers and key changed to every relay deleted it

Yep, similar to what happens in regular systems today if a user's or a provider's password leaks.

I think incentives for medical relays could be aligned. Hospitals / medical providers / insurance companies would need to subscribe to them. Medical relay operators could expect to charge a higher operational premium, particularly if they provide record storage for subscribers. Medical data is becoming quite expansive in size due to genomics, high resolution imagery, and other large data set diagnostics.

More importantly, medical-providing companies can put encrypted info in relays, allowing other research teams to request access directly to the patient (maybe with a Zap?). If patients give consent for every new share, HIPAA's Covered Entities & Business Associate rules won't be needed anymore. No more data sharing behind our backs.

I have little experience in the software field, but as I work in the medical field I know there are many places in the world where people are still holding physical printouts of their records (imaging results, blood tests, referrals) and have to bring them to the doctor's appointment, the doctor usually has only 15-20min per patient with almost no communication between specialists and hospitals. I know personally of people being sent back and forth between different doctors who are all missing pieces of the puzzle. Those places would benefit greatly from what you are suggesting. I agree that you need this to be very secure and to think of possible attack vectors and leaks. Ultimately I think that whatever you are discussing it would be better than what is already there. I can't comment on the technicals, but this is something I would want to use for sure.

Concept NACK

JonKolbeinn good point but for me it highlights a completely different view of the problem. The industrialisation of medicine is a failure, and it seems no innovation ever quite completes the puzzle, but always promises to - just one more innovation and we'll be there... Proof: hospitals are getting bigger when they should be getting smaller, if they were delivering on their promise.

I work in healthcare too, and it seems to me this entire direction of travel is making matters worse. We have a repeat-business generation system that sustains itself on creating as much misery as it relieves.

We all want to fix medicine, but that means we must always bring our thinking back to what its primary purpose is. Please note also, the job of a medical provider is not to cure you, it is to discharge you. And if that sets you up for the next visit, your hospital will do well.

Hence clinics like mine are victims of their own success. I will forever remain a one-man operation, because I solve people's problems and they move on. There are millions of clinics like mine all over the world, quietly delivering what patients really want. And in the last three years, I've gone back to paper records, paper diary, hand-typed letters and minimal referrals - and all based on one simple principle - knowing my patients. I may see as many in a week as my colleagues see in a day. And the problems they come with are no less challenging than those presenting to world-class oncologists and orthopaedic surgeons, but the satisfaction level seems to be at least as good.

There is scope for many more clinics like mine in the world. We probably should be the majority - because patients like us and they get proper results. Proof: they pay with their own money, and they send others. But we are actively kept down, and that's a matter for politics.

This may seem tangential but you've touched on THE crucial aspect, which is patients getting looked after properly, which is all I care about. If the immediate problem is IT then there are no end of fixes.

But taking the 40,000 foot view, I really think dragging the patient further towards reduction to an entity in an information flow - at the cost of their privacy, autonomy and individuality - is actually making matters even worse not better for them, when clearly these issues are problems of our making not theirs. This sort of administrative direction has failed, and, if we're serious about outcomes for the most important person in the hospital, needs to be abandoned altogether, not fixed.

Just my tuppence worth. Other opinions are available.

Packer0631
I see your point, thank you for your insight. I agree with what you say but I’m not sure I fully understand how we are reducing patients to information entities. What I was trying to convey was that all this data that is attached to patients is valuable information for the clinician. If this information is owned by the patient and is secure, I don’t see it opposing the points you mentioned (which are all valid). Perhaps you are telling me, and please correct me if I’m wrong, that IT solutions won’t fix a problem that requires a change in us (doctors).

Perhaps you are telling me, and please correct me if I’m wrong, that IT solutions won’t fix a problem that requires a change in us (doctors).

Yes that is exactly what I'm saying. But to try and be helpful, I'll elaborate. Read on only if you feel an urge!

Without trying to divert the thread too much I'm saying the need for fully integrated data handling system is a symptom of some other problem. I would argue that most information thought to be clinically important is actually irrelevant to the subject of getting the patient back to health and thereby dealing with disease from that perspective, rather than combative sickness care and symptom management based on methods which which actually create disease not solve it.

Conversely, the most important information time and time again is often not even asked, let alone recorded, and IMO an awful lot of avoidable failure happens as a result. Something doctors find very hard to accept is that for all their brilliance, they are for the most part looking at health and disease in completely the wrong way.

The relevant bit:
so my proposal is that before thrashing out the solution, we need to be sure we understand the problem. A bit outside the scope of this thread I admit, but perhaps what we need most is a broad outcomes-based audit of what kinds of data are being collected, and why, which will of course then demand questions about the kind of care direction in which we are heading. Which clinicians are asking what sort of questions and which have the best outcomes, in both acute and non-acute settings. (And to my mind, a good outcome means the patient lives to 100 enjoying life to the end, but these are values to thrash out also). I know a lot of industries will be very uncomfortable about this, because I believe they already know the answers, but pleasing them is not my aim. But at that stage we can then decide which data solutions are really needed. We'll probably find, as I have, that pen and paper and knowing your patient is a system that in fact cannot be beaten.

I truly understand the urge to solve the entire problem, but I suggest we keep things simple. When problems are too big, no solution ever emerges.

At this point, we should be looking for the most effective use cases to be coded in Nostr, if any. Maybe having a badass Cancer Survival badge is a starting point. Maybe the best starting point is to code FHIR questionnaires in Nostr so that data collection work from one hospital can be directly seen by another hospital (as soon as the patient consents), etc. Health care is full of simple use cases we can use at this stage. Which one is best?

This is a huge improvement over fax machines and email. I wholly support it.

If merged, then kind 32225 should be protected by relays enforcing NIP-42 authentication.

Concept NACK.

I think the problem of patients not being in control of their data and data not being distributed enough within the medical sector can be solved in ways which are more efficient, effective and secure than using nostr.
(Please correct me if I understood the motivation for this NIP wrong.)

Medical data is highly sensitive and thus a lot of regulations apply to it. Therefore, I think this is better handled using centralized solutions since this regulatory environment already requires centralization to enforce laws; do security audits etc.

Using nostr for this information seems to just distribute the responsibility to handle this data correctly.
Who will be held accountable (and thus, incentivized) if something goes wrong when nostr is used? The author of this NIP? The relay operator? Management who said we should use nostr for this data?
In my mind, using a decentralized solution like nostr would just lead to a lot of "finger-pointing" when something goes wrong and thus decrease the efforts to handle this data responsibly in the first place while at the same time not leveraging any of the properties nostr has. I don't see how "it's easy to spin up a relay", "it's hard to ban users", "it's open source" or any other property related to nostr makes nostr stand out as a possible solution.

Better solutions for this problem would be to lobby for better regulation in favor of patients.
As far as I am aware, this is already happening even though slowly.
For example, in Germany, patients can request their full data from their health insurance since 2021 [1].
In 2015, new chip cards have been introduced to distribute this information more easily (and secure!) within the health care system. [2]

I also don't see how this regulatory environment would ever approve of using nostr instead of just creating a own dedicated solution (which can be a fork of nostr). I think there are reasons why email and fax machine are still used as mentioned by this comment and I think this NIP doesn't not reflect on these reasons.

I also think if (some form of) nostr would ever be used in healthcare which is controlled by centralized institutions, they would just come up with their own fork, discuss requirements among themselves and completely ignore this NIP here.

[1] https://gesund.bund.de/en/topics/electronic-health-record-epa
[2] https://gesund.bund.de/en/topics/electronic-medical-data-cards-egk

Folks, Nostr will host medical data (and many other sensitive datasets). The PR is not asking if Nostr should, it's asking HOW we want to do it.

First time commenting on a NIP. I don't disagree with the concept @vitorpamplona, this was being explored as part of the UMA group a few years back (and it is somewhat there still) https://en.wikipedia.org/wiki/User-Managed_Access -now, this never really took off for many reasons. I think Nostr has the capabilities to achieve what the "UMAnitarians" wanted. I think it is good to explore the possibilities. Do not shy away from this, others will do it in a more centralized manner anyway which you can make the argument can be scrutinized even more in a negative way. This gives patients more control over their data. Now, we should be cautious when dealing with peoples lives and we are not ready for that yet, but we should start. Let's concentrate on Identity and how to generate "Sats" beyond Zapping. Don't shoot me on this statement, but a good "ad" framework is necessary.

Update: I didn't realize FHIR mentioned UMA: https://build.fhir.org/security.html - been away for some time.

Hi, is this PR still active? I may implement NIP-82 in my own wallet implementation. I already have cashu tokens implemented and have a simple private record storage and retrieval. This would be straightforward to implement.

Thanks.

Hi Tim, I just updated it.

We moved away from the two events to encode and share secrets and started to use a regular event 82 to just place FHIR content into it.

Then that event can be shared:

1. as is, without any encryption,
2. via one-time wraps using kind 1059,
3. via nembeds inside NIP-17 with additional text around them,
4. using the 32225 kind that allows resharing and viewing permissions to change over time.

Kind 32225 is likely to be used inside EHRs and systems that need to manage the editing of a bundle in a short amount of time. The others are designed to send communications back to patients and other providers via DMs/wraps.

@vitorpamplona - thanks! I'll be looking at closely to see if I can implement.

@vitorpamplona - thanks! I'll be looking at closely to see if I can implement.

Awesome! Feel free to suggest improvements. We are still early and can change things around.

Hi, @vitorpamplona is this NIP going to accepted, soon? I am working on an implementation.

As soon as we have more supporters :)

We can still change some things here and there if you need to.

@vitorpamplona I should have something generic to show at the call next week. I am building in a generic framework first to accommodate the requirements stated in the NIP. Not yet focusing on the FHIR formats as that is a matter of implementation. I am designing such that a doctor who has a wallet can provision to a patient has the same wallet (their own instance, of course) I have created a 32227 kind event that indicates consultation records that a doctor has generated but has not sent/finalized for the patient. Once the consultation is finalized they are sent to the patient's wallet as above and the 32227 records are deleted. Not sure if this is the right way to go, but it is working. Implementation is requirements discovery!

Hi @vitorpamplona I'm a physician who has been building a Nostr based electronic health record system. Early in the process I stumbled upon this dual-encryption approach that complements NIP-82 nicely. Each clinical event gets encrypted twice via Nip-44: Once to the practice pubkey ("Content") and once to the patient's ("patient-content" tag). This allows for a single event the patient and physician both have access to independently decrypt using their private keys. My current system has an EHR and patient portal and includes multi-user staff access with their own keys tied to the practices so they can document, all connected to a private nostr relay. If this is useful, I'd be glad to expound. I've open sourced it with the help of Claude AI, here: https://github.com/johnsoc34/nostr-ehr,

Hum... there seems to be a lot of conflicts with existing events for your new kinds. Maybe you will need to rotate to new numbers.

Other than that, you might want to write a new nip and send it as a PR defining exactly how things are stored and encrypted.