The Standard Health Record (SHR) is an ambitious standards development project. It seeks to standardize information in every area of a person’s health, with the goal of establishing a high quality, complete, computable, integrated health record. “One human, one health record” is our primary goal, but we know data standardization is the key to enabling ALL downstream information uses: healthcare data exchange, aggregation, care delivery, safety, decision support, analysis, reporting, and research.

It is a big job. ICD-10 distinguishes over 12,000 disease categories. There are approximately 100 medical specialties and numerous sub-specialties. But in the words of Dr. Stan Huff, if we have to boil the ocean, we’ll do it one bucket at a time. To this I might add: we need more buckets and bigger burners. By that I mean, not only do we need more parallel efforts, 10 or more at a time, but each effort must develop standards 10 times faster (not to mention, 10 times better) than the healthcare community has ever done, so collectively, we move 100 times faster than ever before.

Think about the traditional HL7 work group process and how it meanders and drags on for years at a time, often ending with a paper product, not a computable, testable artifact. While FHIR has moved the needle on this, FHIR profiling still depends on painful, one-at-a-time, hand crafting. That isn’t going to get us there.

The Clinical Information Interoperability Council (CIIC) is a new initiative to increase the number of simultaneous domain-specific standards efforts. That’s more buckets. There is a significant amount of clinical content already in SHR, and thousands of clinical models at openCEM.org, and that’s a significant amount of water that’s already hot.

What about bigger burners, capable of bringing all those buckets to a rapid boil? There is no doubt that the process of building consensus among a broad group of stakeholders takes time. But the glacial pacing of the 4-month ballot cycle is deadly. We need to accelerate the process of building and testing information models. The methodology needs to be aimed directly at domain experts, not informatics geeks (like myself). It must enable those experts to express their clinical information needs simply and directly. It must make that process fast, transparent, and agile. It must allow creators to see the implications of their choices, notice the shortcomings quickly, and make corrections trivially.

As a community, we’re terrible at discovering and stamping out bugs in our specifications. It’s 2017, and still our primary method of quality control is reading ballot documents and perusing class diagrams. In my experience, that’s almost totally ineffective. Actual hands-on use is the only effective way to understand our own creations, and find and fix flaws. To speed up standards development, prototypes must be automatically generated from specifications. Every proposal must be immediately turned into testable software. As humans, we will always make mistakes and take many iterations to get things right. If we can’t reduce the number of iterations, at least we can make the iterations faster.

If we really could capture and test out our ideas immediately, we might be able to do a model iteration per week, instead of one iteration per 4-month cycle between HL7 meetings. That’s 10x right there, and then we’re cooking with gas. And that’s the only way to boil the ocean.