Personalization challenges often relate to data. Data drives the solutions needed to deliver personalized experiences, making your data practices and governance a critical piece of the puzzle. Unfortunately, more data doesn’t necessarily create more value. What’s more important than how much data you have is knowing when to leverage data (Gartner).

Here are a few common challenges we’ve helped clients navigate:

1. No Single View of the Patient or Member

Having a 360-degree view of your patients and members is a cornerstone to executing the one-to-one marketing that progressive organizations are delivering. It’s also a significant obstacle for many organizations. Without a complete view of all consumer data, it’s difficult to know who your consumers are and how to anticipate their response at any given time.

This boils down to a data management issue. Organizations struggle to gain this single view for various reasons: inability to connect data across multiple systems, industry regulations, poor data quality, lack of patient and member data outside of the healthcare setting (e.g., transportation access, socioeconomic status, household income, food and housing, neighborhood, community needs, etc.), or lack of relevant supporting technology. These gaps hinder an organization’s ability to truly deliver person-centered touchpoints.

Overcoming these challenges involves building the right digital foundation to achieve a complete patient or member view. This includes:

• A unified login and registration process across digital properties to recognize patients
• A mature, orchestrated approach to data access and integration for the platforms you intend to use in driving personalization
• Customer data platforms that collect data in real time for holistic, up-to-date member profiles
• HIPAA-compliant targeted communications that are transparent and respectful of consumer data

While it may be a challenge, healthcare organizations are taking steps to integrate disparate platforms and achieve a holistic view of the consumer. External data sources, like the publicly available Health People 2030 or United States Census Bureau, can be layered in to add to the 360-degree view of the customer, ensuring social factors like car ownership, rent, and home ownership, are considered.

2. Inability to Quickly Gain and Apply Insights

First and foremost, your patients and members are consumers. These healthcare consumers are active across a variety of different channels and devices. If you wish to engage with a prospective audience, you must meet them where they are and become part of the conversation. To create a personalized experience in the moment, you can’t limit yourself to optimizing it for one channel, nor can you solely rely on historical and basic consumer profile data.

Whether you have thousands or even millions of members, you also need to be able to scale these personalized experiences. To do this, your digital experience platform needs to be able to harness and analyze member data to automatically deliver customized content, offers, and programs to individuals. When you automate the communication across channels, you will be able to improve conversions through consistent, relevant offers every time.

As emergent types of interactions within the healthcare system begin to see rapid adoption, the boundaries of this personalization also expand. Personalization isn’t just about pointing a patient to the tools, tasks, and experiences most relevant to them, it’s now about making sure that the consumer’s experiences across engagement screens, channels, and modalities mirror what you, their care provider, knows about them that others may not.

We are balancing the need for better, quicker, and faster personalized experiences with the real and pervasive risk that if we build these tools without thinking about diversity, equity, and inclusion (DE&I), we could be building inequities into the foundations of the digital world we hope will transform healthcare by removing those very inequities.

AI and ML don’t understand the nature or risk of bias, instead these programs look at the data to find patterns that they can learn from. If models ultimately result in bias, it means the data provided to them has inherent bias in it.

There are specialized techniques that can be employed to monitor and detect for bias in AI and ML models, and those should be leveraged during the development and testing phases as well as in production to continuously monitor personalization predictions.

Bias detection should be closely analyzed to understand its impact on DE&I, as not all biases have the same level of risk and, in some cases, might even be expected (e.g., personalized maternity service messages are shown to be biased toward women between 20 and 40 years old).

Personalization becomes an extension of your healthcare organization’s own digital partnerships. Everything that makes the series of interactions and options easier for consumers to navigate – from core personalization to e-signature – is part of the overall goal.

Personalized solutions have the potential to draw out implicit biases that can perpetuate health inequities in marketing to your consumers. Here are some ways to combat this challenge:

• Start with DE&I. Be aware that implicit biases exist, and you may be susceptible to them. If you bring a DE&I lens to every topic, you are more likely to build effectively.
• Communicate with your consumers, patients, and members regularly, and educate yourself on ways to reduce your biases.
• Leverage journey science services to make the right information as accessible, relevant, appropriately engaging, and timely as possible to reach the right people in the right way.
• Leverage interoperability services to make informed and timely clinical decisions and to carefully and safely draw inferences about when and to whom/what we can communicate messages that will be most beneficial to patients.
• Leverage automation techniques and continuously monitor for biases in your AI and ML models or marketing audiences and have a process to review those techniques through a DE&I committee.
• Contact us to learn more about our journey sciences, interoperability, automation, and monitoring services.

EXPLORE NOW: Diversity, Equity & Inclusion (DE&I) in Healthcare

3. Lack of Coordinated Resources to Execute

Securing and coordinating resources to execute a personalization strategy is another challenge. Part of the problem lies with ownership of this role. Does it belong to the digital marketing team or a specialist in corporate marketing? What role does IT play, and to what extent are they involved in the implementation? Answers to these questions will vary based on the structure of your organization and the approach you take.

As you move from planning to execution of your personalization strategy, considerations will include:

• Understanding the resources needed, and whether you can build internally or need to find an external partner.
• Forming a center of excellence (CoE) or small team with cross-functional roles to provide leadership, share best practices, and offer support and training when needed.
• Building your internal team by establishing a development governance model to ensure governance is an enabler rather than an inhibitor. When done right, governance should empower people to make decisions and streamline the decision-making process.

Learn more about personalization in healthcare

Healthcare consumers have high expectations for a personalized (or at least a relevant) experience, but many healthcare organizations struggle with delivering it. This is especially difficult with the need to avoid invasiveness and inherent data bias towards the social determinants of health that could perpetuate inequities. A powerful digital foundation gives you the ability to personalize experiences.

While your organization may not yet deliver deeply personalized experiences, the potential is there. Partnering with a digital consultancy that specializes in healthcare solutions will help you reach that potential. Our experienced and award-winning team will not only help you implement the solution but also create a strategy to align the people and processes to embrace it.

Gain step-by-step guidance on how to overcome challenges, expand use cases, comply with regulations, combat bias in AI and ML models, successfully implement/execute/grow strategies, and use CDP/CRM/DXP to deliver personalized experiences through our interactive guide.

