Security Policy Designer: The Intel® SOA Expressway gateway now allows relevant teams from architecture, security & operations to design & enforce policy templates that conform to Enterprise requirements

Policy Dashboard: The updated policy dashboard offers a new view of services with visual representation of policies and features to quickly apply policies to other services, functional operations, or application service endpoints . This delivers unprecedented runtime SOA governance capabilities to monitor and manage services in the data center.

Integrated Governance: Making design time and run time SOA Governance seamless across vendor products has been the desired objective of our customers so that existing investments can be re-used across enterprise-wide implementations. With this release, Intel SOA Expressway now integrates with design time governance solutions from Oracle FMW 11g, Software AG Centrasite and IBM Tivoli for a truly integrated web service governance model

Secure Token Service (STS): The new release of Intel SOA Expressway supports IBM Tivoli Access Manager for delegated authentication/authorization, as well as ability to issue, authenticate, and convert CA SiteMinder and Oracle ObSSO session tokens into SAML assertions. This STS standards-based functionality enables customers to leverage their legacy identity infrastructure and proprietary identity tokens for seamless cross-domain single sign on or identity enabled web services to partner systems

Oracle Fusion Middleware 11g Integration: Intel SOA Expressway also offers support for XACML based fine grained authorization using Oracle® Entitlements Server as PDP/PAP (Policy Decision Point/Policy Application Point). The implementation has been validated on Oracle Enterprise Linux. Deployment of Intel’s SOA Expressway security gateway is now the recommended way to apply perimeter security for B2B services deployed on Oracle Fusion Middleware.

XA Support: Intel SOA Expressway fully supports Open Group’s XA Global Transaction standard for fast update of multiple dependent resources. This is useful across many industries including healthcare where updates can be made to aan individual patient record and these updates can be cascaded to other systems with a single transaction call.

Network HSM: Additionally, Intel and Sophos are announcing a joint partnership and plans to support integration of Intel SOA Expressway and Sophos SafeGuard CryptoServer Hardware Security Module. The partnership brings together two market-leading security products, one for SOA security and one for cryptography, into one integrated solution. For certain applications, customers will need to ensure that asymmetric private keys, symmetric keys (configured out-of-band), and passwords are only visible in the clear within a secure cryptographic boundary that is safe from attacker access. Integration with the Sophos SafeGuard CryptoServer provides this secure boundary in a FIPS 140-2 Level 3 key-storage appliance with centralized management. For clear separation of duties compliance, the security administrator responsible for key management is cleanly separated from the administrator responsible for the operation of the network server running Intel SOA Expressway. The combined solution is well positioned for use in highly regulated industries with stringent security regulations like financial payments ( PCS DSS), government agencies (SIPERNet) and healthcare organizations (HIPAA)

Intel and Sophos will jointly present Intel SOA Expressway and SafeGuard CryptoServer at the CARTES 2009 Conference in Paris Nov17. You can learn more about Intel® SOA Expressway here and more about Sophos’ SafeGuard CryptoServer product here.

]]> http://software.intel.com/en-us/blogs/2009/10/21/intel-announces-intel-soa-expressway-r23-and-partnership-with-sophos-for-highly-regulated-secure-soa/feed/ 0 http://software.intel.com/en-us/blogs/2009/10/14/new-intel-soa-expressway-for-healthcare-release-powers-patientprovider-community-exchange-at-newark-beth-israel-medical-center/ http://software.intel.com/en-us/blogs/2009/10/14/new-intel-soa-expressway-for-healthcare-release-powers-patientprovider-community-exchange-at-newark-beth-israel-medical-center/#comments Wed, 14 Oct 2009 13:30:39 +0000 Joshua Painter (Intel) http://software.intel.com/en-us/blogs/2009/10/14/new-intel-soa-expressway-for-healthcare-release-powers-patientprovider-community-exchange-at-newark-beth-israel-medical-center/ It’s been about a year and half since we first released Intel® SOA Expressway for Healthcare, which is a purpose-built, easy-to-deploy integration appliance for connecting islands of information together to enable a secure, high-performance, best-of-breed health information infrastructure. We have now begun shipping release 2.2, which contains a number of new feature enhancements.

• Healthcare Quick Start Kit: prebuilt modules, workflows and data transformation maps to reduce learning curve and improve developer productivity.
• Improved Microsoft Windows Support: new deployment options that take advantage of Windows installer technology make it simple to automate deployment and installation of SOA Expressway across a cluster of servers. In addition, we’ve beefed up support for command line scripting (CLI) on windows to enable even more flexible product configuration and administration using automated scripting tools.
• Reliable Messaging and Replay: advanced support for configuring guaranteed delivery options for sending and receiving of health data.
• Hardened Appliance Form-factor: In partnership with Dell, we now offer a 1U high-performance hardware appliance with tamper-resistant features not available anywhere else.
• Virtualization: Since Intel SOA Expressway is software it supports a variety of hardware virtualization technologies. We’ve now made that even easier by making the product available as a Virtual Appliance in the VMWare Virtual Appliance Marketplace

So is this just another integration engine for healthcare? Well, I’ll give you three examples why this product is different:

1. Intel SOA Expressway for Healthcare lets you extend your legacy Health IT. Because rip-and-replace is never an option, we’ve designed an integration appliance that is easily-deployed as an overlay to your existing Healthcare I.T. applications, databases, even interface engines. Intel SOA Expressway lets you extend your legacy environment by quickly assembling data from a diverse set of proprietary applications and databases into higher-value, standardized information services layer.

2. Intel SOA Expressway for Healthcare is a highly integrated appliance. It performs message transformation, mediation and routing, and security in a lightweight, tightly integrated, high performance runtime. Intel’s approach addresses the high-cost, poor performance and low flexibility of the software “suite” approach to integration, which typically require a substantial investment in an entire stack of separate products to meet even simple integration needs.

3. Intel SOA Expressway for Healthcare is future-proofed. Most integration products today are focused on micro-level integration, simply moving health data from point-to-point, which actually contributes to information silos, adding cost and complexity to a healthcare information environment. Unlike these products which provide a thin veil of standards support at the edge of the product, Intel SOA Expressway for Healthcare has “designed-in” healthcare standards deep within the product to enable healthcare interoperability, not just point-to-point integration.

Intel SOA Expressway maximizes value from your “legacy” investment while “future-proofing” IT infrastructure -- all at breakthrough cost. The value is clear, whether you are looking to build a backbone for a state or national Health Information Exchange; a B2B Hub for high-volume, secure message processing; or even a provider looking for an inexpensive health information gateway to efficiently exchange healthcare information inside hospitals and with health information networks.

Recently, Intel SOA Expressway was selected by Newark Beth Israel Medical Center (NBI), 600+ bed teaching hospital in New Jersey to power the launch of its first comprehensive electronic health information exchange, which will offer a shared clinical data repository to its partner institutions, physicians, other care givers and patients. Intel collaborated with healthcare portal solutions provider IGI to create a next generation solutions for hospitals and IDNs, enabling healthcare providers to securely exchange patient information at the point of care — key to providing better services and reducing integration costs. View the on-demand webinar here.

IGI is an active Intel systems integrator partner that provides an Affiliated Physician and Patient portal solution that enables uniform access to a broad range of services such as referrals and care coordination, e-prescribing, instant access to labs, claims and medication history, as well as a comprehensive virtual patient record. The integration between IGI ORBIT® and Intel® SOA Expressway for Healthcare provides an efficient, scalable, SOA based solution that connects and translates data as it moves across a healthcare network. IGI ORBIT utilizes Intel SOA Expressway to retrieve data for portal display from a variety of hospital systems including EHR, EMR, database, or HL7 based sources, providing the fastest, simplest way for to enable integrated care services and interoperability across a community of participants.

For more information visit the Intel SOA Expressway for Healthcare website here.

Intel is one of many vendors who deliver products to the healthcare marketplace which provide IHE profile support to address concrete, critical interoperability issues in healthcare. Intel SOA Expressway for Healthcare is software middleware that enables support for IHE profiles at the infrastructure layer, which provides implementers greater flexibility and control in building solutions for information sharing. The two example below can help to clarify what is meant by "infrastructure layer" interoperability.

1) An EHR application can understand HL7v2.5, but is not able to query and retrieve clinical documents from a community HIE that has adopted the IHE profile XDS (Cross Enterprise Document Sharing). Expressway can enable this use case without requiring any changes to the EHR application.

2 ) A hospital wishes to publish and share encounter summaries with a network of affiliated physicians. Expressway can facilitate this by simply redirecting the HL7v2.x message feed from the hospital interface engine. In addition to IHE profile support, Intel has spent several years developing pre-defined maps from all major version of HL7 2.x to HL7v3 based data formats. This reduces the time and cost spent integrating systems.

In both of these examples, there is a need to leverage existing investments in legacy whilst recognizing that more flexible, scalable architectures and standards are required going forward. Expressway fulfills an integration function as part of an infrastructure layer, which permits healthcare providers to approach interoperability in a manner and at a pace that is more consistent with their own strategy, rather than a vendor roadmap or one department's legacy applications.

Moreover, an integration approach to healthcare interoperability is a key enabler towards "intrinsic interoperability", which is the ultimate goal of standards. Renowned SOA expert and author Thomas Erl wrote that "software programs that are not interoperable need to be integrated. Therefore, integration can be seen as a process that enables interoperability. " In Healthcare, organizations such as IHE as well as standards bodies like HL7 and OMG (through HSSP) are making great progress towards realizing this vision. If they are successful, then the need for integration should begin to gradually go away.

For next years Showcase, there is already discussion within IHE about plans for a new showcase category for interoperability "infrastructure" based on middleware solutions like Intel SOA Expressway for Healthcare.

If you are looking for more information on Expressway's support for IHE profiles, I would encourage you to visit Joe Welsh's new blog at: http://software.intel.com/en-us/blogs/author/joe-welsh/

Intel® SOA Expressway for Healthcare is a specific implementation of a new product category called a SOA "soft appliance", which delivers a breakthrough in simplicity, cost and scalability for enabling high-quality health information exchange.

First, it creates an integrated network for the sharing of patient information which is scattered across a diverse set of systems in different domains. This includes electronic medical records stored in isolated EMRs, practice management or clinical systems, and even accommodates paper records. Having a “virtual”, joined-up view of a patient’s medical record can immediately improve efficiency, reduce waste and mitigate risk for decision making in healthcare. Second, it enables an integrated workflow at multiple levels between the patient, affiliated physicians and specialists, the hospital and payer networks. This provides substantial time savings due to more efficient collaboration, especially in reducing the number of duplicate orders requests. Today, it's quite common for everything from scheduling to referrals to be handled by phone or fax, which is resource intensive and error prone; this solution can reduce these errors, specifically those associated with repeat data entry – there's a wealth of industry research data on the error rates associated with manual data entry, most figures put this between 5 and 15%.

