So, it started out like this.

I’m a tech lead and I’m always on the hunt for clients to work with. Ever since the lockdown ended haven’t found much in the way of work. I’m always on the hunt for those “boring” problems to solve.

I came across someone on Mastodon who was asking for something to manage patient records for her daughter–a system where she could print out a summary of tests, and go to her doctor with a printout – all self-managed.

She was genuinely interested in me building something for her. But when I quoted out what it would cost, she admitted there was no way she could afford it.

But that got me thinking–there really isn’t a good patient medical portal for the patient. The most popular one is MyChart (linked; IMO it’s definitely decent), but what happens of you switch providers or lose your insurance? Your MyChart account is no more.

So I’d like to get peoples’ input. Would a self-managed patient portal on the fediverse be something you’d use? Of course it would be open source and e2e-encrypted, so that the server host wouldn’t have access to the data.

The fediverse would also allow the project to be profitable…hospitals can pay for a special branding license, but all of the patient data is yours to keep and take it to other doctors while keeping the service free and open source.

What do you all think? Would you use something like this?

  • @babboa
    link
    English
    52 years ago

    MyChart (or care everywhere which is the provider facing interface) is already searchable by other providers from within epic, all they need is patient permission. I can see labs, notes, and interpretations of imaging, though admittedly no actual imaging from other hospitals, etc… Due to the sheer volume of data transmitted for CT scans and MRIs and the different image processing systems used by various hospitals. The data doesn’t disappear when you change providers, but rather it stays stored and accessable to help ease that transition. As to worries about it disappearing, CMS already requires keeping records for 7 years and many states mandate 10 years plus a day, which at that point those records are often of marginal value at best for any current care anyway. In practice, at this point I’ve seen records 10+ years old in systems that transitioned back around 2010, including records that were uploaded into epic from their previous emr. All that being said, we do need a stronger push to a standard set of communication between emr systems. That ball got rolling in earnest with the 21st century cares act but the actual implementation is still ongoing for most systems(anything emr related often moves at a relatively glacial pace in part due to the HIPAA concerns as someone else expressed), but we are already seeing things like pharmacy prescription data getting pulled in.

  • @wabafee
    link
    English
    3
    edit-2
    2 years ago

    Sounds interesting though it seems like a lawsuit waiting to happen, medical data tends to be very personal and some countries have laws preventing people from sharing this information. Being in fediverse would mean implicating multiple server owners if information is potentially leaked. If it does not scare you, go for it I think it has potential.

    Edit: Disclaimer not a lawyer or a medical personnel

  • @[email protected]
    link
    fedilink
    English
    22 years ago

    I think a client program is a much simpler route — that is, you don’t really need cooperation with providers nor software vendors (with the myriad of headaches that comes with) unlike with the fediverse proposal.

    A client could simply connect to the MyChart server of your provider, display the data, etc. The data could be downloaded and cached, in the case that you switch providers or the MyChart server goes down for whatever reason. In this way, the data is there on the patient’s computer for their viewing pleasure.

    Of course, interfacing with the APIs of MyChart and other portals might not be easy, but it’s certainly easier and more viable than constructing a totally new infrastructure of these portals using ActivityPub.