Part I:
Learning Modeling and Notation Tools

Orchestrating Generative AI in Business Process Models

Blog

By John Svirbely

(Read Time: 2 Minutes)

Going from Zero to Success using BPM+ for Healthcare. Part III: Going from Paper to Practice

Blog

By John Svirbely

(Read Time: 3 Minutes)

Going from Zero to Success using BPM+ for Healthcare. Part II: Getting Started

Blog

By John Svirbely

(Read Time: 3 Minutes)

Going from Zero to Success using BPM+ for Healthcare. Part I: Learning Modeling and Notation Tools

Blog

By John Svirbely

(Read Time: 3 Minutes)

In Healthcare, Interoperability is Just the Start

Blog

By John Svirbely

(Read Time: 3 Minutes)

Transforming Healthcare with Trisotech

Blog

By John Svirbely

(Read Time: 5 Minutes)

All Blog Articles

Read our experts’ blog

What is SMART on FHIR^®?

SMART on FHIR^®, an abbreviation for Substitutable Medical Applications and Reusable Technologies (SMART) on Fast Healthcare Interoperability Resources (FHIR), is an open, standards-based technology that enables innovators to create apps that seamlessly and securely integrate with Electronic Health Records (EHRs).

It combines the Fast Healthcare Interoperability Resources (FHIR) standard with an authorization protocol based on OAuth 2.0 to provide access to data in a standardized format with granular access controls.

Note: HL7^®, and FHIR^® are the registered trademarks of Health Level Seven International and the use of these trademarks does not constitute an endorsement by HL7. CDS Hooks™, the CDS Hooks logos, SMART™ and the SMART logos are trademarks of The Children’s Medical Center Corporation.

SMART on FHIR has revolutionized the way Electronic Health Records (EHRs) are accessed and utilized in the healthcare industry. This innovation is the product of the collaboration between technology and healthcare, aiming to improve the interoperability and delivery of healthcare services. It has the potential to unlock health data and drive innovation across the healthcare ecosystem.

By leveraging the SMART on FHIR specification, healthcare innovators can develop apps that query, update, and analyze a patient’s EHR data without custom integration or interference to EHR system operations. Apps can offer clinical decision support, customized patient education, interoperability bridges, Population Health Management, and more.

SMART on FHIR enables an iPhone-like app platform for healthcare.”

Dr. Kenneth Mandl,
Director of the Boston Children’s Hospital Informatics Program
and co-lead of the SMART project

Who Uses SMART on FHIR?

SMART on FHIR is used by major companies like Epic, Cerner, Allscripts, Meditech, athenahealth, Microsoft Azure, and Apple, showcasing its widespread adoption and importance in the healthcare sector. Epic and Cerner, which account for over half the U.S. EHR market, both integrated SMART capabilities into their systems in 2018. The SMART on FHIR specifications allow organizations to use plug-in applications and run them inside any EHR that complies with HIPAA.

In the United States, SMART™ support is specifically referenced in the 21^st Century Cures Act of 2016. The 21^st Century Cures Act requires a universal API for health information technology, providing access to all elements of a patient’s record accessible across the SMART API, with no special effort.

SMART on FHIR is widely adopted because it delivers many benefits. Here are just a few:

Open standards.
Apps that comply with SMART are reusable and can be repurposed with minimal effort.
Programmers can build and modify their apps without ruining the way healthcare providers and patients access data by easily disengaging the protocols for accessing EHR from the app.
SMART on FHIR has an ever-growing app gallery of providers and patients to choose from.
SMART on FHIR has a large community of engineers and tech experts to ask for advice.

What is SMART on FHIR used for?

SMART on FHIR apps, both publicly available and custom-created, are demonstrating major healthcare benefits in care coordination, clinical decision support, clinical research, data visualization, disease management, genomics, medication, patient engagement and education, Population Health Management, risk calculation, telehealth, interoperability bridges, and many more areas.

For example, an app called CORSI helps emergency physicians safely prescribe opioids by analyzing FHIR resources against state PDMPs (Prescription Drug Monitoring Program) data. Another app identifies EHR data inconsistencies in under one second compared to traditional manual review methods that take weeks. SMART and SMART on FHIR apps are creating an ecosystem of medical apps that are reducing costs and improving health on a major scale.

A well-recognized and significant usage of SMART on FHIR is for Clinical Decision Support.

The SMART on FHIR Standard

In 2009, in a New England Journal of Medicine article, the Computational Health Informatics Program, Boston Children’s Hospital, introduced the idea of an API to promote an apps-based health information economy. The SMART team focused on leveraging web standards, presenting predictable data payloads, and abstracting away many details of enterprise health information technology systems while marshaling data sources and presenting data simply, reliably, and consistently to apps. Since 2013, through co-development and close collaboration, SMART and FHIR have evolved together. SMART enables FHIR to work as an apps platform today referred to as “SMART on FHIR.” The SMART authorization layer complements the FHIR specification by allowing patients to authorize trusted third-party apps to securely access select FHIR resources relevant to the apps.

Here are the HL/7 Standards and Specifications related to SMART:

Foundational
- FHIR: Fast Healthcare Interoperability Resources. Web standard for health interop
- CDS Hooks: Clinical Decision Support Hooks. Web standard for CDS in the EHR workflow
Data access
- US Core Data Profiles: FHIR data profiles for health data in the US (“core data for interoperability”)
- FHIR Bulk Data API Implementation Guide: FHIR export API for large-scale data access
UI and Security Integration
- SMART App Launch: User-facing apps that connect to EHRs and health portals
- SMART Backend Services: Server-to-server FHIR connections

Trisotech and SMART on FHIR

Trisotech provides support for SMART on FHIR through the Healthcare Feature Set (HFS)

via features and functions that allow healthcare organizations to model and automate their decisions and workflows.

Learn More

Access is provided to FHIR®, CDS Hooks™, and SMART™ on FHIR, as well as AI and Machine Learning (ML) capabilities. The Healthcare Feature set makes understanding and using the latest interoperability standards in healthcare technology available in a modern, easy-to-use way that is compatible with existing software systems in any healthcare setting.

Autogenerated SMART on FHIR webapps

How to develop SMART on FHIR apps? With the Healthcare Feature Set, SMART on FHIR web applications can be created from decision, workflow, and case models using one-click deployment. Links to those SMART on FHIR applications are automatically generated and are suitable for inclusion on CDS Hooks “App Link Card” or in any SMART compatible environments.

FHIR Support

Trisotech’s Healthcare Feature Set allows for data storage, retrieval, and patient data exchange using the FHIR (HL-7®) interoperability standard. Re-useable FHIR data types and drag and drop FHIR resources are available for all FHIR Resource structures including Foundation, Base, Clinical, Financial, and Specialized resource structures.

Predefined FHIR Data types

Trisotech provides out-of-the box FHIR data types that can be assigned with one click to elements in Decision models (DMN), Workflow models (BPMN), and Case models (CMMN).

CDS Hooks Support

CDS Hooks is one of the most common ways to embed Clinical Decision Support (CDS) automation functionality in a clinician’s workflow. When an EHR system notifies external services that a specific activity occurred within an EHR user session, a CDS service can gather needed data elements through FHIR services and return information to the clinician in the form of a “card.” As part of the Healthcare Feature Set, Trisotech provides a CDS Hooks server to accept decision support requests and generate customizable CDS Cards in return. Where CDS Services require specific FHIR Resources to compute the decisions the CDS Client requests, CDS Hooks support will provide the interface to acquire those resources.

Connection to a FHIR Terminology Server

The Healthcare Feature Set allows concepts used in Workflow, Decision and Case models to be healthcare coded using healthcare coding systems (SNOMED CT, LOINC, RxNorm, ICD, etc.) and ValueSets through a connection to a terminology server of choice that adheres to the FHIR Terminology Sever specification.

Discover the complete set of feature of the Digital Automation Suite.

Learn More

