SOA Pharma

While researching SOA developments and opportunities within the pharmaceutical industry, I have discovered some interesting concepts that seem to have broader implications.

Off-Label

In a pharmaceutical context, Off-Label refers to uses of drugs that are not approved by the regulators and cannot therefore be printed on the product label or officially promoted by the drug company. More generally, it refers to any unauthorized or emergent use of a product or service.

Telephone companies were originally oriented towards providing voice services. Computer users started to use modems, which were designed to extract added value from a voice connection by using it to transmit data. With Voice Over IP, we have now come full-circle: VOIP is designed to extract added value from a data connection by using it to transmit voice. These services are now officially sold by the telephone companies - off-label has become on-label.

Within a service economy or SOA, there is often an explicit intention that a service should be used as much as possible, in as many different contexts as possible. This helps to extract economies of scale/scope from the service. (In very simple terms, the more the service is used, the greater its use-value.) It also helps to achieve more flexible structures, since the overall behaviour of a service-based solution can be altered by changing the use of a given service.

A service designer can build a certain degree of generality and flexibility into a service. For example, by defining the preconditions to be as weak as possible, and by designing differentiation into the service itself.

But a service consumer can sometimes go beyond this, using the service in ways that are not intended by the service designer, may not be properly supported by the service provider, and may even be a formal breach in the terms and conditions. For example, an internet site may offer a weight tracking service for slimmers. A farmer may discover that he can use the same service to track the weight of his livestock, perhaps by falsifying some of the data input fields and by appropriately interpreting the data outputs.

If the service provider detects this, there are several possible responses. Firstly, to tighten the service preconditions to prevent this use, and possibly blacklist the offending consumer. Secondly, to tolerate this use, but monitor its impact on performance or possible liability. Thirdly, to enhance the service to fully support this use (perhaps under a different brand identity).

Why would a service consumer knowingly use a service in a way that is not officially supported by the service provider? Obviously there is some risk involved for the service consumer. But if the service can be twisted to deliver a desired result, is this necessarily a problem?

Some service providers will see off-label use as a form of abuse. Clearly there are some forms of abuse that threaten the security of the service provider and/or of legitimate users, and this risk must be properly managed. However, it is not necessary to regard all off-label uses as security threats. In many cases, it is better to regard off-label uses as business opportunities.

More importantly, we need to see off-label service usage as a governance issue. What controls (if any) are appropriate for off-label service usage, and how do we accommodate the asymmetry between on-label and off-label in the geometry of services.

Shared Care Protocol

With long-term healthcare, there are complex referral pathways involving several practitioners.

A shared care protocol is designed to ensure effective liaison and joint working between practitioners. It defines who is responsible for what actions and outcomes. For an example, see this response to this management conundrum from the Pharmacy Management journal.

An internet search for "shared care protocol" will find hundreds of specific protocols for specific drugs and other healthcare treatments.

The shared care protocol is essentially a piece of orchestration. There are two key questions here: firstly whether the protocol is standard or customized for each patient; secondly whether it is defined by a specialist team or through negotiation between multiple stakeholders (collaborative composition).

Helen Snowden and Sarah Marriott argue for local protocols. (Developing a local shared care protocol for managing people with psychotic illness in primary care, Psychiatric Bulletin (2003) 27: 261-266)
The notion of shared care protocol has obvious relevance for customer relationship management, where a range of customer-related actions need to be appropriately coordinated and orchestrated, in a way that is appropriately aligned to the unfolding responses of the customer. More generally, any business challenge that calls for a complex and coordinated response to some unfolding situation, which is found in some of the most interesting applications of SOA.

Surrogate EndPoints

The specification, orchestration and testing of healthcare (including drug treatment) is defined in terms of achieving certain endpoints. This enables a clinician to make connections between the clinical trial data and the desired patient outcomes.

But sometimes the real endpoints are difficult or impossible to measure quickly. So clinical trials and care protocols are defined in terms of surrogate endpoints. These are alternative metrics that are thought to provide a reasonable indication or prediction of the real endpoints. For example, measuring blood pressure or cholesterol levels as an indication of the likelihood of heart problems.

The problem for the clinician is that these surrogates introduce another level of complexity into the reasoning process. The statistical correlation between the surrogate endpoint and the real endpoint works for the average patient, and becomes less reliable as the patient diverges from the norm.

Business processes commonly use surrogate endpoints and metrics, which often relate to the intermediate steps of a business process. For example, an online marketing operation might measure the number of enquiries, based on an expectation that a certain proportion of these enquiries can be converted into sales. This leads to a functional decomposition: one subsystem is responsible for delivering enquiries, while another subsystem is responsible for converting enquiries into sales.

But the more you differentiate your operations to address different market niches, the more difficult it becomes to integrate the subsystems back together in a consistent and effective way. SOA allows more complex differentiation and integration, and potentially supports much greater levels of customer-specific behaviour at a given cost level. But in order to design this properly, we need to include both the real and the surrogate endpoints in our business models for SOA.

Links 

Center for Health Evidence: Users' Guides to Evidence-Based Practice


Richard Veryard, Business Modeling for SOA Worked Example: Pharmaceuticals (CBDI Journal May 2005)

See also Off-Label (March 2005)