Business

Salesforce.com announced the beginning of building vertical solutions back in DF 14 (It was my very first DF attendance). Back then I didn’t know what to think of it. One thing was sure; Salesforce was not the first to do this. Coming from a Siebel background where they also massively built retail, automotive, life science, … vertical solutions the concept was not new and working for several clients in those days showed that most of them also chose for the vertical instead of horizontal version of Siebel. So we were quite curious on how Salesforce would approach this.

The first pilot version of Health Cloud came under our eyes about a year later when we were working with a client that was very interested in having a Health Cloud solution. It immediately became clear Salesforce was not approaching it the same way as Siebel did before. While Siebel built very complete, detailed, holistic solutions that covered almost every inch and aspect of the specified industry, Salesforce was more building a backbone that had all the core components and was looking for ISV partners to build on top of that a more complete solution. Easy business you would say but then again they put a lot of thought in the backbone to make sure it can fit a wide variety of use cases within the industry. The initial conversations and presentations we had with the product team showed they did their homework. It was kind of a ‘careful’ first version, one where they could still go any direction if perception and feedback of the first ‘early adopter’ clients would require them to. Hiring industry specialists that worked on the model and not just look at the IT perspective was a very good move in this area and for sure contributed to the quality of the product. Again, another year later we are participating in a first Health Cloud implementation for one of our clients in Europe. Having been involved in the architecture, design and building of the solution we wanted to share our experience with the community.

THE HEALTH CLOUD CONCEPT

Patient centricity, you get bombarded with it in HC sessions at the Salesforce events. And that’s also exactly what it is. The patient is the centre of the solution and then specially its care plan and activities. All the rest evolves around this concept, every contributor to the patient care plan and every source of information that can help to bring a more complete and better picture of the patient’s care.

CARE PLAN

The core of it all is the Care Plan (under the hood it’s the Case object) which is the main record of information that can give you all the specifics about an individual’s treatment or illness. You can see it as a medical state of a patient or as a plan to evolve the patient into better health. The Problem and Goal concept can be utilized to show the clear steps and aspects to consider in the person’s treatment path. The care team (underneath case team object) here can be used to give the right people in the care team the right role and visibility. It drives the accessibility to the patient’s data as well. But you don’t have to stick with only these items of the care plan. In one of our use cases we extended it with our own specific information (custom objects) that we wanted to capture. Not everything that you want to track from a patient can be put under problems & goals and so some easy configuration (point & click) was sufficient to make this happen. The Care Plan was in that sense a good basis to start from. What we had also done was build the care plan template concept on our own. We didn’t have the feature available then (as it was only introduced in Winter ’17), now it is so we can think of a migration plan. It’s a nice example of where Salesforce listens to its clients to make the product better :-).

THE INDIVIDUAL (AKA PATIENT)

Another key component is the Individual object, well not really ‘object’ in the context of other Salesforce object. It’s more of a virtual way of showing information that’s coming from multiple other objects underneath. It’s a combination of Account and Contact (with specific record types) as in the world of a Patient you need to capture the information from a personal point of view (contact information, collaboration, medical information, …) but also from a customer point of view (transactions like orders, cases, tasks, …). It’s almost like Person Accounts but not the same as Person Accounts by default disables Contacts while the Individual concept does not. We had a bit of a challenge embedding this concept in our overall Master Data architecture as in the context of an ERP integration it didn’t map seamlessly. We also had other non-health cloud users in the same Org and so by definition if you don’t have the license you can’t access the individual records (be it contact or account). At the end we managed it with the proper governance in place from both process and technical + integration point of view. But you anyway get into the risk of data duplication to make things work if you need to host both HC and non-HC users using some of the same data in 1 Org.

Another item to consider in this setup is the fact that when searching for a patient (using global search) you get its contact and account record showing up in the results, you don’t get the individual record (as it’s not a real object). Depending on which one you pick you will see different drilldown behaviour as only the Contact will open up the Patient card and the other HC objects. So this is a bit tricky to handle.

The candidate patient concept is beneficial to the patient creation process. Often the patient needs to go through some kind of validation before being considered an actual patient that can be worked with. This process helps in that area whereby patient candidates are converted into actual patients. But HC expects candidate patients to be imported from an external source and in our use case we didn’t have any need for integrating as we created patients ourselves coming from discharge requests from hospitals. This use case however is currently not 100% supported in the console (New button is not available on standard Candidate Patient view). Hopefully one of the next releases will enable this feature. For the rest we extended the candidate patient conversion process easily with a flow to mainly populate our care plan (at that time care plan templates were not yet available).

EHR OBJECTS

The ability to integrate EHR information is essential to most of the use cases we encountered although depending on the country the general readiness and acceptance by the regulatory instances varies a lot. Data Privacy comes easily into play and with that strict rules on data residence, protection, storage and visibility. So usually each use case you encounter you will have to mitigate this risk one by one. Recently we came across another business scenario in the medical research area where the idea was to let patients capture some of their own data in order for resident doctors to do trending on mass population for rare diseases. The ability to have more and time-accurate data was the primary objective here. And they also asked the question to integrate some EHR data to use that also in the trending and analysis. It’s kind of an inevitable discussion in any HC endeavour so it seems.

PATIENT CARD, TIMELINE, COLLABORATION

Very powerful is the main collaboration view where you can see the complete care team with its chatter feed that can provide a complete view of what happens with that patient to all stakeholders that need to see it. It’s all in one view. This really shows the extensibility of the solution. You can easily think about building a healthcare professional portal, a patient mobile app or portal or a patient view for any other type of stakeholder.

The patient card will show you what you want to see (contact details, medical history, conditions, laboratory results, treatment information, … ) and can be easily extended with other custom information that you want for your business case. By default it looks at EHR objects (built into HC) but can also easily look at other custom objects you can add. One limitation (or maybe we haven’t found the solution) is that you can only display related information to the patient’s contact record. When you want to show some custom fields you created on patient contact or account record this becomes a bit more difficult to do as the top part of the patient card is not customizable (as of the time of writing this blog of course). An alternative is to create a new tab on the patient card to display all patient data from the account record.

The timeline view is one of my favourites, a healthcare person can easily get a full overview of the patient and it’s short or long term history of activities. You can use this to search and view all actions related to the patient’s history and also classify it and show/hide certain activities to make it really tailored for you. Event icons bring context to the timeline as well. It’s extremely responsive. Some features that are not in there for the moment but could be of benefit to improve are

• The ability to customize the fields you see on the activity (or perhaps when you hover over it).
• The ability to drilldown on a task to get more details
• The ability to clearly indicate which activities could potentially require actions to be done (mostly meaning indicators like colours or similar). We know in the Today view you can also see activities you need to handle but having this in the timeline view would also be beneficial.

HEALTH CLOUD CONSOLE

The console is based on the same concept as the Sales or Service Console (hence HC is kind of an enhanced service cloud feature). Leveraging this was a good and smart idea. You build on top of what you already have out of the box, you get immediately a nice and intuitive layout and you know you can still extend it as you wish. But the biggest added value of the console is that the user gets the perception that it’s an app on its own. It’s a fresh layout with the specific tabs like Today, Patients and Candidate Patients. The filters and view layout for the patient list views can be set by filtering on related data and this is very powerful and a feature we had not seen before. It lets you create almost any list you want and very useful in light of patient segmentation. On the other hand it seems to be technically a ‘heavy process’ so this might be one of the reasons why the views take sometimes quite long to load.

Customization on the 3 tabs mentioned before is limited and we quickly came upon some use cases where we didn’t know what to do. Going back and forth with support and the occasional product person we could get a hold off helped but not always. I guess our initial limited scope of users had something to do with it :-(.

The console is good but it is at the same time a must to be used in HC. Although you can easily avoid using it and use a non-console app to access the HC objects it will complicate things. Remember the individual (aka patient) is in fact an account and a contact so depending on what you’re capturing on either object the HC components like timeline and collaboration view behave differently. Tasks on the Timeline view need to be linked to the Account and not the Contact for one. Some fields on Contact display on the Patient Card. Creation of an individual will require you to create both account and contact, although there is a trigger available that will create the contact and care plan based on the Account of type Individual. So you can work without the console but need to be aware of these things.

But for the major part it did what we wanted it to do and also the feeling we got that more enhancement would come quickly did not make us worry too much. We had already experienced in the pilot program that the Product team really listened to what we said and also adapted the product during that time as well.

PERFORMANCE

This was and to some extent still is a bit of an issue with Health Cloud. Namely the console load time took very long. It improved a lot already with Spring ’17 but there is still room for improvement.

EXTENSIBILITY

Built on the platform you can count on HC to be extensible. Aside from the before mentioned customizations we did we’ve also extended the console with some graphs that show certain patient metrics. It’s usually showcased in all HC events and presentations but make no mistake they are NOT included in the package. It’s probably normal as this is very much tied to your business case. However it shouldn’t be too hard to build them. We built trends and graphs for blood pressure, temperature or weight but you can extend it with anything that you’re capturing and do some really nice things with it. These graphs then also show immediately the added value a tool like HC can bring to its users. Aside that we also exposed some HC objects on SF1 to be used for doing care in the field or at the patient’s home.

SOME OTHER LEARNINGS

Patient Conversion process
Learning the hard way, we discovered that the patient conversion process does not work at all when you have validation rules on the Account or contact object. And it doesn’t give you any clear error message let alone that debugging is not possible with this managed package.

Global Search
This one is quite tricky. As the patient (or Individual) information is actually stored in 2 objects (account and contact) when you type in the name in the global search and click either of the 2 records the console behaves differently. While the contact will show you the patient card and all related HC tabs the account will just show you a classic account page and nothing else. So this is a bit tricky to overcome and may require your users to be trained properly in picking the right record.

Releases
When you were part of the early adopter group and started using the first versions in a real life program you might have noticed that later versions actually removed certain fields. Now it should not be a big deal I guess but when you’re using a CI tool like Jenkins and in the middle of a release you get a new version this can cause quite some headaches as significant manual clean-up is needed then.

Mobile Health Cloud
Although it was mentioned briefly in the beginning there is no mobile health cloud app available as of yet. The main reason would be to have some data offline. We encountered a business case where offline was a must as field nurses would not have coverage everywhere. SF1 can be used partly for this but it doesn’t give the same experience one has when working with the console.

Support & Documentation
Always log tickets when you need help from support, whether you’re already live, testing, building or even just in discovery phase. It’s the best and quickest way to get help for your problem. You get tempted quite fast to contact that one guy you talked to during a SF event or got an email from once a while back.
In terms of documentation there is the implementation guide which is a good basis to start from but it’s still fairly limited. There are trainings available as well and the Community Group Health Cloud for Partners helps as well (https://partners.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F930000000XZDk). But most is trial and error and sharing blogs like this hopefully also helps.

Data privacy
As already mentioned this is a topic to be handled on case by case basis. Depending on the type of information you’re gathering, what you’re doing with it and who you’re exposing it to you will have to make decisions on what mechanisms to put in place. Salesforce Shield is good that it’s bolt on to the HC license (I think or at least I heard) as it gives you the ultimate data protection BUT at the same time it adds quite some limitations to your application as well. The limited use of SOQL, sharing rules, lookups, formula fields on encrypted fields and also the fact that some standard fields simply cannot be encrypted will have to be taken into consideration and not a lot of alternatives are out there. For a full list of trade-offs of the Shield Platform Encryption (https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/security_pe_considerations.htm)

Finally, we hope you can benefit from this blog, it is based on our experience and knowledge so it may not be a 100% accurate. Feel free to comment with thoughts, discussions, general feedback on the below coordinates or in the community group.

Geert Adams
Managing Partner / Salesforce Principal Consultant
geert.adams@c-clearpartners.com