Damus
Open in Damus
reidsomethings profile picture
reidsomethings
@reidsomethings

Faith. Family. Sound Money. Nostr based electronic health record. https://github.com/johnsoc34/nostr-ehr

npub17g8pf3n3wcu24lhuf5wd22ct4vtsa3tpsmz7ncm680uqx4khqz9sh74jl3npub
[email protected]nip05
[email protected]lnurl
Relays (18)
  • wss://atlas.nostr.land – read
  • wss://eden.nostr.land – read
  • wss://no.str.cr – read & write
  • wss://nos.lol – read & write
  • wss://nostr-pub.wellorder.net – read & write
  • wss://nostr.bitcoiner.social – read & write
  • wss://nostr.inosta.cc – read
  • wss://nostr.milou.lol – read
  • wss://nostr.mom – read & write
  • wss://nostr.oxtr.dev – read & write
  • wss://nostr.wine – read
  • wss://puravida.nostr.land – read
  • wss://relay.damus.io – read & write
  • wss://relay.nostr.bg – read & write
  • wss://relay.nostr.com.au – read
  • wss://relay.nostrati.com – read
  • wss://relay.orangepill.dev – read
  • wss://relay.snort.social – read & write

Recent Notes

fiatjaf · 3w
If we had infrastructure for curating entries, allowing groups to vote on proposed additions and deletions and simple UIs for viewing the list of all items in a list then it would be easy to get rid o...
 reidsomethings profile picture
reidsomethings @reidsomethings
I'm building a nostr based EHR (actually two with different iterations). The ideal is getting other healthcare entities to naturally converge on a format standard without being decreed into one (theres already too little flexibility in most aspects of healthcare) . The format that more easily allows for privacy and portability of patient's own data would win.

Seems like there would still need to be a place to see what candidate implementations exist, such as staging relays, or something.



𝕾𝖊𝖗 𝕾𝖑𝖊𝖊𝖕𝖞 · 3w
The previously dulled one, it’s a cycle.
reidsomethings profile picture
Ugh I hate to say it but the virtual urgent care feature is just too vulnerable. Wide open APIs, risk of spamming the schedule, npub exposed, patient lists visible. Mitigatable but way more of a problem than the features's benefit. Gona have to chop this feature

reidsomethings profile picture
Working on adding a telehealth service that plugs into the nostr EHR and portal. Think of it like urgent care by video, paid in sats.

Also, changing portal to allow parents to choose which child's chart they're in from parents own chart. This creates lots of key management decisions. Decided on a parent grant system so parent can still message doctors office without having to switch in and out of accounts on the portal.

Will be doing a big security audit next. APIs in billing and calendar need authentication added. Also it is optional if the practice chooses to store patient nsec. If they do, will plan to encrypt by default.

reidsomethings profile picture
The Nip17 invoice DMs and the fhir rest api for connecting traditional outside medical facilities require nsec for signing and decrypting respectively. As it stands currently the practice key sits on the server in two different files. This weighs heavy on my mind and needs fixing.
My solution is a to create a separate "billing bot" keypair and a "FHIR API" keypair. These are purpose-limited identities:

-Billing bot keypair: only used to send NIP-17 invoice DMs. The key only has permission to send messages, not decrypt clinical data.

-FHIR API keypair: gets its own ECDH grants (kind 1013) just like a staff member would. It can decrypt patient data through the shared secret, but if compromised, you revoke its grants and rotate — same as firing a staff member.

The practice nsec stays offline. The risks after an exposure or server compromise goes from everything to just billing messages or read-only FHIR access depending on which key leaks.
🤙1