reidsomethings's avatar
reidsomethings
reidsomethings@NostrVerified.com
npub17g8p...4jl3
Faith. Family. Sound Money. Nostr based electronic health record. https://github.com/johnsoc34/nostr-ehr
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
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.
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.
The Nostr-based electronic health record (EHR) has now been open-sourced. It contains multiple systems including EHR, Patient Portal, and Billing/Patient Management capable of invoices paid in bitcoin. The patient portal can be used by anyone to connect your own personal private health relay and then share with the desired doctors relay. My portal can be reached at portal.immutablehealthpediatrics.com. Choose your relay, login with nostr extension, yubikey, passkey, or nsec. This is not currently an open practice but have plans for a small pediatric practice in the works. The EHR itself has a demo mode so anyone can try it out and see it. You can even add mock patients. Just download the NostrEHR-Setup-1.0.0.exe Also ignore the website, its in need of some adjusting. I'd be glad to hear what people think. Let me know if there are some changes that you would recommend (especially critical ones) or features you'd want for building better medical-sovereignty tools. https://github.com/johnsoc34/nostr-ehr
The Nostr EHR is done, polished, and ready to prep for showcase. I've added a multiuser system for nursing, medical assistant, doctor, etc. to document under their own keypair. EHR has yubikey auth login. The patient portal can use PIN, nostr signer, yubikey, passkey, or nsec for login. Tidied up the billing dashboard. Invoices will be sent by email. Invoice delivery is also set for nostr DMs but it uses NIP-4, because NIP-17 is not currently compatible with my relay whitelist. I'll have to configure the relay to allow kind 1059 events so I will likely fix this in the future.
In regards to the underlying architecture of the Nostr electronic medical record ive been working on. Stumbled upon this dual-encryption method that fits nicely into modern and sovereign documentation of medicine and further into NIP-82 as a 5th sharing mode. And I don't know how to submit a NIP lol. Im not a dev and maybe this is all dumb but i find it compelling because i have the working product sitting on my computer. @Vitor Pamplona https://primal.net/a/naddr1qq25utfjfckku3n9vcc4jtf3fdnhwcntwfxxgq3q7g8pf3n3wcu24lhuf5wd22ct4vtsa3tpsmz7ncm680uqx4khqz9sxpqqqp65wtr40h4
Yesterday did some polishing to the Nostr EHR. Bug fixes to scheduling, and patient management flow patches. Added the ability to switch relays in the patient portal without having to log out. Also, hardened up passwords and keys on the server. AI doesn't do this by default unless prompted. The last couple of weeks i have noticed passwords were being stored cleartext on the server. The billing list password was exposed on the browser JavaScript bundle. Finally got around to patching those up. Also improved some of the backup procedures. Two more major tasks and a little more polishing and I think I'll be ready to open source this: login feature using yubikey and multi user access.
I set up the telehealth system for the Nostr EHR, this weekend, using WebRTC and Coturn running over the private relay with NIP44 encryption for signaling, with patient/doctor npubs for authenticated identities. This was the most troubleshooting I've had to do, yet. Took two days of work to iron out the functionality. It was a serious headache. It now works consistently, though. Patient and doctor logging in and connecting works well now. Most of the problems were connection timing, Kind issues, and Coturn server configurations. Glad this one is done. Gona have to revisit some functionality nice-to-haves later, like the ability to change screens during an appointment, when connected by phone. But I'm calling this phase done.
reidsomethings's avatar
reidsomethings 0 months ago
The Patient Portal needs some UI improvements but this portal can be used by any patient with a nostr based health record to access to their own nip44 encrypted records whether on their practices relay, their own relay, or any other relay they want to host it. The cleartext tags do contain some metadata. Anyone with whitelisted access to the private relay can see that events exist, when they were created, which pubkeys are involved, and what type of FHIR resource it is (encounter, immunization, etc.). They just can't read the clinical content without either the practice secret key or the patient's. (I post this is for my own education and anyone else that may be curious, dev or not) image
The hardest technical challenge Ive come across for this Nostr EHR is multi user access. So much so that I think this is where the project forks depending on needs; enterprise versus private practice. Currently I'm faced with three options: 1.Shared Practice key via Nip-46 (Nsec bunker). Bunker whitelists staff npubs. Revocation of privileges possible. However, its dependent on bunker being up to publish to the relay and nsec bunker is new and untested. Any troubleshooting turns into option 2 with more steps. 2.User keypairs with the practice key. Practice key encrypted to staff pubkey. Staff logs in w nsec and stores practice key for the session. Clean and simple. Makes for low latency but now practice key is on multiple machines. Privileges are limited by UI only, which is similar to current EHRs, but cannot be revoked. Revocation of privileges requires practice key rotation, which can be a lot of work. 3.Staff signs with their own keypairs. Becomes a group of whitelisted keys and each clinical event is encrypted for the group+ patient keypairs. Clean revocation and audit trails but requires a huge architecture change since the current setup revolves around the single practice key. This would be ideal for enterprises. I'm leaning option 2 for this project but the truth is 3 sounds ideal. I'm gona think about this one a bit.
Nostr EHR: Document upload brought up a lot of flow and security questions. Ultimately set up a practice blossom server(NIP-B7). Documents are encrypted w AES-256. Copy of ciphertext goes to blossom. Aes key inserted into FHIR document reference, which all gets dual-encrypted via nip-44 and publishes to practice relay. So both the practice and the patient can decrypt the one event because of the dual-encryption. If/when a patient leaves the practice, they can go to a new practice that runs on nostr. Share their npub (like giving an insurance card). Patient shares records with provider using the providers npub, via patient portal. The portal uses the pt nsec and re-encrypts their data (including uploaded documents on blossom) for the new practices pubkey and publishes it to the new practice relay which opens up in the EMR/EHR I think this is the first patient-portable dual-encrypted health record system where a single private key gives a patient ownership of their medical history across any provider who runs the software. Whether it's useful depends on if it is adopted. But it is possible.
Nostr EHR: added queue write and sync so I can "publish" if relay is offline. When it comes back on the cache flushing and publishes to relay. EHR timeline and clinical best practices added Setting up document upload right now.
My Nostr EHR has relied on a consistent websocket connection but if the connection is lost the EHR disconnects and becomes useless until it reconnects. Today I added a caching systeming that allows the FHIR condition resources like labs, imaging, problem list, etc. to load immediately by pulling locally from an indexed database. Modified the connection indicator to show whether the EHR is caching or connected. Then did some bug fixes. Tonight phase 2, will be working on the write queue, that will queue outbound events (like encounter records) to be indexed while offline. To then eventually flush the queue when back online.
reidsomethings's avatar
reidsomethings 2 months ago
Schiff's interview with Tucker is so funny. His idea of tokenizing gold is just creating the fiat system all over again. Brother. That's literally how the dollar started.
reidsomethings's avatar
reidsomethings 3 months ago
Christmas lights followed by hot cocoa by the fireplace and a Christmas movie is a great way to finish a Christmas day. Merry Christmas. Christ is king of kings and lord of lords.