Date published: 01.09.08 - not release date

MedicAlert Embraces SOA to Drive Business Agility

How a Leading Non-Profit Leveraged SOA Infrastructure to Change Its Business Model for the Better By Jorge Mercado, Lead Architect of the Software Architecture Group, MedicAlert Foundation

At MedicAlert, we have vividly seen how service-oriented architecture (SOA) can enable business agility and elevate the value of the IT organization’s work. Since we launched our SOA initiative two years ago, we have laid the foundation for vital new forms of collaboration with partners and accelerated the introduction of new products and services that can strengthen the business.

MedicAlert, a non-profit organization with four million members worldwide, is best known for the medical bracelets worn by our members. The bracelets let doctors and other healthcare providers know if there's a particular medical condition – such as an allergy or an illness – that must be recognized in an emergency situation.

While we have provided services that protect and save lives for fifty years, we have moved more deeply into healthcare information services in recent years. We now enable members to login to our systems and manage their personal health records while maintaining security, privacy and confidentiality. The MedicAlert repository relies on Web service interfaces to support standard Personal Health Records (PHR), including electronic drug prescriptions and for patient record interoperability. The repository of personal health information facilitates the delivery of critical medical information between patients, providers, payers, and emergency responders around the clock and across the world.

We realized two years ago that our growth, improvement and continued success were dependent on creating greater interoperability with other health service organizations such as hospitals, doctors’ offices, labs, pharmacies, and healthcare payers. We wanted to be able to accept information from these partners and populate our members’ medical records on their behalf. Unfortunately, the systems we had in place were not designed to effectively populate data in this fashion.

SOA for Interoperability

Recognizing this challenge, we embarked on an initiative to implement a services-based system. We now have approximately twenty Web services in production – and many more in development.

We began with a bottom-up approach that enabled us to start small and get results quickly. As time progressed and business needs continued to come forth, we began to engage in more a of top-down approach to our SOA delivery strategy. More specifically, we embarked upon an approach whereby both strategies would converge.

We looked at how to get our systems implemented quickly using Web services in ways that would support our business. We were most concerned with security and management of these services, and evaluated management tools and industry-standard security mechanisms that would meet our architectural requirements. We were able to move fast, while remaining aware of the business objectives we needed to address and processes we intended to model. Ultimately, we deployed Microsoft BizTalk Server 2004 as the process integration and rules engine and AmberPoint for runtime governance and Web services management.

Our SOA system has dramatically enhanced partner interoperability. In the past, we would have to rely upon S/FTP based solutions that would involve chunking through data and writing records directly to a database. While that may be a “classic” way of conducting this sort of activity, it was not a scalable one.

A better approach is to have a generalized set of services that can be offered up to these partners either directly or indirectly. While one has to be prepared to address custom requirements as necessary, the objective is now to create a scalable system and be able to wrap custom policies around the services that are produced. Our new policy engine enables us to execute different policies to accomplish a vast array of tasks in a scalable and secure way.

Runtime Governance

Runtime governance is critical to the success of any services-based system. We took a long look at our options here. Our selection of AmberPoint has enabled our architecture and infrastructure teams to concentrate on Web services implementation and performance as opposed to the litany of low-productivity tasks that would have been necessary in its absence. Among the benefits of the “policy-based approach” that we have taken to governance:

•Performance Metrics. We are now capable of monitoring system traffic in real-time using a single console. Detailed performance metrics helps us monitor traffic volume, response times and other key performance indicators.

•Visualization. This capability enables us to see and understand the impact of system changes and perform root-cause analysis if there are problems. Further, we can clearly see all the service interdependencies, which are visually mapped out by the software.

•Flags and Alerts. Having a system that can alert us to unexpected conditions enables us to rapidly detect, diagnose and address system errors – whether they might be service level violations or faulted decryptions.

•Virtualization. Service virtualization enables us to aggregate internal services into a single, unified, composite offering for use by external parties including partners and members.

While these capabilities represent a vital and valuable foundation for our SOA efforts, it is our team’s ability to enable and support agile business moves that represents the most significant payoff to the organization overall.

Business Agility and New Product Rollouts

One of the most compelling examples of our new business agility came when we launched our new E-HealthKEY service. This service enables our members to store comprehensive, personal medical information to a USB memory stick, which they then can attach to a keychain and carry with them at all times. It is a windows-based desktop application that runs on a member’s PC. The member plugs it in, the application loads up the data and the member can manage health records on the PC – synchronizing all of his or her health data off our back-end system.

As a result of our investments in SOA and Web services, we were able to roll this service out far more rapidly and effectively than would have been otherwise possible. E-HealthKEY consumes XML documents with the member’s medical information. Orchestrations then parse that data out and route it to the right systems to update the member’s medical record. This underlying support infrastructure enabled the rapid rollout of the service and has positioned us to continue introducing new ones. While present efforts have focused on managing inbound information, we will increasingly be focusing on securely distributing health information – ensuring it is available in real-time at the clinics and labs where it’s needed.

