Please don't shoot the messenger here, but your doctor and insurance company are very likely already using the web to exchange information about you. You can either have that in a way that is standards-complaint and vetted by a large group of browser engineers, or they could try to roll their own... which would you prefer?

I can argue that it's easier to architect an intranet web medical data viewer right now than a typical desktop application accessing an intranet server.

Client-server desktop applications typically use custom protocols and custom servers leading to a higher likelihood of security issues.

They're harder/slower/trickier to update and administer within a big organization, leading to a higher chance of messing up.

Whatever security issues you can think of running it in a browser context, more exist when running it as native code.

If you run an intranet web service with the same security precautions as a public web service, which is currently very well explored, there are less things to go wrong.

Factually we're already there. I've reviewed my own HIPAA-sensitive lab results in a patient portal for example. I'd go check out some of the solutions Epic Systems has put out if you're interested in current product offerings in the space.

Information wants to be shared, collaborated on, and worked on in real-time... both private intranets and/or public internet provide platforms to do this.

Perhaps, but keep in the mind that Intranets exist. It is possible to have 'private' web services.

It’s actually mandated now that providers allow free, on-demand, API access to patients for their medical data.

Yes, I do. Not all medical info need privacy.