To build a better broker…

Back when I started working for a previous company I remember sitting in meeting after meeting with clients explaining the benefits of integration and having an enterprise class integration platform. It seemed like every customer needed to be educated on its possibilities and on the level of effort that is required to build out an enterprise integration strategy. These days I sit in less of those meetings. People are more and more aware of the need for an integration strategy and the possibilities that a good broker affords them; no longer constrained to simply route messages, we can now execute complex business logic and mine for critical business data within these platforms.

So it should be pretty straightforward now to design, implement and deploy a stable, flexible and performant platform. In fact I should be out of a job. But that’s not the case, much to the relief of my mortgage company. Integration is still complex and bespoke. There are no really good one size fits all approaches to integration, no single tool or solution that solves all challenges. Partly this is to be expected. Most organisations have different requirements, different philosophies that affect which trade-offs they would take in any given scenario. Moreover integration is primarily approached on a project by project basis. Rarely does an organisation have the foresight or budget to sit down and design a fully blown strategy for integration, and deign out a consistent framework for all integrations within the organisation. This leads to some challenges, not least of which is the complications driven by unchecked growth of the overall solution. A great example here is solutions built on top of the HL7 Accelerator for BizTalk. The accelerator makes life much easier in developing healthcare integration solutions, but has a tendency to funnel development down a particular design pattern that works well for individual integrations, but poses serious challenges for enterprise scale integrations of full clinical environments.

For the last few years it’s been my privilege to work with some very intelligent and insightful colleagues and partners as well as customers. In that time we have all batted around the idea of a productised Clinical Broker. Now I should add the caveat here that I am fundamentally a consultant, not a product person. That may well colour my view of what’s required. In conjunction with a number of others, I have spent some time going over the challenges inherent in healthcare integration solutions and worked to design out a number of different approaches to integration solutions. More and more these days I have come to the conclusion that a framework is more of a benefit to the customers and a design pattern that will allow the flexibility that is required, but at the same time satisfy the biggest requirement I repeatedly come across; the customers rarely want to build a full solution from the ground up.

So over the next few posts I would like to go through the following thoughts;

  1. History and Issue of Healthcare Integration
  2. Compiled versus Configuration
  3. Separation of Business Logic and Routing Logic
  4. Performance
  5. Microsoft Framework Offerings
  6. Guidance Automation Toolkit/Domain Specific Languages
  7. The Canonical Data Model

As a starting point (actually back to front, but there you go) there are a few core requirements I believe are crucial for a successful deign pattern/framework;

  1. Separation of Business Logic and Routing Logic: This may well be one of the most crucial issues I have come across and the failure to achieve this appropriately is at the core of most management problems associated with large, multiple integration segment solutions I have been involved with or reviewed.
  2. Encapsulation of Business Logic as "Services": This requirement supports the previous one. Business logic must be represented as discrete services to support manageability of the platform
  3. Consumable Service Repository: Once we accept the encapsulation of business logic as services, the need to register and consume these services is a given.
  4. Subscription Registration System: A flexible design would allow non-developer subscription to messages within the ecosystem. A registry of available messages and providers should be provided to enable downstream systems to choose which messages/events to subscribe to from which providers.
  5. Message Wrappering: A typical way of passing messages through the system is to fully represent the message within the broker engine. This however leads to a rapidly complex system. A different way to look at it is to wrapper the message in a standard header and promote required business values into the header for in-engine processing.
  6. Ordered Delivery: This is an area which provides a large level of complexity. Briefly HL7 messages can have an accumulative effect and often need to be received by downstream systems in the intended order. HL7 provides a protocol for ensuring order, but this is rarely implemented by vendor systems. It should be noted that the requirement here is for ordered messages per patient NOT overall. This provides some interesting options for solving this issue.
  7. Independent Cessation of Message Delivery: An enterprise integration solution will have multiple downstream systems consuming the same messages. For example if a Hospital Information System is responsible for admitting patients, it will often provide an ADT stream, which multiple downstream systems (say a Laboratory Information System and a Radiological Information System) will require. The solution should enable any one of the downstream systems to temporarily shut down it’s inbound interfaces without forcing all downstream systems that share common messages to shut down.

This is by no means intended as an exhaustive list. But its a start. In my next post I’ll cover off some of the history in the way medical systems are integrated with HL7 and some of the issues inherent in the past solutions.

Tags: , , , , ,

Powered by Qumana

Advertisements

0 Responses to “To build a better broker…”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





%d bloggers like this: