Staying Focused While Tackling Complexity

Throughout the 80s and 90s, people like Steven Huesing – the founder of this magazine – worked tirelessly to advocate for the need for interoperable systems to provide clinicians with the information they need. I’ve always felt humbled by the industry luminaries that came before me who had the foresight, passion and knowledge to recognize the impact that information (or at the time simply “computers”) could have on improving the lives of Canadians.

In so doing they paved the way for people like me, entering the industry in the early 00s at a time when governments across Canada we’re coalescing around the need for health information standards and a national EHR.

I wish I could tell our predecessors that designing interoperable systems and selecting supporting standards has gotten easier. Over the years the “separation of concerns” has appropriately facilitated breaking complex system needs into numerous individual components. In turn, this has led to an exponential increase in the number of different software and hardware components required to support large-scale interoperable systems. Every point of separation comes with its own unique challenges in helping ensure each component of the systems can “talk” to each other. Couple this with 30 years of legacy systems and data, and you have the perfect storm for increasingly complex design decisions.

In Canada, the vast majority of our jurisdictional EHRs support a variety of health information standards (HL7 v2 messaging, HL7 v3 messaging and Clinical Document Architecture) within different domains (lab, pharmacy, diagnostic imaging, etc.) and buried in the exchange standards are a myriad of different terminology standards. The vast majority of these have been implemented using SOAP-based web services in an architectural paradigm that is sometimes referred to as “server-to-server”.

Meanwhile, RESTful interfaces have been rising in popularity and represent another architecture paradigm for implementers to consider. RESTful implementations provide simple, out-of-the box interoperability. Predefined CRUD (create, read, update, delete) operations and searches leveraging HTTP: POST, GET, PUT, etc. However, it also represents complex decisions for jurisdictions that have significant investments in SOAP based web services, as the two approaches have some important differences, including typical syntaxes (XML vs. JSON) and parts of the security stack (e.g. SAML vs. OAuth).

Many jurisdictional EHRs rely on SAML-based solutions to authenticate providers and allow them to maintain patient context when switching from one application to the next. These solutions look for provider credential data and patient details in the SOAP header which is expressed in XML. As a result, moving to a RESTful interface that supports the JSON syntax requires jurisdictions to consider changing fundamental services like Single Sign On and Patient Context Sharing.

As with all things IT, workarounds exist. Following the SAML Bearer OAuth profile, provider credential data can be encoded in the HTTP header in a regular REST API interaction, and the infrastructure can be amended to not only to look at SOAP headers but also inside HTTP headers, which would facilitate support for pure JSON based RESTful services.

HL7’s most recent draft standard, HL7 FHIR, is gaining unprecedented attention from developers and private sector organizations. The emerging HL7 FHIR standard supports four interoperability paradigms: REST, Messaging, Document and Services.1 The good news is that as far as FHIR goes, it can support multiple interfacing and architectural approaches. This can also complicate matters for jurisdictional governments who are trying to make technology design and investment decisions today.
Anyone considering supporting multiple interoperability paradigms (e.g. supporting both SOAP based web Services and REST APIs) needs to carefully consider several things:

  • Cost and speed of Maintenance: changes to external interfaces or back-end systems may impact all versions of interfaces and require applying changes and testing of each interface separately. This creates all sorts of complexity in creating changes to testing environments, build and deploy tools, and overall release and change management processes.
  • Security and Privacy: one interface should not compromise security features of another interface. For example, masking and “break the glass” rules should be implemented consistently across all interoperability paradigms.
  • Version tracking vs not tracking: when one interface supports tracking of multiple versions of data over time (e.g. HL7 FHIR version/history) and another interface supports only current snapshot (HL7 V2/V3), it may create inconsistency and data loss in the back-end database repositories, which then may result in the incorrect reporting or presentation to a user.

What will the next 30 years hold? It’s a safe bet that the complexity of Jurisdictional EHRs will continue to rise as more needs are introduced via the proliferation of sensors (the Internet of Things), mixing of private Cloud based services with traditional on premises infrastructure (Hybrid IT), and other technologies I’m sure we can’t even begin to imagine. The only thing I hope is we can honor those who came before us and not lose sight of why we’re doing this.

Thank you to Iryna Roy, Architect and Standards Subject Matter Expert for her contributions to this article.

i HL7 FHIR Presentation – FHIR For Architects, Lloyd McKenzie Jan 2016.

share this article...
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn