The efficient transfer of health information between and amongst healthcare providers is one of the greatest challenges the health sector faces. Healthcare provider information systems vary considerably in terms of modernity and sophistication, from paper-based systems to highly sophisticated web-based integrated information management tools. Information needs vary from practice to practice. The Health Connection Engine facilitates the interoperability between these multiple systems by abstracting the interfaces used to connect them and by providing a rich and extensible adapter framework.
For those that want a more detailed overview before downloading the documentation, the following material provides some context.
What is the Health Connection Engine (HCE)?
HCE was originally conceived as a demonstration environment to show Microsoft clients how collaborative and connected health could be achieved. That was HCE 1.0, connecting the health applications of 6 vendors.
Subsequently, as HCE 2.0 it was enhanced to be production ready for implementation in some initial deployments.
At the same time work has been undertaken to identify potential requirements for demonstration in Canada (in a HIAL context) and elsewhere. As particular Health Connectivity challenges are identified, potential design approaches have been considered, and where appropriate have been documented.
This material is thus a mix of:
- Production ready design and code that can be tailored to the user’s requirements
- Demonstration ready design and code that can provide a base for extension
- Design patterns that can be considered for adoption when considering similar issues. In that regard, reference should also be made to the Connected Health Framework as that may provide different approaches for consideration.
The Design Principles also provide an important context for why HCE approaches particular design issues in the way it does.
As far as possible, sections of the Architecture and Design Guide have been marked to clarify the maturity of the material in terms of production readiness.
Health Connection Engine (HCE) Background
The efficient transfer of health information between and amongst healthcare providers is one of the greatest challenges the health sector faces. Healthcare provider information systems vary considerably in terms of modernity and sophistication, from paper-based systems to highly sophisticated web-based integrated information management tools. Information needs vary from practice to practice.
HCE was developed as a consequence of a project to demonstrate how Microsoft’s Collaborative Health strategy could be brought to life. The project involved the integration of applications from 6 Microsoft ISV’s, in such as way as to also provide the means for plug-and-play of applications from other Microsoft partners around the world. It followed the journey of a Type 2 Diabetic patient through primary, secondary and tertiary settings of care.
The Strategic Challenge for Connected Health
One of the most significant IT challenges facing larger organizations today is determining how to address evolution of the application architecture.
This applies both to those that selected integrated enterprise applications in the expectation they would cover the full functionality required, and would be readily upgradeable over time, and those who have gone for integration of “best of breed”.
To their dismay, the purchasers of enterprise applications have found that upgrading the whole suite is such a major, costly and disruptive project, that they avoid doing so unless absolutely necessary. Consequently, best of breed and other point solutions start to appear to address urgent needs, and need to be integrated with the enterprise application. Meanwhile, those who purchased best of breed solutions initially have found the complexity of the application integration increasing. Whilst in most cases they have used integration middleware, rather than the hand crafted interfaces used historically, the mapping is still necessarily individual application focused, and with complex changes needed for changed applications.
For these reasons, a number of the major enterprise application vendors have recognized they need to adopt a component approach to their applications, allowing the connectivity to work in such a way that organizations can upgrade individual components, rather than the whole suite. Their approach to this has generally been to adopt a service orientated architecture based on web services. In parallel with that, application integration architects have been considering similar approaches to reduce the integration complexity.
With the range of clinical support systems in the Health sector, the integration challenges are magnified, despite the positioning of some major vendors as “the” answer.
Although service orientated architectures have their own complexity, they are based on standards. The major opportunity for Health Application Integration is that health informatics is substantially standards based. The goal therefore is to develop a standards based set of web services that together with an integration orchestration allow applications to collaborate in an ecosystem based solely on the nature of the events being described, without having to be aware of the nature of the applications using those services.
The HCE offers the opportunity to start developing a “next generation” approach to application connection, allowing existing systems to participate in the ecosystem (whether through existing middleware tools or HCE) and over time allowing more flexible connection of both existing and new applications.
As such, HCE is a standards-based set of web services enabling health point of service applications to connect with other applications to support clinical collaborations delivering more efficient and knowledge based healthcare.
The following are key overarching design principles for the HCE
- A Service Oriented Architecture approach has applied
- Consequently, the objective is for connected systems to be “Plug and Play” – provided they can supply or use data in schema compliant form through adapters.
- The adapters used internally are reference implementations of the structure required for connected system adapters.
- Messages represent clinical events not data items within individual point of service systems (known as service providers within an HCE solution)
- Translating messages at the edge of the solution - Semantic / data translation of messages should be where it is most easily handled – whether that is in the point of service system, or closer to the edge of the HCE within the adapter
- EHR information should as far as possible be federated, with pull-based messaging to assemble information where it is needed, when it is needed - although the architecture does not enforce that
- All messaging is synchronous, with those connected systems requiring asynchronous messaging being handled through a store and forward service provided by the adapter
- Service blocks should be self contained (in accordance with SOA principles) providing flexibility for physical deployment
- Connected systems (service providers) should not have to know the details of systems receiving or supplying data i.e. they should not have to map that data to the requirements of the other system, but rather abstract it to be consistent with standards based XML schemas appropriate for the particular clinical (and administrative) events being supported.
- Where an interactive session is needed (such as use of decision support tools within a clinical workflow) this will be undertaken by the originating connected system (source service provider) invoking the decision support system, not via the use of HCE messaging.
- Unless decided otherwise in a particular implementation, the clinical payloads should not be visible to the HCE i.e. they are encrypted / decrypted by the adapters and thus only visible within each service provider.
- HCE should allow implementing organizations to leverage existing, legacy applications and infrastructure investment. The use of adapters and the HCE provides translation from legacy applications to a Service Oriented Architecture based solution
- The overall design of the HCE should support connection of HCE with existing messaging infrastructures – e.g. HCE to HealthLink in the New Zealand context
- The introduction of a HCE-based solution should minimize disruption to existing clinical workflow. Where ever possible, information distributed via the HCE should be presented in a user’s existing application, without introducing yet another application for users to access information available within an HCE-based solution
- Specialized knowledge and logic within each point of service or connected system should be leveraged wherever possible – e.g. ordering of laboratory tests should be completed using the interface provided by Laboratory Information Systems (LIS) directly instead of replicating functionality within a practice management system
- The HCE should leverage the Microsoft technology stack throughout the solution from server products (e.g. BizTalk Server, SQL Server, and Active Directory) through to code (Patterns & Practices Application Blocks and Enterprise Library). This approach maximizes use of existing components, minimizes custom coding, allows solution to evolve in-line with Microsoft product roadmaps and reduces the technical risk by reusing widely used components
What HCE is not
HCE is not a
- Clinical Data Repository (CDR) – although it could optionally support consolidation of clinical information into such a CDR (whether some form of consolidated information store or a partial information set to support, for example, “out of hours” emergency care when source systems may not be available for recent treatment history, current meds and allergies)
- Clinical Portal – this is assumed to be provided by an appropriate point of service system (even if that was only a viewing portal such as one based on MOSS)
- Point of Service system