The proper interpretation and use of IHE’s definitions for actors, options, profiles, and transactions is a regular source of discussion and sometimes confusion. This may come up again at next weeks meetings.
Each Actor, Transaction, Integration Profile, and Content Profile defines functionality that will be added to a Product, i.e., a "mixin". Rather than have precise executable code, these are requirements that are included by reference. Options add functionality that will be added to an IHE Actor, i.e., "inheritance". Some Actors are found in multiple profiles. This is a combination of common requirements that apply to all profiles, "mixin", with specific requirements that apply only when within one profile, "inheritance".
Some languages (like C++ and Smalltalk) lack mixins. Mixins are independent chunks of functionality that can be added to an object rather than inherited from a parent object. This corresponds to how interchangeable parts work in the real world.
Consider an automobile maker like Toyota. They have five models of Prius (1-5). They have four engine types. They have two wheel sizes. They have three battery pack types. They have multiple model years. A Prius 1 can only have the small engine. The Prius 2-4 have the medium engine. The Prius 5 has the fancy engine. The Prius 1-4 have the NiMH battery pack. The Prius 5 has the lithium battery pack. The rules go on for all the alternative components. They use the same components for several model years, while changing other aspects of each model.
So Toyota makes five Prius models and has mixins for engine, wheels, battery packs, etc. As you expand to their entire product line you find commonality of wheels, engines, and other parts across a wide range of products.
When you look at vehicles in general you find that mixins extend much further. You can find the same Cummins engine in many products from different companies.
The definition of standard building blocks that can be used as components in different products is also valuable in software. IHE defines components so that the components of products that provide interoperability can have common specifications. This leaves the product creators the flexibility to innovate with product features without losing interoperability.
Imagine a Product that is described as conforming to
- A Time Client within the Consistent Time Profile
- A Document Consumer within the XDS.b Cross Enterprise Document Sharing Profile
- A Document Consumer within the Multi-Patient Stored Query Profile, supporting the Asynchronous Web Services Exchange Option.
- A Content Consumer within the BPPC Profile
What does that mean? Diagrammatically it can be shown as:
The Time Client within Consistent Time Profle refers to the NTP RFCs for 95% of the time functions and transactions. All of these are included by reference. The IHE Time Client adds the requirement to the glue and other logic that whenever current time is used, the time from NTP must be used. It also adds the requirement that the system be configurable to be synchronized to with 1 second (at worst). It limits the requirement to include only those NTP functions that a client will need. The Time Client need not act as an NTP server. Implementing this requirement is usually no harder than turning on and configuring the inherent system NTP services.
The Document Consumer part is more complex. All Document Consumers must meet a variety of functional requirements for dealing with documents. These include functions around privacy and security, as well as interfaces to a variety of communications, local storage, and system services. The Product features usually depend upon the use of these services.
The Document Consumer within the XDS.b Cross Enterprise Document Sharing Profile has a long list of functional and transaction requirements. These define the external behavior of the product exposed by the document consumer.
The Document Consumer within the Multi-Patient Stored Query Profile adds some query capabilities and some privacy and security requirements. In theory a Product could exist that simply does these queries without ever retrieving the documents using the other Document Consumer actor, but that is unlikely. The profile assumes that the appropriate product glue exists to use the query results to drive document retrieval. IHE does not specify how the two Document Consumer actors communicate, nor does the Product design need to implement them as separate actors in the code.
This Document Consumer also supports the Asynchronous Web Services Exchange Option. This makes it a kind of Document Consumer within the Multi-Patient Stored Query Profile. It complies with all those rules. In addition, it complies with the rules of the Asynchronous Web Services Exchange option. This corresponds to an "inheritance" relationship in object oriented terms. Note, in this artificial example I did not include the Asynchronous object on the other Document Consumer. That Document Consumer does not have the extra capabilities. This is not a realistic choice by a Product designer. A real product designer would be more consistent and add that option to all of the Document Consumer actors in their product.
The Content Consumer within BPPC Profile adds internal functions without adding any external transactions. It is assumed that there exists glue to attach it to some sort of communications transactions, and in this case those communications functions are those provided by the two Document Consumer mixins. There are generic Content Consumer functions dealing with access control, internal storage, etc. These enable whatever the other Product features are.
The "within the BPPC Profile" adds the ability to process documents of a particular format. In this case it is the Basic Privacy Consent document. The profile also includes functional requirements that other parts of the Product will comply with the restrictions found in the consent documents. (That generates a lot of product specific requirements on the glue logic and product features.) There is also the requirement that a Content Consumer in the BPPC profile shall be grouped with one of three different IHE actors. In this example the Document Consumer within the XDS profile is used. This requires that at a minimum, the Product can use the Document Consumer functions to obtain BPPC format documents.
Many people are sloppy with their terminology when speaking or writing. They assume a context rather than using the sometimes very long phrases needed to be precise. They may say that they are making a Document Consumer actor. This will cause confusion in the absence of a mutually agreed context. They could mean that they are developing a library or set of mixins for a particular language and interface. This library will be incorporated into some other Product to provide the Document Consumer functions in conformance with the rules of some integration profile. Or, they could mean that they are developing a complete product, and that this product will incorporate the Document Consumer functions and support the Document Consumer transactions in the context of some integration profile.
When the context is mutually understood you know which of these alternatives is meant, what profiles are involved, options involved, etc. Without a shared understanding of context, confusion results. This kind of confusion is unfortunately common in IHE discussions and documents. It’s easy to pick up a document and not realize the context.
Another problem is that we have not re-factored the system in many years. Some original understandings were wrong. New capabilities have been added. As with all long lived software systems the result is occasional awkward and confusing constructions.
For example, knowing what we know now, I would argue to re-factor the Document Consumer, Document Recipient, and Media Importer. It would be much clearer to have a basic set of core functions, which would in turn have mixins for XDS transactions, XDR transactions, and XDM transactions. It’s now clear that there is a common set of document management functional requirements that is independent of the communications transactions. These are presently in the Document Consumer, Document Recipient, and Media Importer. They would be moved to a new generic core actor. The transaction specific mixins would be defined. That would make addition of FHIR and other future transaction specific functionality much tidier. We would be able to specify "use the <new generic actor> plus XDS, XDR, and FHIR mixins" for example.
That might happen some day. Anyone who has been through the re-factoring of a large system knows that this is a lot of work, and it’s not likely to be undertaken until the pain of dealing with the present awkwardness becomes substantial.