By Ruby Raley, Director, Healthcare Solutions, Axway
InformationWeek’s recent article on syntactic interoperability brought to mind observations I’ve had on the subject in the last year.
It’s important to recognize that XML, open standards, and proprietary standards are just starting points for syntactic interoperability, not ends in themselves. To quote one of Axway’s senior architects, “In healthcare, standards are the common point of divergence.”
In other words, it’s where you kick things off; and if at some point you discover your organization’s needs have changed or evolved, you can just repurpose, add, or subtract fields, and customize to your heart’s content — something XML readily accommodates.
But that doesn’t guarantee that after all this tweaking you can actually send a message out and be sure the receiving party will be able to read it.
In the context of standards and interoperability, syntax cannot simply be repurposed willy-nilly. If you’re a health plan that leaves your own Health Plan Identifier field blank all the time — or if you simply take the field out because you don’t need it — the intended recipient of your message may have designated “Health Plan Identifier” as a required field in their database, so they won’t be able to receive your data. Additionally, the type of nomenclature your recipient accepts as input for the field may need to exactly match your nomenclature for the field. And when it comes to syntactic interoperability, XML does not mandate or control the ways in which fields can be used.
So how should we deal with this reality?
First, let’s define which core, mandatory fields will comprise the messages. That alone has the potential to minimize the time it takes to establish a connection from months to weeks. (As noted in the article, there are groups already at work on that process today, and Axway applauds their efforts and fully supports their approach.)
Next, consider how to treat optional fields. While “optional” to me might mean, “I won’t need that field so I won’t use it,” to you it might mean, “It’s not a key field in my database, but I need its values.” But that doesn’t mean you can repurpose the field and put any value you wish in it (i.e., a user-defined field). Instead, when using XML you must carefully think through your intentions for each field, and consider how your partners and others in the industry (the people in your community, for instance) will use them.
We have to recognize that healthcare, as an industry, is still very fragmented, comprised of a veritable patchwork of health plans, each of which has developed group fields, message styles, and usage patterns they prefer. And it’s become a Tower of Babel. Each group speaks its own dialect of a language that another group speaking another dialect of that language can’t understand.
At Axway, we believe the canonical form — a form that an HIE converts data into while defining core and optional fields — addresses this issue, defining a standard on one side of the conversation so that any healthcare provider can submit data. When another party needs that data, the HIE simply identifies the format that party requires and converts the data from the canonical form to an outbound form, one the receiving party can easily read.
It works. It’s practical. It’s common sense.
The only thing stopping the industry from leveraging the canonical form is the work it requires: defining core fields and optional fields — and their expected values / formats — and creating documentation for the entire structure.
Syntactic interoperability should be high on our list of goals, and we can’t assume we’ve achieved it simply because we’ve accounted for XML, open standards, and proprietary standards. Instead, we need to identify the real challenge — accommodating each other’s preferred method of communication using the canonical form — and bring the era of miscommunication to an end.