Many hospitals initially consider extending their EHR solutions to these physician networks, but this isn't an ideal approach for a few reasons:

• Hospital workflows are focused on episodic care, which are fundamentally different than ambulatory care workflows, which are geared more towards a patient's lifelong health records. Therefore, the Healthcare IT systems supporting each need to be different as well.
• This approach doesn't accommodate a practice's existing investment in an ambulatory care records system. This typically results in one of two outcomes, both of which are less than ideal: numerous expensive system integrations between the ambulatory EMRs at the affiliated physician practices, or reliance on a set of redundant processes, like dual data entry.

Recently, Intel and IGI teamed up to bring a solution for a hospital's affiliated physicians to the marketplace. This is a best of breed solution that integrates Intel SOA Expressway with IGI's ORBIT framework to enable sharing of health information, streamline the referrals process, and provide seamless access to hospital, payer and ancillary services.

Affiliated Physicians Solutions from Intel and IGI

IGI’s ORBIT® is a comprehensive solution for Managed Care companies that would like to implement a Provider Portal to interconnect physicians, hospitals, labs and the payer systems. It provides a physicians portal, patient management and clinical data repository, online transaction status for claims, member benefits, referrals/pre-cert, and much more.

Intel SOA Expressway for Healthcare is a high-performance health information gateway from Intel, that simplifies healthcare information interoperability. It provides a configuration-centric solution to integrates islands of health data and ensure data privacy, delivers out-of-the box support for healthcare data standards, and enables healthcare organizations to service-enable their legacy Healthcare IT to interoperate with the entire healthcare enterprise.

I've put together a video demo of solution which can be viewed online, or you can download a higher res version here.

Intel® SOA Expressway for Healthcare is a specific implementation of a new product category called a SOA "soft appliance", which delivers a breakthrough in simplicity, cost and scalability for enabling high-quality health information exchange.

]]> http://software.intel.com/en-us/blogs/2009/01/22/enabling-hospitals-and-their-affiliated-physicians-to-stay-connected/feed/ 0 http://software.intel.com/en-us/blogs/2008/11/12/design-approaches-for-patient-identification-in-health-networks/ http://software.intel.com/en-us/blogs/2008/11/12/design-approaches-for-patient-identification-in-health-networks/#comments Thu, 13 Nov 2008 06:27:15 +0000 Joshua Painter (Intel) http://software.intel.com/en-us/blogs/2008/11/12/design-approaches-for-patient-identification-in-health-networks/ My last few posts have looked at the role of data standardization and terminology translation in enabling healthcare organizations to exchange information that can be understand by all. Terminology translation acts as a bridge to make it possible for two organizations to share and understand health data that is "codified" differently.

The linking of patients to their health data is another important bridge in enabling heath information exchange. Being able to uniquely identify patients is central to meeting both patient and provider care objectives to lower cost and improve quality and access to healthcare, such as:

• Simple identification and organization of health data, improving access and reducing costs

• Linking of health records to create a longitudinal record set for an individual, enabling a complete view of patient information

• Information aggregation for analysis and research, supporting better understanding of diseases and treatments and driving better outcomes

• Ensuring patient privacy, confidentiality and security, to which patient identification is a pre-requisite

The challenge lies in how healthcare in delivered in practice: patients tend to receive care at many different institutions in their lifetime, such as a primary care physician, university hospital or a local health clinic. Each of these care facilities tend to assign institution-based identifiers to a patient's health records, which is adequate within that institution but becomes meaningless once those records move outside of that institution. This is especially significant in today's healthcare marketplace, where patients routinely cross both institutional and geographic boundaries for their care needs.

Design approaches for patient identification in health networks tend to fall into two categories: those that require unique patient identifiers, and those that do not. There are many interesting and innovative approaches based on unique identifiers, some of which have real merit when applied to healthcare information infrastructure on a national scale. However most call for significant investment in time and resources to implement, administer and build out supporting infrastructure. Several proposals based on unique identifiers are outlined in detail in this HHS whitepaper. In the United States, HIPAA requires unique identifiers for providers and employers, but policymakers are no longer pursuing the idea of a unique patient identifier due to significant controversy as to how it can be implemented without comprising individual privacy. Once the policy and implementation issues are ironed out, national identifiers will be an important ingredient in solution for health system interoperability and data exchange. It will never be a complete solution, however.

As such, I'd like to focus on an approach that doesn't require a unique identifier, one that is available today and in in wide use by healthcare ecosystem. In this design approach, identification methods are based on a Master Patient Index (MPI). An MPI links a patient medical record number with a limited set of common identification elements known to a patient, such as patient first/last name, sex, birth date, SSN and mother’s maiden name. The following is a very high-level scenario to illustrate how an MPI works:

