reidsomethings

"I hate AI (I love it)" https://youtu.be/dbMXi9q78Tk?si=d_6PObNHAVXhtoQW

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.

Here are some preview photos of NostrEHR, Patient Portal, and Billing system. https://github.com/johnsoc34/nostr-ehr/blob/main/README.md

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/naddr1qq25utfjfckku3n9vcc4jtf3fdnhwc…

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.

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)

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.