The Role of an Interop Expert

In my many years as a Standards Geek and later as an Interop Guru, one of the things that I learned is that my customers will rarely name interoperability as a core requirement.  Nor, do they want to pay extra for it. The only time they have is when it had Buzz (like FHIR does now), or mandates (like C-CDA).  And if you drill into the detail, they will rarely scratch the surface of buzz or mandate.

If you look at the work break down structure for a product, you’ll see that a product release is made up of features that are delivered by software components that have different capabilities.  If one release has 3 features (or 30, your mileage may vary), and each feature requires 3 components and each component needs to use 3 capabilities ... (turtles all the way down), then engineers will have to deliver 3^3 or 27 software components, plus glue for 9 components, plus baling twine for 3 features.  That’s a lot of work.

But if you design capabilities with reuse in mind then it gets a lot easier.  Let’s look at three features:

• When patient labs are out of range in a lab report, please flag it for my attention.
• Please route information to Dr. Smith when I’m on vacation..
• Let me know when Susan’s labs come back.

Each of these is a very distinct requirement, and yet every single one of them can use the FHIR Subscription capability (which in turn can be built over the same parts used to support search) to implement their functionality.  Each one of these follows the pattern: when this, then that.  And so the biggest piece of that is determining the “when this” ... which is exactly what subscriptions are good for.

It’s my job to:

1. Know this
2. Call it out in designs
3. Educate my teams to think this way.

It turns an insurmountable pile of work into an achievable collection of software that can be delivered.

    Keith