By Dr. David Hay, Product Strategist, Orion Health
Twitter: @OrionHealth
I’ve always thought (and I think generally accepted) that IT projects—particularly those that involve sharing information—have a greater chance of success when the people that will be affected by the project are deeply involved with the project itself.
This is especially true in health IT, where the domain is particularly complex and the processes that could be affected tend to vary widely.
A big part of the problem is that due to the technical nature of these projects, it can be hard for the technical people involved to explain and explore the issues in a way that clinicians can understand. (In reverse, it is like trying to explain the details of how chemotherapy works to a non-clinical person.)
It was really interesting, then, when reading an article on the VA’s VistA application, to see statements like this:
“The Hardhats’ key insight—and the reason VistA still has such dedicated fans today—was that the system would work well only if they brought doctors into the loop as they built their new tools. In fact, it would be best if doctors actually helped build them. Pre-specified computer design might work for an airplane or a ship, but a hospital had hundreds of thousands of variable processes. You needed a ‘co-evolutionary loop between those using the system and the system you provide them,’ says one of the early converts…”
And like this:
“So rather than sitting in an office writing code and having the bureaucracy implement it, the computer scientists fanned out to doctors’ offices to figure out what they needed.”
As it turns out, unfortunately, the article is describing how VistA may be replaced by a commercial product, but that is as a result of management and political decisions rather than the clinical value of the product.
It’s in this communication between software engineers and end users (which, of course, includes patients as well as clinicians) that FHIR has the potential to “level the playing field” by defining a set of easy-to-understand “exchange things” (the resources) as well as describing just how you can exchange them (e.g., APIs, documents, messages). And, by leveraging technologies already well understood by the development community, it further lowers the bar to involvement in health IT from new vendors.
Further, the reach of FHIR into the sector continues to expand. For example, in the latest version that has just been released (STU-3 or “Release 3”), we have resources and operations specifically intended to support “clinical reasoning” such as care planning and decision support, and with the development of associated standards like CDS-hooks, there are even common architectural approaches that are being defined—and this is being done with the vendor community rather than being imposed on it. And, finally, tooling is being developed—like clinFHIR and Simplifier—that helps participants visualize how these work together and to assemble examples to assist the overall design process.
FHIR will allow clinicians to become more involved in the delivery of health-related IT projects: It is widely recognized that clinician-led IT projects have a higher success rate than technically led ones. FHIR represents a major standards upgrade that will boost access to health information, which will improve the access to a patient’s electronic health record.
Truly, FHIR is becoming the enabler for the health IT revolution.
This article was originally published on Orion Health and is republished here with permission.