R6 Ballot (2nd Draft)
ExchangePublish-box (todo)
FHIR Infrastructure  Work Group | Maturity Level: 2 | Standards Status: Trial Use |
Though FHIR resources are primarily designed for the RESTful HTTP-based implementation, it is not necessary to use a RESTful interface when exchanging the resources; one way that they can be exchanged is in the context of services. Service Oriented Architecture (SOA) is an architecture pattern using services to encapsulate and provide discrete pieces of application functionality to each other. Services communicate by invoking public interfaces and exchanging information (as parameters and outputs) in accordance with a well-defined service contract.
Services are cohesive sets of functions that maintain responsibility for both data and "state" for the scope of their responsibility. Services have a unity of function, such as Terminology Management, Identity Management, or so on, working with other services in collaboration as part of an orchestrated workflow. Data within a service typically follows a "black box" model and is not classically exposed, instead using pre-defined interfaces to make specific behavioral requests for the service to fill.
To relate this to FHIR, resources in a service-oriented implementation can serve two discrete roles: either as a payload parameter, specifying information flowing into or out of a service; or in a behavioral sense, using FHIR APIs as the invocation mechanism for engaging a service. Service APIs are often realized using either RESTful or SOAP-based interfaces.
Of note, there are potential benefits in considering usage of FHIR and SOA together. FHIR allows for ease of implementation and ready access to data payload in an open way. SOA has maturity around transactional integrity across distributed systems instances, providing a framework for loose-coupling and addressing pre-conditions, exception handling, and other implementation considerations of complex distributed systems.
This section illustrates different contexts to allow implementers to make informed decisions at implementation time, considering potential impacts and solution patterns to benefit specific situations. In doing so, this section will clarify what is meant to apply SOA principles and specifications within a FHIR environment/implementation, and the converse. 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.
This section is being included as FHIR offers a highly flexible framework for interoperability that can be deployed that can be used in a variety of different ways, and in ways that have the potential to hinder interoperability if not done thoughtfully or consistently. Use of SOA patterns and approaches can mitigate this risk, limiting the potential liability resulting from the extreme flexibility of FHIR and fostering 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.
The definition of specific services is a domain or context specific task. It is anticipated that this would be done as separate specifications that make use of the underlying facilities defined in this specification. HL7 has already defined a portfolio of services that take advantage of REST- and SOAP-based interfaces, but the parameters passed to and from those services are not at present resource-based. These are potential extension points that may lend well for FHIR implementation. Services defined like this are able to build on the common underlying platform features defined in this specification such as REST or messaging, and add specific interactions where appropriate. Alternatively, the service interfaces can build an entirely separate implementation.
Note that for each of the items below, there are paired sets of standards, an HL7 Standard defining the functional specification, and an OMG Technical Standard containing SOAP bindings (for all the items below) and REST bindings (for about half of the items below).
The portfolio of healthcare SOA service specifications includes:
)))))
Note: FHIR-enablement of the services above is already occurring on a limited basis. The Clinical Quality Improvement Framework (CQIF) portion of the FHIR specification
is an example of a technical interface and resources that have been influenced by prior SOA work.
Similarly, this specification defines a Terminology Service which
is tightly integrated with the RESTful API (note: this terminology service has different goals than
the CTS2 service, so they are not functionally equivalent). FHIR itself is a framework for the instantiation
of an RLUS service. Definition of other additional services based on the service interface definitions
provided by the HL7 SOA work group will be considered if there is enough interest in this.
Given that there are a set of available services that can be applied directly or used as a pattern in conjunction with FHIR, it merits consideration that there are alternative ways to bring together FHIR and SOA, each of which has benefits and drawbacks. Three specific styles of implementation have been identified:
Determining which of the above implementation styles is best suited to a situation is context-dependent. The following table presents these alternatives, deliberately using qualitative measures to help navigate to the best-fit based upon influencing factors. "Harvey Balls" in the table below indicate relative strengths and weaknesses of the implementation alternatives.
| 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 can support stateless processing |
| Support of "loose coupling" | Minimum of dependencies between the calling and responding system; reduces burden on client to manage 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 |
FHIR resources are designed to be used in a wide variety of contexts. In particular, FHIR resources are required to be suitable for use in a REST environment. This means that there are number of design requirements and choices that impact how suitable resources are for use with services.
If service use was the only consideration, different decisions would be made, and resources would be more suitable for use with services. However, this would curtail their usefulness and reusability in other contexts.
API/Interface Design. Services' API design is explicit and exposes service capabilities which are a part of a service contract to consuming applications. This contrasts with what is the default interface into a FHIR server of a REST-based interface exposing CRUD operations and stateless access. Good SOA design practice indicates loosely-coupled access (e.g., external clients do not have visibility into the inner workings of a service) improves implementation flexibility over time, permitting design and performance improvements with the maturation of the implementation. As such, interfaces are typically exposed and aligned with business functionality (such as "Register Patient" or "Validate Identity").
Bridging what is not necessarily a natural-fit between SOA operations and RESTful operations are key to interface design. Implementers may elect to apply finer grained FHIR interactions to be encapsulated in coarse-grained functions, delegating those responsibilities to either implementations within a FHIR instance or to external code not visible to the service consumer.
Principal within the design objective is to minimize or eliminate responsibilities on behalf of the service consumer to understand or apply knowledge of the service implementation. This frees up the service provider to be able to evolve and improve the inner workings of the service without a "ripple effect" adversely impacting service consumers. In doing so, technical dependencies are minimized. Several good sources of SOA Design Patterns are available from HL7 and other public sources.
Data Storage and Coherence. The approach to and complexities associated with data storage and overall data coherence will significantly depend upon whether an implementation is subject to enterprise policies and whether data consistency is the responsibility of the service provider or consumer. In Enterprise settings, these issues are typically governed by organizational policy. FHIR servers and their data persistence would need to fit within that policy, with data access following that policy and services interacting with "policy enforcement points" to assure that appropriate permissions are in place.
Where data consistency is the responsibility of the service (or server) use of SOA-friendly interface protocols, such as SOAP and potentially REST, create the access channel for integration. This may necessitate defining minimum sets of data that are required to comply with data coherence expectations (in other words, a service contract that specifies the collection of resources that must be updated in tandem, and the scope of what constitutes a 'single transaction' - more on this in the Transactional Integrity section).
In alternative implementations data 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 to the data element level.
Transactional Integrity. When encapsulating functionality within a SOA-type service, data and transactional integrity are essential in making sure that data received and stored is accurate and consistent with what was received. An issue particularly with update functions, the ability to update multiple different resources and maintain harmony among them as part of a broader transaction is how this is typically realized.
Should one part of the update 'fail', one would expect all the other updates to be "rolled back" to a prior, stable state. Rollback is not expressly specified as part of the FHIR. Data update and integrity becomes the responsibility of each service. 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).
Applied use of SOA patterns have benefits in terms of distributed transactional integrity, as SOA has substantially removed burdens from calling (client) applications, instead levying these responsibilities upon the service provider. This has relevance because it is customary in larger scale implementations (such as large enterprises) that service consumers are varied and not necessarily know in advance to the service. As a result, these implementation patterns make for more robust infrastructure, mitigating potential implementation risk and ultimately improving data quality. We note that these elements can be manually accommodated in FHIR implementations, absent use of SOA patterns, though that can lead to inconsistent interpretation, delegated responsibility to client application(s), and the potential for incompatible implementations.
Modularity. The modularity of resources - which resources are defined, and why - is driven by a wide set of considerations around how they are used. Resources are a platform on which a set of business/clinical services of various kinds are provided. Accordingly, the resources are defined for general use, and they can be expected to be less suitable for a particular service than custom defined structures. The pay back is wider re-use of the information that the service deals with.
Effective "service-orientation" establishes modularity at both a macro and micro-level. At the macro-level, services themselves are modular, componentized, and composable. Since each service has a singularity of purpose with a well-defined interface, they are naturally suited to working in tandem with other services and consistent with modular design. At a more fine-grained level, the interfaces into and out of services also allow for modularity, and the ability to leverage the structure of FHIR resources as a payload descriptor for carrying data structures and corresponding semantics across APIs is modularly based.
Explicit State. All resources represent the various states of the record and real-world entities involved in a transaction explicitly. This is necessary for use in RESTful and document contexts, where there is no explicit transaction. Service interactions are typically associated with implicit semantics, such as a request to change the status of a resource to something else, for example. The fact that resources that carry this state explicitly as well as the transaction fixing state implicitly creates duplication between the two, and this will need to be managed.
Error Handling. 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. It is not anticipated that there is a need to change error management for FHIR, except to address payload-specific errors that may arise.
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.
Resource References. The most obvious impact is that resources refer to each other using full URL based references, and there are a number of rules around how these references are resolved. In the context of a service, this means that the references between modules carry this extra weight of choice and obligation, even when it might not be necessary.
FHIR resources or bundles may be used as the parameters or outputs of service interfaces.
Orchestration. 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 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.
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. This includes topics such as identity management, access control, or other dimensions of a secure solution. 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.
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.
Resource Identity. All resources have a single identity (the full URL), and a logical id which may be maintained as the resource moves from server to server (see Managing Resource Identity for further discussion). Since this identity is used by any reference to the resource, it must be maintained when the resource is exchanged so that references from other resources to the one being exchanged can still be resolved. Any use of resources in a service environment needs to address how these references can be resolved. This can be achieved by delegating the reference resolution to a RESTful framework, by ensuring that all the relevant resources are contained in the service call, or by making some service-based arrangement by which additional resources can be retrieved. Services that exchange resources SHOULD maintain resource identity. Further, as explicit version tracking is not a guaranteed capability of a service call, services that exchange resources should include version information associated with resources being exchanged.
Capability Statement. When using RESTful exchange, messaging, and document based exchange, the Capability statement allows authoring and reading applications to describe how they use a resource. The Capability Statement supports trading partner negotiation from specification time through to run-time discovery. The Capability statement doesn't provide any equivalent way to make declarations about services, though this might be added in the future if common requirements emerge. Services are expected to make appropriate arrangements around discovery and compatibility, though it is expected that these will vary considerably.
Services that exchange resources MAY choose to provide support for describing and changing descriptions of service implementations.
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. 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.
As these areas are both commonplace within health settings and not inherent strengths of FHIR, the marriage of FHIR and SOA techniques provides a viable and beneficial path forward to improving implementation and mitigating risks by leveraging proven and established industry best-practices.
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.
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 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. Implementers should consider evaluation of the contextual landscape to determine where FHIR and SOA can benefit from complementary implementation leverage points.
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. Noting that there are different styles of realizing FHIR and SOA together, a recap of the principal alternatives would include:
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.
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 applies a systematic framework for orchestration using industry accepted formalisms, avoiding costs and complexities associated with an ad-hoc approach |
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.
Finally, 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.
FHIR ®© HL7.org 2011+. FHIR R6 hl7.fhir.core#6.0.0-ballot2 generated on Mon, Aug 12, 2024 16:59+0800.
Links: Search |
Version History |
Contents |
Glossary |
QA |
Compare to R5 |
|
Propose a change