Thought Leaders In Cloud Computing: Doug Menefee, CIO of Schumacher Group (Part 3)

By Sramana Mitra and guest author Shaloo Shalini

SM: What is the architecture of these solutions?

DM: The architecture is built off the Apex code. The Apex code as well as the Web services interfaces that we write are inside Salesforce.com. These Web services include everything from .NET to Cold Fusion.

SM: So, these are not applications built on top of Force.com, for instance?

DM: With Apex, they are using Visualforce and the native architecture of Saleforce.com as a platform. I should call that Force.com. It is typical to talk about Salesforce.com because [while] the application layer is mostly CRM, the Force.com platform, which is what they are trying to brand and market, and those types of things are really where we will build most of our custom objects, and we use the inherent capabilities, features, and functionality of Salesforce to do that.

SM: With the integration strategy you talked about, you seem to have harnessed solutions such as Cast Iron and other integration technologies to really make the data flow across your organization. Can you talk more about what has been the philosophy behind such decisions, what kind of architecture has been deployed, and what are some of the real use cases that you have been able to pull off by implementing these integration solutions to such an extent?

DM: The best example I can give on a use case is in healthcare. Now, the challenge for me is, I’m guessing that many of your readers may not be too familiar with the healthcare industry. I would have to translate things that happen inside the healthcare space into more of a generic business explanation.

SM: But we want the specifics. Actually, I hear quite often from a lot of CIOs that in their specific verticals, the long-tail applications or the vertical applications are not tackled at all by vendors today. So, they have to deal with these customizations upfront. I think that today, this is one of the greatest opportunities for entrepreneurship in cloud computing. It may be the greatest blue-sky opportunity out there right now. So, please feel free to speak about specifics in healthcare.

DM: All right. When we bring on a new contract, we have an arrangement with the hospital that says, “We want you to provide a physician practice to us.” Now, a physician practice has to have a certain number of physicians associated with it belonging to sets of specific expertise. So, what we do is manage that process through Salesforce. A part of this process is typical Salesforce automation. But then we move into recruiting, which is complex. For us, finding and recruiting the right physicians for the specified practice of a hospital is extremely difficult. We usually do tie up with a lot of typical lead generation [companies] in the recruiting processes. But when we are working with physicians, it is different. With physicians, the job process is not like it is for many people who want to work for company and they say, Here is my resume, do you hire me or not hire me? In our world, we have to verify each physician through a specific recruiting process to ensure that they have all the right credentials and references. The physicians eventually have to work with the hospital, so essentially we create a package for the hospital through which they approve a particular physician.

It’s managed inside Salesforce.com, so that may take up four or five different departments. What we are doing inside Saleforce.com is walking a physician through a package where each job function is contributing to that physician’s record. At the end of the day, our credentialing and provider enrolling department aggregates all of this physician information in a format such that all that the hospital has to do to set up a new practice is to go through it and approve whether or not that physician can work at that hospital, in tandem with the recruiter. Once the physician is approved by the hospital, we put that physician on a schedule. We create what is called a first schedule date, and that first schedule date sets up a trigger. When that first schedule date appears, we take the information about the physician and move it, using the Cast Iron solution, to our physician scheduling application. This application is called Tangier, and it essentially gives the scheduler a new resource they can schedule for a hospital practice. The scheduling application knows what it takes to be able to look at the physician’s information specifics inside the Salesforce.com setup, such as pay rates, the shifts that particular physician wants to work, the profile, and so on.

SM: Got it!

DM: A lot of it is about timing and triggers. That is why we have so many workflows that are built inside of our environment to deal with triggers and actions in case a particular milestone is hit. In a typical case, the trigger notifies another person of a task, or it notifies another system that there is an activity to be done and kicks up a new workflow.

SM: In terms of architecture, your entire application is built on a basic Salesforce.com module, and you have extended it to do all of these special functions, right?

DM: We have what’s called an enterprise license with Salesforce.com which gives all of our employees and every physician inside of Schumacher Group our license.

This segment is part 3 in the series : Thought Leaders In Cloud Computing: Doug Menefee, CIO of Schumacher Group
1 2 3 4 5 6 7 8 9