DSTU2 Ballot Source
This page is part of the FHIR Specification (v0.5.0: DSTU 2 Ballot 2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions 
This page and the other FHIR/SOA/Services page will be reconciled and collapsed to a single page during ballot reconciliation.
This section clarifies what it means to apply SOA principles and specifications within a FHIR environment/implementation, and the converse. The use of SOA is an established discipline and provides a means of encapsulating behavior. Because the FHIR specification is still at an early stage of development, similar work within FHIR is presently less well developed.
The potential benefit of SOA to FHIR is leverage of previous work done in SOA environments thus allowing FHIR to leapfrog within SOA capabilities so that those developing FHIR implementations will not have to re-invent these wheels.
One of FHIR's greatest successes lies in its simplification of implementation. It does not currently 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 make implementation of complex behavior both more easily and more consistently than would be achieved without its use.
FHIR offers a highly flexible framework for interoperability that can be deployed and used in a varity of different ways. This flexibility can become a liability because systems designed for different patterns of use cannot easily interoperate. SOA principles can be used to provide an overall framework that leads to deployment and consistency. SOA provides guidance for how components interact, how to partition responsibilities, and how to manage workflows among different parts of systems, all of which have potential utility in FHIR implementation settings.
Note: FHIR is still under development, and this section is still under development too.
If I am doing FHIR, why do I care about SOA? Isn't SOA just a technology, and isn't REST either more current or just what Web Services uses anyway? Isn't REST better than SOAP? These are very common questions that surface time and time again among implementers. FHIR is not a natural replacement for Service-oriented Architecture (SOA). Nor is SOA �better than� or �worse than� FHIR. If we consider both of these as approaches, there are natural complements which result in benefits from applying SOA techniques to FHIR.
One of FHIRs tremendous strengths lies in its accessibility, ease of implementation, and flexibility to be applied in a number of different situations without encumbering implementations with excessive burden. For any one implementation, these strengths stand on their own, but when multiple implementations need to work together, the likelihood of having multiple different (and incompatible) FHIR-based solutions to the same problem increases, resulting in inconsistency and interoperability challenges.
This section assesses different contexts to allow implementers to make informed decisions about the degree of impact of applying SOA techniques and to assess potential benefit for specific situations. It will identify the situational factors to consider, and the elements of the SOA discipline that can be applied for more effective FHIR implementation, providing a roadmap on how to optimize your implementation toolkit to make you and your team most effective.
There are a few fundamental aspects of systems distribution that illustrate the principal differences between SOA and FHIR. At its core, FHIR is based upon the elemental capabilities of Create, Read, Update, Delete (CRUD), allowing access to resources where interaction is primarily based upon these operations. Of note, multi-step or complex processing levies requirements upon the calling, client application.
The objective of this ballot section is to identify areas of relative strength and weakness for both FHIR and SOA, and to identify where there are implementation benefits in applying techniques spanning the two approaches. This analysis was conducted from two perspectives:
SOA in a FHIR Environment considers the benefits of applying SOA patterns and best-practices to a FHIR implementation community. In these cases, developers are faced with implementation decisions that have the potential to benefit from existing case studies, design patterns, or guidance that may either help provide consistency among FHIR implementations, or which may address gaps - either known or unidentified - resulting from implicit assumptions around a FHIR implementation.
FHIR in a SOA Environment considers the implications of using FHIR in a large, established enterprise that has or is making investments in SOA infrastructure. In these cases, shared services, enterprise policies, and existing infrastructure is common, and FHIR implementations would need to fit within the fabric of that environment.
It merits mention that not every FHIR implementation benefits from SOA, and vice-versa. The goal of this section is to help implementers navigate based upon their specific considerations to help determine if and to what extent these approaches provide benefits.
In order to best determine the overlaps, synergies, and alignment points between FHIR and SOA, the following comparative analysis has been conducted. The table identifies a number of qualities associated with distributed systems integration, and subsequently provides a qualitative scoring as to the �fitness� of three different implementation approaches to support that quality. The scoring is deliberately subjective as the intention is to help readers navigate to those alternatives best suited to a given situation. The implementation approaches are broad categories most exemplary of FHIR implementations, specifically:
FHIR + REST, also referred to as RESTful FHIR, which is the predominant approach for implementing FHIR today.
FHIR + WS* represents FHIR implementations using the web services stack as the communication protocol instead of REST. This would include use of FHIR resources as payload parameters in SOAP calls, for example.
FHIR + SOA Pattern illustrates the impact of applying interaction patterns, exception handing and role definition, guided by SOA practices, atop an implementation technology (SOAP, REST, or others).
Contrast of Implementation Approaches
| Solution Quality | Short Description | #1:FHIR + REST (RESTful FHIR) | #2 FHIR + WS* | #3 FHIR + SOA Pattern | Comments |
| Support of transactional integrity | Transactions may involve multiple steps composed together into a single unit | ◒ | ◒ | ● | Transactional integrity is not assured in #1 or #2 but can be hand-coded. #3 assures that this is addressed |
| Support of stateless transactions | Transactions are independent and do not require supporting context | ● | ● | ● | Each of the implementation approaches are capable of supporting stateless processing |
| Support of "loose coupling" | Minimum of dependencies between the calling and responding system; reduces burden on client to from managing context of interaction with service | ◒ | ◒ | ● | The notion of "loose coupling" is fundamental to SOA and inherent in that architecture. Loose coupling can be supported by FHIR, but it does not innately do so |
| Use of FHIR Resources as Data Payload | Representation of FHIR resources for use as query or return parameters | ● | ● | ● | Data payload includes input data as well as data returned |
| Support of Dynamic Service Discovery | Provides for service registration, search, discovery, and late binding | ◒ | ◒ | ● | This is part of SOA specification and customary in implementations. For the others it is up to the approach |
| Provides resource-oriented operations | Supports ability to create, read, update, delete resources; | ● | ◒ | ◒ | Direct access to resources/data revisions in a strength of REST and FHIR. Direct access to fine-grained transactional operations are generally not supported within SOA |
| Suitability for atomic transactions | Fitness to support fine-grained transactions, such as data access or targeted update | ● | ◒ | ◒ | REST is ideally suited for point access or updates of specific data elements/resources - functions discouraged within SOA and WS* |
| Suitability for composite transactions | Fitness to support complex transactions: context-sensitivity, multi-step workflows, etc. | ◒ | ● | ● | SOA provides for complex event processing, multi-step sequencing, orchestration |
Sequencing of events, particularly when those events involve orchestration of complex or dynamic processes, can benefit from the application of SOA techniques and patterns. This is common where multi-step processing is involved, and particularly important when adjustments to a process flow can be made based upon situational context. SOA design patterns are frequently used to govern interactions for dynamic processes, non-sequential workflows, or dynamic workflows involving human intervention and/or consideration of external factors as part of processing. The ability to model interaction patterns using languages such as SOAml, and to define roles and role interactions, are tools that may be useful to FHIR development in these circumstances, and would be indicators signaling that SOA has the potential to add value to a FHIR implementation.
SOA design principles can provide guidance to a FHIR implementer resulting in reduction of co-dependencies between components, promoting "loose coupling" and minimizing potential impacts resulting from changes to inner workings of one component adversely affecting others. (For those familiar with the term, this encourages "black box" implementation).
SOA provides guidance around data persistence, durability, and expectations in support of the data lifecycle.
These considerations are summarized in this table:
| Capability | #1:FHIR + REST (RESTful FHIR) | #2 FHIR + WS* | #3 FHIR + SOA Pattern | Comments |
| Supports dynamic adjustment in workflows | ○ | ◒ | ● | In a native FHIR environment, this must be done by hand. The WS* stack provides for some interaction patterns, but limited. Use of formal notation (BPMN) and service orchestration is most robust option |
| Supports ability to batch multiple operations | ◒ | ◒ | ● | FHIR Batch allows for concatenation of multiple process steps. SOA Orchestration allows for fine grained control, grouping and sequencing of multiple operations |
| Provides for management of data coherence (e.g., Deadlocks, transactions) | ○ | ○ | ● | SOA principles define data governance, assigning responsibility for all data management within a service contract |
| Provide support for orchestration languages (BPMN, SOAml) | ○ | ◒ | ● | SOA applys a systematic framework for orchestration using industry accepted formalisms, avoiding costs and complexities associated with an ad-hoc approach |
Orchestration is a term typically used within SOA to describe the steps, sequencing, and dynamic adjustment of workflow to meet a process need. Orchestrations may be entirely automated and fulfilled in a short timeline, or longer and multistep in fulfillment of a business process that may involve manual steps and human intervention. In the context of FHIR implementation, orchestration would refer to the sequencing of collections of FHIR (or service) calls that are used in tandem to fulfil a specific need.
Orchestration is neither natively supported nor unsupported in FHIR, save the availability of the FHIR Batch mode which allows for some degree of compounding of operations. In a SOA environment, orchestration is typically realized by documenting in some formalism, such as Business Process Modeling Notation (BPMN), a sequence of steps and flows, and inherent logic or decision-points affecting that flow. An engine is then capable of executing the process flow, receiving inputs during execution to adjust or adapt those processes based upon situational need as part of delivery fulfillment.
There are many examples where this approach is advantageous. For example, in a Care Management situation, test results, current problems, chief complaint, and potentially even resource availability might affect subsequent steps in fulfilling a care plan. Based upon changes to any of these factors, the sequence of calls and ultimately the systems or FHIR servers involved would vary. The role of automated clinical decision support is another example that naturally ties to workflow orchestration, adjusting care pathways based upon patient evaluation and affecting process flows within a health system.
At present, to support this complexity within a FHIR setting without the use of SOA tools, these flows would need to be manually coded, either by having a directed sequence of calls, or by creating an independent capability effectively acting as an orchestrator. This can be supported within FHIR exclusively, but all of the steps and corresponding state management would need to be done by hand. FHIR Batch provides some of this capability, allowing for aggregation of multiple steps, but does not necessarily support the event processing needed in complex workflow situations.
Recognizing that there are situations where the coming-together of FHIR implementation and SOA techniques are advantageous, there are several implementation approaches available. Note that the selection of which approach is advantageous for any given situation will depend upon a variety of factors: existing legacy implementation and available APIs (particularly for interfacing applications), the strategic direction/IT roadmap of the organization, and so on.
It is important to note that electing to apply SOA patterns to FHIR implementation does not fundamentally change the nature of what is being implemented. Applied correctly, it results in minor adaptation to coding and interface design resulting in enhanced consistency across implementations as well as enhanced interoperability and robustness.
Should the above evaluation factors result in a determination that FHIR/SOA guidance is useful, this section will describe specific implementation considerations to take into account. Please note that it is particularly important to determine which high-level categorization best fits your situation. For each high-level alternative, we present several implementation factors affected by the use of FHIR combined with SOA in that context. These "dimensions" apply to any implementation, and are described in the context of each category to illustrate their implications and differentiate among the approach alternatives.
We anticipate that future guidance will mature this thinking, providing code examples and prescriptive techniques more akin to an implementation guide.
("A FHIR Environment into which we are applying SOA Techniques")
Data Storage and Coherence. Within a FHIR environment, storage is managed within the FHIR server, consistent with non-SOA FHIR implementations. Data consistency is the responsibility of the Server, but responsibility may carry to consuming applications if they are provided with sufficient update rights so as to make that a concern. Data validation also has a shared responsibility, first with the FHIR Server, and additionally with the authorized updating applications. Data visibility is a product of the REST interface, typically allowing CRUD operations down to the data element level.
Transactional Integrity. Updating applications maintain responsibility to sustain transactional integrity as state management is typically not performed within the FHIR server. The FHIR specification does not specifically provide for "rollback" in the event of transaction errors, as may be associated with complex or large transactions involving changes to multiple resources. If desired, coding will need to be done to accommodate this capability.
API/Interface Design.The default interface into a FHIR server is REST-based, providing CRUD operations and allowing for stateless access. The FHIR specification does not inherently provide for concurrency management (e.g., managing of "deadlock" conditions where two resources each await update permission from the other). As a result, within the FHIR server itself it is assumed that fault tolerance and server availability is being managed (beyond the scope of the specification).
SOA techniques may be useful in API design in the form of providing "design patterns" to govern interactions between FHIR servers and/or between client-to-server communications (such as the "Fire and Forget" pattern). These patterns can help foster loose coupling within FHIR, reducing the burden associated with intra-Server implementation and reducing risks associated with distributed processing. SOA can define encapsulation techniques to guide which and how FHIR functions are to be exposed. The HL7 SOA Workgroup has a portfolio of Service standards that may be useful in this regard.
The portfolio of HL7 Service Functional Models currently includes:
Error Handling.The FHIR specification does not specifically address error handling between and across servers and clients. When implementing within larger or more complex environments, particularly in situations where multiple FHIR servers may be involved (especially if they are provided by different vendors/implementations), error handing and management can quickly become complex and untenable.
SOA provides an implementation approach providing consistency in error handling, escalation, and error management. These tools can be leveraged to identify likely error conditions and exceptions based upon prior SOA work, helping to put into place infrastructure within FHIR to manage those exceptions. Moreover, this alignment creates future opportunity to more effectively integrate FHIR resources into an enterprise SOA fabric should that become a need.
Security.Identity management, access control, or other dimensions of a secure solution are inherently part of a service architecture. SOA guidance can foster an effective design involving FHIR in support of authentication, policy enforcement, role-based access controls, and a host of other provisions and protections. It is important to note that within SOA, security is an established, mainstream, and mature offering. Reuse of these concepts can help prevent inadequate, incomplete, or ineffective security measures within FHIR, and eliminate the need to re-invent solutions exclusively for FHIR.
("Applying FHIR to Enterprise Solutions")
Data Storage and Coherence.In an enterprise environment, data storage and data management are typically governed by organizational policy. As such, that policy determines the operational parameters to be satisfied by the implementation. FHIR servers and their data persistence would need to fit within that policy, with data access channels into those data stores being in compliance with that policy.
Use of SOA-friendly interface protocols, such as SOAP and potentially REST, create the access channel for integration. Depending upon the degree of specificity of the interface, exceptions may need to be made to allow for use of FHIR Resources as part of parameterized payloads into and out of these services. Established minimum sets of data may be required to comply with data coherence expectations (in other words, it is often required to send data in context, and not just selectively include specific data elements). The organizations SOA architecture may govern and enforce these policies. Services have responsibility to interact with organizational policy enforcement points to assure appropriate permissions are in place.
Transactional Integrity.In part as a function of the "black box" design approach described above, data integrity and transactional integrity are in part enforced within each service as a result of the nature of their exposed APIs. Data update and integrity becomes the responsibility of each service. FHIR interfaces may be exposed as part of these services, but would be subject to the integrity rules/constraints of each service.
API/Interface Design. Services' API design and explicit exposing of service capabilities is an essential and elemental feature of a SOA architecture. Services provide loosely-coupled access (e.g., external clients do not have visibility into the inner workings of a service). Each service exposes specific interface capabilities and clients must use those capabilities. SOA interfaces are typically aligned with business functionality and are coarse-grained (such as "Register Patient" or "Validate Identity", etc.). Note that there is not necessarily a "perfect match" between SOA operations and RESTful operations -- Finer grained FHIR interactions may be encapsulated in coarse-grained functions. The API definition is where loose-coupling manifests in an implementation. Exposing an API access to the inner workings of a service has onward implications that potentially limit an ability to undertake technology or design changes within the service. The goal is to minimize technical dependencies, allowing maximum freedom to evolve and enhance the way a service operates without affecting what capabilities it provides.
For FHIR implementations, we recommend review of the HL7 SOA balloted healthcare standards, as well as reviewing SOA design patterns. There are many public sources of these patterns available on the web.
Error Handling. Error handling within SOA is defined and should be directly leveraged for implementations involving FHIR. We would not anticipate the need to change error management for FHIR, except to address payload-specific errors that may arise.
Security.Security is inherently a dimension of any enterprise SOA architecture, meaning that the responsibility within a service implementation is to provide the "hooks" to interact with that architecture. In other words, the service does not need to create or enforce security, it needs to interact with those enterprise components that have that responsibility.
Enterprises typically have security architecture into which a SOA environment will have already integrated. Service implementations would rely upon this existing infrastructure as part of authentication, access control, etc. Policy enforcement is a function of the architecture and not a specific service itself. Services would rely upon policy enforcement points to govern access to information.
While technical dimensions of security would be addressed by the security architecture directly, FHIR implementers should anticipate that data-specific access control policies would need to be captured and formalized so that they are enforceable within the architecture. For example, if a new service is handling protected health information, the policy enforcement point within the architecture would need to know that the service has that nature of data.
FHIR and SOA are not competing technologies; rather they are complementary implementation approaches that have the potential to augment each other dependent upon the context for their use. As implementation decisions are undertaken, we advise evaluation of the contextual landscape to determine the degree of SOA applicability to a FHIR project, or vice-versa.
FHIR has proven itself as beneficial in that it provides an easy-to-implement and coherent approach to accessing healthcare resources using a modern protocol stack. SOA has proven itself over time in multiple vertical market segments as a way to divide responsibilities and authoritatively manage information across distributed systems. Marrying the discipline of SOA with the implementation ease of FHIR is a winning combination when the situation warrants.
Note that this section is less about a technology protocol as it is about alignment and architectural fit, such as encapsulating behavior, data representation in service calls, and division of responsibilities between a service implementation and the service consumers and other supporting services. We envision maturing this section to include specific service examples, exemplary code, and potentially self-evaluation checksheets or maturity models to help guide implementers toward effective solutions. Feedback on this section is welcomed and may be directed to the SOA list at soa@hl7.org
© HL7.org 2011+. FHIR DSTU (v0.5.0-5149) generated on Fri, Apr 3, 2015 14:36+1100.
Links: What's a DSTU? |
Version History |
Specification Map |
Compare to DSTU1 |
|
Propose a change