Our SOA infrastructure also lays the groundwork for others to OEM some of our offerings as Web services. Other organizations can add our services to their own to enhance the value they bring to their customers. In this way, SOA and Web services have brought new opportunities for growth to our company and our industry partners.

It should come as no surprise that these types of capabilities strengthen ties between IT and the business. Business leaders at MedicAlert want to be able to react more quickly and make our services more valuable. They want to bring on more members at a faster rate. Being able to more rapidly respond to business opportunities addresses their objectives – and now they realize that SOA can help the organization meet those goals.

This has changed how IT systems teams collaborate with the business. The department heads from our business development group, marketing and sales group, operations and finance all get together when new objectives emerge. They lay out opportunities and business objectives. Typically, there are one or two representatives from IT and the engineering side at these meetings. It is very informal. We work out feasibility, necessary resources and timeframes.

In the past, IT often wouldn’t get enough information or the right information from stakeholders in order to develop effective systems, as the classic requirements-gathering processes did not work for MedicAlert. We move quickly and make decisions quickly. But we have learned to ask the right questions and get the right information to build systems that will advance the business. If you build your systems in relation to your business model, then you’ll have more success with your SOA.

From a Web services management perspective, we demonstrate our agility through rapid service rollout, versioning and upgrades. We believe it is vital to seamlessly introduce new versions of services in order to build confidence in and commit to our approach. For internal services, and with a service policy engine, we dynamically re-route requests to appropriate service versions, transform requests and responses to maintain backward and forward compatibility between clients and Web services.

By taking this approach and having the capabilities to deliver, our architecture and infrastructure teams have developed greater confidence and respect among the company’s business leaders. Our company is now investing significantly to enable us to further build and enhance our services-based architecture, our systems, and our talent pool.

What we recognize is that success for us comes down to two things: scalability and agility. We must be able to scale the processes necessary to support the business. We also must be able to help the business create and respond to opportunities in the marketplace.

We could probably do all (or most) of the things we are now doing without SOA. But it would be very difficult and it would not scale. It would not be agile or adaptive whatsoever. It would take months to carve out each solution. SOA is not, at heart, about the technology. It is about making your business more agile – being able to rapidly seize new business opportunities.

Lessons Learned

Our SOA initiative has significantly changed the way we work and the impact that our IT teams can have on the business. First of all, one has to realize that is just way too much for one person or one role to do. We are a small shop. We wear many hats. But now we are trying to give everyone their own hat. We have expanded the team, hired people with more specific skills. Our developers now can concentrate on developing. Web services infrastructure specialists can concentrate on infrastructure. We have expert programmers that really understand the nuts and bolts of Personal Health Records. We have another set of engineers that really understand Web services – how to make them work together, how to secure, deploy, and manage them. This deepening specialization enables us to be more concerned about the bigger picture.

To me, a critical aspect of SOA delivery is about making sure a Web service is modeled and designed properly -- that it is reusable, solution-agnostic, and can be actively versioned. Part of that challenge is defining layers of services. The lower you go in terms of service layers, the more reusable your services should be. The opposite is true as well. The higher you go in terms of service layers, the less reusable because they start to solve very specific business problems.

Another aspect of SOA delivery is orchestration of business processes in the integration layer. Web services become more useful when they are combined with other Web services to provide the substance of a particular business process. You start to address bigger business problems – not just updating a database record, for example.

In addition, make sure you have established a solid plan for management and security before your launch your endeavor. It is all too easy to lose control of services if they are merely launched in an ad hoc, bottom-up fashion. This chaos will eventually undermine your ability to act with agility and dynamism. At the same time, poor approaches to security threaten to leave the operation vulnerable.

One also must draw on the perspectives, capabilities, and best practices of experts when possible. Select vendors with a proven ability to deliver in runtime conditions – with an eye toward their design-time contributions and capabilities as well. Check their customer references and industry partners. We made our vendor selections with great care and diligence, and we have been pleased with the outcome.

However, the most important thing we have learned in the course of our SOA initiative – something I try to convey to other architects – is that complacency is a career and organization killer. If you enter the world of SOA thinking you already know it, then you are going to fail. You must go into this with a very open mind. Architectural and development approaches that have worked in the past may no longer scale or perform at the levels that are now possible. It is critical to keep learning the craft and looking for opportunities to enhance the agility of the business.

Jorge Mercado is the Lead Architect of MedicAlert’s Software Architecture Group.

For more info, contact:
Monique Chambers
Devonshire Marketing
0870 2407995
07788 751722