Understanding User Needs for Interoperability: Standards for Business Cases in eHealth

By Anna Orlova, PhD; Karima Bourquard, PhD; and Charles Parisot

AHIMA, in collaboration with Integrating the Healthcare Enterprise (IHE) International, has been publishing the findings of the Use Case Task Force in a series of articles in the Journal of AHIMA’s Standards Strategies section. The first article in this series published in the Journal’s June 2017 issue provided definitions for the concepts that define user needs for the adoption of health information technology (HIT) to support HIT systems interoperability and information sharing across systems.¹ These concepts are business cases (breakthrough areas), use cases, realization scenarios, technical use cases, and storyboards. This article, the second in the series, presents the hierarchy between concepts, illustrates the hierarchy using the examples of assembling the artifacts in the domain of clinical imaging, and describes the approach and standards for building the business cases.

Hierarchy Between Concepts

Figure 1 below presents the hierarchy between concepts of business cases (breakthrough areas), use cases, realization scenarios, and technical use cases with implementation options (IHE integration profiles). The June 2017 article provided specific examples of these concepts in the domains of radiology and immunization.² Figure 2 below illustrates the hierarchy with specific instances of the concepts in clinical imaging.

The business case “clinical imaging” is widely developed due to the development of picture archiving and communication systems (PACS) and the need to integrate images and their descriptions into electronic health record (EHR) systems.

Two use cases depicted in Figure 2 include “Hospital imaging workflow” and “Access to images.” They are focused on the realization scenario of mammography (prevention, diagnostic and treatment) as follows:

• Hospital imaging workflow from the patient administration management (scheduling, registration, admission) in care setting, the radiology test order, the testing performed, the images archiving, the description of the mammography test results in the report and result reporting, and privacy and security considerations needed for information exchanges
• Access to images and test reports by patients or by providers via information sharing between information systems and/or mobile applications

For those two use cases, Figure 2 provides examples of realization scenarios and their related technical use cases and set of implementation options (IHE integration profiles). The IHE profiles provide detailed specifications for describing the integration capabilities between systems by coordinated implementation of communication standards such as DICOM, HL7, W3C, etc. (visit www.ihe.net/profiles/ for more information). The latter comprise the standards-based technical interoperability infrastructure needed to securely share information between a hospital’s EHR and PACS as well as patients’ and providers’ HIT applications. Figure 2 also shows that realization scenarios are reusing common technology described in the technical use cases and their implementation options.

Building a Business Case

The hierarchy shows that business case is the first artifact in defining the need for HIT application in a healthcare organization. It is aligned with the organization’s eHealth strategy and business goals. Business cases are built based on the business process analysis. A business process is defined as a series of activities and logic that form a repeatable pattern. Some processes are very dynamic or ad hoc, never running the same way twice; others are very well-defined and run exactly the same way every time. Typically, organizations want to apply business process automation where it adds the most value (i.e., to a highly repeatable process with high business value). Repeatable processes such as billing and insurance claims handling were the first ones automated in healthcare.³

The business case document is developed as the result of the business process analysis. Table 1 below presents the outline for the document with the definition of each component.⁴

Standards for Defining Business Cases

For many years, companies attempted to automate business processes and it became clear over time that standardization of business process automation was needed. Graphic modeling tools were developed for representation of business processes, such as flowcharts. Graphic modeling used for a visual representation—together with the metadata to describe the activities in the process and the business rules for the decisions in the process—is called a workflow or process model.

OASIS, the Organization for the Advancement of Structured Information Standards (www.oasis-open.org), is a not-for-profit consortium of over 5,000 members that developed the eXtensible Markup Language (XML) standard, and also developed the Web Services Business Process Execution Language (WS-BPEL), an execution language to describe the behavior of business processes in a standards-based environment. Processes can use Internet services to invoke business functions, and the process itself can be exposed as a web service. A web service can be described by Web Services Definition Language (WSDL). WS-BPEL defines the end-to-end business process including the way for “stateful” long-running processes between different business systems and a format for an XML document. Stateful means that a computer or program is designed to track and remember interactions with other programs. The language describes the syntax for the elements of a process, such as the partner links, service invocations, data variables, correlation sets, etc. An extension to WS-BPEL called BPEL4People defines an approach for extending WS-BPEL to support scenarios where people are required as part of the business process. Another aspect of BPEL4People is WS-HumanTask, which defines how a task for a person can be invoked as a web service.

OMG, the Object Management Group (www.omg.org), is an international open membership not-for-profit computer industry consortium to develop enterprise integration standards. OMG developed the Business Process Modeling Notation (BPMN) to provide a standard notation for the process diagram. Using such a notation ensures consistency, so that no matter who created the diagram, the same icons are used to represent the same objects. A second goal of BPMN is to define how the elements of a BPMN diagram should map to WS-BPEL.

WfMC, the Workflow Management Coalition (www.wfmc.org) developed the XML Process Definition Language (XPDL) to have an XML format for the storage of BPMN diagrams. If different vendors use XPDL as their file format, they can easily exchange process models. XPDL is complementary to WS-BPEL; it is a file format to promote the interoperability of tools. It captures all of the attributes of each BPMN object and metadata, storing them in a standards-based format. As with WS-BPEL, XPDL allows vendors to add in their own proprietary extensions.

Working with the organization’s staff, a business analyst creates a process model using BPMN as the basis of the visual aspects of the process, ensuring consistency in notation. The file for the model is stored in XPDL format. An IT specialist takes the XPDL file and imports it into a modeling tool to see the same visual representation in BPMN as the business analyst. The IT specialist exports the model into WS-BPEL, then adding in additional technical attributes for execution. So, BPMN is what process looks like; XPDL is how it is stored; and WS-BPEL is how it is run.

For more information about the AHIMA-IHE collaboration, please contact Anna Orlova, PhD, at anna.orlova@ahima.org.

Notes

^[1] Bourquard, Karima, Anna Orlova, and Charles Parisot. “Understanding User Needs for Interoperability: Defining Use Cases in eHealth.” Journal of AHIMA 88, no. 6 (June 2017): 42-45.

^[2] Ibid.

^[3] Fasbinder, Marc. “Business process standards, Part 1, An introduction.” IBM developerWorks. October 17, 2007.

^[4] Public Health Informatics Institute (PHII). “Taking Care of Business.”

Anna Orlova (anna.orlova@ahima.org) is senior director of standards at AHIMA. Karima Bourquard (karima.bourquard@in-system.eu) is engineer-consultant at IN-SYSTEM, France, director of interoperability at IHE-Europe, Belgium and co-chair of IHE-France. Charles Parisot (Charles.parisot@ge.com) is the manager of standards and interoperability at GE Healthcare, and chair of IHE-Services at IHE-Europe, Belgium.