That's still better than a lot of healthcare software. I have no issues with it running PHP, CVS is more of a hassle for devs. My current EMR only recently came out with a UI that works outside of IE and their proprietary ActiveX controls.

Hey, at least it's not MUMPS. And CVS? Compared to certain other EHS software, that's luxury.

I thought Epic was migrating to dot net?

The frontend / client app, yes. The backend DBMS and business logic called Chronicles is still written in M aka MUMPS.

OpenEMR collaboration happens on GitHub: https://github.com/openemr/openemr

Yeah it started in CVS in 1998ish :-p

If it ain't broke, don't fix it.

Not sure how I feel about my medical information being handled by PHP...

This won't make you feel any better...

Many healthcare systems are a COBOL-dialect all the way at the bottom. Some of these had PHP layers shimmed in, when the web became a thing.

I've seen php scripts that shell out to .bat's, that interface with the COBOL engine. It's a mad world.

For context, a large amount of healthtech software was written in the 80s (kind of like fintech, the difference is that there's no competitive advantage to having better technology in health).

It's a minor miracle that anything works at all.

I showed someone from the Allscripts innovation group what I could do in an Elixir repl once, and his jaw hit the floor. Then I showed him how we wrote parsers. He said we'd never make it because we turned around new features too fast for anyone to trust us.

Haha, among the most popular EMR you'll find a snarl of Perl, PHP, VB, Mumps/M, C#, old Java, cobol, and several proprietary languages. There is a small number of people who die in the US every year do to medical mistakes attributable to software bugs.

Would it make you feel better to know your PID is being stored in a database language where the only data type is strings, and there is an intrinsic command to interpret any string as code?