“Conversation from the Sidelines” is a new series at Lantana’s blog. We’ll share experiences from conferences or events that gave us a different perspective on the industry.

First up, the HL7 January 2016 Working Group Meeting (WGM) in Orlando, FL. gave me an opportunity to fill-in for Crystal Kallem as an Interim Co-Chair for the Clinical Quality Information work group. It was also my first HL7 FHIR Connectathon.

King Co-Chair for a Day Week

For readers not familiar with the workings of HL7, each work group or sub-committee has two or more co-chairs. These co-chairs make sure the work group functions smoothly. They conduct and direct meetings, lead discussions, and ensure HL7 rules and regulations are followed correctly. HL7 calls this a “healthy” work group.

The CQI work group held an impromptu vote, and suddenly I was a co-chair. This may give the impression that becoming a co-chair is easy. Assuming my role, I could call on 3+ years of participation and observations from these meetings. Still, a small part of me hoped the committee had made a mistake.

Co-chairs plan and assess the week’s agenda. As a work group member, I had drifted in and out of agenda discussions. This time around, I focused on understanding every discussion topic for every session; especially those under my jurisdiction. The advantage: I felt incredibly informed about work done by the committee. The ability to drive the discussion is essential for a co-chair.

Perhaps the most obvious aspect of co-chairing is leadership. Co-chairs direct both the agenda and the discussions. Ensuring the entire work group can participate, however, can go unnoticed. At times, HL7 meetings can get hijacked by a few members – they understand the issues, dominate discussion, and contribute valuable insight, but there cannot be real consensus when more than half the work group doesn’t follow. As a work group member, this is always frustrating. As a co-chair, I used my position to pause and simplify the discussion for everyone.

After a week, I felt connected, well-informed, and encouraged about bringing my brand of leadership to the work group. Suddenly, serving as a co-chair wasn’t about more ‘work’ and contributing to the organization, but about personal ‘growth’.

FHIR Connectathon 

The FHIR Connectathon takes place on the weekend preceding the week of the conference, for which I had given up my Friday and Saturday nights. Obviously, I had a lot on the line! Connectathon 11 was my first, meaning I was officially late to the FHIR show. I wasn’t sure how to prepare because I didn’t know much about FHIR or the tracks. Word of warning for first-time attendees: this event is notoriously overwhelming.

A veteran among the Connectathon crowd, Rick Geimer warned that I should “get there at least 30 minutes early because the Connectathons regularly fill out…and make sure you grab me a seat!” Sure enough, the conference hall was already 75% full when I got there at 8:40PM (delayed by 10 minutes because the hotel was a maze).

Within the first hour, I was connecting to FHIR servers and pulling down resources (remember, without any prep). By mid-day, I had run the test use cases for the track I was focused on (the CDS-Hooks Track). At the end of day one, I had all of the basic pieces for the track. By mid-day on Sunday (the end of the Connectathon), I had a working client implementation.

It’s exciting how simple it is to get a working client in FHIR. I had always been told FHIR development is faster because the syntax is simpler than CDA and V3. Or perhaps the resource model was easier to work with, as opposed to CDA’s document paradigm. Others say it’s because the documentation is much simpler to read and access than 900+ implementation guide documents (I’m looking at you, C-CDA R2). Healthcare data is fundamentally complex, and FHIR can’t fix that. There are more than 90 resources in FHIR already. That’s a daunting number, and I struggle to accept that rationale.

The Connectathon really made this rationale come together. FHIR development is faster, but not because of the simpler syntax or data types. It’s not the resource model or the REST-based architecture. It’s not the documentation. The reason is the sum of these small to medium improvements. Lots of technologies are easy to get started, but falter at a later step. Each component of FHIR is a part of a system – a system of small improvements that vastly improve the end result. The rapid progress you make delivers a powerful psychological boost. That momentum is addictive. Now I know why so many people are FHIRed-up!