GET THE GUIDE: Personalize Your Healthcare Marketing: Crawl, Walk, Run, Fly

A healthcare experience upgrade – that’s the quest of so many healthcare organizations. Consumers expect better healthcare experiences. Government has even mandated it. And, below the surface, data serves as important connective tissue powering seamless, connected experiences for patients, members, and their care ecosystems.

Interoperability helps unlock data’s greater potential — healthcare innovation, more meaningful care touchpoints, and so much more.

The mechanics that support truly visionary interoperability initiatives require more than “a flip of the FHIR switch” though. It takes strategic thinking, reliable data, and architecture that supports the safe, rapid, secure, scalable, and compliant sharing of that data.

READ MORE: Deliver Fully Integrated Experiences In Healthcare

FHIR and API Know-How, Plus a Whole Lot More

Wanting to do more than simply meet the CMS interoperability mandate, our payer client seized the opportunity to build a scalable infrastructure that mobilizes data in ways that truly put the consumer first – giving all members secure access to their health information when they need it most and in a way they can best use it.

We grounded their solution in a pragmatic, holistic approach, evaluating when we could leverage the payer’s existing platforms as well as opportunities to modernize in ways that would benefit multiple organizational initiatives.

This approach encompassed three core tenants:

Interoperable Data = Modernization + Optimization + Democratization

Our integration and healthcare expertise equipped the payer to achieve faster time to market while leveraging its existing enterprise investments. We safeguarded a solution that meets all standards and rules when sharing protected health information (PHI). Additionally, our expertise in data governance ensured that data can be trusted and leveraged as a true strategic asset.

READ THE FULL SUCCESS STORY: Empowering Healthcare Consumers and Their Care Ecosystems With Interoperable Data

Healthcare Interoperability Solutions

Three areas of Perficient expertise – integration, healthcare, and data governance – together forged a solution that equips this payer client, its partners, and its members for more personalized, meaningful care experiences and better health outcomes.

Have questions? We help the largest payers and providers in the U.S. navigate integration strategy, data architecture, platforms, implementations, and change management. Contact us today, and let’s discuss your specific needs and goals.

EXPLORE MORE: Get to know the Senior Solutions Architect who helped lead this project

CMS interoperability rules generated quite the commotion in healthcare this past year.  But when you think about it, these mandates are pushing us closer toward the consumer-centric goals that healthcare organizations already aim to prioritize.

Interoperability Mandates Mirror Business Needs

Rules and Regulations. Regulations like the CMS Final Rule mandate that health care organizations make patient data available and shareable. The latest rule includes: Patient record API Provider directory API Payer-to-payer transfer Notification of discharge and other events BlueButton		General Trends. General trends in today’s mobile interconnected world drive many of the same outcomes: IT modernization Retiring of point-to-point solutions Move to cloud, which requires rethinking of solutions and architecture Sharing of data outside your four walls
Key Interoperability Standards. These standards are maturing and allow for easier sharing of patient data: FHIR® Smart IG/Oauth2 Open ID Connect		Business Needs:  Need for business agility and resilience Healthcare consumerization Mobile Demand for better healthcare outcomes Manage challenge of combined/colliding provider and payer functions

Integration and Interoperability: Boosting Consumer Experience and Innovation in Healthcare

To remain competitive and compliant, healthcare organizations are:

• Ramping up real-time data exchanges across a growing web of communication points
• Leveraging data models for batch, EDI, and HL7® sharing
• Integrating with external AI models
• Managing communications and care delivery across mobile and medical device applications

Through it all, patients and members expect to engage across multiple channels.

RELATED: Interoperability Options for Healthcare Payers: Meeting the CMS Final Rule (and Beyond)

Healthcare organizations’ ability to accelerate transformation is crucial so your organization can adapt and flourish in an increasingly competitive and ever-changing landscape. We recently published a video that explores this opportunity:

EXPLORE MORE: Healthcare PowerByte: Interoperability – Make Data a Strategic Business Asset

A Data Integration Partner for Leading Healthcare Organizations

We help the largest payers and providers in the U.S. strategize, plan, and deploy transformative change with lasting impacts – providing high-quality and affordable care, engaging and empowering consumers on their healthcare journey, and positioning their organization for innovation, agility, and efficiency. Read about some of the successes our integration, interoperability, and data experts have helped organizations achieve:

• Empowering Healthcare Consumers and Their Care Ecosystems With Interoperable Data: Wanting to do more than simply meet the CMS interoperability mandate, our payer client seized the opportunity to build a scalable infrastructure that mobilizes data in ways that truly put the consumer first – giving all members secure access to their health information when they need it most and in a way they can best use it.
• Cloud-Based Business Solution Streamlines User Experience and Reduces Costs: Our solution created new functionality for the healthcare services company’s users, optimized internal operations, and increased member adoption and dollars saved for its provider network.
• Collaboration Boosts New Patient Acquisition: Ownership of data and the flexibility to truly integrate open scheduling were paramount, so the health system did not want to outsource to a third-party application. We innovated an API-based open scheduling integration with Henry Ford’s MyChart EMR system. We further integrated the scheduling system with Cadence, which Henry Ford physicians use to manage their schedules.
• Driven by Core Principles to Enable a Healthy Community: We equipped our client with a foundation to deliver mobile solutions and integrate with external vendors

Interoperability and Integration Are Driving Healthcare’s Future

On May 6, 2021, Matthieu Rethers, Senior Solutions Architect at Perficient, and Dan Domkowski, Artificial Intelligence, Machine Learning, Deep Learning Specialist at Red Hat, hosted a webinar that discussed how to map your interoperability roadmap for success leveraging Red Hat OpenShift Ignite.

Together, Perficient and Red Hat share how they helped a leading senior healthcare provider develop a plan and implement a modern platform that supports its integration across 36 systems, achieves its interoperability needs, and allows the client to quickly upgrade its EMR in less than six weeks without missing a beat.

The patient is at the center of the 21st Century Cures Act. The interoperability provisions grant patients more power over their care and access to key information.

Interoperability, a popular term in the healthcare industry, is the ability to exchange electronic health information seamlessly and securely without significant effort from the user. It allows for payers, providers, and patients across organizational, regional, and national boundaries to have complete access, exchange, and use of all authorized information, and removes concerns of information blocking.

To continue to promote interoperable health information and data sharing, both the Office of the National Coordinator for Health IT (ONC) and The Centers of Medicare & Medicaid Services (CMS) have issued new rules that mandate an application programming interface (API)-led approach to interoperability in healthcare.

The ONC Cures Act Final Rule and the CMS Interoperability and Patient Access Final Rule work together to enforce the interoperability and information blocking provisions of the 21st Century Cures Act for the seamless exchange of patient, member, and physician electronic health records (EHR) across payers, providers, and third-party smartphone applications for patient use.

What does it mean for me?

For Patients:

• Obtain Secure Access to Health Records: Acquire a secure patient access to electronic health records and easily obtain control of personal care and medical records through smartphones and authorized modern software applications.
• Shop for Care and Manage Costs: Gain transparency with expanded choices for patients and payers in healthcare with insights delivered about care quality and costs to assist in making health and financial decisions.

For Hospitals and Clinicians:

• Efficient and Inexpensive Patient Data Requests: Easily provide patients with access to their information in a fully automated, cost-effective manner. With secure, standardized APIs, patients will be able to access their health information from an app of their choice without special effort on the part of the hospitals or clinicians.
• Provide a Choice of Applications: Leverage open APIs with secure access to data for applications. A growing, innovative application marketplace and the final rules will help ensure certified APIs are made available in a way that is safe, secure, and affordable.
• Maintain Information Blocking with Common Sense Exceptions: Benefit from information blocking provisions with defined practices that are considered reasonable and necessary activities that would not constitute information blocking. The Final Rules establishes exceptions to allow hospitals and clinicians common sense operational flexibility. This includes protecting patient privacy and security as well as handling situations where moving data is technically infeasible.
• Put the Patient’s Safety First: Balance the patient and clinician needs and encourage transparency around patient safety issues within health IT, while also attempting to protect the intellectual property rights of health IT developers who have made large investments in building user interfaces and workflows.

Concerned about the complexity of making interoperability a reality?

By leveraging the MuleSoft Accelerator for Healthcare, we can help you make patient data accessible by digitally transforming how your organization delivers EHR in a way that meets the new mandates and puts control back into the consumers hands. Our strategy and consulting expertise will ensure healthcare payers and providers successfully follow these new rules while delivering powerful, secure, and scalable capabilities – and when implemented effectively, health information exchange (interoperability) can also reduce the burden of certain administrative processes, such as prior authorization.

At Perficient, we excel in tactical MuleSoft implementations by helping you address the full spectrum of challenges with lasting solutions, rather than relying on band-aid fixes. The end result is an intelligent multifunction resource that reduces costs over time and equips your organization to proactively prepare for future integration demands.

We’re a Premier MuleSoft partner offering integration expertise that’s strengthened by our extensive healthcare know-how, particularly when it comes to safely using, transporting, and securing healthcare data.

Ready to achieve interoperability? Download our interactive guide!

Download our guide, An API-Led Approach to Interoperability in Healthcare With MuleSoft

As of January 1^st, 2021, Medicare Advantage, Medicaid, CHIP, and plans on the federal Exchange beginning in 2012 are required to support a standardized FHIR API.  Fast Healthcare Interoperability Resources (FHIR) is a standard for exchanging electronic health records that is easier to implement as it uses current API technology. This standard facilitates interoperation for legacy systems, allowing for a much easier integration. It also emphasizes the goal that the exchange of healthcare information to health care providers and individuals should be easily and securely accessible across a variety of devices and third party medical applications.

With regulations such as the CMS Final Rule, patient data such as the below needs to be available and shareable:

• Patient Record API
• Provider Directory API
• Payor to Payor Transfer
• Notification of discharge and other events
• BlueButton

Adding a FHIR API on top of your Electronic Health Record (EHR) system connects disparate data across systems to standardize patient data and create accessibility to payers, providers, and patients. Patients with providers in different healthcare systems can access a single portal. This portal integrates data from different formats and delivers a comprehensive view of the patient (including allergies, care plans, health issues, and medications).

Implementing MuleSoft with Perficient

Beginning with an enterprise tool allows you to address challenges once, rather than relying on a rapid fix to meet requirements. This helps relieve additional costs down the road, as non-interoperability integrations are typically not handled by niche vendors. Perficient partners with MuleSoft to improve clinical, financial, and operational efficiency. We leverage the MuleSoft Accelerator for Healthcare, which includes pre-built APIs, integration templates, connectors, and reference architectures constructed to take on real-time loads without sacrificing data governance or quality.

Coupled with the MuleSoft Accelerator, we review the current environment, data resources, and healthcare resources to build architecture and proof of concept with patient and provider data while navigating the complexities of regulatory reform. We’ve built a jumpstart to help you get your platform up and running with at least one integration within four weeks – with built-in support following the integration:

• Week 1: Finalize architectural elements, such as the approach for FHIR and other standards
• Week 2: Instantiate services to ensure security and availability both internally and externally
• Week 3: Set up initial integrations to key services using the FHIR standard
• Week 4: Test and launch solutions in a production environment

Perficient’s Healthcare Industry Experience

In addition to real time healthcare integration, Perficient has worked with industry standards such as HL7 and CCD/CCDA to transfer patient records to a variety of systems and data repositories. We understand healthcare data as well as how to safely transport, store and use it. We have assisted leading healthcare providers with their transformational journeys to better align with ever-changing business needs while modernizing their IT environment.

Recently, our ability to build API-led connectivity architecture in MuleSoft with interoperability design patterns and best practices provided an efficient digital health solution with a single membership and billing system. We were able to streamline member enrollment and termination processes, member payment transactions, and real-time payment processing. By incorporating matter management, document management, and legal hold, we increased efficiency, transparency, and collaboration. Our solutions were delivered with the client’s best interests in mind and followed by continued business-critical support.

Raj Palla, MuleSoft Practice Director, and Mike Porter, Managing Principal – Healthcare Practice, also contributed to this post.

Healthcare leaders have access to more healthcare data and technology than ever before allowing them to transform patient and member care. A one-size-fits-all-approach doesn’t work anymore and we’re being challenged to do more through personalized medicine.