Resources

Related to FHIR

Trisotech

the
Pioneer

Trisotech Telemedicine Webinars Series
Process Automation in Telemedicine: Improving Efficiency

Presented at FHIR North 2021 by

Dr. John Svribely, CMIO at Trisotech

Denis Gagne, CEO & CTO at Trisotech

Informed Consent (also known as Consent for Medical Treatment) is required prior to most medical procedures. It allows the patient to actively participate in decisions about what his or her own care. Informed Consent is therefore an integral part of Patient-Centered Care.

FHIR defines a Consent resource that is meant to cover four different uses cases: Privacy Consent, Medical Treatment Consent, Research Consent, and Advance Care Directives. Currently, only the Privacy Consent use case has been elaborated.

In this session we will explore the usage of the FHIR Consent Resource for the purpose of Informed Consent. This process will be captured using the BPM+ set of standards and combined with the usage of the FHIR Consent resource.

Attendees will learn about:

The FHIR Consent Resource.
The Informed Consent/Medical Treatment Consent process.
Representation of the process using BPM+ Standards.
A demonstration of an automated Informed Consent for Total Hip Arthroplasty (THA) surgery.

View the slides

Videos

Recorded webinars

What is Business Process Management?

What is BPM?

All businesses have processes. Processes are typically differentiated from projects because processes are predictable and repeatable. They are the building blocks of operating a business.

While many organizations have similar fundamental processes, the unique parts of their processes, dictated by their specific business methods, form the basis of the organization’s competitive advantage and often their “culture.” A process can be defined as a series of steps leading to identified outcomes. Common business processes are often named with descriptions like Opportunity-to-Order, Order-to-Cash, or Employee Onboarding. The sequence of work and steps performed can vary from instance to instance based on inputs, decisions, timing, dates, etc. However, regardless of the value of these variables, to properly define a process one must know all the possible paths and outcomes in advance i.e., predictability.

Business Process Management is a management discipline with the key goals of discovering, modeling, analyzing and optimizing business processes. While some BPM solution providers might include business process automation – a BPM engine or automation platform – as part of BPM, Trisotech defines process automation as a separate discipline. As a methodology, BPM can be thought of as similar to (and sometimes encompassing) other methodologies like continuous improvement (CI) or total quality management (TCM).

Why is BPM Used?

Once a predictable process has been defined through process discovery, it can be optimized – often called process improvement – and performed over and over in a standard way i.e., repeatability. By the act of discovering and defining a process, the resulting process documentation becomes a valuable organizational asset. The use of BPM can improve business operations’ performance and agility, lower costs and add value to customer products and services. Often cited specific benefits include higher efficiency and productivity, reduced costs, increased revenue, better agility, operational consistency, greater customer service focus, better regulatory compliance, increased security, and higher operational visibility.

Business Process Management Software in healthcare

BPM in Healthcare

Utilizing Business Process Management in Healthcare provides a huge array of opportunities to deliver better patient care and services, reduce errors, improve profitability, and ensure regulatory compliance at every level.

More info on healthcare

Process-driven healthcare organizations can create standardized clinical guidelines that facilitate consistent organizational policy, patient diagnosis, treatment, and reporting for both individuals and populations. Business processes can also provide real-time feedback and recommendations to providers, be embedded in most patient encounter systems, and integrate the use of standards like FHIR® and CDS Hooks.

Business processes are not just valuable in the clinical setting, however. They are also extensively used in healthcare insurance and patient services settings. Examples of these types of processes include claims processing, pharmaceutical and durable medical equipment (DME) pre-authorizations and patient, provider, and facility scheduling.

Business Process Management Software in finance

BPM in Finance

Business Process Management is helping to fuel the disruptive FINTECH industry as well as assisting existing financial institutions and service providers in transforming the way they do business to remain competitive.

More info on Finance

End-to-end business processes are facilitating the digital transformation revolution that has put the customer in the center of a 360 degree organizational view. That in turn has led to the optimization of existing operations and customer-centric policies and procedures. Standardized processes lead to higher operational visibility as well as better and more easily audited regulatory compliance.

BPM is driving better risk assessment and management, underwriting decisions, lending automation, servicing automation, insurance claims processing, and many other financial activities. By using predictable and repeatable business processes the financial industry is experiencing higher growth rates, greater profitability, more rapid digital adoption, higher rates of compliance, improved efficiency, and better security than ever before.

Trisotech BPM Solutions
What is Business Process Management Software from Trisotech?

Trisotech provides 100% browser-based business process management discovery and modeling tools in cloud-hosted or on-premise environments. The process discovery tool – the Discovery Accelerator – helps business people describe the Who, What, When, Where, and Why of how their processes work through simple interactive screens and/or existing written policies, guidelines, business rules or other documents. These business observations can then be turned into an initial workflow starter diagram with the click of a single button.

Business processing modeling software from Trisotech – the Workflow Modeler – is used to produce a visual workflow using the international standard BPMN (Business Process Management Notation) via an intuitive drag-and-drop visual interface. These model diagrams provide comprehensive documentation, analysis, collaboration, and reporting features recognized as the gold standard in the process modeling industry and can be used directly by the Trisotech business process automation software. Using Trisotech’s BPM tools and combining the Workflow Modeler business process mapping software with the Trisotech Business Automation platform gives customers an unrivaled, powerful, and comprehensive low code/no code application development capability.

Improve your Business Processes to drive Business Automation using Trisotech

Free Trial

Trisotech

the
Innovator

Read what people are saying about Trisotech and the Digital Enterprise Suite

FOR IMMEDIATE RELEASE:

Trisotech Featured in HealthTech Magazine Cover Article

Montreal, QC – May 25, 2021 — Trisotech (http://trisotech.com), a leading provider of Intelligent Business Automation-as-a-Service, today announced that it has been featured as the cover story in a Digital Health special edition of HealthTech Magazine titled Trisotech – Bridging the Business-IT Divide.

Trisotech, through their digital transformation solutions, is driving innovation in many industries including healthcare. Trisotech healthcare clientele include international and U.S. acute care hospitals, healthcare insurance organizations, renowned teaching hospitals, and healthcare professional organizations.

The cover article discusses how using Trisotech workflow and business decision modeling along with Trisotech automation engines helps healthcare organizations blend IT challenges with clinical practices. According to Trisotech Founder, CEO and CTO, Denis Gage, “Most healthcare providers want centralized, easy-to-understand and change standard process and decision methodologies. They not only want tools that adhere to international standards for building those processes and decisions, they also want those tools to support other standards like FHIR® for data storage and retrieval and CDS Hooks for real-time decision support at the point of care. We do all that and more.”

“We are very pleased that HealthTech Magazine has recognized our transformative innovation in the healthcare space,” continues Gagne, “and has provided this article that delves into our innovations in an informative and easy to understand way. We are also pleased to be a founding member of the BPM+ Health community where these ideas including our nearly 1,000 free pre-built evidence-based workflow and decision models are being put into practice every day. These models are human-readable, machine automatable, and embeddable in most medical encounter systems. Healthcare organizations can use these models, created under the direction of Trisotech CMO John Svirbely, as they are, or quickly and easily modify them to fit the exact nature of their organization’s policies and procedures. Healthcare organizations can also, of course, create their own processes and decisions from scratch since the easily understood visual models can be built and shared by practitioners, IT and business people.”

Founded in 1996, Trisotech aids enterprises in realizing their Digital Transformation goals by visualizing, improving, innovating, transforming, and automating their most critical business processes.

About Trisotech

Trisotech is a global leader in digital transformation solutions. Trisotech The Digital Enterprise Suite is a highly visual and interactive software suite that enables technical resources to encapsulate programmatic logic and lets non-technical business people assemble the business logic to innovate, transform and improve their business. Combining concepts of simplicity, usability and collaboration in the cloud, the Digital Enterprise Suite is composed of theDigital Modeling Suite and the Digital Automation Suite. Trisotech customers use the Digital Modeling Suite to create a digital twin of their organization using visual models and the Digital Automation Suite to leverage business automation as a service in industries such as healthcare, finance, and the public sector.

Trisotech is a privately held company.

Website: http://trisotech.com

###

For information

Denis Gagne
CEO & CTO
Trisotech
dgagne@Trisotech.com

All registered trademarks are the property of their respective owners.

Read Complete Article

Press releases

In the news

What Does a Workflow Management System Do?

Workflow Automation software executes computer-driven flows (processes) of human and system tasks, documents, and information across work activities in accordance with flow paths based on business decisions. Workflow Management software also ensures processes – both internally across organizational boundaries, and externally for Customer/Client interactions – are optimized, repeatable and auditable while still being quick and easy to change.

While Robotic Process Automation (RPA) has been making inroads in automating tasks within processes, Workflow Automation software is far more powerful than RPA. However, the two are both compatible and synergistic. RPA bots can automate individual tasks within a business process, but they typically can’t connect those tasks together. Good workflow engines allow RPA tasks to be included as part of a process.

Workflow Design software and Workflow Process software are being effectively used in practically every industry, frequently serving as standard operating procedures software. Digital Workflow software can be especially effective and valuable in two industries: Healthcare and Financial Services.

Workflow Automation Software
in Healthcare

Request Demo

The Healthcare industry is large and diverse. While the focus in healthcare is usually on the front-line workers, the caregivers and providers, there are also multitudes of back-office workers.

Large-scale healthcare organizations are often in linked businesses, networking physicians and other providers, acute care hospitals, long term care facilities and insurance organizations. Using Trisotech’s Business Process Management software all these organizations can create secure standards-based software to help them store and retrieve data as well as standardize and automate workflows and decision making across all parts of their business.

Most healthcare providers want standard processes and decision methodologies that are centralized, easy to understand, automated through workflow engines, and quickly changed by SMEs without resorting to the need for heavy IT involvement. This, in turn, frees up IT resources to work on centralizing, consolidating and making available the latest technologies across organizational silos. This includes providing technologies to support standards like FHIR® for data storage and retrieval, Clinical Quality Language (CQL) and CDS Hooks for clinical decision support in real-time at the point of care. Trisotech’s Workflow Design software and Workflow Automation software supports all these standards and allows automated processes to be fast and easy to change as regulatory requirements and new medications and procedures evolve.

Using Trisotech’s workflow management software, healthcare organizations can develop evidence-based workflow and decision models that are human-readable, machine automatable, and embeddable in most medical encounter systems. While healthcare organizations can and do create their own automatable models, Trisotech also provides pre-built models including nearly 1,000 free customizable care pathways, clinical guidelines, and healthcare decision calculators in the BPM+ Health standard. This way, Trisotech’s process management software enables practitioners to stay updated, accelerate solution adoption and ensure greater consistency in care execution. Additionally, the comprehensive visual models offered by the Workflow Design software are readable by IT, providers and business people, serving as a guideline specification, the guideline logic, the guideline documentation, and the automation code for the workflow engine – all in a single visual artifact!

1,000
FREE customizable care pathways, clinical guidelines, and healthcare decision calculators

Moving to evidence-based practices is very desirable but also often difficult for healthcare organizations. Subject matter experts (SMEs) and clinicians constantly work with IT to translate large volumes of regulatory, new medication and procedure information into organizational policy. This is a consistent and expensive requirement for SMEs using their existing, often antiquated systems to keep information up to date. Trisotech’s Workflow Design software and Workflow Automation software solutions allow healthcare organizations to easily define and deploy evidence-based best practices that offer a consolidated view of the interactions and multiple touchpoints with patients, care pathways, and workflows at the point of care.

Back-office tasks such as pre-authorization, medical necessity determinations and off-label drug prescription approvals have a huge bearing on patient experiences. They are also time-consuming, expensive and highly manual activities. Utilizing Workflow Process software for these types of activities expedites decisions for waiting patients, allows for services to be rendered sooner, and increases ROI. Using Trisotech’s digital workflows paves the way for improving both the perceived and real quality measurements for any healthcare organization.

Healthcare Payers and Insurers are also leveraging Trisotech’s process management software to automate processes like claims processing and pre-authorization determinations, leading to more efficient decision making and significant cost savings. Trisotech’s Automated Workflow software can ensure the correct information is collected at the outset, help pay claims rapidly and organize case management for disputed or confusing exception claims. The workflow software also helps payers keep complete records in case of an audit. Health plan members benefit from a better experience as they can access the care they need with minimal delays and without surprises at the time of claim payments or billing.

More info on Healthcare

Workflow Automation Software
in Financial Services

Request Demo

Financial services make up one of the economy’s most significant and influential sectors. This sector is made up of Banking Services including Retail Banking, Commercial Banking and Investment Banking. Also included are Investment Services, Insurance Services and Tax and Accounting Services.

These businesses are composed of various financial firms including banks, finance companies, lenders, investment houses, real estate brokers, insurance companies, etc. Trisotech has customers using its Workflow Design software and Workflow Automation software in all of these businesses. The typical description of this sector is Financial Services, but it is really made up of both services and Financial Products like mortgages, investments, credit cards, insurance policies, etc. This means that it is not only a business-to-business (B2B) sector but also has a huge business-to-consumer (B2C) component. Marketing, selling and servicing these products is fertile ground for Trisotech’s Workflow Automation software.

Various forms of proprietary financial software have been in use for decades and the adoption of those early technologies now presents the industry with an increasing risk in the form of technical debt. Old technologies are being disrupted by newer cloud-based offerings which include standards-based business process management software that is far better suited to meet the rapidly changing personalization, self-service, risk and compliance needs of today’s marketplace. Indeed, improving client service by automating policies, accounts, investments, claims and more using digital workflows is a cornerstone of the digital transformation efforts in financial services. To simplify the complex process of digital transformation and in order to streamline their processes and decisions, financial enterprises should render organizational workflows and business decision logic into international standards-based visual diagrams and documents. When using Trisotech’s Digital Enterprise Suite, not only can those visual diagrams be shared by business people and technical people they can also be automated by Trisotech’s workflow engine directly from those visual diagrams.

Share
knowledge across your organization and free up your IT resources

Technology replacement is also very important because most organizations have their knowledge, policies and procedures embedded in large complex programs maintained by IT programming staffs. Today, “old school” practices like SMEs maintaining Excel spreadsheets for policies and rules (regulatory and organizational) that then must be “translated” by IT into traditional programming languages and proprietary rules systems are giving way to visual models incorporating standardized “decision services.” Using Trisotech’s Digital Enterprise Suite, modern workflows and decision services can be built and maintained by SMEs and turned into automated business processes by clicking a single button. This, in turn, frees up IT resources to work on centralizing, consolidating and making available additional more current technologies across organizational silos.

Challenges

Primary challenges the financial industry is facing today include rapid and often massive regulatory changes, privacy, security, and fraud prevention, surpassing or keeping up with the competition by exceeding customer expectations, and replacing old technologies with emerging technologies. Trisotech’s workflow software is already recognized as the reference implementation for many international standards such as BPMN, CMMN, and DMN. In the financial industry Trisotech is rapidly taking a leadership position with its implementation of the Mortgage Industry Standards Maintenance Organization (MISMO) standard and support of other standards like the Financial Industry Business Ontology (FIBO), common database connections and multiple AI techniques.

For Fintech organizations, Trisotech’s Workflow Design software and Workflow Automation software accelerate digital transformation by providing the ability to easily define, deploy and maintain improved decision-making and workflows supported by artificial intelligence and machine learning in a graphical environment. While Trisotech’s Digital Enterprise Suite is being used by customers for everything from retail credit card processing to insurance claims processing, one area, underwriting, has been of particularly high value to customers.

Underwriting is the process by which an institution takes on financial risk – typically associated with insurance, loans or investments. Underwriting means assessing the degree of risk for each applicant prior to assuming that risk. That assessment allows organizations to set fair borrowing rates for loans, establish appropriate premiums to cover the cost of insuring policyholders, and creating a market for securities by pricing investment risk.

Underwriters evaluate loans, particularly mortgages, to determine the likelihood that a borrower will pay as promised and that enough collateral is available in the event of default. In the case of insurance, underwriters seek to assess a policyholder’s financial strength, health and other factors and to spread the potential risk among as many people as possible. Underwriting securities determines the underlying value of the company compared to the risk of funding its capital acquisition events such as IPOs. All of these activities lend themselves to digital workflow software solutions.

For example, mortgage loan origination. By utilizing Trisotech’s Workflow Design software, customers are able to build standard operating procedures software for loan origination that encompass the organization’s specific underwriting policies. These workflows can be created and maintained by underwriting experts while complex mathematical models, AI and privacy and security requirements are taken care of by IT personnel. Trisotech provides for all of this in a single common visual model understandable by both the business people and the IT personnel while still maintaining separation of concerns through granular permissions. Once the visual model is complete, a single button click can automate the workflow and make it available to Trisotech’s workflow engine part of the Workflow Process software.

More info on Finance

What Is Workflow in Software?

The unique capabilities of Trisotech’s Automated Workflow software are rooted in its ability to simplify the complex process of digital transformation for all. In order to streamline their processes and decisions, enterprises must first know what those processes and decisions are. Discovering and validating them is the responsibility of business leadership not solely IT. Thus, a must-do activity of digital transformation is rendering organizational workflows and business decision logic into international standards-based visual diagrams and documents. Then, they can be shared by business people and technical people and automated directly from those visual diagrams.

Trisotech calls this process Business Services Automation. The Trisotech offering includes visual Workflow Design software and visual Workflow Automation software.

Trisotech Workflow Automation Solutions

Workflow Design software

The Workflow Design software includes workflow automation software (BPMN), decision automation software (DMN) and case management automation software (CMMN) along with a larger suite of application tools that facilitate workflow discovery, promote organizational standards use and support workflow design life cycles. The software also supports AI and RPA integrations, full API support and the configuration and management of users, permissions and models.

Workflow Automation software

Trisotech’s process Workflow Automation software includes workflow engines that can directly execute the business process management models. These workflow engines are utilized through RESTful APIs, provide the highest levels of privacy and security and can be containerized and thus scalable on demand across a wide variety of public and private cloud configurations including high availability configurations.

Trisotech’s Workflow Automation software also provides a full rich visual configuration interface supporting server environment configuration, audit logs, debugging tools and management of running workflow instances. Trisotech’s digital workflow software is high in value, low in cost and backed by world-class technical support.

Put succinctly, Trisotech’s Digital Automation Suite (DAS) is an API-first, container-based scalable cloud infrastructure for business automation. It enables complex automation of business workflows, cases and decisions in a simple, integrated run-time environment. It allows organizations to leverage business automation as a source of competitive advantage, via high performance, flexible, and linearly scalable automation engines. The Digital Automation Suite also offers an outcome-driven orchestration of AI and other emerging technologies using international standards and a microservices architecture.

Trisotech

the
Innovator

BPM+ Health Clinical Pathway Implementation Showcase
Healthcare Concept Maps combined with a FHIR^® accelerator.

BPM+ models are based on open standards that can be used to visually depict the structure and behaviour of healthcare workflows and decisions. If these workflow and decision models are to completely model healthcare clinical guidelines, then they also need to orchestrate logical data structures of medical concepts and data in the electronic health record.

In this presentation, we look at:

Introduce two knowledge entity models of the most common medical conditions and observations.
Bind them to logical data structures based on FHIR^®, referred to the FHIR^® accelerator
Demonstrate them in action.

FHIR® and the [flame mark] are registered trademarks of Health Level Seven International (HL7) and are used with the permission of HL7. Use of this trademark does not constitute an endorsement of products/services by HL7®.”

As presented by:

John Svirbely and Denis Gagne

View the Slides

Videos

Recorded webinars

BPM+ Health Clinical Pathway Implementation Showcase

Healthcare Concept Maps combined with a FHIR^® accelerator.

Healthcare Concept Maps combined with a FHIR Accelerator from Denis Gagné

In this presentation, we look at:

Introduce two knowledge entity models of the most common medical conditions and observations.
Bind them to logical data structures based on FHIR^®, referred to the FHIR^® accelerator
Demonstrate them in action.

As presented by:

John Svirbely and Denis Gagne

Watch the Webinar

Content

Presentation

Watch the Webinar Download the Case Study

Automatable Healthcare Decisions and Workflows Using FHIR®

Automatable Healthcare Decisions and Workflows using FHIR® from Denis Gagné

Healthcare decision support ideally takes place within the clinician’s workflow with access to all of the patient’s healthcare data and preferences. As patients move around the healthcare ecosystem, their electronic health records must be ubiquitously available and discoverable. FHIR® can serve as a lingua franca for this data.

For decision support to be embraced by physicians, it needs to be timely, based on best practices, simple to understand and easy to adopt. BPM+ workflow and decision software provide a visual representation of evidence-based best practices with the potential for automation.

As presented by:

Ken Stevens, Director of Enterprise Solutions at Smile CDR
and Denis Gagné, CEO & CTO at Trisotech.

Content

Presentation

View the Slides Download the Case Study

Automatable Healthcare Decisions and Workflows using FHIR®

As presented by:

Ken Stevens, Director of Enterprise Solutions at Smile CDR
and Denis Gagné, CEO & CTO at Trisotech.

SUGGESTED

Healthcare Resources

Dana-Farber Cancer Institute

Articles

Orchestrating Generative AI in Business Process Models

Blog

Going from Zero to Success using BPM+ for Healthcare. Part III: Going from Paper to Practice

Blog

Going from Zero to Success using BPM+ for Healthcare. Part II: Getting Started

Blog

Going from Zero to Success using BPM+ for Healthcare. Part I: Learning Modeling and Notation Tools

Blog

SMART on FHIR

Standard

In Healthcare, Interoperability is Just the Start

Blog

Mayo Clinic

Articles

Transforming Healthcare with Trisotech

Blog

Trisotech Named Among the 10 Most Innovative Healthcare Companies Making a Difference in 2023

In The News

Trisotech The Pioneer Streamlining Clinical Workflow and Decision Automation

Articles

Intermountain® Health’s New Interoperability

Articles

Adding Smarts to Drug Package Inserts using Clinical Workflows and Decisions

Webinars

Modelling the Preoperative Surgical Journey

Webinars

Low-Code No-Code, and Pro-Code

Innovation

Integrating clinical workflows and decisions

Webinars

Optimizing Preoperative Assessments

Webinars

Exploring the combination of BPM+ and HEDIS

Presentations

Trisotech Healthcare Feature Set (HFS)

Product

How CQL fits into BPM+ Health

Webinars

Videos

Recorded webinars

FHIR North Automatable Clinical Guidelines with Open Standards

As presented by:

John Svirbely and Denis Gagné at the FHIR North 2020 Conference

Content

Presentation

What is CDS-Hooks?

CDS Hooks is both a free open-source specification and an HL7^® published specification for user-facing remote clinical decision support (CDS). CDS Hooks can use FHIR^® to represent patient information and recommendations but is architecturally an independent specification. The CDS Hooks specification is licensed under a Creative Commons Attribution 4.0 International License.

Note: HL7^®, and FHIR^® are the registered trademarks of Health Level Seven International and their use of these trademarks does not constitute an endorsement by HL7.

The four basic components of CDS Hooks are:

Service – A decision support service that accepts requests containing patient information, and provides responses
Hook – A defined point within the client system’s workflow with well-known contextual information provided as part of the request
EHR – An electronic health record, or other clinical information system that consumes decision support in the form of services
Card – Guidance from decision support services is returned in the form of cards, representing discrete recommendations or suggestions that are presented to the user within the EHR

In 2015, The SMART team launched the CDS Hooks project to trigger third party decision support services. Today, Clinical Decision Support (CDS) Hooks is a Health Level Seven International^® (HL7) specification managed by the HL7 Clinical Decision Support (CDS) Workgroup. CDS Hooks provides a way to embed near real-time functionality in a clinician’s workflow when an EHR (Electronic Health Record) system notifies external services that a specific activity occurred within an EHR user session. For example, services can register to be notified when a new patient record is opened, a medication is prescribed, or an encounter begins. Services can then return “cards” displaying text, actionable suggestions, or links to launch a SMART app from within the EHR workflow. A CDS service can gather needed data elements through secure Fast Healthcare Interoperability Resources^® (FHIR^®) services. Using FHIR services allows CDS Hooks to provide interoperability between healthcare systems operating on different platforms.

SMART – Substitutable Medical Applications, Reusable Technologies

The SMART Health IT project is run out of the Boston Children’s Hospital Computational Health Informatics Program. Through co-development and close collaboration, SMART and FHIR have evolved together since the SMART standard enables FHIR to work as an application platform. The SMART project’s most recognized work is the “SMART on FHIR” application programming interface (API) which enables an app written once to run anywhere in a healthcare system.

SMART on FHIR (Fast Healthcare Interoperability Resources)

SMART on FHIR defines a way for health apps to securely connect to EHR systems. A SMART on FHIR application or service executes via SMART specifications on a FHIR system, extending its functionality through the use of clinical and contextual data. Together with the FHIR models and API, the SMART on FHIR specification components include authorization, authentication, and UI integration.

Who Uses CDS Hooks?

CDS Hooks support is built into all the major EHR products including EPIC, Cerner, Allscripts and athenahealth. Indeed, every type of healthcare organization from large-scale HMOs like UnitedHealth Group, Anthem, Kaiser, and Humana; to PPOs like Clover Health; to teaching hospitals like the University of Utah, Stanford Hospital, Mayo Clinic, and North Shore University Hospital (Northwell); to professional organizations like the American College of Emergency Physicians (ACEP) and the American College of Obstetricians and Gynecologists (ACOG) have access to these technologies.

Standards-Based Implementation of CDC Recommendations use the CDS Hooks interoperability framework for the integration of the guideline recommendations into EHR systems.

In the United States, SMART support is specifically referenced in the 21^st Century Cures Act of 2016. The 21^st Century Cures Act requires a universal API for health information technology, providing access to all elements of a patient’s record accessible across the SMART API, with no special effort. CDS Hooks are typically implemented as SMART applications.

What is CDS Hooks Used For?

CDS Hooks enables the creation of standard places within the EHR workflow where the EHR can issue a notification of an event that is happening. This notification can be received by an external (typically SMART) application which returns pertinent information to the EHR for display to the EHR user. In FHIR-speak, the information returned is a “card.” Cards can be of three types:

Information card – Conveys text that may be useful for the clinician
Suggestion card – Provides suggestions for the clinician
App Link card – Links to reference materials or apps

Because FHIR is an open-source standard, new hooks can be created by any interested party. Today, there are six standard “hooks,” which have been defined as part of Version 1 of the standard:

patient-view – Patient View is typically called only once at the beginning of a user’s interaction with a specific patient’s record
order-select – Order Select fires when a clinician selects one or more orders to place for a patient (including orders for medications, procedures, labs and other orders). If supported by the CDS Client, this hook may also be invoked each time the clinician selects a detail regarding the order
order-sign – Order Sign fires when a clinician is ready to sign one or more orders for a patient, (including orders for medications, procedures, labs and other orders).
appointment-book – Appointment Book is invoked when the user is scheduling one or more future encounters/visits for the patient
encounter-start – Encounter Start is invoked when the user is initiating a new encounter. In an inpatient setting, this would be the time of admission. In an outpatient/community environment, this would be the time of patient-check-in for a face-to-face or equivalent for a virtual/telephone encounter
encounter-discharge – Encounter Discharge is invoked when the user is performing the discharge process for an encounter where the notion of ‘discharge’ is relevant – typically an inpatient encounter

Prescription writing is an example you can use to visualize the way this technology works. In the EHR the event of writing the prescription triggers a CDS Hooks (order-select). The hook can be received by a patient engagement application. The application then returns a Suggestion card recommending that the patient be provided educational materials, enrollment into a support program and given an offer for copay assistance. An Information card indicating drug/drug or drug/disease adverse reactions might also be supplied.

The CDS Hooks Standard

The CDS Hooks specification and Implementation Guide describes the RESTful APIs and interactions to integrate Clinical Decision Support (CDS) between CDS Clients (typically EHRs but possibly other health information systems) and CDS Services. All data exchanged through the RESTful APIs is sent and received as JSON structures and transmitted over channels secured using HTTPS (Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS).

This specification describes a “hook”-based pattern for invoking decision support from within a clinician’s workflow. The API supports:

Synchronous, workflow triggered CDS calls returning information and suggestions
Launching a user-facing SMART app when CDS requires additional interaction

User activity inside the clinician’s workflow, typically in the organization’s EHR, triggers CDS hooks in real-time. Examples of this include:

patient-view when opening a new patient record
order-select on authoring a new prescription
order-sign on viewing pending orders for approval

When a triggering activity occurs, the CDS Client notifies each CDS service registered for the activity. These services must then provide near-real-time feedback about the triggering event. Each service gets basic details about the clinical workflow context (via the context parameter of the hook) plus whatever service-specific data are required. This data is often provided by the FHIR prefetch functionality of the CDS Hooks Discovery URL.

Each CDS service can return any number of cards in response to the hook. Cards convey some combination of text (Information card), alternative suggestions (Suggestion card), and links to apps or reference materials (App Link card). A user sees these cards, one or more of each type, in the EHR user interface, and can interact with them as follows:

Information card: read the informational text
Suggestion card: read a specific suggestion(s) for which the CDS Client renders a button that the user can click to accept. Clicking automatically populates the suggested change into the clinician’s EHR user interface
App Link card: click a link to an app (typically a SMART app) where the user can supply details, step through a flowchart, or do anything else required to help reach an informed decision

A good way to get a single-page technical overview of CDS Hooks including Discovery, Request and Response specs is to view the CDS Hooks “cheat sheet”.

Download Cheat Sheet

Trisotech and CDS Hooks

Trisotech CDS Hooks option generates CDS Hooks compliant end points for Trisotech automation services.

Learn More

CDS Hooks Discovery Endpoint

Trisotech modeling and automation platforms support the CDS Hooks 1.0 standard for processing and data prefetch in the Workflow and Decision Management modelers. Once the desired actions are modeled, publishing the models to the Service Library for automation purposes automatically provides a CDS Hooks Discovery endpoint URL for that service. That endpoint describes the CDS Service definition including the prefetch information required to invoke it according to the CDS Hooks 1.0 standard. Currently, this endpoint implements the standard CDS Hooks discovery endpoint for Patient View (patient-view).

CDS Hooks FHIR Prefetch

Using the CDS Hooks endpoint features requires preparation through entries in model inputs. Each input that will be prefetched from FHIR needs to have a custom attribute called FHIR that contains the query for the prefetch. For example, in a Workflow Data Input shape the custom attribute to prefetch the current patient information might look like this: FHIR: Patient/{{context.patientId}}

If you were using a decision model the DMN Input shape to prefetch a specific-code observation from the current patient might have a custom attribute like this: FHIR: Observation?subject={{context.patientId}}&code=29463-7

If your model is properly configured with the FHIR custom attributes and published to the Trisotech Service Library, an HTTP “GET” on the provided endpoint will result in a JSON description of the service. Each CDS Service is described by the following attributes:

Field	Optionality	Type	Description
hook	REQUIRED	string	The hook this service should be invoked on
title	RECOMMENDED	string	The human-friendly name of this service
description	REQUIRED	string	The description of this service
id	REQUIRED	string	The {id} portion of the URL to this service which is available at `{baseUrl}/cds-services/{id}`
prefetch	OPTIONAL	object	An object containing key/value pairs of FHIR queries that this service is requesting that the EHR prefetch and provide on each service call. The key is a string that describes the type of data being requested and the value is a string representing the FHIR query.

Also, the prefetched data can be “POST”ed at the base URL (removing the /cds-services from the discovery URL) to execute the service.

CDS Card FEEL Templates

Trisotech modeling also supplies modeling templates for all three types of CDS Cards. Information, Suggestion and App Link card templates are available in the FEEL language format for inclusion in Decision and Workflow models.

CDS Card Automatic Default Generation and Explicit Card Mapping

A CDS Card is automatically generated from the service unless your service is designed to explicitly output cards. By default, an Information card that has the name of the service as its summary will be automatically generated. Each service output will be added to the card detail in the format Key: Value.

For explicit mapping needs, if your model/service outputs a data type that is consistent with the CDS Card definition (required fields: summary, indicator, and source), only these outputs will be transformed to cards. It should be moted that your model/service can have one or many outputs that are CDS Cards. An output can also be a collection of cards. The data type of the output is what is considered to determine if explicit mapping is used for a service.

CDS Hooks Sandbox Testing

The CDS Hooks community provides a publicly available sandbox for services testing and all Trisotech modeling/service CDS Hooks features are tested and demonstrated using the CDS Hooks sandbox.

CDS Hooks Continuous Improvement

Trisotech is continuously improving CDS Hooks features including plans to add additional Version 1 standard hooks such as order-select, encounter-start, etc.

Trisotech

the
Pioneer

What is FHIR^®?

The HL7^® FHIR^® standard is a free and open standards framework created by Health Level Seven^® International (HL7^®) and intended to facilitate the interoperability of computerized healthcare systems. FHIR^® officially stands for Fast Health Interoperable Resources, although today, almost everyone including HL7^® uses the approved alternate name Fast Healthcare Interoperability Resources. The FHIR^® standard provides a standard data model for describing healthcare health and administrative data and a RESTful API (Application Programming Interface) using JSON, XML or Turtle to manipulate and search that data. FHIR also provides open-source tools, a collection of global FHIR servers for testing etc., and a robust community of implementors.

Note: HL7^®, and FHIR^® are the registered trademarks of Health Level Seven International and their use of these trademarks does not constitute an endorsement by HL7.

What is HL7^®?

Health Level Seven^® International (HL7^®), found at hl7.org, is a not-for-profit, ANSI-accredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information to support clinical practice and the management, delivery and evaluation of health services. The HL7 organization is supported by more than 1,600 members from over 50 countries representing healthcare providers, government stakeholders, payers, pharmaceutical companies, vendors/suppliers, and consulting firms.

Who Uses FHIR?

FHIR is a recent standard, but its usage is exploding. The standard’s evolution to include imaging resources, financial resources and clinical decision support resources has allowed for more comprehensive data analytics, precision medicine, and automated clinical pathways. Also driving the standard’s adoption is the growing expectation among patients and the new generation of physicians that healthcare data sharing should be as convenient and secure as financial services data sharing. Finally, demand for interoperability continues to grow as widespread adoption of EHR systems, changes in business models such as accountable care, and government regulations make data standardization and data sharing a standard of care.

While nearly every healthcare service organization recognizes the need for standardization of data representation and manipulation, and many have been working towards this for years, adoption of FHIR has been accelerated by government regulatory requirements and FHIR adoption by healthcare software vendors including many of the biggest industry names such as Epic, Cerner, Allscripts, athenahealth, and others. At the same time, consumer software vendors like Apple, Google, and Microsoft have embraced FHIR almost assuredly making this the standard that everyone in healthcare will adopt.

The biggest single driver for adoption of the FHIR standards comes from U.S. federal health leaders at CMS (the Centers for Medicare & Medicaid Services) and ONC (the Office of the National Coordinator for Health IT.) CMS and the ONC have used the 21^st Century Cures Act (45 CFR 170.215) to implement new final rules geared towards healthcare interoperability improvement. The 21^st Century Cures Act was signed into law in 2016 and then sent to the ONC and CMS for review. Upon review, the ONC and CMS produced two primary new rules, the Information Blocking final rule and Interoperability and Patient Access final rule. CMS is now also finalizing the Interoperability and Prior Authorization Final Rule via CMS Interoperability and Prior Authorization proposed rule.

At this time (Sep. 2021) the Interoperability and Prior Authorization final rule (CMS-9123-F) was withdrawn for review and approval by the Director of the Office of Management and Budget (OMB).

These two agencies have created final rules including the FHIR standard data Resources and APIs using USCDI – the US Core Data Set for Interoperability. The US Core Implementation is based on FHIR Version R4. In its rule, CMS requires Medicare Advantage plans, state Medicare and CHIP managed care entities, Medicaid managed care plans and qualified health plans in the federal exchanges to implement, test, and monitor openly published FHIR-based APIs to make patient claims and other health information available to patients through third-party applications and developers. ONC requires that FHIR must be the standard by which health IT developers certify their APIs. An additional rule in the interoperability space will go into effect in 2023 and require impacted payers to provide information about a patient’s prior authorizations as part of a patient access API, giving patients a better understanding of how the prior authorization process impacts their care.

Because EHR vendor’s proprietary systems have made it exceptionally difficult to exchange patient and other healthcare data, physicians and other healthcare providers, hospitals, health IT vendors, and health information exchanges are required under the Information Blocking rules to respond to any legitimate request to exchange or provide access to electronic health information (EHI) stored in their electronic health record (EHR) system. Such a request could come from a patient, another provider, a health plan seeking information for clinical purposes, or a public health agency. This effectively eliminates what is generally referred to as “information blocking” a practice that is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information.

Finally, the API Condition and Maintenance of Certification (45 CFR 170.404(b)(3)) requires software developers with health IT previously certified for technical API conformance, to provide all customers with upgraded API technology certified to this new certification criterion by December 31, 2022.

Other Major Governmental Projects Around the Globe

Almost every country has some set of interoperability initiatives associated with the FHIR standard. Some examples include:

NHS Digital (part of the National Health Service), the publicly funded healthcare system in England, – designs, develops and operates the national IT and data services that support clinicians at work, help patients get the best care, and use data to improve health and care. With the adoption of FHIR release 4 they intend to create a unified approach to interoperability across England, Scotland, Wales and Northern Ireland. This will enable consistent information flows across borders to improve health and care outcomes for all citizens.
Brazil – The IT Department of the Sistema Único de Saúde (SUS) part of the Brazilian Ministry of Health, started one of the world’s largest platforms for national health interoperability, called the National Health Data Network, which uses HL7 FHIR R4 as a standard in all its information exchanges.
Canada has significantly engaged with FHIR standards at both the national and provincial levels. National support includes the Standards Council of Canada, Canadian Institute for Health Information (CIHI), Canada Health Infoway InfoCentral (an open, group-based community platform available for clinicians, e-health representatives, vendors, developers, and others interested in working collaboratively to accelerate clinical interoperability in Canada), and the Industry Trade Association of Canada (ITAC) Health Interoperability Standards Committee. Most provincial organizations also have some FHIR-based projects through their Health Information Standards Committees (HISC) with Ontario (eHealth Ontario), British Columbia (B.C. Fast Healthcare Interoperability Resources [FHIR] Standards) leading the way for FHIR.

What is FHIR^® Used For?

Because FHIR^® provides a standard way of describing healthcare data and relationships as well as methods (standard APIs) for manipulating and searching that data, FHIR is suitable for use in many environments such as EHR-based data sharing, cloud communications, mobile phone apps, server communications in large institutional healthcare providers, and much more. FHIR defines modular components called “Resources” and those building blocks can be used to create clinical and administrative healthcare applications and systems in much the same way as other modern internet applications do at a considerably lower cost than other existing alternatives. The FHIR standard enables developers to build “browser-based” applications that allow access to data no matter what EHR system forms the user’s base infrastructure.

By using FHIR organizations can, when needed, get away from document-centric approaches like encounter notes, patient charts and faxes and expose discrete data elements as a service request. For example, a provider may not¬ want to retrieve an entire document about the patient, he or she may just want the patient’s latest complete blood count (CBC) information. FHIR is also providing new interoperability opportunities, such as direct information exchange with patients so they can more easily access their own medical record via a common web portal or mobile app, as well as with organizations in other parts of the healthcare value chain such as health insurers, life insurers and life sciences companies.

While the FHIR standard is great, it is not without some issues. The most obvious is that not every use case in health care can possibly be accounted for in a standard. Both the sheer breadth of healthcare solutions and the constantly changing clinical and pharmaceutical landscapes make the task too great. However, FHIR does have a “solution” for that. One of the original premises of creating the standard recognized the problem and states that the standard is intended to handle 80% of the use cases in healthcare. That other 20% is up to organizations with additional needs to provide themselves. In order to facilitate these additions, the FHIR standard provides a very easy-to-use “extension” capability.

Another issue is one common to both emerging and older in-place standards – versioning. More about this in the section FHIR Versions and What They Mean below ↓↓

Finally, the FHIR standard is huge and comprehensive. That makes the use of it by various countries and organizations difficult to manage and support. Many organizations need only a subset of the full standard and some organizations may store the same information in different ways and still be compliant. This has led to “Implementations” of the standard for specific interoperability purposes. The Implementation Guide Registry lists nearly 150 of these Implementation Guides ranging from the US Core Data Set for Interoperability (USCDI). Other guides include the International Patient Summary, the Australian Base, the US Drug Formulary, Genomics Reporting, and many more. Because Extensions and API access can be part of the implementation guide, some Implementations even specify things like “read only” access by limiting the acceptable “Interactions”.
See The FHIR Standard below ↓↓

The FHIR^® Standard

Because worldwide healthcare is very diverse, the full FHIR standard is large and comprehensive. The intended scope of FHIR is broad, covering human and veterinary clinical care, public health, clinical trials, administration, and financial areas. It is designed to enable information exchange that supports providing healthcare for global use and in a wide variety of architectures and environments. The FHIR standard is implemented on top of the HTTPS (HTTP Secure) protocol and builds on and adapts modern, widely used RESTful practices to provide interoperability for integrated healthcare services across a wide range of teams and organizations. The standard is also licensed under Creative Commons “No Rights Reserved” license which means it is free to use.

While described as five components (see What Is FHIR? above ↑↑), the FHIR standard really contains two primary components, Resources and APIs. From an operational perspective, HL7’s internal standards development and governance processes determine what a Resource is, and which Resources exist. In addition, the FHIR specification also provides a mechanism for contextualizing resources for specific needs within specific bounds called Profiles. The FHIR framework also contains a verifiable and testable syntax, a set of rules and constraints, methods and interface signatures for “FHIR-aware” APIs, and specifications for the implementation of a server capable of requesting and delivering FHIR business objects.

Resources

Resources are instance-level representations of healthcare entities – a collection of information models that define the data elements, constraints, and relationships for “business objects” that are relevant to healthcare such as Patient, Procedure, Encounter, Observation, Order, etc. There are currently 145 defined Resources and over 50 more “proposed/expected” to be built listed on the FHIR website.

All Resources have these five features in common:

A URL that identifies the Resource (example https://example.com/path/Patient/98635402)
Common metadata (includes Logical ID [such as Patient ID] explicitly represented in the URL, version ID, and last modified date.)
A human-readable XHTML summary
A set of defined data elements – a different set for each type of Resource
An extensibility framework to support variation in healthcare

Each Resource type defined in FHIR has a manager (or “entity set”) that lives at the address [FHIR Server]/[type]where the [type] is the name of the Resource type. For instance, the Resource manager for the type Patient will live at: https://server/path/Patient. Each Resource instance also carries a human-readable text representation using html as an alternative contingency display option for clinical safety. This is often used for complex clinical information where existing systems currently use simple textual/document-based approaches.

Extending and restricting Resources (collectively known as ‘profiling a Resource’) is done with a “StructureDefinition” Resource, which is a statement of rules about where extensions are used and/or how the data elements in a Resource are used.

For those of you less familiar with information models and data structures it might help to visualize each Resource as one of 145 single spreadsheets (Patient, Observation, Encounter, etc. tabs at bottom) in a spreadsheet file (perhaps Resources.xslx) where the data fields like Name, Gender, Birthdate, Patient Identifier, etc. are columns for the Patient spreadsheet. Each Resource has different data and relationships so the columns for each Resource would be different. Finally, think of each instance (Patient Bill Bloggs; ID 98635402) as the rows. In reality, the data models are far more sophisticated than a spreadsheet and commonly include relational links to other Resources.

APIs – How FHIR Data Exchange is Implemented and Managed

By definition, an API (Application Program Interface) is a collection of well-defined interfaces for interoperating between two applications. Although not required (implementers can also use GraphQL), the FHIR specification targets RESTful interfaces for API implementation. For manipulation of Resources, FHIR provides a REST API with a rich but simple set of Instance, Type, and System interactions that include:

Create – Create a new Resource with a server assigned id = POST https://example.com/path/{resourceType}
Read – Read the current state of the Resource = GET https://example.com/path/{resourceType}/{id}
Update – Update an existing Resource by its id (or create it if it is new) = PUT https://example.com/path/{resourceType}/{id}
Delete – Delete a Resource = DELETE https://example.com/path/{resourceType}/{id}
Search – Search the Resource type or all Resources based on some filter criteria = GET https://example.com/path/{resourceType}?search parameters
History – Retrieve the change history for a particular Resource or all Resources = GET https://example.com/path/{resourceType}/{id}/history

There are also more comprehensive interactions that include Batch/Transaction, Operation, Vread, Patch, and Capabilities. In addition to these interactions, there is an operations framework, which includes endpoints for validation, messaging, and documents.

Extending and Restricting the API – defining a set of desired behaviors – is done via the CapabilityStatement Resource which lists the REST interactions (read, update, search, etc.) that a server provides or that a client uses, along with some supporting information for each. The only interaction that servers are required to support is the Capabilities interaction itself – to retrieve the server’s CapabilityStatement. Beyond that, servers and clients support and use whichever API calls are relevant to their specific use case. FHIR servers can also provide additional operations that are not part of the FHIR specification. The Conformance Resource supports defining what OperationDefinitions make use of particular names on an endpoint. Implementations are also able to extend the FHIR API using additional content types. For instance, it might be useful to read or update the appointment resources using a vCard-based format. vCard defines its own mime type, and additional mime types can safely be used along with those defined in the FHIR specification.

Managing Variability

The FHIR specification describes a set of base resources, frameworks and APIs that are used in many different contexts in healthcare. Recognizing the wide variation between different geo-political jurisdictions and segments of the healthcare industry with no central authority to impose common business practices, the intent of the standard was to provide coverage for 80% of the common use cases and define a simple framework for extending the existing Resources and describing their use with Extensions and Profiles.

Profiles can define:

Rules about which Resource elements are or are not used, and what additional elements are added that are not part of the base specification
Rules about which API features are used, and how
Rules about which terminologies are used in particular elements
Descriptions of how the Resource elements and API features map to local requirements and/or implementations

By default, all systems can read all Resources, but applications can add more control and meaning using Profiles. Many healthcare contexts require extensive local agreements between parties to make sure data exchanges are accurate and complete. Healthcare variability can also be seen where the same information may be represented differently and with different levels of detail, granularity, and nesting by exchanging parties. For example, in some cases a blood pressure measurement may be just a simple observation, a vital sign measure, while in other cases it can be a rich set of highly defined data that includes things like controlled vocabularies for posture, exercise, etc. The Resource types defined in the FHIR specification focus on the general, common use cases. Richer and more specific content can be supported and standardized by defining “profiles” on the base Resource types.

FHIR Versions and What They Mean

As standards change over time and presumably get better, those currently using previous versions of the standard face hard choices about how to, or even if they should, change production-level systems to conform. This is especially problematic when specific versions of the standard get included in contracts and even law as has already happened with some United States laws (see Who Uses FHIR above ↑↑).

Today, the current standard is FHIR Release 4 (FHIR R4) which now contains fully normative content for many Resources. As you might see from the milestones below, work on many projects including those described below were undertaken at the standard’s earlier development levels.

Here are some major milestones in the FHIR development timeline:

Dec 27, 2018	4.0.0	Release 4 (1^st Normative Content + Trial Use Developments) also called R4
Feb 21, 2017	3.0.0	Release 3 (STU – Standard for Trial Use) also called STU3
Oct 24, 2015	1.0.0	DSTU2 (Second Draft Standard for Trial Use)
Sept 30, 2014	0.0.82	DSTU1 (First Draft Standard for Trial Use)

Some early projects using the FHIR standard of note include:

Dec. 2014 – The Argonaut Project is a private sector initiative to advance industry adoption of modern, open interoperability standards. The purpose of the Argonaut Project is to rapidly develop a first-generation FHIR-based API and Core Data Services specification to enable expanded information sharing for electronic health records and other health information technology based on Internet standards and architectural patterns and styles.
Jan. 2018 – The Da Vinci Project stakeholders are industry leaders and health IT technical experts who are working together to accelerate the adoption of HL7 Fast Healthcare Interoperability Resources (HL7^® FHIR^®) as the standard to support and integrate value-based care (VBC) data exchange across communities.

Trisotech and FHIR^®

Trisotech supports the FHIR standard in several ways including the FHIR R4 Accelerator, direct connections to FHIR Terminology Servers, Healthcare Value Sets and Code Systems lookup/auto-completion support, extended Healthcare run time automation support and Terminology/Definition Linking in Models.

Trisotech offers various FHIR modeling accelerators and the Digital Automation Suite can integrate with various FHIR servers.

Learn More

The FHIR R4 Accelerator – FHIR at Your Fingertips

Trisotech provides pre-defined and pre-populated FHIR R4 Resources Accelerator. This Accelerator provides predefined FHIR Resource structures in the form of FEEL data types for use in the Decision, Workflow and Case modelers, and the Discovery Accelerator. Adding a FHIR Resource as a FEEL data type to a model is a simple drag and drop operation. The FHIR Resources in the Accelerator are organized by category (e.g. Individuals, Diagnostics, Medications, etc.) and sub-category (e.g. Individual->Patient, Provider, etc.) reflecting the FHIR standard Resource Index for quick reference. Specific Resources can also be found through the Trisotech Accelerator search function. Once a FEEL data type has been added to a model, all the fields in that structure are available for use in the modelers. In for example, clinical decision tables and other DMN logic, FEEL statements for condition expressions in sequence flows (decisions) in Workflows, etc.

FHIR Resource FEEL data types as input data in DMN models, for example, can be used “by reference” meaning there is only a single modeling source for the definitions thus locking them so they can only be administered using specific privileges. This addresses separation of concerns issues. Multiple Accelerators can address custom Implementations and differing version support since accelerators can be copied and/or changed per user needs. The use of this Accelerator can easily save hundreds of hours of work for a healthcare organization adopting FHIR.

FHIR Terminology Server Support

The Trisotech modelers and automation functions support a direct connection to your FHIR Terminology Server of choice. The FHIR Terminology server settings are configured in the Administrator interface. Many large healthcare organizations have their own terminology servers and there are numerous publicly accessible terminology servers, as well. Each Terminology Server supports a specific set of operations defined by the service provider on the RESTful interface (APIs). Technically, to achieve this these servers typically provide ValueSet and CodeSystem FHIR Resources via expanded FHIR operations defined by OperationDefinition Resources.

Trisotech makes extensive use of these Resources by connecting Terminology Servers to the Knowledge Entity Modeler (KEM) for Terms definitions and supports linking and auto-completion lookups from those servers for Decision, Workflow and Case Modelers.

FHIR Value Set and Coding Systems Lookup and Auto-completion Support

Each Term in a KEM model has a tab for Healthcare coding which offers auto-completion of codes using ValueSets and CodeSystems from a FHIR Terminology server. In the ValueSets section you can search for ValueSets by keyword in the search field (such as “Diabetes”) to get a list of ValueSets available. Select the result you want to add, and it will appear in the Coding list auto filling the 3 fields Coding system, Code and Display name. You can add more than one code (i.e. a list) to support multiple codes for more detailed specifications or in support of multiple coding systems such as ICD9/10, SNOMED, LOINC, CPT, etc. Once a ValueSet has been added to the KEM model, a suggestion dropdown which will appear when you type content into it. The suggestions will be filtered from every coding system you already have in your current model, and it will also search on your FHIR Terminology Server for corresponding ones not yet added. Finally, the user can put a coding system URL directly into the Coding System field and the modeler will automatically replace the URL with the coding system name. (e.g. http://snomed.info/sct sets SCTUSX as the Coding System Name.

FHIR Term Linking in Model Shapes

Terms used in the Name and Description fields of model shapes can be linked to Terms created in the Knowledge Entity Modeler (KEM). This means you have direct access to organizational vocabularies (Terms) that can be defined and maintained by connections to FHIR Terminology Servers. Using your own organizational Terms associated with specific Value Sets and Code Systems ushers in a new era in conformance and a powerful way to specify and limit coding system use across the entire organization.

Healthcare-specific Extended FEEL Functions and FHIR

New healthcare-specific extended FEEL functions (“healthcare codes”, “healthcare term codes”, and “healthcare code in term”) are also available in the modeler menu and to access KEM Terms or coding system codes (e.g. ICD-10, LOINC, etc.) in the automation engines at run time. These are typically used with Decision Models (DMN) to determine if specific healthcare codes defined by a Term in your Knowledge Entity Model or a specific code or term in an external coding system terminology server are present for a Patient. This makes determining a specific condition in a Patient (such as “Diabetes” defined via codes your organization supports) visual and very simple to understand in clinical decision models and clinical pathway workflow models.

Trisotech’s powerful combination of extended Healthcare FEEL functions, FHIR Terminology Server support and direct URL support for other terminology servers makes decision making in DMN models and sequence flows in Workflow models available at runtime through the Trisotech automation engines.

Resources

Related to FHIR

Trisotech

the
Pioneer

Decision Model Creation and Deployment Using DMN

Abstract

Decision Model and Notation (DMN) is a standard established by the Object Management Group (OMG) allowing visual representation of Business Rules content and logic. This representation is executable – i.e., the decision model can be deployed in an execution environment and be invoked to deliver decisions in real time. A major healthcare provider network was an early adopter of DMN for implementation of Clinical Decision Support. In this session, we share our experiences in the creation and deployment of DMN models. This webinar demonstrates:

Creation and Testing of a DMN Model for LACE Score – A risk score for readmissions

Illustration of DMN patterns via reusable functions and knowledge modules that enable re-use of commonly occurring CDS logic patterns

Stepping through the explanation provided by a DMN model for a given decision support inference

Search for previously created decisions – and reuse of a pre-existing decision in a new model

Re-use of pre-created Value Sets across multiple Decision Models

The ability to integrate the invocation of a DMN model with an EMR/HIE using CDS Hooks/CDS Cards and display the explanation using a SMART on FHIR application

Featured Panelists

Vipul Kashyap, Clinical Information Systems/Enterprise Information Architect

Videos

Recorded webinars