Lessons Learned from Implementing a Service Oriented Architecture in Healthcare

I thought I would take the time to post some lessons learned over the past three years leading a ground-up initiative at WellMed Medical Management creating a service oriented enterprise application for physicians and medical management staff to treat and transition care for patients.  Service Oriented Architecture (SOA) is an often misunderstood concept even among the ranks of IT professionals.  While many SOA initiatives have manifested and exposed internal business logic in the form of web services the approach for SOA is actually very non-technical and is rooted in a deep understanding of the business and strategic goals and involves an ever evolving process of continuous improvement and refinement.  This makes the approach both strategic and operationally focused.  In this post I will outline what I feel are some critical components necessary for a successful SOA-based project.

 

Understand the Business Domain Model

While many companies evolve over time it is important to ensure your view of the business domain evolves with it.  Healthcare organizations are no different.  Communication is key especially in rapidly changing and evolving environments such as healthcare and defining a clear functional domain model will help pave the way for future development or shifts in business.  Find natural lines of separation within the business and look for natural service boundaries which allow you to build services that make sense.  By creating separation of services boundaries you help define sources for data and information and avoid duplication within your architecture.

Lines of separation can be found between:

  • Different lines of business (e.g.. Medical Management, Clinical, Research, Transportation, MSO, HMO, etc…)
  • Product & Service Lines (e.g., Transportation, Disease Management, Chronic and Complex programs)
  • Product Variations

Understanding the business is critical to ensuring that IT is aligned adequately to support business functions.  IT is often a common service that crosses multiple business functions.  Common services that cross boundaries include infrastructure, data warehouse, applications, development, etc…  Through this modeling effort many IT organizations can quickly identify gaps in existing service and support for the business community.

 

Maintain a Common Definition of Terms

In complicated environments like healthcare where efficiently managing risk for medically managed patients and members is critical to the success of your business you must take a solid look at the data flowing into and out of your organization.  Having a solid definition of what a bed-day is from a hospital visit, as an example, is important from both a financial perspective and a medical management perspective.  Stratifying patients based on acute events such as historic hospitalizations, lab results, HRA’s, or audits are equally important for the management of that patents care.   Both finance and medical management aspects of the business are critical to the patients care yet the consumption of information can be viewed and assessed slightly diffent unless a common method for defining data and terms associated with managing your business are clearly defined.

 

To effectively define these terms you must:

  • Build from business domain knowledge
  • Evangelize the terms and their correct usage
  • Introduce new terms slowly
  • Seeking definitions that are both
    • Unambiguous
    • Context insensitive

 

Maintain a Consistent View of the Ideal System

 

I’ve always been an advocate of having a strategic and long-term vision for a product.  Knowing where you are going will help you make day-to-day decisions that will ultimately help you get to where you need to be.  The ideal system will often seem unrealistic to many but setting the bar higher than others will help make your organization more agile and ready to change as market or other external factors shape your business.   Our approach to building a strategic enterprise application included components for mobile devices (pre-iPad) and both patient and provider portals.  They will not always manifest themselves as a product immediately but setting the groundwork and service breakdown will allow you to readily transition to other products or services.

 

The following items will help you build a consistent view of your ideal system:

  • High level design or model of the:
    • Goal system and
    • Intermediate steps
  • Consider all relevant aspects
    • Hardware/Networking
    • Services/Communication Protocols
    • Data/Access
  • Keep it in a maintainable form
  • Evangelize the roadmap

 

I’ve found that keeping a current copy of the ideal system will help you in many other aspects as well such as quickly describing the business to potential employees, vendors, partners, and even internal staff.

 

Seek Opportunities to Advance the System

 

Service Oriented Architecture is a concept and proposition you must be dedicated to and not a passing trend you can close as part of a project.  As such you must change your mindset and approach to all your projects.  Often SOA initiatives are grounded in major strategic initiatives.  Like any major IT initiative it should fundamentally support the businesses core objectives and strategic goals.  Your choices from a day-to-day perspective should seek to advance this strategic effort and build upon the shoulders of what has already been created.  A core tenant of SOA initiatives is the concept of re-usability.  When building new services or implementing new features you should always seek opportunities to advance the system as a whole.  Ways to do this include:

  • Avoiding Big Bang Architectural Changes
  • Implement the final system in small steps
  • Places to look for strategic opportunities include
    • New lines of business
    • New clients or partners
    • 3rd party software updates
    • New vendor software that complements your core products (i.e. Med Management & EMR)
  • Incorporate changes with the highest potential return
    • Looking for small changes with the highest amount of return
  • Seek to learn from each opportunity

 

Evangelize the Vision

The architect is a business leader and will often be your biggest advocate for driving business change using technology.  This is a very collaborative role and this person must work closely with executives and have a firm understanding of business trends, strategic initiatives and goals so changes or shifts are adequately made within the application and technology architectures supporting the business.  Ways to evangelize the vision include:

  • Continually show the company
    • Where the IT end of the business is headed
    • How it’s going to get there
    • Why it should go there
  • Create opportunities in
    • Design Meetings
    • Architecture, Development & Governance meetings
    • Hallway conversations within IT and with senior leadership

 

 

Continuously Improve Everything

 

Lastly, I would say continuous improvement is an overarching requirement and mindset you must install in all of your initiatives.  This can’t be drove from the architect or developers alone but must involve changes in processes of the business departments.  In our case it involved the close interaction of  infrastructure, executive management, line workers (nurses, case managers, health coaches, etc…).  Like the agile methodologies we put in place to develop our enterprise product you must have continuous interaction and have the mindset of continually improving your product and services.  To do this you and your entire team must:

  • Seek a to maintain a better understanding of the business even as it evolves and changes
  • Add and refine terms in the domain dictionary
  • Evangelize, Evangelize, Evangelize…. (E Cubed)
  • Seek alignment between the business and IT and use changes in business as opportunities

 

This is by no means an easy process but evoking change within an organization, especially a large one, is not a simple undertaking.  I’m sure I will have more to add as time goes on but take these little tokens of knowledge, go-forth and build your own agile enterprise applications.