AFAQ Healthcare Suite

In August 2014, I was 27 years old and I did the thing every sensible person warns you against: I co-founded a healthcare software company in Amman. Not a SaaS side project with a runway plan and a pivot option. A consultancy that would ship a full Electronic Health Record system to a live cardiac hospital in Saudi Arabia, with real patients, real clinical workflows, and real consequences for getting it wrong.

We called it AFAQ. Twelve engineers. Me as Founder, CTO, Principal Engineer, Product Manager, Acting CEO, IT Manager, and Development Manager — simultaneously, on the same business card, with a salary that was effectively zero for the first year. Nobody warned me that “Chief Everything Officer” ages you in dog years.

What the suite actually was

AFAQ’s core product was a hospital-wide EHR/EMR platform: clinical, administrative, and financial modules, with full ERP capabilities. The pitch was coherence — a hospital shouldn’t need seven different vendors for seven different systems. We’d ship one platform, Jordan-built, ready for Gulf healthcare facilities mid-upgrade-cycle from paper-and-legacy to modern.

The stack was not minimal. Java EE. Spring Boot, Spring MVC, Spring Security, Spring WS. Hibernate with JPA. AngularJS and Bootstrap on the administrative interfaces. Talend ETL for data transformation. Tomcat and WildFly as application servers. PHP with Symfony and Yii for integration layers. MySQL and Oracle as primary databases. HL7 and FHIR for interoperability. And GT.M — which I’ll get to.

Too much for a 12-person team? Yes. We shipped it anyway, because when you’re the one who signed the contract you don’t get to complain about the scope.

The GT.M connector nobody else was writing

Here’s the piece I’m still proud of, a decade later.

GT.M is a hierarchical NoSQL database — the storage engine underneath VistA, the VA’s open-source EHR that’s been running in American veterans’ hospitals since the 1980s. It runs on MUMPS (now called M). Its tooling is sparse. Its documentation assumes you know a context that dates back forty years.

In 2015, nobody was writing modern database connectors for GT.M. We had to, because AFAQ needed to interface with hospital systems where the pharmacy and billing data lived inside GT.M infrastructure — and “route around it” wasn’t an option when your client is a cardiac centre and the data is clinically load-bearing.

So I read the GT.M programmer’s guide, read the MUMPS specification, and wrote connectors that made GT.M behave like something you could call from a modern Java service. Most engineers write zero database connectors in a career. Most who do write one for Postgres or MySQL, where every question has a Stack Overflow answer. Writing a GT.M connector in 2015 meant reading source code and mailing lists from people who’d been doing this since before I was born. Worth every hour.

Prince Sultan Cardiac Centre

The flagship deployment was Prince Sultan Cardiac Centre in Al-Ahsa, Saudi Arabia — a specialist cardiac facility where the KPIs aren’t quarterly growth numbers; they’re things like door-to-balloon time (the interval between a patient presenting with chest pain and an intervention beginning), medication reconciliation error rates, and duplicate test order counts.

These are life-and-safety KPIs. Before go-live, the AFAQ team ran KPI analysis across the centre’s clinical workflows — mapped the paper-based and legacy processes, identified where the numbers mattered most, then built reporting pipelines inside the EHR that surfaced the right data in the right place. Talend ETL carried the transformation load. HL7 messages handled the interoperability layer between systems.

Go-live was a Tuesday. A few nurses asked where a button moved. That’s how you know it went well.

Twelve engineers, one architecture decision a month

Managing twelve engineers while being the principal engineer on the same product is a coordination problem without a clean answer. You’re supposed to delegate technical decisions. You’re also supposed to make them faster than anyone else on the team because you’re the one on the hook for the contract. Those two things fight each other every week.

What worked: extreme specificity of ownership. Every engineer owned one thing. The billing engineer owned billing. The pharmacy engineer owned pharmacy. Cross-domain decisions went through me, and I made exactly two of them per month, max — because every cross-cutting call is a context-switch tax on everyone else.

We ran lean domain ownership before it was a blog post concept. It’s not an original idea; it’s just the thing that keeps a small consultancy coherent when the scope is wide and the team is small.

What archived means here

AFAQ ran from August 2014 to January 2017. Two and a half years. I left in early 2017; the suite was in production at the time. Whether it’s still running in some form at Prince Sultan Cardiac Centre — I genuinely don’t know. Healthcare software tends to outlive its original authors by a long margin. The GT.M connectors especially: that kind of infrastructure doesn’t get replaced on anyone’s preferred timeline.

The company was less a company than a forge. Twelve engineers came in knowing Java or PHP. They left knowing how healthcare data models work, why HL7 exists, how you negotiate a contract with a hospital IT department that has twelve layers of procurement approval, and what it costs to be wrong about an assumption at the data-model layer when your production database is Oracle and your client runs a cardiac ICU.

I came out with the same knowledge, plus a very specific set of opinions about what makes healthcare software hard — and it has almost nothing to do with the code.