In season 1 episode 2 of the Intelligent Data Podcast, host Arvind Murali and his guest Juliet Silver, Perficient’s Chief Strategist of Healthcare, discuss the state of affairs in the healthcare industry including the “Triple Aim”, the COVID-19 pandemic, IoT in healthcare, and more.

We’re also looking at the patient or the member as a consumer as well. And we’re seeing a big shift from payors and providers, because they’re looking at the consumer in the same way as other industries do. So we’re starting to paint that picture with data around the lifetime value of that consumer and we’re leveraging data both internal and external to market to them, to reach out and engage with them, and to be able to capture interactions and preference data. – Juliet Silver, Healthcare Chief Strategist

Listening Guide

Healthcare Data is Changing Consumer Care

• Data, analytics and healthcare consumerism [3:10]
• “Patient” to “Health Consumer” [7:58]
• Triple aim and leveraging third party data (Peloton, Fitbit, etc.) [9:10]
• How the COVID-19 pandemic has affected the healthcare industry [10:58]
• Physician burnout data [13:10]
• Telehealth and volume-based versus value-based care [15:39]
• AI’s impact on healthcare [17:15]
• How do you govern IoT healthcare data [21:30]
• New interoperability mandates for FHIR standards [25:06]
• Data accessibility, transparency and portability creating consumer choice [26:55]
• Data ethics, data privacy and data security [29:33]
• Healthcare Data-driven solution case studies [31:43]
• Advice to executives as they prepare for a post-COVID world [33:58]

Get This Episode Where You Listen

And don’t forget to subscribe, rate and review!

Apple | Google | Spotify | Amazon | Stitcher | Pocket Casts

Connect with the Host and Guest

Arvind Murali, Perficient Principal and Chief Strategist

LinkedIn | Perficient

Juliet Silver, Perficient Chief Strategist of Healthcare

LinkedIn | Perficient

Learn More About Our Healthcare Solutions

If you are interested in learning more about Perficient’s Healthcare services capabilities or would like to contact us, click here.

The CMS Final Rule sparked some interesting conversations and problem-solving among the interoperability team at Perficient. It’s one of the first times payer or health insurers had to react to these types of rules. The way they treat the data and the location of all the data makes this a different ball game than what you have to follow if you were a hospital. That means that while the basic rules understanding remains the same, the solutions you consider are actually quite different.

The Ask

Earlier this year, CMS / ONC released their much anticipated “Final Rule” which mandates that payers who have anything to do with federally related plans have to do the following:

• Patient Access API: Provide a FHIR-based API that lets patients access their claims and encounter information through 3rd party applications
• Provider Directory API: Make Provider Directory information available through a publicly available FHIR-based API
• Payer-to-Payer Transfer: Allow members or patients to request transfer of their records to another payer

Payers that meet key criteria must make these capabilities available and must do it following open standards like FHIR, SmartIG, and OpenID.

READ MORE: Fast Healthcare Interoperability Resources (FHIR) Explained

The Challenge

While many payers already have data and integration platforms available, most are not set up to make this data publicly available. In addition, a lot of this data resides in a range of systems. Those systems also have overlapping data. Therein lies the issue. Overlapping data means you have to find it, transform it, and deduplicate that data. It’s possible to make a real-time call, but the more duplicates you have and the higher the overlap of data, then the more you need to do.

In other words, just creating a FHIR API won’t allow you to meet the need.

YOU MAY ALSO ENJOY: Healthcare PowerByte: Interoperability – Make Data a Strategic Business Asset  

Deciding on Solutions

Most of the early debate in our team was what type of architecture would meet the criteria demanded by the CMS Final Rule. Unfortunately, no one architectural approach will work for every payer. This allows integration platforms with FHIR support and FHIR server type solutions to enter the mix. They can even co-exist depending on your ecosystem of platforms and data sources.

In order to make a decision, you need to take into account the following:

• Where does your patient / member information reside? Is it in multiple location for claims, eye exams data, clinical data, etc.?
• Where does your provider information reside?  Is it easily accessible via an API?
• Is there a lot of overlap of data in the various data sources?
• Do you have a hard time pulling from the data sources and mapping it to the correct member?
• Do you already have (or will you soon have) an integration and API management platform? (NOTE: Both can be needed.)

A Few Thoughts on Possible Solutions

As noted, not everyone will land on the same solution.

Larger organizational structures and larger numbers of data sources drives you toward a more complex solution set. I would put the solution in a few categories:

1. For those that have few data sources like mainly just claims data, you can consider using an integration and API management vendor to front both provider and patient data and to serve up the FHIR-based resources.
2. For more complex, you can consider a FHIR Server or FHIR “solution.” This may need to be paired with the enterprise integration and API Management platform. This approach means the following:
   • You pull all the data into one central location
   • You perform data transformation and de-duplication on it so that patient data is correctly defined
   • This data will not be real time; by it’s nature, there will be some latency
   • The normalized data can then be called securely by whatever is fronting your API’s
3. A hybrid option can work if your provider data is easily accessible and already centralized
   • API platform calls provider data and enables a FHIR API
   • Centralized patient data platform for the more complex patient data scenarios

SUCCESS STORY: Empowering Healthcare Consumers and Their Care Ecosystems With Interoperable Data

The bottom line is that each organization has a variety of options. You always have to take your systems and your data into account to create your final architecture.

Just remember that FHIR is the standard and not the solution. Most of the heavy lifting occurs behind the actual FHIR call.

Have questions about your near- or long-term integration and interoperability goals. Our experts can help. Contact us to get started.

Welcome back! You’ve made it to the final blog in this series on managing coexistence and interoperability in Microsoft Teams! Last time we discussed in-tenant interop flows. This time we’ll wrap things up by discussing external access/federation and how this differs from coexistence. For those of you coming from the Skype for Business world, you probably have a love/hate relationship with federation and the benefits it can provide. With that being said, it remains a huge aspect in Teams especially when Skype for Business is in the mix. So without further ado let’s get our federation on!

Federation 101

Ever want to chat with someone outside of your organization within Microsoft Teams? I introduce to you….federation! By definition, federation is communication between users in two different tenants. Teams federation currently works in the same way that Skype for Business federation works, meaning every federated communication that happens within Teams is an interop thread back to the Skype for Business environment. This will also include the ability to see your federated contacts in your contact list (once added), as well as the presence of that federated contact. We’ll touch on the interop piece later in this article, but just know that the same prerequisites that are defined in interop will also apply for federation between users in different tenants (regardless of the client being used).

Note: Teams federation v2 is something currently being worked on by Microsoft. This will provide native Teams to Teams federation. This means that a Teams Only user in one tenant can communicate with a Teams Only user in another tenant with all the features available in a native teams conversation, as opposed to the current federation that is limited to the interop experience. 

Since federation works in the same way that interop works this means there will also be certain cases where federation won’t work. For example, in the previous blog post we mentioned that interop from the Teams client in Islands coexistence mode where Skype for Business on-premises is deployed will not work. The same scenario holds true for federation, so be sure to keep this in mind when planning federation with other organizations.

How do we configure federation in Teams?

Now that you know what federation is and how it functions, let’s discuss how you go about implementing federation in your organization! In order to configure federation within your organization you’ll need access to the Microsoft Teams Admin Center. Once there you’ll just need to find the “Org-wide settings” tab on the left hand side of the admin portal. Expand that and you should see a tab entitled “External Access“. Click on that and you’ll be presented with a screen like the one below:

To break things down even further, we have the following options when enabling federation:

1. Communication is allowed with all external domains (default setting)
2. Allow only specific external domains, all others will be blocked
3. Block only specific external domains, all others will be allowed

In addition, you have the option of communicating with Skype commercial users if that floats your boat. One thing you may notice between Skype for Business and Teams federation is the lack of optimization available. So, if you want the full Teams experience it is recommended that you spin up a Teams meeting so you can get all that Teams has to offer.

Federation Routing

If the table below looks familiar, that is because we covered something similar from the last blog post on interop-flows. As with interop, the routing will always be determined based on the recipient’s mode. After that, you should see what client the originator is using (SfB client vs Teams client) and lastly where the originator is homed (SfBO vs SfB on-prem). From there, we will know if the conversation is even possible (i.e. A user in Islands mode initiating the communication within the Teams client whom is homed in Skype for Business on-premises would fail).

With federation you’ll notice things are a little more clear cut, in that both Islands and SfB mode users will always land in their Skype for Business client (with the exception of the scenario in red above). In the exception above, you’ll see that any originator operating in Islands mode with Skype for Business on-premises and using their Teams client to initiate the federation will be unable to federate.

Interop 101

As mentioned earlier, federation goes hand in hand with interoperability. But what exactly is interoperability and why do we need it? Interoperability is the communication between a Skype for Business user and a Teams user. This will include the following chat and calling features:

• 1-on-1 experience only (no meetings)
• Plain text chat only (no fancy emoticons, GIF’s , etc.)
• Capabilities for chat and calling are identical in federated and in-tenant cases (have I stressed this one enough… )

So why do we need interop? Well, as with many companies you may see that going straight to TeamsOnly mode for your entire organization is not easy nor practical. This is where interop comes in, because it allows you to maintain communication with Skype for Business users in your organization even after others have been upgraded to TeamsOnly mode. Obviously we other workarounds where we can have the Skype for Business user in Islands mode and have that user utilize their Teams client to communicate with the other user in TeamsOnly mode. However, we may face a more complex scenario where a user only has access to their Skype for Business client, thus interop is needed to communicate between Teams and Skype for Business. Interop will typically occur in the following scenarios:

1. Intra-org during migration: Commonly in scenarios where Islands mode (side-by-side) is not being leveraged but other coexistence modes are being used.
2. Cross-org during and after migration: Federation between your organization and another organization.

Interop Prerequisites

Last but not least, let’s go over the required prerequisites for interop in Teams. As mentioned in prior blogs, when there is an on-premises environment in play you will need to ensure that Skype for Business is configured for hybrid/split domain to allow for intra-org interop. This also means that your Teams user’s account must be homed in Skype for Business Online to allow 1-on-1 interop chats and calls. Any Teams user that still has their Skype for Business client homed on-premises will not be able to interop or federate with their Teams client. Instead they will need to use their Skype for Business client.

Core Concept Summary

This concludes the blog series on coexistence and interop in Microsoft Teams! As you can probably tell, there are many different scenarios at play here and things can tend to get a bit confusing when introducing interop and federation between Skype for Business and Teams. However, if you had to take anything out of today’s blog (and previous blogs) it would be the following core concepts:

1. Coexistence involves the Skype for Business and Teams clients working together in the same organization.
2. You should utilize coexistence modes to control your user experience until you can upgrade to Teams Only mode
3. If you currently have a Skype for business on-premises environment, be sure a properly implement Azure AD sync and establish hybrid/split domain in your organization prior to implementation.

I hope you have found this blog series beneficial and I’d recommend checking out the official Microsoft training here, as this content may change in the coming months as new features and functionality is introduced in Microsoft Teams!

Welcome back! In part 1 of this blog series we covered at a high level what coexistence and interoperability between Skype for Business and Microsoft Teams involved. This time, we’ll take things a step further by looking at the technical view of interoperability scenarios you’ll need to know in order to implement this in your organization. With that being said, let’s start discussing what you’ll need to know as an administrator to ensure a successful upgrade!

Technical Requirements

Azure AD Connect

First thing you’ll want to take a look at involves Azure Active Directory Connect. If you currently have Lync/Skype for Business Server on-premises the first thing you’ll want to do is ensure Azure AD Connect is up and running. This is by far the most critical piece in ensuring a success upgrade to Teams, as you won’t be able to get to Teams without this in place. I will also stress that this will need to be the first step in your upgrade process, since you will need to ensure a proper sync is done between your on-premises AD directory and Azure AD before you can start creating Teams users. Without doing this step, you will have issues with duplicate DNS entries, user accounts, broken routing experiences, and even broken policy assignments. This will also include the synchronization of the ‘msRTCSIP’ attributes from the on-premises environment to Azure AD. For some additional information around this, I encourage you to check out the Microsoft documentation here.

Skype for Business Hybrid

Next thing up is the configuration of Skype for Business hybrid/split domain to allow coexistence between the Skype for Business Server on-premises and your Office 365 tenant. Although hybrid isn’t a strict requirement, it is highly recommended as interoperability between Skype for Business and Teams will require that hybrid be in place. So in essence, if this is not configured and you have some users in Teams Only mode while others are still on-premises Skype for Business Server, then they will be unable to communicate with one another. In addition, if you plan on migrating your users from Skype for Business on-premises to Skype for Business Online (or straight to Microsoft Teams) then you will need hybrid/split domain configured to achieve this. For some addition details on this subject, check out Microsoft’s documentation here.

Interop Flow Breakdown

Now that we know what the technical requirements entail, let’s take a look under the hood on what each of these interop flows will look like so you can more easily determine which scenario fits your organization best. But first, some things to note:

Routing will be determined by:

1. Recipient’s mode (Islands vs one of the Sfb modes vs TeamsOnly)
2. Originator’s client of choice (Teams vs Skype for Business)
3. Where originator’s Skype for Business client is homed (on-premises vs online)

After you’ve determined those 3 points above you should then be able to determine if the communication will be possible or not. You’ll see a prime example of this in one of the examples below.

SfBO** and TeamsOnly (In-tenant) flow

In this first scenario we have a Skype for Business Online user (User A) trying to talk to a Teams Only user (User B). In this scenario User A has a Skype for Business Online client but does not have the Teams client. On the other end we have User B who is running in Teams Only coexistence mode and although they have the Skype for Business Online account, they won’t be able to use this since they are in “TeamsOnly” mode. So, how do we know User B has a Skype for Business Online account? Well, if they didn’t then you would be unable to assign the user to TeamsOnly mode. As mentioned earlier, this is one of the requirements for Teams Only mode, that you ensure your on-premises Skype for Business server users have been migrated to Skype for Business Online. As far as how these two users communicate with one another, they will leverage the gateway inside of the Teams service in Office 365 which is provided by Microsoft and won’t require any additional overhead on your part. When the Skype for Business Online user (User A) goes to talk to the Teams user (User B), the Skype for Business Online client actually thinks it is talking to another Skype for Business Online client. However, the Teams service will determine that this is actually enabled as a Teams Only user and instead redirect the conversation to the gateway and from there the conversation will appear on User B’s Teams client. This is how the interop between the two clients is established behind the scenes.

Note**: The scenarios above covers all SfB scenarios (SfBOnly, SfBWithTeamsCollab, and SfBWithTeamsCollabAndMeetings) since they all function the same from a routing perspective

SfB On-premises** and TeamsOnly (In-tenant) flow

This scenario is a little different than the one above, in that now we are dealing with a Skype for Business on-premises user trying to communicate with a Teams Only user. Assuming we have hybrid/split domain configured between the on-premises Skype for Business server and the Office 365 tenant, the Teams Only user (User B) will function the same way as in the previous scenario where the Skype for Business on-premises user (User A) will try to talk with the Teams Only user (User B). User A’s client will think that it is talking with a Skype for Business Online user when in reality the receiving end is a Teams client. Like before, the service will realize that this client has been upgraded to Teams and in turn will send the request to the gateway which will forward that request to the Teams client and we’ll have the interop thread established successfully! Once this is all said and done the sender (User A) will see a little yellow banner indicating that the person they are looking to talk to (User B) is not on a Skype for Business client.

Note**: The scenarios above covers all SfB scenarios (SfBOnly, SfBWithTeamsCollab, and SfBWithTeamsCollabAndMeetings) since they all function the same from a routing perspective

Islands Online and TeamsOnly (In-tenant) flow

This scenario is a bit different from the two previously mentioned. In this scenario user A would be in Islands mode, meaning the user’s Skype for Business account is in Skype for Business Online as well as Microsoft Teams. User B on the other hand will be a TeamsOnly user which means they will have a Skype for Business Online account but the account will not be available to that user because they have been upgraded to the ‘TeamsOnly’ coexistence mode. If the Islands mode user (User A) uses their Teams client to talk to the TeamsOnly user (User B), this communication will happen natively inside of Teams. As you may have remembered from our last blog, Islands means that all communications that starts in that client will end with the same client type on the receiving end. With that being said, if the user wanted to use their Skype for Business client instead to talk with the TeamsOnly user (User B), the TeamsOnly user will technically have a Skype for Business Online account provisioned. However, since this account only serves as a “shadow” account and cannot be used by the TeamsOnly user the communication will go from User A’s Skype for Business Online account to User B’s Skype for Business Online shadow and then will be routed to the gateway. The gateway will then forward this on to the Teams client instead, which will establish the interop thread between the Islands user (User A) and the TeamsOnly user (User B).

Note: The routing mechanisms are driven by the coexistence mode assigned to the target user.

Islands On-premises and TeamsOnly (In-tenant) flow

Was the previous scenario too easy for you? Well, let’s use the previous scenario but throw in some additional complexity. Let’s say instead of having User A’s account being homed in Skype for Business Online, we’ll have this user homed on-premises. First things first, you should remember that we need hybrid connectivity in order to a Teams Only user. So assuming you have hybrid configured within your environment, if the Islands mode user (User A) uses their Teams client to talk to the TeamsOnly user (User B) then this will occur natively inside of Microsoft Teams. Now, if the Islands mode user (User A) tries to talk to the TeamsOnly with their Skype for Business on-premises client, then this will work the same way as in the previous scenario. Assuming hybrid is configured properly the Skype for Business on-premises client will try to talk to the Skype for Business Online account for User B. However, since User B is in TeamsOnly mode and they are unable to use their Skype for Business Online account, this “shadow” account will have the service forward this request on to the gateway where it will send this on to the Teams client. Thus the interop thread will be established between the Teams client and the Skype for Business on-premises client. You may be thinking, “well that was easier than I thought it would be”? Luckily Microsoft does a great job of making this whole process seamless for not only the end user but for the administrator as well!

Islands Online and SfB** (In-tenant) flow

In this scenario we have User A in Islands mode wanting to speak to User B whom is in one of the SfB modes (SfBOnly, SfBWithTeamsCollab, and SfBWithTeamsCollabAndMeetings). So, to break this down User A is homed in Skype for Business Online but will also have a Teams account and they will be able to utilize all features available in both clients. User B on the other hand will have a Skype for Business Online account but not a Teams account because they are in one of the SfB modes listed above. This means that the chat and calling capabilities will not be available to this user within Teams. Now, when User A (Islands mode user) uses their Teams client to talk to User B (one of the SfB modes), User B will only be able to receive messages within their Skype for Business client. From the clients perspective Teams will send this communication to the gateway which will be able to route this message through Skype for Business Online over to Skype for Business (User B). This would then establish the interop between the Teams client at User A, and the Skype for Business client (User B).

Note**: The scenarios above covers all SfB scenarios (SfBOnly, SfBWithTeamsCollab, and SfBWithTeamsCollabAndMeetings) since they all function the same from a routing perspective

Islands On-premises and SfB** (In-tenant) flow

In this last scenario we will have User A in Islands mode but this time their account is homed on-premises. Since they are in Islands mode though, they will be able to utilize both clients with all features available. User B is setup in the same way as the previous scenario where they are in one of the SfB modes, meaning they will not have the ability to use the Teams client for chat and/or calling. Provided hybrid/split domain is properly implemented, when User A (Islands on-premises user) uses their Teams client to talk to User B (one of the SfB modes), User A will go to the gateway and the gateway will realize that User B is in one of the SfB modes and does not have the ability to utilize the Teams client to call/chat. So, the gateway will attempt to route this back to the client, however since User A is homed on-premises the client will be unable to use the interop gateway thus they will be unable to communicate with User B. The same concept holds true to any type of federation, as this will use the same interop gateway. To combat this, User A will be forced to use their Skype for Business client instead in order to communicate with User B.

Note**: The scenarios above covers all SfB scenarios (SfBOnly, SfBWithTeamsCollab, and SfBWithTeamsCollabAndMeetings) since they all function the same from a routing perspective

ATTENTION: Islands mode users homed on-premises utilizing their Teams client will be unable to communicate/federate with SfBOnly, SfBWithTeamsCollab, and SfBWithTeamsCollabAndMeetings users. In order to communicate in this use case, they must use their Skype for Business on-premises client.

To bring it all home Microsoft has so graciously provided a 1:1 interop chat/calling routing table that you can reference. Just as a recap, routing will always be determined by the co-existence mode that is assigned to the recipient/target.  You can use this table to determine where the conversation will land. As an additional point of reference you can visualize the “From originator” as User A, and “To target” as User B from the examples above.

This concludes this weeks blog on managing coexistence and interop in Microsoft Teams. Check back in soon where I’ll be finishing this blog series by discussing external access/federation routing in detail and summarize the key learning from this series!

One of the biggest concerns when switching from Skype for Business to Teams revolves around the ability for the two products to work together. However, what is often overlooked is what will be required to meet these expectations. Fear not, in this article we’ll be discussing the high level in’s and out’s for interoperability and coexistence within Microsoft Teams so you can get a firm understanding of what will be required when it comes time to implement these concepts in your organization.

First things first, let’s define each of these terms for those of you that aren’t coming from the Skype for Business world or just aren’t familiar with this terminology.

• Coexistence – Both Skype for Business and Microsoft Teams clients are present in the organization.
• Interoperability – Instant Messaging (IM) or calling between a Skype for Business user and Microsoft Teams user within the same tenant.
  • Notice that this only refers to chat and calling but not meetings. This is because meetings work within the application in which they were scheduled.
    • If it is a Teams meeting you will join with a Teams client
    • If it is a Skype for Business meeting you will join with a Skype for Business client
• Federation – Instant Messaging (IM) or calling between a Skype for Business or Microsoft Teams user in different tenants.
  • With federation, the sender can be federated via Skype for Business (on-premises, hybrid, or online) or via Microsoft Teams. On the recipients end, their experience is defined by where their Skype for Business account is homed in addition to the modes applied to that user.
  • Similar to Interoperability, meetings will work within the application in which they were scheduled.

Image provided by: https://docs.microsoft.com/en-us/microsoftteams/upgrade-and-coexistence-of-skypeforbusiness-and-teams

Now that we know how these terms are defined, we can dig a bit deeper into how each of these paths can be managed within your organization.

Which path is right for you?

Managing Coexistence in Microsoft Teams

Coexistence will be managed using the TeamsUpgradePolicy which will allow us to set the specific Teams upgrade mode. The mode will govern the following:

1. Routing of incoming VOIP calls and chat messages (IM’s)
2. The client in which you can initiate the message or call (Teams or Skype for Business)
3. The service in which you can schedule a meeting (Teams or Skype for Business)

*Note: You will always be able to join meetings regardless of the mode. The mode is only controlling what we use to schedule the meetings.

These mode will be applied on a per user basis and can be assigned using either the Teams Admin Center or PowerShell. In addition, these modes can be assigned to those of you using Skype for Business on-premises. Please note, the Teams Only mode would be the only exception to this rule, as it requires your Skype for Business account to be homed in Skype for Business Online. As mentioned earlier, you can assign these modes on a per user basis. However, you also have the ability to configure a mode to be the org-wide setting (tenant default).

*Note: Per user settings will override a org-wide setting. 

Lastly, when managing coexistence it is important to understand that you do have the flexibility of mixing and matching different modes across your organization. This means you can have some users on Islands mode while other users are on Teams Only mode. However, you should keep this to a minimum as it can create lots of confusion around management of Teams by having different functionality of Teams from one user to the next.

Different Coexistence modes

As you see in the table below there are 5 different coexistence modes to choose from:

• Teams Only
  • This is the end state of a user being upgraded.
    • All calls and chats will land within Microsoft Teams regardless of where they originated
    • All meeting scheduling will be performed only within Teams
    • Core collaboration set will be enabled (teams, channels, bots, apps, tabs, file sharing, etc.)
    • Skype for business application will still be present but serve in an optimized meeting mode configuration where they will be unable to create new chats or new VOIP calls
    • 3PIP phones will continue to work with limited functionality via a cloud gateway service
    • Teams presence will be shown in both systems
    • Outlook add-in will only include the ability to schedule meetings within Teams
    • End users can still join meetings from their respective clients

Note: All new tenants created after October 2018 (with less than <500 users) will have Teams Only mode set as the default.

