For many people, hands-on experience is often the best way to learn and evaluate data tools. I’ve been working with a colleague from our Azure team, Kunal Jain, to put together an end-to-end Azure Synapse and Power BI solution using 120+ million rows of real CMS Medicare Part D Data that is available for use in the public domain. If you’re not highly technical, and you’ve never used Azure or Power BI before, you can still deploy this solution with a few simple steps using an Azure ARM template. We also provide a video to walk you through a paint-by-numbers tutorial. The Azure ARM template will automatically:
Create Azure Data Lake, Azure Data Factory, and Azure Synapse
Pull the raw data from CMS into a Data Lake using Azure Data Factory
Shape the data and create a dimensional model for Azure Synapse
Deploy the solution to Azure Synapse, including performance tuning settings
The entire process takes about an hour and a half to run, with most of that time spent on waiting for the scripts from the ARM template to finish. Once deployed, another video also walks you through the steps of connecting it to a pre-built Power BI report template. The whole process should take about 1-2 hours with no code required, and at the end you can review and evaluate and end-to-end Azure and Power BI solution using real CMS Medicare Part D Data:
While the source CMS data is real public Healthcare data, the intent of this project is to provide you with a simple end-to-end solution for the purposes of learning, demos, and tool evaluation. We intend to enhance and build upon this solution in the future, but it is not a supported solution intended to be used for production purposes.
Below is a tutorial video for deploying the solution. Note that this is designed to be low code with only a few things to cut and paste. All you need is an Azure account, and you can pause the Synapse instance or delete the entire Resource Group at any time. There are also simple instructions on the GitHub page:
Here is another tutorial video describing the process by which to connect the Power BI Template file containing the business logic:
The following diagram summarizes the steps of the whole process:
Azure Data Factory, along with Power BI, creates the following logical model that enables highly performant end user queries for complicated questions about the data. Notice that a CSV file is also added to the Power BI layer to demonstrate that custom criteria from a business user can be used to query the Synapse data:
Calculations have been added to the Power BI Semantic Layer to enable complex analytics such as Pareto Analysis:
Below is a screenshot of the pre-built Power BI report:
Power BI Import Datasets are simple to build and highly performant. Power BI literally imports and compresses an optimized cache of reporting data. Most of the time, Power BI architects will schedule their Import Datasets to refresh on a schedule. Sometimes the availability of new data is not predictable, and they will want to ensure that reports have current data by triggering a Refresh when the source data changes. A Data Refresh API can accomplish this task, but implementing it is not a code-free experience.
Self-Service Business Intelligence architects seeking a low code option for triggering refreshes of their Power BI Import Datasets have another option. Power Automate, which like Power BI is part of the Power Platform, has an easy-to-use action that Refreshes a Power BI Dataset. The video at the top of this blog article details the process for setting up a Flow in Power Automate that triggers a Refresh. Towards the end of the video, note that a methodology for scaling out this capability is reviewed. Regardless of the source of data, most ETL/ELT tools will complete by adding or updating data for a reporting source. The updates or additions then need to be refreshed into a Power BI Import Dataset cache.
In a large enterprise environment, self-service Business Intelligence users will often pull data into Power BI from many different sources. Sources could be EMR data, ERP data, Open Data public repositories of Population Health data, CRM data from Dynamics, or many other sources.
Triggering a Power BI Refresh refresh using Power Automate is easy, but with a disciplined approach it can be even easier for both users and administrators. First, consider adding an Azure SQL Database (DB) that is read-only for all Business Intelligence users who might need to trigger a Power BI refresh. You can use other Connections for your trigger, but Azure SQL DB is a simple option since it can be in the same Azure tenant as Power BI and does not require Gateway Administration. A separate table can be added for every source of data that a user might need to use as a trigger. If each ETL/ELT process in an organization adds a single row to a table in Azure SQL DB upon completion, then there would be a complete set of trigger tables users could access in a single Azure SQL DB. Consider the diagram below:
The trigger tables in Azure SQL DB do not need to contain any data from the actual source, and therefore data Security should not be an issue. The trigger tables need an Identity column, and ideally Date, Time, and possibly Datetime columns would be helpful too. Consider the following example:
In short, self-service Power BI users who need to trigger Dataset Refreshes from unpredictable data sources can be granted access to a centrally managed and carefully curated Azure SQL Database containing simple trigger files for data sources in an organization.
This video walks through the process of creating a Power Automate Connection to an Azure SQL Database. Future videos about Power Automate will reference this one to get started with connectivity to Azure SQL DB.
Let’s start this article off with a simple summary of the use case:
You’ve been tasked with creating an analytics solution based on large volumes of data containing PII (Personally Identifiable Information)
End users will need to see Summary Level Data for their Department, and also Drill to Detail Level Data containing PII.
Here’s the catch! Users can only view Detail Level Data containing PII for a subset of the Department cohort! For example a Physician can view reports and do interactive analysis of aggregated data for every patient in their entire Department, but they are only allowed to see details containing PII for their own patients.
You’d like to deliver an easy-to-use and highly performant solution that has a simple, cohesive, and elegant design.
Consider the diagram below. A User can see aggregated data for all Specialties, but only two States. When the User drills to detail, they can only see detail data containing PII for one State and one Specialty:
Traditional Row Level Security (RLS) can be used to prevent users from viewing data they are not supposed to see, but it also prevents them from viewing aggregated metrics of the rows obfuscated by RLS. Also, even when PII has been scrubbed from data, re-identification can still be an issue. For example, there may be only one person in a zip code with a rare medical condition. Even though their PII has been scrubbed from a reporting data set, showing data for that zip code and medical condition could lead to re-identification of the person. It is often a best practice to set the grain of de-identified data at a count of persons that reduces or eliminates this risk. Implementing this concept into Power BI Aggregation Tables or Azure Synapse Materialized Views can prevent queries from yielding granular data below a certain patient count. In the example below, that minimum is 8 patients:
In the example above, the Aggregation Table (left) can be set to have different RLS than the Detail Table (right). If the Aggregation is cached in Power BI as an Import table, and the Detail Table is in Azure Synapse, then drilling to details which are different from the aggregates can be achieved such as in the example below:
When using Azure Synapse Analytics with Power BI, you can apply RLS to any of the three basic types of data tables: 1) Power BI Import tables for ease-of-use and highly efficient query performance from an optimized cache of data, 2) Azure Synapse Materialized Views for MPP performance using efficient queries, and 3) Azure Synapse Tables for limitless scale. The diagram below shows these three options that you can mix-and-match in a Composite Model and even layer them as Power BI Aggregations:
Using a methodology of controlling access to Detail level data differently from Aggregated data can be used in many different, flexible and useful ways. Addressing concerns with protecting PII is a common use case. There are a few considerations that should be evaluated and rigorously tested if considering this type of architecture:
Implementing RLS has performance implications in both Power BI and Azure Synapse. Every time a query uses RLS, an additional layer of complexity is added. The RLS design, Power BI Model sizing, and Azure Synapse Analytics sizing all need to be evaluated.
RLS architecture should be designed to require minimal compute, and also rigorously tested before the Azure Synapse and Power BI Data Model designs are finalized.
An efficient and effective RLS design will minimize the chances of future re-work, reduce compute overhead for processing queries, and potentially reduce costs due to optimized query performance and storage requirements.
This article is the fourth in a series exploring how Power BI paired with Azure data tools creates a flexible, scale-able, and achievable healthcare analytics architecture:
#1 – Unleash Massive Healthcare Data Volumes to Analytics using Power BI Aggregations – Click Here!
#2 – Control PII and Sensitive Data Risk for Self-Service BI using Power BI DataFlows and Azure Data Lake – Click Here!
#3 – Microsoft Azure Information Protection Secures Power BI Data Exports for a Seamless DLP Strategy Click Here!
#4 – Combine Azure Synapse and Power BI RLS to Analyze Aggregated Data while Controlling Granular PII (This Article)
COVID-19 has rapidly become a world-changer. While the world’s Healthcare professionals prepare for the unknown, many of us are seeking useful news and updates. Recently, The Center for Systems Science and Engineering (CSSE) at Johns Hopkins University released a COVID-19 Dashboard that has a fantastic interactive map. In the spirit of Open Data, they also made their data set publicly available on GitHub.
Here is a video detailing ways that you can interact with the COVID-19 Power BI Dashboard linked above. I’ll keep the data updated daily, and add new content when possible. Any advice or suggestions about new perspectives, calculations, and content would be welcome as I plan future iterations:
Business Intelligence and Analytics are often restricted in Healthcare organizations due to regulatory concerns about sensitive data such as Personally Identifiable Information (PII). Report viewers often want to export data from reports, but until now there has been no way to effectively track and protect exported files of data. Also, allowing access to reports from un-managed devices has often been an all-or-nothing approach. Microsoft Information Protection and Cloud App Security tools are now in Preview for Power BI as part of your enterprise Data Loss Prevention strategy. Here’s a demo of how Microsoft Information Protection works as a part of Power BI Data Protection:
This article is the third in a series exploring how Power BI paired with Azure data tools creates a flexible, scale-able, and achievable healthcare analytics architecture:
#1 – Unleash Massive Healthcare Data Volumes to Analytics using Power BI Aggregations – Click Here!
#2 – Control PII and Sensitive Data Risk for Self-Service BI using Power BI DataFlows and Azure Data Lake – Click Here!
#3 – Microsoft Azure Information Protection Secures Power BI Data Exports for a Seamless DLP Strategy (this article)
#4 – Combine Azure Synapse and Power BI RLS to Analyze Aggregated Data while Controlling Granular PII – Click Here!
A previous article at this link reviews many of the challenges that Healthcare organizations face due to Privacy and Regulatory concerns for PHI and other types of Sensitive Data. The diagram below is from that article, and shows three common ways that Sensitive Data can be shared inappropriately:
User Exports Data and Shares with Unapproved Users – Power BI Data Protection (using MIP/AIP) is now in Preview to prevent inappropriate sharing.
User Shares a Report with an Unapproved User – Power BI Workspace Level Security, Row Level Security, and Data Protection can all be used to mitigate this scenario.
Re-Identification due to Small Data Aggregation sizes, Using Deep Learning or Referencing Other Databases – Cloud App Security Tools and other Power BI capabilities can reduce this risk, but thoughtful Data Model design by solution architects is also needed and sometimes requires expertise outside of what can be provided by a digital toolset.
For companies operating in highly regulated industries such as Healthcare, the promise of self-service Business Intelligence often takes a back seat to regulatory concerns about sensitive data such as Personally Identifiable Information (PII). Healthcare companies require capabilities to control the flow of sensitive data for both enterprise and self-service Business Intelligence. This article will review strategies for controlling access to sensitive data while still empowering users to gain value from Microsoft Business Intelligence and Analytics tools.
This article is the second in a series exploring how Power BI paired with Azure data tools creates a flexible, scale-able, and achievable healthcare analytics architecture:
#2 – Control PII and Sensitive Data Risk for Self-Service BI using Power BI DataFlows and Azure Data Lake (this article)
#3 – Microsoft Azure Information Protection Secures Power BI Data Exports for a Seamless DLP Strategy – Click Here!
#4 – Combine Azure Synapse and Power BI RLS to Analyze Aggregated Data while Controlling Granular PII – Click Here!
Terms often associated with sensitive data include PII, PHI (Protected Health Information), and PIFI (Personally Identifiable Financial Information). Data that could be used for unfair financial market trades, often referred to as “insider information,” is also a consideration when granting users access to data. I am not an expert on these laws and the specifics of the associated requirements, but the tools and techniques below will hopefully provide value as you consider a plan for managing sensitive data.
Protecting and De-Identifying sensitive data goes beyond the simple removal of names, addresses, social security numbers, etc. The challenge of minimizing sensitive data risk becomes more complex when using Business Intelligence and Analytics tools. Here’s a few examples:
Healthcare
Data that seems impersonal can sometimes be used to deduce identities. “Re-Identification” is a hot topic in Healthcare usually referring to methods where outside information and/or data mining techniques can be used to identify individual patients. Data in Business Intelligence Models is organized, compressed, and cleaned up in a manner that is prime for Re-Identification.
“Re-sharing” reports can transfer visibility from an approved to an unapproved viewer.
Rare disorders and characteristics can be used to identify people. (i.e. one person in the whole State has a rare genetic disorder, and the ICD10 for that disorder is on a report)
Financial & More
When viewing Sales or Financial data, can you deduce the next Quarter’s earnings? Who should have access to what level of detail?
“Exporting Data from Reports” takes data out of pre-defined security constraints.
Banking and Financial Data – How do you report without exposing Customers who can be identified by their Unique Investment Profiles?
Here’s a few examples of how sensitive PII might get accidentally shared with the wrong person:
IMAGE A
A.1 – Example #1 (above) – User A exports data to Excel, a flat file, a document, or into another file format. User A could then share that file with User B, who wasn’t supposed to see that data. A.2 – Example #2 – User A builds a report for a Group of users who have permission to see the PII. User C re-shares that report with User B, not knowing that User B was not supposed to see that data. A.3 – Example #3 – User A scrubs obvious PII from data that is part of an enterprise reporting Data Model. User B is aware that there is only one patient in a specific zip code, and they see data for that zip code. This is still a PII violation.
When sensitive data is shared with approved users, there are tools and techniques which can help minimize the risk of accidental sharing. New Power BI Data Protection capabilities, Administrative Settings, Power BI DataFlows with Azure Data Lake, and Row Level Security can help simplify security and access to sensitive data.
Power BI Data Protection Microsoft Information Protection and Cloud App Security tools are now built into Power BI. These capabilities are game-changers for the Business Intelligence field, and were just recently announced at Ignite. New capabilities include Security for data after exporting it from Power BI, and device-based Security. Example A.1 above is directly impacted by these new features. Click here for more details. I will cover Data Protection in the next article of this series.
Power BI Administrative Settings There are several settings in the Power BI Administrative Portal that can impact access to PII. Click here for a comprehensive list. A few I’d recommend understanding in detail for an enterprise deployment requiring PII governance include:
Create Workspaces
Use Datasets Across Workspaces
Enable Microsoft Information Protection Security Labels
Set Sensitivity Labels for Power BI Content and Data
Share Content with External Users
Publish to Web (most customers turn this off)
Export Data
Export Reports as PowerPoint Presentations or PDF Documents
Print Dashboards and Reports
Allow External Guest Users to Edit and Manage Content in the Organization
Email Subscriptions
Use Analyze in Excel with On-Premises Datasets
Data Flows and Azure Data Lake What is DataFlows? DataFlows is a self-service ETL/ELT tool in Power BI that is easy to use with a low-code/no-code interface. It also allows Power BI Administrators to control data available to self-service Power BI Model architects. Here is a comparison of DataFlows and enterprise ETL/ELT tools:
IMAGE B
So how do Power BI DataFlows and Azure integrate for Sensitive Data Access Control? In the slide below, notice that the functional components of Power BI exist within the same secure Azure tenant as Azure Data Lake. There are also other tools available in Azure for enterprise grade ETL/ELT, Data Science / ML Projects, and for scaling up very large databases using Azure Synapse Analytics. It is important to note that at the time of writing this article, Power BI DataFlows and Azure Data Lake integration is still in Preview:
IMAGE C
Let’s review key features having enumerated green arrows above: C.1 – Low-Code / No-Code ETL/ELT – Power BI Pro users can create low-code/no-code ETL/ELT packages using DataFlows. Pro users can also use existing DataFlows as tables of data to build Power BI Models. By default, DataFlows are stored in a hidden SaaS Azure Data Lake that is part of Power BI. If you choose to add your own Azure Data Lake, you can access the content that has been loaded into it by DataFlows. Once in Azure Data Lake, data can be used in DataBricks, ETL/ELT tools, Azure databases, and third party applications outside of Azure. As a result DataFlows does not trap your data in Power BI, and you can use those tables of data anywhere. C.2 – Azure ML Integration – DataFlows also has native integration with Azure ML. If your Data Science team publishes Models to Azure ML, DataFlows users can use those ML models to score tables of data during scheduled refreshes. The integration is point-and-click with no need to write code. Azure Cognitive Services can also be integrated in a similar way. C.3 – Open Platform for Third Party Connectivity – Third Party tools can pull data from Azure Data Lake, and connect to Power BI Data Models in Premium just like they can with Analysis Services. C.4 – Open Platform for Third Party Reporting – With Power BI, end users can build reports with the data visualization tool of their choice on top of those Premium Power BI Data Models.
So how can DataFlows help control access to PII? Consider the scenario in the following diagram:
IMAGE D
D.1 DataFlow 1 – This DataFlow contains PII that is intended for a select audience. User A is allowed to view this data when it is in an App, but is not allowed to use it for building new self-service Models. User B is not allowed to see data from this DataFlow anywhere.
D.2 DataFlow 2 – DataFlow 2 contains data scrubbed of all PII that can be viewed by both User A and User B. Both User A and User B can use this DataFlow to build new self-service Power BI Models.
D.3 DataFlow 1 Workspace (circled in purple) – User A and User B are not part of the Workspace containing DataFlow 1, so they cannot access the DataFlow to build new Models.
D.4 Power BI Model Workspace(circled in purple) – DataFlow 1 is used to build a Power BI Model stored in a separate Workspace. User A has privileges to use the App from this Workspace, and therefore can view the data. User B does not have permission to view this Model, and is blocked from viewing reports that use the Model as a source.
In the example above, User A Can View the App containing PII but Cannot make their Own Report or Re-share the App. User B Cannot View Anything from DataFlow 1.
A few considerations when using DataFlows with Azure Data Lake:
IMAGE E
In the image above, note that Administrators with access to the Azure Data Lake can see all of the data from Power BI DataFlows. If there is PII in the DataFlows, Data Lake Administrators will have global access to that data.
Keeping DataFlows and Power BI Models in separate Workspaces allows you to restrict the level of access to PII. Someone with access to a DataFlow can blend that data with other sources, and share it with unapproved users. DataFlows containing PII should only be available to trusted and trained Power BI Model architects. Once data is in a Model, settings and permission levels can then minimize the risk of data from that Model ending up in another Model that has different users given permission to view it.
The next two articles in this series will also focus on capabilities that enable secure use of PII in an enterprise and self-service Business Intelligence environment:
#3 – Control PII and Sensitive Data Risk for Self-Service BI using Power BI Data Protection (Coming Soon)
#4 – Power BI with Azure SQL Data Warehouse enables Advanced Row Level Security with Variable Access at both the Summary and Detail Levels (Coming Soon)
Digital Transformation will leverage massive data volumes to improve both the quality and cost of healthcare…doesn’t that sound easy? Large volumes of data and complex logic have long made healthcare analytics a challenge. New capabilities to address these requirements have been added to Power BI for use with powerful databases such as those in Azure. These new capabilities can help healthcare analytics teams achieve more. This article is the first in a series exploring how Power BI paired with Azure data tools creates a flexible, scale-able, and achievable healthcare analytics architecture:
#1 – Unleash Massive Healthcare Data Volumes to Analytics using Power BI Aggregations (This Article)
Healthcare reporting and analytics often require massive data volumes with tables that are both exceptionally wide and deep. Architectural concepts such as Large Type 2 Dimension tables, Many-to-Many Relationships, and Secondary Key Relationships are rare exceptions in most Business Intelligence designs yet are common in Healthcare. Numerous reference tables are often required that can also have complex architectures due to ever-changing categorization systems such as DRGs, ICDs, CPTs, and others. Add calculation logic such as qualifying visits, LOS calculations, complications, and cohort inclusion/exclusion criteria and the challenges becomes daunting. Successful solution design requires deep healthcare industry expertise along with powerful tools.
Have you been held back by data volume limitations in Power BI? Have Power BI Import Models hit the Pro 1GB and Premium 10GB limitations, while Direct Query Models demand too many resources from your source databases? Power BI’s new Aggregations feature combined with Composite Models can now help you unlock massive volumes of data for analytics.
One of the biggest challenges with Business Intelligence has always been organizing large volumes of data so that they are usable within the confines of technology. An ideal target architecture would allow data to be stored in one place and queried by users who interface with a purely logical metadata layer. Relational Databases, ROLAP Models, and most recently Direct Query Tabular Models all achieve this goal, but query complexity and user concurrency often create performance bottlenecks due to technical limitations of source databases. Here’s a simple diagram of a Direct Query Model for a tool such as Power BI:
Cached data models have been an effective workaround since the early days of OLAP/MOLAP technologies. Import Mode Tabular Models within SQL Server Analysis Services, Excel PowerPivot, and Power BI also leverage a cache of data to enable high query concurrency with complex logic. Import (Cached) Models have great performance, but caching extremely large volumes of data is not always practical or scale-able:
Power BI now offers Composite Models, which combine the best of both traditional options by allowing Import and Direct Query tables in the same Model. Tables with extremely large volumes of data or near-real-time requirements can be in Direct Query mode, and Tables that are suited to a cache can be in Import or Dual mode:
The three basic types of Power BI Models can be visualized as follows:
When querying an extremely large table of data, Direct Query mode can send multiple queries to the source database with every click of a filter on a report. If there are complex queries and high user concurrency, the demands placed on the source database can be extreme. Power BI Aggregations offers you a new way to seamlessly blend an Imported Summary Table and a Direct Query Detail Table within a Composite Model for an architecture that is obfuscated from both DAX calculation authoring and end users who are viewing reports. With Aggregations, an Import Mode Summary Table will be queried whenever logically possible and the full Direct Query Mode version of the table will only be queried when details not in the Summary Table are required. Consider the following scenario. Notice that with Aggregations there is no need to use Direct Query against the source for Query #1:
What about scenarios where details are needed that do not exist in the Aggregation? For Query #2 below, a query is sent via Direct Query mode since Procedures do not exist in the Aggregation:
If we were to use a logical model to explain what’s happening with Aggregations, it would look like this:
Are Aggregations just a fancy new version of a Summary table? Yes and No. With traditional Summary tables users would either need to select separate calculations for Summary and Detail reporting, or programmatically switch between the two tables using tricky MDX or DAX code. Power BI Aggregations are hidden from the end users, so a simple DAX expression written against the Patient Visit Table (such as Total Visits = SUM(‘Patient Visit Table’[Total Charges]) will automatically look to see if it can query the Aggregation table first, and only send a Direct Query if there is detail unavailable in the Aggregation such as a filter on Procedures. The examples provided in this article would most likely be part of a more detailed architectural design, such as the one below:
How does this impact the size of the Model published to Power BI? By reducing the volume of data in the cache, the size of the Model is greatly reduced. Here’s the results from a test I ran on real healthcare data from the CMS Medicare Part D database:
Model
Columns in Storage
Row Count
Size
Relational DB in Azure SQL DB
Physician, Specialty, City, State, Drug
90,000,000
35.5 GB
Power BI Import Model
All
90,000,000
1.8 GB
Power BI Composite Model w Aggs
Specialty, State, Drug
750,000
35 MB
Here’s a video that discusses the Model mentioned above along with a demo:
In the example above, queries were lightning fast unless filter criteria for specific physicians or cities were selected. Only when that level of detail was needed would a query get sent back to the Azure SQL DB.
Let’s take this another step further! Aggregations can be Imported Summary tables, but they can also be in Dual Mode or Direct Query Mode. Direct Query Mode Aggregations can effectively be used as Indexes to optimize queries that are sent back to a source. Multiple Aggregations can also be added to the same source table, and Precedence can be given so that the most efficient ones are evaluated for queries first, then additional Aggregations can be queried before a true Direct Query is sent to the source:
In summary, Power BI Aggregations expands the possibilities for building models leveraging larger data volumes, while still allowing for great query performance and high user concurrency. Any questions of comments? Please leave a comment or reach out to me on Twitter or Linkedin.
Highly engaged teams will often identify opportunities for improvement as a result of effective collaboration. Teams enabled with tools to drill into details of workflow components, track progress of initiatives, and explore data can foster a culture of continuous improvement and progress. Microsoft’s suite of Modern Workplace tools enables users to securely collaborate, discover, and share information in their quest to improve quality of care and operations. In a provider setting, viewing data on an interactive hospital floor map can add value to these teams by providing context that helps identify root causes and trends.
In order to understand the value analytics offers clinical and business teams, let’s use an example that a real-world healthcare team might encounter. For many types of inpatient surgical procedures, there is often a goal to check a patient’s post-surgical pain score at certain intervals. Increasing pain scores can sometimes indicate risk for complications, and can also lead to general patient dissatisfaction. Visit this link for more details.
If pain scores aren’t being checked on a regular basis, how might a team address that challenge? There are probably many questions that a team would want answered such as: Are certain care teams doing a better job than others? Should we focus on improving compliance for high-risk patients first? Does room location impact frequency of pain score checks?
Microsoft’s Modern Workplace tools are designed to be user-friendly and secure for business and clinical users, which liberates teams to build their own workflows and solutions. If a team is tracking pain score evaluations, and also has access to related clinical data (databases, flat files, spreadsheets, etc), they can create a reporting model in Power BI that is designed to evaluate criteria for a specialized patient cohort. Using Visio Online, they can also track pain score monitoring compliance on a map of a hospital floor. The report can be securely embedded within Teams to become a seamless component of collaboration. Just to be clear, all of this can often be accomplished by an analyst without writing any code.
Analytics and data exploration no longer needs to be isolated in a separate portal designed and managed by wizards behind a curtain. Analyzing data and information is an integral part of the way that teams collaborate, think, share, and take action. When action is warranted, teams using Microsoft tools have several options for next steps. They can discuss in Microsoft Teams, securely share the report findings, or set up an automated alert for proactive notifications (i.e. when a current inpatient’s pain score doesn’t get checked).
In the example above, a team can view pain score compliance within Microsoft Teams and add comments that trigger actions in near-real time. The report seamlessly integrates Power BI (report design), Visio Online (hospital floor map), Power Apps (comments section), and Microsoft Flow (sends Alerts to users when urgent comments are entered) into a single solution. All of this content can be created and put together by subject matter experts and analysts. Clinical and Business users can now securely collaborate, discover, and share information in their quest to improve quality of care and operations.
If you’d like to discuss this demo, just let us know. Here’s a few links to explore the different tools discussed in this article and the embedded video at the top of the article:
Power BI allows users to create data driven alerts with a few clicks. What if a user wants to distribute those alerts to a broader audience? This tutorial uses Microsoft Flow to distribute Power BI Alerts via email addresses and distribution lists.