Hospital A and hospital B agree to notify one another of all Admissions, Discharges and Transfer (ADT) transactions. Both hospitals have independent EMR systems, and both are augmented with a solution like Intel® SOA Expressway for Healthcare to manage the exchange of ADT messages with the help of an MPI solution. The MPI is responsible for linking and indexing all known local identifiers for a patient to "master" identifier. For example, an ADT message from hospital A for the patient "Mary Smith" with local patient identifier A012 would be linked to the MPI identifier of M002, which contains all the mappings for the other clinical systems that hold records for Mary Smith. In this scenario, the MPI would resolve Mary Smith's local identifier for hospital B e.g. B029, enabling an ADT message exchange that is seamless between the hospitals.

Typically, MPI solutions are deployed within a single care organization to link and index patient identifiers across disparate clinical and administrative systems. The ADT exchange in the example above would be more commonly addressed by an Enterprise MPI (EMPI), which is used to create an complete view of patient information from data sources (including discrete MPIs) scattered across multiple facilities, application systems and databases, to deliver the right information about patients in real time in a variety of clinical settings. Intel SOA Expressway for Healthcare includes pre-built adaptors for validated application vendors in this space, making it simple to configure EMPI lookups for the any healthcare integration scenario.

In this post I barely scratched the surface of how MPI technology helps facilitate high-quality health information exchange. In a future post, I will discuss some of the architectural considerations for patient identification in large, national health infrastructure networks. Architectures of this type and scale have a unique set of requirements which require careful attention to the areas of data integrity, security, privacy and compliance.

Intel® SOA Expressway for Healthcare is a specific implementation of a new product category called a SOA "soft appliance", which delivers a breakthrough in simplicity, cost and scalability for enabling high-quality health information exchange.

But first a quick side note: it is no accident that we are seeing growth in this area in healthcare before some other markets. The reasons are twofold: the first is XML, which is largely ubiquitous now as a data format, which emerged as the standard for information exchange has leveled the playing field for how data is packaged for exchange between systems. The second is the progressiveness of the health informatics community, which over the past couple of decades has invested heavily in the development of extremely rich clinical information models which permit classification of just about any disease, condition or drug know to man. With the publication of HL7 version 3 and the RIM a few years back, we have reached a turning point where health information can now be represented with a specific clinical or administrative context, and with explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages. What does that mean? It's essentially a recipe to permit the exchange of information that can be understood by all, man or machine. That's powerful, and here are some application areas that depend on it:

Quality Metrics Reporting: this includes the aggregation and reporting of quality measures developed to quantify provider and plan-specific measures of quality. These initiatives are typically driven by major payers or are government mandated and focus on key metrics like morbidity, mortality and patient experience. For anyone familiar with initiatives like Pay-for-Performance (P4P), this is a subject not without controversy. Ultimately this will deliver more information about the quality and cost of care into the hands of consumers, which is a good thing.

Research: adverse drug reactions (ADRs) are one of the leading causes of death in health care, responsible for over 100k deaths each year. ADRs represent a significant public health problem which is largely preventable. Several research areas of interest are delivering new knowledge that can help healthcare providers predict possible drug interactions: analysis into drug-drug , drug-disease, and drug-food interactions, post market surveillance of prescription drugs, and pharmacogenetics, which is the application of genetics analysis to predict drug response, efficacy and toxicity.

Biosurveillance: defined as the "automated monitoring of information sources of potential value in detecting an emerging epidemic, whether naturally occurring or the result of bioterrorism". Information sources include public health data as well as electronic information not traditionally monitored by public health. For example, data from hospital diagnoses, pharmacy sales, primary care reporting, and environmental conditions can be fused in real-time to develop an operational frame for biosurveillance applications. Its value to both the public health and homeland security has driven significant investment in this area in the past number of years.

Intel® SOA Expressway for Healthcare is a specific implementation of a new product category called a SOA "soft appliance", which delivers a breakthrough in simplicity, cost and scalability for enabling high-quality health information exchange.

]]> http://software.intel.com/en-us/blogs/2008/10/27/healthcare-applications-that-depend-on-data-standardization/feed/ 0 http://software.intel.com/en-us/blogs/2008/10/02/designing-for-gray-scale-under-the-hood-of-medical-terminology-translation/ http://software.intel.com/en-us/blogs/2008/10/02/designing-for-gray-scale-under-the-hood-of-medical-terminology-translation/#comments Thu, 02 Oct 2008 21:59:18 +0000 Joshua Painter (Intel) http://software.intel.com/en-us/blogs/2008/10/02/designing-for-gray-scale-under-the-hood-of-medical-terminology-translation/ My last couple posts have touched on the importance of data standards in enabling interoperability in healthcare. It is important to recognize, however, that data standardization is not about dictating the way organizations capture and share clinical data. Often there is specific local and institutional knowledge that is represented in the information of a given healthcare organization, which can't be characterized easily by national data standards. Geographic or cultural phrasing, local eponyms, and lay names are critically important to the local delivery of care. For each participant in a health information network, these nuances in data syntax and semantics are analogous to shades of gray. This "grayscale" presents a set of challenge for participants who need unambiguous, shared understanding of information to enable decision making.

An architecture for Health Information Exchange must accommodate choice and dealing with change - it must be designed for grayscale. This includes choice of medical vocabularies, messaging standards, and other terminology interchange considerations. In my last post I introduced the notion of a Common Terminology Services to deliver a set of capabilities in this space. In this post, I will discuss a technical architecture for enabling this.

Let's start with a simple example: a clinical system in a hospital places an order for a medication to a hospital pharmacy application. To simplify discussion of architecture and system interactions without lots of fancy pictures, I've included a simple model to call out the key actors in this example, and their role and relationships.

CIS = Clinical system in the hospital e.g. CPOE

Rx = Pharmacy application

IA = Integration application, responsible for workflow, data type mapping, and message normalization

CTS = services supporting terminology interchange

The flow begins with the CIS sending an HL7v2.x medication order message to the IA, which normalizes the message to a format understandable by the Rx application. Before sending the message onwards to the Rx application, the message is handed off to the CTS to normalize the coding scheme used for the medication being ordered. At this point, the message has been augmented with the appropriate semantics which can be understood by the Rx application, and contains a set of standard codes that the Rx application can understand in order to fulfill the medication order.

This example seems straightforward enough, but there is some substantial work going on by the CTS actor. First, it's worth mentioning that CTS is actually a set of industry standard interfaces specification created by HL7 to enable vendor-independent access to medical terminology applications. The CTS specification encompasses three categories of terminology services: Messaging, Vocabulary and Translation.

Messaging services are responsible for ensuring a successful handshake with the source system at the application protocol level, handling mediation of vocabulary domains, contexts, value sets, coded attributes and other artifacts of the HL7 message model. These services allow a wide variety of message processing applications (like the IA in the example above) to create, validate and translate HL7 data types in a consistent and reproducible fashion. Vocabulary services communicate with terminology management software, and do so in terms of code systems, concept codes, designations, relationships and other terminology specific entities. Vocabulary services allow applications to query different terminologies in a consistent, well-defined fashion. Finally, CTS Translation services provide the ability to create and deliver mappings – or translations – between concept codes from different code systems.

A single set of CTS services for a healthcare institution would facilitate service-oriented architecture (SOA) interfaces to all applications. That way, the institution could be assured that all mappings were consistent, and it would need to add updates to vocabulary and mappings in only one place. The combination of the CTS functional approach with the reliance on the Integration Application (IA) actor delivers a couple of key advantages. Firstly, interactions between the health information or clinical systems and the terminology interchange application are flexible and loosely coupled, due to the use of the IA to mediate the flow of data. This avoids expensive and complicated changes that might otherwise be required to permit those systems to share data or participate in integrated workflows.

The second advantage is that the CTS provides a common interface and reference model for understanding, so that across a variety of types of healthcare applications, there is a common set of terms when discussing and communicating terminology related concepts in both human and computable environments. This way, applications interfacing with the CTS are not required to know about specific terminology data structures, and more importantly, how to access them. Applications can be developed independently from the terminology service software.

I had intended to dedicate more space to some example applications for terminology exchange in healthcare, but will save that until my next post.

Intel® SOA Expressway for Healthcare is a specific implementation of a new product category called a SOA "soft appliance", which delivers a breakthrough in simplicity, cost and scalability for enabling high-quality health information exchange.

Example 1

After a consultation with a patient, a specialist orders a series of lab tests. Only a week earlier, the patient went for series of tests related to her condition after a visit with another specialist. A lab results check is run which determines that some of the tests ordered are duplicates and thus may be unnecessary.

Example 2

A patient arrives in an emergency room complaining of chest pains, and is prescribed a blood thinner. A drug interactions check performed by the hospital pharmacy reveals that the prescribed drug has a negative interaction with the patients anti-anxiety mediation. An alternative drug is prescribed which has no such interactions with the patient's existing meds.

The speed and quality of decisions like these can improve efficiency, reduce waste and mitigate risk for decision makers in healthcare. In the first example above, the patient and the physician were both saved the time and expense of duplicate lab testing, which today is a frequent yet unnecessary expense during the delivery of healthcare. These decisions can even mean the difference between life or death, as in the case of the drug interaction example called out above. In both of these examples, data normalization has enabled better decision making.

Let's examine the system to system interaction in example 1 that facilitated the lab test check in the example above. A clinical system where the specialist practices solicits information about the patient's list of current medications from an information system at the practice of patient's primary care physician. Assume that these two systems are configured to share health information using an integration solution like Intel SOA Expressway for Healthcare. The query of the patient's health record at the PCP reveals that just 5 days ago a series of tests were ordered for the patient. These tests are designated with codes specific to the health information system at that practice e.g. numeric codes like 0078-192834, or for some systems abbreviated procedures codes like “cmp bld test”, “bld panel”, “bld compl”. For the Practice Management Information System at the PCP, the meaning of terms are very clear e.g. 0078-192834 = "pulmonary function study ", etc. However, to the clinical system at the specialist's practice, these codes are meaningless. Both systems have their own vocabulary for health care - lists of chief complaints, diagnoses, procedures and lab tests. The syntax and semantics of these phrases is usually derived from the clinical systems from where the data originates. For a healthcare computer system to “understand” a clinical statement, the meaning of the statement’s content must be unambiguous. This need for clarity clearly exists for the name of the laboratory test in our example. Similar concerns apply for medications, diagnoses and procedures.

The solution is to normalize the clinical descriptions for lab test by applying standard healthcare terminologies such as SNOMED CT, LOINC, CPT-4, ICD- 9, RxNORM, etc . These representations are based on key international and national standards that have been recognized as the correct elements of meaning for clinical information. By translating local terms to industry standard forms, data can be safely and consistently exchanged - each system can “understand” the data that it has received. This data can then be consistently aggregated, displayed, and analyzed. In the interaction above, the normalization can be implemented as a service responsible for the mapping of terminology between local form of the clinical system and the standard form.

This and related services are commonly known as a Common Terminology Services, or CTS (also referred to as Common Medical Vocabulary Translation, and other variations). The Intel SOA Expressway for Healthcare "soft appliance" simplifies the integration of such a service in a health information exchange by exposing a set of CTS interfaces to facilitate terminology translation and mapping, and includes pre-built adaptors for validated application vendors in this space.

In my next couple posts I will look deeper at the technology enablers for an architecture providing medical terminology translation, and address a broader set of applications for terminology exchange in healthcare, focusing on the area of quality metrics reporting, analytics, bio-surveillance and research.

Intel® SOA Expressway for Healthcare is a specific implementation of a new product category called a SOA "soft appliance", which delivers a breakthrough in simplicity, cost and scalability for enabling high-quality health information exchange.

]]> http://software.intel.com/en-us/blogs/2008/09/23/semantic-normalization-making-sense-out-of-health-data/feed/ 2 http://software.intel.com/en-us/blogs/2008/09/15/peeling-back-the-onion-of-health-data-interoperability/ http://software.intel.com/en-us/blogs/2008/09/15/peeling-back-the-onion-of-health-data-interoperability/#comments Mon, 15 Sep 2008 16:36:30 +0000 Joshua Painter (Intel) http://software.intel.com/en-us/blogs/2008/09/15/peeling-back-the-onion-of-health-data-interoperability/ Data interoperability is vital to today’s healthcare computing environment, allowing clinical information to be effectively and consistently exchanged, compared, and analyzed among healthcare partners such as insurers, pharmacies, affiliated providers, and public health departments. Put simply, data interoperability enables better decision making. The solution is clear: data standardization. But statistics show that the development and adoption of data standards is much easier said than done. Why is that, when we are clearly no stranger to standards in other aspects of our daily lives: railroads run on the same gauge track, we have a standard system of weights and measurements, and ISO 9000 has become the norm for quality systems management. Clearly, a set of common clinical data standards which would help reduce to the cost of healthcare and enable better outcomes, is long overdue.

As an architect, I usually find myself thinking top down and jumping straight into "clouds and arrows" mode when I think about a problem like this. But on occasion I find it useful to start at the bottom and work my way up. This is one of those times, so I'd like to start by peeling back of the rather large and layered onion of "data interoperability". First, a simple yet meaningful definition of data interoperability: the ability of two parties to exchange information that can be understood by both parties. That may seem like too basic a definition, but it masks a fair degree of complexity if we break it down.

Firstly, the notion of exchange infers agreement on a set of mechanisms for the transfer of the information. Considerations in an IT exchange include network, transport, application and messaging protocols. Thanks to the OSI layered model and the phenomenal growth of the Internet, most information exchanges conform to the TCP/IP transport protocol (not surprisingly, there are a few well known exceptions to this in healthcare). On top of this there are a wider variety of protocols in use: applications protocols like HTTP or FTP, and messaging protocols like ebXML, JMS or SOAP. Some older, established standards like HL7 v2.x are still in wide use in the healthcare industry, which require conformance to several of the layers described above. Either way, agreement on these protocols between two parties represents a contract for exchange of information.

The second part of the definition above deals with facilitating shared understanding between the parties. There are two key considerations: agreement on the structure and meaning of the data. Structure is defined as the formatting and order of information, and that it conforms to a set of expected rules. Those rules may be fairly loose in the case of requiring only valid XML, or more strict like conformance to an information model or schema as in the case of X12, HL7v3 or NCPDP. Meaning is defined as being interpretable, by humans but also by machines in some cases. After all, let's not lose sight of the true goal of data interoperability: to enable better decision making. Ultimately these decision fall to humans, but every efficient flow of information requires numerous machine-decisions along the way e.g. content routing, authentication, alerts, etc. Achieving a shared understanding requires agreement on the meaning of the information, referred to as "semantics". Semantic considerations for health data might include detail on the nuances of clinical diagnoses, care processes or lab tests.

Facilitating this shared understanding is often a challenge for healthcare organizations wishing to exchange health data, due to significant variation in use of medical vocabularies, level of customization, and geographic, cultural and professional differences. Data standardization can address these challenges to enable organizations to exchange information that can be understood by all parties. In practice, this standardization takes the form of a set of processes responsible for "normalization" of the clinical terms in data, which is the recognized way to remove ambiguity and improve comparability. In the next post I will describe an architecture to facilitate data normalization, with some specific examples that highlight the myriad of benefits to decision making.

Intel® SOA Expressway for Healthcare is a specific implementation of a new product category called a SOA "soft appliance", which delivers a breakthrough in simplicity, cost and scalability for enabling high-quality health information exchange.

Our first story takes us to Shanghai, to a government-led initiative to enable the sharing of electronic medical records between 23 of the top state-owned hospitals in and around Shanghai. In an initial phase, a solution was put in place to enable each hospital to collect medical record data from its Hospital Information System (HIS) at a predetermined time. Each night, synchronization from the hospital to the datacenter would take place, giving doctors in each of the 23 hospitals access to a consolidated historical medical record for each and every patient in hospital network.