• Skype for business with Teams collaboration and meetings (Meetings First)
  • Targeted and optimized for Skype for Business on-premises organizations using Enterprise Voice. Chat and VOIP calling will remain in Skype for Business, while meetings scheduling and collaboration will be within Microsoft Teams.
    • Alternative to islands mode as this will prioritize the Teams meeting experience
    • Meetings are created in Teams but IM, VOIP calling, and presence will remain within Skype for Business
    • Skype for Business presence is shown in both systems
    • Outlook will only show the Microsoft Teams add-in for meeting scheduling
    • No overlap between Teams and Skype for Business in this scenario (IM, VOIP calling, and presence are on in Skype for Business and off in Teams)
    • Regardless of the mode assigned to the user the end user can still join meetings on their respective clients
• Skype for business with Teams collaboration
  • Leverages the Skype for Business client for IM, VOIP calling, and meeting scheduling. The only piece in Microsoft Teams will be the collaboration aspect (teams, channels, bots, apps, tabs, file sharing, etc.)
    • Alternative to Islands mode due to benefit of predictability and interoperability of communications
    • Skype for business remains unchanged for chat, VOIP calling, and meeting capabilities but adds in Teams collaboration capabilities (teams, channels, access to files in O365, and applications)
    • Teams communication capabilities like private chat, VOIP calling, and scheduling meetings will be disabled by default
    • Outlook will only show the Skype for Business add-in for meeting scheduling
    • No overlap between Teams and Skype for Business in this scenario (IM, VOIP calling, meetings, and presence are on in Skype for Business and off in Teams)
    • Skype for Business presence will be available in both systems
    • Regardless of the mode assigned to the user the end user can still join meetings on their respective clients
• Skype for Business Only
  • Specialized for customers only wanting to utilize Skype for Business
    • Limits confusion by providing only 1 client to work with
    • Incoming VOIP calls and chats will land in Skype for Business regardless of where it was initiated
    • End user can only initiate calls and chats within Skype for Business
    • End user can only schedule meeting within Skype for Business
    • Skype for Business presence shown in both systems
    • Outlook will only show the Skype for Business add-in for meeting scheduling
    • Interoperability will be available with Teams Only users
    • Users can still participate in Teams meetings they are invited to with Skype for Business client or Teams client (if Teams client isn’t installed they can join via the Teams Web Experience)
    • Only supports basic chat, VOIP calling, and desktop sharing capabilities between Skype for Business and Teams
• Islands (side-by-side)
  • This is the recommended starting point for organizations
    • This is the default coexistence mode in Office 365
    • Incoming VOIP calls and chats will land in the same client as the originator
    • User has ability of leveraging both clients (Skype for business and Teams) side-by-side
    • No interoperability is needed in this approach since Skype for business conversations stay in Skype for Business and Teams conversations stay in Teams
    • Presence is completely separate between the two systems
    • Chat, VOIP calling, and meetings will be available in Skype for Business
    • Chat, VOIP calling, meetings, and collaboration will be available in Teams
    • No restrictions being placed on the Teams client in this approach
    • Phone System/CCE/OPCH features will only be supported in Skype for Business while in Islands mode
    • Direct Routing not supported in Skype for Business
    • Feature sets overlap

Note:

1. The ability to join an existing meeting (whether scheduled in Teams or in Skype for Business) is not governed by mode. By default, users can always join any meeting they have been invited to.
2. By default, when assigning either TeamsOnly or SfbWithTeamsCollabAndMeetings to an individual user, any existing Skype for Business meetings scheduled by that user for the future are converted to Teams meetings. If desired, you can leave these meetings as Skype for Business meetings either by specifying -MigrateMeetingsToTeams $false when granting TeamsUpgradePolicy, or by deselecting the checkbox in the Teams Admin portal. Note that the ability to convert meetings from Skype for Business to Teams is not available when granting TeamsUpgradePolicy on a tenant-wide basis.
3. Regarding Skype for Business Only mode, currently Teams does not have the ability to disable the Teams and Channels functionality so this remains enabled for now. However, this can be achieved by using the App Permissions policy to hide teams and channels.

This concludes the blog about coexistence and interoperability in Microsoft Teams. Check back very soon, as I plan on covering the requirements for managing coexistence as well as a deep dive into interoperability and federation between Skype for Business and Teams! I hope you have found this blog helpful and I look forward to seeing you in the next blog!

Blockchain has the potential to radically alter the way enterprises conduct business and process transactions. The technology can reduce operational costs and friction, create transaction records that are immutable, and enable transparent ledgers where updates are nearly instantaneous.

However, despite its immense potential benefits, there is a great deal of confusion and challenge in leveraging blockchain. Its nascent technology, a lack of talent to support it, complex system integration, and disruptive impact on existing business process all stand in the way of realizing value.

PERFICIENT’S BLOCKCHAIN TRAINING

To help get you on the path to success with blockchain, we have developed a three-day training course. In just three days, we will provide you with the foundation for blockchain can help transform your business.

During the training, our blockchain experts will engage with your business, architecture, and development teams to outline the concepts of blockchain, build out use cases, facilitate basic and advanced development of blockchain applications, and assist with ongoing learning.

COURSE AGENDA

Day 1: Blockchain Basics

Audience: Business, Architects, Developers
This course begins with the foundational concepts and use cases for blockchain. Subsequently in an instructor-led interactive workshop, trainees will learn how to develop and deploy their own blockchain applications.

Day 2: Developing a Blockchain Solution

Audience: Business, Architects, Developers
This session is for engineers who know the basics of blockchain and want to learn the key components of Hyperledger Composer, study in detail the transactions workflow, and spend a sizable amount of time on experiments with blockchain. The aim of this session is for developers to acquire solid technical skills in building blockchain applications on Hyperledger Composer.

Day 3: Advanced Application Development

Audience: Architects, Developers, Sr. Developers
This training session will be focused on developing full-featured blockchain applications with a smart contract in Java and an application interface.

WHERE TO START

Are you emarking on a blockchain transformation? If you’re interested in hearing more, please fill out the contact form at the bottom of this page or call (855) 411-PRFT. In just three days, you can get on the path to success with blockchain.

For more on blockchain, join our upcoming webinar: