This post was last updated on 2/5/24.
5 Essential Tips for a Successful Health Cloud Implementation
Salesforce’s Health Cloud can be the centerpiece of your patient engagement workflows, if you set it up correctly. As Kicksaw’s Lead Health Cloud Architect, I’ve worked with big, small, new, and established businesses to help them realize the power that Salesforce can bring to the healthcare space. I’ve also seen the headaches and expensive surprises that can occur when a business doesn’t take the time to think through their implementation strategies before they start building.
Here are five tips that Kicksaw recommends for every business that’s considering a move to Health Cloud:
Enable Person Accounts
Pretty much every Salesforce admin out there has had it drilled into their heads that “Person Accounts are bad!” I see this time and time again in the various forums I frequent, and in most cases, I would agree. Person Accounts can introduce a lot of unnecessary complexity into an org, and once you turn the feature on, you can never turn it off. Sounds pretty scary, right?
When used in the right data model, however, Person Accounts are pretty great. They allow you to treat patients and members as both Contacts and Accounts, which then gives you tremendous flexibility to build relationships around them. Does the patient have a provider on their care team who works out of two facilities? Are members of the patient’s household taking part in managing their care?
Where standard accounts and contacts would require a dizzying amount of customization to make this apparent, enabling Person Accounts in Health Cloud allows you to not only use standard objects and fields for these relationships, but to display them graphically as well.
The Health Cloud admin and developer guides do a pretty good job of covering this setup step at this point, but just to reiterate: don’t use the Individual model for patients. Enable Person Accounts at the start of your build.
Determine the Features You Want Before You Install
Every Salesforce admin has been in this position: your company has purchased a new product, management is pushing to see results fast, and you’ve been sent an installation guide that reads like War and Peace. So, what do you do? You install all of the packages in the guide, then go through and figure out what your team actually wants to use.
Do not, I repeat, do not do this with Health Cloud.
Health Cloud has multiple data models and distinct features targeted towards specific use cases in the healthcare industry such as insurance claims pre-authorizations, life sciences program enrollment, patient specialty referrals, and more. It is highly unlikely your business will need all of these features, and installing them will clutter your org with hundreds of fields, objects, record types, metadata, and more. These become a nightmare to get rid of later on.
Take the time to sit down with your stakeholders and determine their use cases and requirements. Then, go look through the various managed and unmanaged packages to get an idea as to which features are included. At that point, you can determine what needs to be installed (in a sandbox of course!). Remember, when in doubt, wait to install — it’s always easier to add more features than it is to clean up a messy org!
Use Standard Components Wherever Possible
As I mentioned above, Health Cloud’s packages come with a ton of stuff. There are sample flows, Apex triggers, custom metadata types, and other elements that drive a lot of the UX within Health Cloud. That being said, until you’ve spent some time under the hood, the purpose of each of these components will not be immediately clear, even if you read the admin guide from cover to cover.
Fortunately, the product team at Salesforce has put a lot of time and effort into making sure Health Cloud supports and integrates easily with common healthcare workflows and systems. They are constantly releasing upgrades and coming up with new ways to shorten the time to value for their clients.
All of this is to say that you should try to use the tools they have provided as much as possible before deciding to build custom solutions. Health Cloud’s documentation recommends that you “extend it — don’t replace it.” While it may seem faster at times to just build a custom object or add a custom field, you might be painting yourself into a corner that prevents you from easily taking advantage of new features down the road.
Try to use the fields and objects provided, and customize the sample flows Salesforce provides instead of starting from scratch. Nothing is more frustrating than having to completely re-architect something that took you hours to build, just so that you can turn on that new feature that the Salesforce Account Exec told your boss is “super easy to set up.” Let Salesforce’s product managers do as much of that architecture work for you as possible, then sit back and let Health Cloud upgrade itself!
Consider Your Patient Communication Options Early
Yes, Health Cloud is HIPAA compliant, at least for data at rest. But what happens when you need to send PHI to a patient, or to another provider who isn’t in your Salesforce org?
First things first: standard email is not going to work for you. CMS has strict requirements around secure patient messaging that tools such as Outlook and Gmail simply aren’t built for. Are patients going to need to send in attachments? What about health questionnaires or consent forms? Are you receiving referrals via fax?
Health Cloud comes packaged with several tools to assist with some of these use cases, but depending on your needs, you may find that a third-party solution is a better fit with your business. Tools like Zix or Paubox can help with sending and receiving secure email. eFax has a HIPAA-compliant fax product that can integrate with Health Cloud, and tools like Formstack or Form Assembly can help manage patient forms and consent. All of these tools come with additional licensing costs and take time to procure, so it’s best to investigate these options early on in your project discovery phase, so that your implementation doesn’t grind to a halt while you wait for signed vendor contracts.
Integration Plan & Middleware
On its own, Health Cloud is a powerful engagement platform for healthcare businesses. But where it really shines is in its ability to aggregate data from across all of the different discrete systems in the healthcare continuum and display it in one comprehensive, longitudinal patient record. No more clicking between windows to find the data you need on a patient. Just log into Health Cloud and see everything in one place. Sounds fantastic right?
Well, it is, but in order to get there you’re going to need to integrate all of these systems, and that will take some decisions.
Health Cloud is not intended to serve as an EHR. Instead, it is designed to complement EHR workflows by leveraging the power of Salesforce on top of your EHR’s data. Unfortunately, many EHRs and other clinical systems only have HL7 APIs available, which Salesforce can’t communicate with directly. If this is the case for your EHR, plan on procuring some type of middleware such as Mulesoft or Redox.
If you’re lucky and your system has a JSON API that can be integrated directly with Salesforce, you can plan to build a custom integration. Just understand that there is nothing out-of-box that will allow you to declaratively integrate Health Cloud with external clinical systems, so plan on finding a solution if you want to take full advantage of Health Cloud’s integrated data model.
This is just a sample of the many tips and tricks that Kicksaw has learned about the nuances of setting up a successful Salesforce Health Cloud integration. We’ll be sharing more of these in future blog posts, in our monthly email newsletter, and in our LinkedIn feed.
Feel free to reach out to us directly if you have a project or question you want to discuss in more detail — just submit the Contact Us form at the bottom of this page and we'll be in touch.