FHIR : Joint SOA and ITS
Goals of the Section:
Introduction
There is a potential misconception that FHIR and Service-oriented architecture are exactly the same thing, however they are not. This section seeks to clarify what it means to apply SOA principles and specifications within a FHIR environment/implementation, and the converse. The use of SOA as an established xxxxx has a means of encapsulating behavior and has an associated methodology for use in specific domains. Because the FHIR specification is still at an early stage of development, similar work within FHIR is presently in its infancy.
The potential benefits of FHIR is to leverage previous work done in SOA environments to allow FHIR to leapfrog in capabilities so that those whom are developing FHIR implementations will not have to re-invent these wheels.
One of FHIR’s greatest successes lies in its simplification in implementation. It does not contain out-of-the-box behavior for workflow, behaviors, etc., or well defined APIs. The common set of patterns that the SOA specifications provide can be leveraged to facilitate implementation of complex behavior both easier and more consistent than would be achieved without its use.
Applying Business Context – Marrying SOA and FHIR
Ø Sequencing
o Identifying and supporting common patterns based upon domain expertise
o Composition of multi-step processes (e.g., deterministic flow)
o Orchestration of complex, dynamic processes (eg., nondeterministic flows)
o Ability to support non-sequential workflow, such as care record management
o Ability to support dynamic workflows involving human intervention
Ø Persistence
o Talk to “white box” vs “black box”
o Discussion of State. FHIR is (nominally) stateless. SOA is often stateless, but can support stateful [Note: this one needs a delicate touch – for example, the SOA Services themselves are stateless, but the orchestration is not]
o SOA provides guidance around data persistence, durability, and expectations around support for the data lifecycle
Ø Business Principles [Follow up with Craig]
Relating SOA and FHIR
o Differentiation Table(s)
o SOA vs WS* vs RESTful
<need to elaborate in the prose some of the key points that don’t naturally suit to the table. The idea that services form an authoritative responsibility and encapsulate that. That services have and can manage completeness and context so as to prevent ‘cherry picking’ just specific data elements.>
Table 1. Contrast of Implementation Approaches
Short Description / #1 FHIR + REST(RESTful FHIR) / #2 FHIR + WS* / #3 FHIR + SOA Pattern / Comments
Supports transactional Integrity / Transactions may involve multiple steps composed together into a single unit / ◒ / ◒ / ● / Transactional integrity can be supported in each of the alternatives, but it is not an inherent outcome and requires additional work by the implementers for #1, #2
Supports stateless transactions / ● / ● / ●
Supports “loose coupling” / ◒ / ◒ / ● / Loose coupling minimizes dependencies between the calling system and responding system, removing the burden of understanding how the other works.
Use of FHIR Resources as Data Payload / Data payload includes input data as well as data returned. / ● / ● / ●
Provides for service registration, discovery, etc. / ◒ / ◒ / ● / This is part of SOA specification and customary in implementations. For the others it is up to the approach.
Provides support for targeted update/ CRUD operations (resource-oriented operations) / ● / ◒ / ◒
Suitability for atomic transactions / ● / ◒ / ◒ / REST is ideally suited for point access or updates of specific data elements/resources. CRUD support in WS* and SOA must be specifically addressed/coded.
Suitability for composite transactions / ◒ / ● / ● / Beyond CRUD operations, functionality is not well defined within REST technology stack.
Table 2. Inherent Capabilities related to Workflows and Patterns
Short Description / #1 FHIR + REST(RESTful FHIR) / #2 FHIR + WS* / #3 FHIR + SOA Pattern / Comments
Support for dynamic adjustment in workflows / ○ / ◒ / ●
Supports ability to batch multiple operations / ◒ / ◒ / ●
Provides for management of data coherence (e.g., Deadlocks, transactions) / ○ / ○ / ●
Provide support for orchestration languages (BPMN, SOAml) / ○ / ◒ / ● / FHIR does not inherently serve as an orchestrator of calls, but can serve as a participant within an orchestration.
Orchestration
o Introduce what orchestration is and how it relates to FHIR
o Difference between orchestration for business process (human interventions, machine based, etc. Multistep, may have long timeline) vs. orchestration for service composition (entirely automated, short timeline).
o Relate orchestration to business need/business case
§ Highlight that an instance of an orchestration is realization of a use case/”story”
§ Cite Care Management as an example.
o Introduce established techniques, ‘labels’/patterns & Design Patterns (e.g., Workflow management)
§ Decision Support, focused on Order Service, as an example of orchestration
§ Highlight that this can be done in FHIR exclusively, but that all of the steps and state management would have to be managed by hand.
o Relationship with FHIR Batch capability
§ (Need to chase down what FHIR Batch provides. Invite FGB to call?)
Approach Alternatives (examples of HSSP portfolio, such as Order Service and RLUS)
o Simplify service interface to allow full support in FHIR
§ Mirroring behavior of SOA using exclusively FHIR technology stack
§
o “Service as a Black Box”, FHIR payload
§ “Classic” SOA over SOAP, using FHIR resources as paramters
§
o Process and Delegate Pattern
§ Hybrid: Option 1: FHIR call to FHIR Server which makes subsequent SOA Call, such as returning pointers to resources as payloads.
§ Hybrid: Option 2: Service is running external to FHIR server and returns FHIR compliant payloads
Implementation Considerations
WE ARE HERE!!!
o “SOA in a FHIR Environment”
(e.g., “SOA techniques to support RESTful FHIR implementations”)
§ Error Handling – Identify likely error conditions or exceptions based upon prior SOA work, and establish infrastructure within FHIR environment to manage those exceptions.
§ Transactional Integrity
§ Security (identity, access control, etc.)
§ Data Coherence
§ API/Interface Design
· Loose coupling; encapsulation, etc.
· “Who owns the deadlock problem” example
o “FHIR in a SOA Environment”
(e.g., “applying FHIR into Enterprise Solutions”)
§ Error Handling – error handling in SOA is defined. Would not anticipate changing error management for FHIR except for codes associated with FHIR payload.
§ Transactional Integrity
§ Security (identity, access control, etc.)
§ Data Coherence
§ API/Interface Design
· Loose coupling; encapsulation, etc.
· “Who owns the deadlock problem” example
Ø “FHIR” and forget
o
Ø Benefits of Services
o B
Ø Let’s support encapsulated behavior and complex behavior
Ø Clarify relationship between “FHIR Services” and “SOA Services”
Ø Clarify point of view relating to technology stack / PSMs
Action Items
Ø Sections of FHIR Specification need to be reviewed for accuracy
Ø Use of “REST operations” as they equate/relate to Service
Ø Need for a FHIR on SOA Design Guide