Their pre-existing solution was based on JMS and suffered from both network and compute performance problems. On average, each hospital was required to upload about 900K patient records using the queue-based architecture over a four-hour window, which created enormous network overhead and required massive amounts of centralized data processing. In addition to these performance problems, the queuing system was not very reliable and lacked manageability hooks for alarming, alerting, etc. It soon became clear that the project needed a new solution that could handle the large message sizes and high performance workflow required for patient data sharing.

A new solution put in place in the most recent phase replaced each edge server as well as the central JMS-broker with Intel® SOA Expressway for Healthcare "soft appliances". In this new architecture, the queuing system instantly benefited from a high-performance, highly reliable software runtime. The integration function, which was previously handled entirely centrally, was subsequently distributed more evenly across the health network. Each soft appliance at the edge was responsible for orchestrating a workflow comprised of database queries, XML conversion and message creation and distribution. By applying the SOA network model design pattern combined with the breakthrough XML processing and manageability capabilities of Intel® SOA Expressway, the Shanghai hospital network was able to lower their support costs, improve reliability and reduce each hospitals 900k record load time by half.

Our second example takes us to Latin America, where a research institution was chartered by the government to demonstrate the feasibility of a healthcare data interoperability solution for rapid development and deployment of a virtual patient record system. As part of their strict attention to facilitating low TCO, the team restricted their consideration to configuration-oriented COTS products, rather than a custom-code solution. Their specific end goal was to enable a health information exchange to underpin a government-sponsored portal to give patients a more complete view of their health records.

Four geographically dispersed health regions were identified as source systems for EMR information. Each of these systems of origin were responsible for preparing and sending patient data over a network to a centralized patient service, which handled a series of orchestrations to update a database and deliver data to the portal application. Intel's® SOA Expressway for Healthcare "soft appliance" was evaluated as it met requirements across a number of categories like performance, reliability, scalability, security and message processing and routing. Specific attention was given to the Intel product's configuration-centric capabilities compared to a more conventional hand-coded solution.

Two architecture models were developed for two phases of this solution: phase one was based on a conventional, centralized architecture that delivered high-performance and scalable HIE from the distributed source systems to centralized virtual patient record service. A second phase evolved the architecture from a centralized to a hybrid model, similar to that described in the Shanghai story. This called for deploying soft appliances at key source systems to accommodate future use cases like bi-directional patient record synchronization and federated record location. This second model will enable deployment of a fully standards-based, canonical information bus and reap the myriad of benefits touched on in the previous post.

But the most compelling feature of this success story was how quickly the team in Latin America were able to light up this architecture. In less than one week and with only a single systems analyst to setup and configure workflows using the codeless Service Designer of SOA Expressway , the benefits became clear. The reduced development and maintenance costs along with reduced complexity in configuring and extending the solution greatly enhanced the research team's ability to realize value very quickly and affordably, what we call "time-to-value".

Intel® SOA Expressway for Healthcare is a specific implementation of a new product category called a SOA "soft appliance", which delivers a breakthrough in simplicity, cost and scalability for enabling high-quality health information exchange.

In the last post, I touched on some of the business and technical challenges that have led to slow growth of wide scale health information exchange and interoperability initiatives. Clearly this stuff is hard, as is to be expected with goals to improve the quality and cost of delivering healthcare. And I should point out that it's equally important to acknowledge the significant political, organizational and policy hurdles to HIE adoption. Ignoring those aspects can bring any new business initiatives to its knees, not just HIE. So let's put this out of scope for the time being. Doing so will allow us to focus on what I argue is the most important technical enabler for high quality health information exchange: getting the architecture right.

Systems integration is not a new phenomenon. For decades, disparate business and administrative systems have been modified, customized, or adapted to share information. The first architectural approach that gained wide scale adoption was adapter-oriented integration. In this model, each endpoint would be fitted with a custom software adapter responsible for translating data to and from other endpoints . Each endpoint in the architecture was required to do the same, and all adaptors where deployed by all network participants. This was fine for relatively small deployments. But it didn’t scale and was expensive to build and maintain, since point-to-point integration requires ongoing change management. The biggest limitation was that costs would rise exponentially as the number of network participants increase. For example, connecting 4 systems together requires 12 bi-directional interfaces, 10 systems called for 90 interfaces, and 100 systems required 9,900 interfaces!

Not long after, the Integration Broker (IB) approach gained broad acceptance with the emergence of EAI in the 1990s. But this just shifted the management of said adaptors to a central broker, and reduced the scale pain to linear from geometric i.e. total number of interfaces to write has been reduced. Any gains realized by the broker architecture tended to be offset by additional costs to maintain the integration solution. Another limitation of this approach is its reliance on being centrally deployed, which presents both network and compute scale challenges for large, distributed deployments. Compute performance could be mitigated by the development of optimized custom wire and data formats, but usually meant locking-in participants to a specific vendor package.

In the last few years, Service-Oriented Architecture (SOA) has re-emerged in a big way, heralded along with Web Services standards as the savior for systems integration. In a SOA, standard technologies and communication protocols enable a common framework for access to and distribution of information. Adoption of XML as the lingua franca for information sharing has leveled the playing field for how data is packaged for exchange between systems. Both of these, along with the core principles of separating access from implementation, loose-coupling and separation of concerns have enabled the distribution of the integration function more evenly across the network and its participants. So SOA and web services really has emerged as a best practice for complex data integration. This is what is commonly referred to as the SOA Network Model.

