In my last post I looked under the hood at data interoperability, examining the need for the normalization of both "syntactic" and "semantic" aspects of healthcare data. In this post I will present a high-level architecture for data normalization to share some understanding of how health information exchange is implemented in practice.
I went to the InfoWorld SOA Executive forum held in New York this week. The theme of the conference was "Realizing the value of SOA". There were several well delivered presentations on the importance of understanding business process first, organizing the right team skills and structure and picking the right early projects in order to crawl, walk and then run with SOA. Without a disciplined approach focused on these basics any technology selection is doomed to either fai
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.
This is the third of a three-part article looking at the area of interoperability and health information exchange (HIE) in the healthcare industry. In the first part, I intended to clearly articulate the key challenges and barriers to adoption faced by those looking to engage in HIE. Part 2 examined an architectural approach to address those challenges as well as some technology enablers to realize a vision for high quality HIE.
In many conversations I participate in regarding Service Oriented Architecture (SOA), part of the conversation oftens leads to "....how best can I incorporate my mainframe in the SOA architecture...". There are a number of mainframe SOA-enabling options, and in this post I will share my opinion on the application of a short-list of tried and true approaches.
Integrating the hot, new SaaS application into a company can often be a challenging undertaking. The SaaS application was acquired for a pressing departmental need, yet manually re-inputting and syncing key data like employee, vendor or supplier master directories is not practical. Manually coordinating a sale by the customer saying "yes" with a win recorded in the sales force automation tool yet hand crafting delivery instructions in the order module of the ERP is not really a sustainable business proc
This might sound odd to some of you reading this, but I am regularly asked the following question ... "What is the difference between SOA and SaaS?".
Given the acronym soup of the IT industry I am not surprised to get that question and expect to for some time to come. The simple answer is that:
- Service Oriented Architecture (SOA) is a means of designing and building software. It is a manufacturing model.
In my last several posts I have been sharing the concepts of a new product category I have been referring to as a SOA "soft appliance". Those posts have covered the origin of the idea, features, benefits and how is it similar to and different from other types of service-enabling infrastructure.
Going forward for a while, I plan on posting on the deployment architectures and usages of a SOA "soft appliance" platform like Intel SOA Expressway.
In the last blog I wrote about the similarities and differences between a SOA "soft appliance" like Intel SOA Expressway and an ESB-based product. Two key questions often arise out of that discussion: (1) Why do I need a SOA appliance if I already have an ESB, and (2) Why is a "soft appliance" better than an easy-to-deploy, secure and high-performance hardware appliance?