Bringing our topic back to healthcare, a service-oriented architecture is fundamental to the development and deployment of a successful HIE initiative. Leveraging the SOA Network Model for wide scale health information exchange can substantially reduce cost and complexity, addressing the challenges described in the previous post. This approach is founded on the creation of a standards-based information bus , on which participants agree to share information that conforms to a common, or "canonical" information model based on XML. For HIE between hospitals, IDNs, regional or national networks, this information is often shared as a set of messages based on the HL7v3, CDA/CCD, or ASTM CCR standards.

Participants are responsible for mapping their source data to the target "canonical" data model, and because all sources are delivering data onto the bus in a standard format, shared services can be offered to provide capabilities like semantic translation, record location, identity mapping, security policy, etc. This technique yields very high quality information exchange, as well as a one-to-one conversion cost between a network participant and the collective network services, which is much simpler and more cost effective than alternative integration models. The bus is highly distributed (often over a secure Internet channel) so that all end points can communicate without the need for a central mediator, and shared service endpoints can be virtualized i.e. deployed as location independent. As an added cost benefit, as new participants join the network there is no need to regression test all the other endpoints.

The net result is an architecture which is semantically precise, loosely coupled, and highly flexible to changes in number of participants, configuration and aggregate capability. But there's still one significant technical hurdle with an architecture like this (and even more so in IB deployments): highly verbose XML data formats and web services protocols can often hamper the performance and scalability of the architecture. Intel has addressed this in its new SOA healthcare interoperability platform, SOA Expressway for Healthcare. Intel SOA Expressway for Healthcare is a specific implementation of a new product category called a SOA "soft appliance", which delivers a breakthrough in simplicity, cost and scalability of implementing data interoperability. It natively delivers on the vision for this architecture and has the performance, scalability and security functionality needed to support an HIE deployment at scale.

In part 3 of this article, I will share with you some success stories from industry where SOA Expressway is enabling high-quality health information exchange via this very architecture.

I'd like to start by looking briefly at adoption of information technology in the healthcare market. Widespread adoption of I.T. in healthcare has been largely limited to systems that provide administrative or financial transactions. But that is changing. It is increasingly recognized that connecting the right people with right information at the right time can help reduce the cost of healthcare and enable better outcomes. Information technology tools such as Electronic Medical Records (EMR), mobile point of care(MPOC) solutions, picture archiving and communications systems (PACS), and clinical and management information systems (CIS/MIS) can contribute to lower costs and can help avoid medical errors, improving both quality of care and quality of life. Fundamental to achieving this vision is the realization of high-quality health information exchange (HIE).

There has been a rising tide of interest and government pressure to establish electronic clinical information and extend it out to the community of care. We are now seeing studies emerge that highlight the significant opportunities and myriad of benefits from healthcare interoperability in various markets around the globe. Some examples include the following: in Canada it is claimed that effective information handling would trim $6-7 billion from national health costs each year; In Australia, over $1.8B could be saved through implementing health information exchange interoperability among health care providers and other health care stakeholders. The HIE opportunity in the United States alone has been valued at $77.8 billion.

But while the benefits of HIE and their value are widely recognized, the vision for wide scale, high-quality health information exchange has not been realized. This is because even though the reward is great, the challenges faced are often greater. Paramount is the problem of how to connect the many tens to hundreds of sources of clinical data into a reliable information source which has reasonably consistent structure and shared semantics for key clinical data elements like patient IDs, chief complaints, diagnostic codes, and drug vocabulary…the list goes on! Add to this complexity the significant costs associated with the startup, scaling and maintenance of HIE, and it quickly becomes apparent why many existing approaches fail to deliver on the vision of broad base health information exchange and interoperability.

Within hospitals, systems will often not interoperate, which contributes to silos of disaggregated information. As a result, these healthcare facilities are only able to build a patchwork view of patient health, or are forced to rely on labor-intensive and error-prone searches through available hardcopy. In other instances where a hospital network may have a working integration solution, it may not be flexible enough to address changes in rules for compliance, reimbursement, or other operational needs in a timely and cost-effective way. Similar fragmentation is apparent as we look beyond the four walls of the hospital. Healthcare is largely a horizontally-organized industry, comprised of patients, payers, physicians, hospitals, pharma, and medical device companies. But although some standards exists (HL7, IHE, others) and the wiring exists (the Internet), there is limited examples of large scale HIE outside of a few large, vertically integrated healthcare organizations (like Kaiser, the VA, Health Infoways in Canada, NHS in UK) which have consolidated governance and oversight of several entities described above.

To extend health information exchange more ubiquitously across communities typically requires some sort of external stimulus. Often the development of a sustainable business model, or adoption of HIE by a large customer can catalyze adoption. We're already seeing examples of both today. But there are two other variables that can substantially disrupt the status quo and catalyze adoption of HIE: addressing the cost and complexity described above. Reducing the extremely high cost of implementation and maintenance, and simplifying the deployment and management of health information exchange can be strategically significant for the adoption of HIE on a wide scale by the industry.

In part 2, I will argue that getting the architecture right at the outset is the single most important enabler for this vision.