Rolling Review

I have long argued for the benefits of an outside-in view of business architecture. In 2008-9, Tony Bidgood and I developed a worked example based on the fictional delivery company Springfield Parcels, to illustrate a range of different business improvement paradigms and modelling notations. One of the key insights from this material was the importance of modelling your customer's process as well as your own. See also my post on Customer Orientation (May 2009).

A few years later, I worked with a regulator that had a complex relationship with the industry (industries) that it was regulating. The regulator's processes consisted largely of a series of complex responses to external events and activities, so I built a business service architecture to provide an outside-in view.

In those not-so-far-off days, regulated companies submitted meticulously compiled dossiers of information to the regulator for review and adjudication. This was a highly sequential and slow process, each stage typically taking several months if not years.

This delay was always a particular challenge in industries such as pharmaceuticals, where regulatory approval is needed before a new drug can be put on the market.

The UK drug regulator, the Medicines and Healthcare products Regulatory Agency (MHRA) was already looking at changing this sequential process before the COVID-19 pandemic struck. With the new Rolling Review approach, the regulator is able to start pre-assessment during the late clinical trials, and substantially reduce the time to market for innovative new treatments. This helps to explain the remarkable speed with which the COVID vaccines were tested and approved. The BBC Horizon programme includes a contribution from Christian Schneider, the MHRA's Interim Chief Scientific Officer.

The principle of rolling review also applies internally within organizations, where innovations often need to be reviewed from various perspectives. Some stakeholders prefer to wait until all the details of the innovation have been worked out, so they can be reviewed holistically. Others prefer to be involved as early as possible, since this provides more chance to influence the overall design and approach. Late involvement may seem a more efficient use of expert resource, but often leaves the expert with little more than a go/nogo decision.

We often see this dilemma with privacy and security. Advocates of security-by-design and privacy-by-design like to get in early; however, it may be difficult to carry out a rigorous Data Protection Impact Assessment (DPIA) if you don't yet know any of the answers to the questions on the template.

The fundamental point here is that all these side processes - regulation, assessment or governance - are only meaningful in terms of the main processes that they are regulating, assessing or governing. So it doesn't make sense to optimize the side process in isolation. The point is to innovate quickly and safely, not to make life easier for the regulators. And the outside-in business service architecture is a great tool for focusing everyone's minds on this.

---

ICO, What is a DPIA?

Sandra Kanthal, Marvellous Medicine (BBC Radio 4 - Horizon, 20 June 2021)

MHRA, Rolling Review for Market Authorisation Applications (UK Government, 31 December 2020)

Richard Veryard and Tony Bidgood, A Brief Evaluation of Business Modeling and Improvement Methodologies (CBDI Journal, December 2008)

Is there a Single Version of Truth about Statins?

@bengoldacre provides some useful commentary on a BBC news item about statins. In particular, he notes a detail from the original research paper that didn't make it into the BBC news item - namely the remarkable lack of agreement between GPs and hospitals as to whether a given patient had experienced a cardiovascular event.

This is not a new observation: it was analysed in a 2013 paper by Emily Herrett and others. Dr Goldacre advised a previous Health Minister that "different data sources within the NHS were wildly discrepant wrt to the question of something as simple as whether a patient had had a heart attack". The minister asked which source was right - in other words, asking for a single source of truth. But the point is that there isn't one.

Data quality issues can be traced to a number of causes. While some of the issues may be caused by administrative or technical errors and omissions, others are caused by the way the data are recorded in the first place. This is why the comparison of health data between different countries is often misleading - because despite international efforts to standardize classification, different healthcare regimes still code things differently. And despite the huge amounts of NHS money thrown at IT projects to standardize medical records (as documented by @tonyrcollins), the fact remains that primary and secondary healthcare view the patient completely differently.

See my previous blogposts on Single Source of Truth

---

Tony Collins, Another NPfIT IT scandal in the making? (Campaign4Change, 9 February 2016)

Emily Herrett et al, Completeness and diagnostic validity of recording acute myocardial infarction events in primary care, hospital care, disease registry, and national mortality records: cohort study (BMJ 21 May 2013)

Michelle Roberts, Statins 'don't work well for one in two people' (BBC News, 15 April 2019)

Benoît Salanave et al, Classification differences and maternal mortality: a European study (International Journal of Epidemiology 28, 1999) pp 64–69

Customer Orientation

@adamshostack objects to something I quoted from Clayton Christensen: Understanding your customer isn't enough.

What Christensen is saying, and I absolutely agree with this, is that understanding the customer is the wrong level of analysis (granularity). What we need to focus on is the job the customers are trying to get done when they use your product or service.

Adam thinks this is "fascinating & wrong. W/o understanding customer orientation, you can't from job" (via Twitter).

I think pharmaceutical sales and marketing provides an excellent example of why Christensen is correct. As I have explained before, a typical twentieth-century business model involved drug company representatives making personal visits to doctors. To support this kind of model, you collected lots of information about the doctor - not just professional (size of practice, specialization, and so on) but also personal (ethnic group, sexual preference, ages of children, golf or squash). The drug company employed a range of representatives of different types, and selected the appropriate rep to visit a white gay squash-playing doctor.

The trouble with this business model is that it is not aligned with the products and services of the drug company. Doctors increasingly regard these kind of sales visits as a complete waste of time; even if they accept the hospitality of the drug companies, they have learned to be resistant to the sales messages.

What the drug company needs to focus on is how to provide more value to the doctor. For this purpose, you don't need information about the doctor, you need information about what the doctor actually does. In particular, you have to understand the decision process in which the doctor thinks about prescribing particular drugs to a particular patient, as well as the collaborative process in which the doctor and other healthcare practitioners discuss alternative courses of treatment with a patient.

Understanding the doctor is missing the point. The opportunity to create business value comes from understanding the work of the doctor. Different doctors may have different styles and habits, and may approach similar cases in different ways (although this is increasingly constrained by procedure and protocol imposed by health authorities or health insurance companies). That's the right level of analysis.

One technique we use for this analysis is business process modelling. But we're not interested in the company's own processes, we're interested in the customers' processes, and in the variations in these processes. Business survival depends on providing products and services that add value to these customer processes, so it's the customer processes we need to understand. Not the customer as a passive and indivisible entity (as in many CRM systems) but as an active bundle of behaviour and capability and purpose.


See also Clayton Christensen on jobs needing to get done (via Anders Sundelin).

---

Related post

Misunderstanding CRM and big data (November 2014)

Update: I have removed links to tweets by Chris Lawer and Gunnar Peterson, who were part of the original conversation, because the URLs in their tweets now point to irrelevant and NSFW content.

Service-Oriented Business Strategy

A service-oriented modelling approach helps us to identify alternative business strategies, involving the creation and deployment of added-value services.

• Identify value-added business services that can be seen (by customers) as more relevant to the context of use. 
• Identify value-added business services that are flexible / reusable (by customers) in multiple use-contexts. 
• Compose value-added business services in an efficient and reliable manner from internal and external capabilities. 
• Provide a service platform to support customers in composing our business services to solve their problems. 

I am in the process of defining an extended example from the pharmaceutical sector. The first part will now be published by CBDI in May 2005.

Why Pharma?

We selected the pharmaceutical industry for a worked example because it provides a good example of a complex information supply chain. A drug company (in collaboration with a distributed network of research and test) produces a drug, together with lots of information relating to the drug. There are several different categories of information user: the patient who takes the drug, the medical practitioner who prescribes and/or dispenses the drug, the health service or insurer that pays for the drug, and the regulator who monitors the safety of the drug.

Pharma appears to illustrate some general characteristics of complex service networks, so this example should be of relevance to other industry sectors.

Above all, for SOA illustration purposes, pharma has two advantages. Firstly, it isn't the same old boring examples everyone else is using (finance, travel, retail). And secondly, it isn't military.

In the past, drug companies have been able to make substantial profits from an essentially drug-centric process, getting high sales volumes for its blockbuster drugs from a largely undifferentiated mass of patients with a given condition. This business model treated the physician or clinic as pretty much equivalent to a retail outlet, and did not involve any relationship with the end-customer (the drug consumer). But this business model is subject to major challenge from several directions.

Approach

We model a business as an open system, whose viability depends on robust and appropriate interactions with a dynamic environment. (This contrasts with the closed system approach adopted by many traditional business modeling methods, whose focus is on producing a complete and coherent account of some internal configuration of processes and services, against a fixed view of the environment.)

We model a service-oriented business as a system of systems. Services here may include tasks automated in software (typically but not necessarily rendered as web services) as well as human tasks.

SOA is not just about decomposition – producing fine-grained services with maximum decoupling. Equally important is to think about composition – how these services can be integrated in many different ways to support a wide variety of demand.

In general terms, there are a number of distinct categories of stakeholder, each performing fairly complex functions in relation to the pharma value chain. A key SOA challenge for a drug company is to provide services to all these different stakeholders in a consistent and coordinated yet flexible way. In order to meet this challenge, we need to produce a series of models, from different stakeholder perspectives, showing how the services can be composed in various contexts of use.

In our view, the essential shift for service-oriented modeling is to view the services, not from the provider's perspective, but from the customer's perspective, and in the customer's context of use.
 

Strategic Reframe

From the perspective of business strategy, what we are looking at here is a strategic reframe of the pharma business. What is the drug company actually selling, and to whom? How does information and services become an integral component of the overall product offering?

The ultimate source of value for the patient is defined in terms of health. The provision of health to patients is based on the deployment of complex medical knowledge by a physician, and this in turn relies on information about particular drugs and combinations of drugs from the drug company and elsewhere. This essentially defines a value ladder, in which the value of the drugs contributes to the value of the heathcare.

While this kind of strategic reframing is widely discussed, what service-oriented modeling provides is a systematic way of determining and analyzing the strategic options, in terms of the value ladders that can be supported.

Can the drug company solve all the problems of healthcare? Can the physician solve all the problems of healthcare? The answer in both cases is of course NO. There is huge complexity involved, and the design goal for SOA is to define a reasonable separation of concerns between the physician and the drug company, that allows each of them to manage an appropriate part of the complexity.

---

Previous Post: SOA Pharma

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)

Straight-Through Processing

In an SOA context, straight-through processing means passing some input services onto your customers, with zero intermediation. This only works if the input and output services are in the same domain.

• Insurance. You buy insurance through a broker. You may pay either the broker or the insurer. (If you pay the insurer direct, then there is presumably some commission paid back to the broker.) You may claim through a service that is actually provided by a separate claims process, under the insurers’ brand.
• Travel. You buy through a travel agent. The services are delivered by the airline and hotel. (You are given a reference number to pick up your tickets and check into the hotel.)
• Logistics. You buy something on eBay, pay via PayPal, and the item is delivered by courier. (You are given a reference number so that you can liaise directly with the courier company.)

These supply chains are more or less transparent, until something goes wrong. If there are problems with the service, you may start by complaining direct to the ultimate service provider, but if you cannot sort things out you have to go back to the person/organization you have the contractual relationship with. There is a contractual chain which may not coincide with the operational information supply chain. However, there has to be a management control chain (higher level information supply) that supports the contractual chain.

In some of these sectors there is a serious risk of disintermediation. For example, many people have stopped using travel agents, and book their airline tickets directly with the airline over the internet. This is possible because the airline domain is just as accessible to the travelling public as to travel agents - in some cases more so. (Sometimes the agents don't have access to all the microservices. And sometimes even the airline employees don't have access to all the microservices. See this example.)

What about the next step? Can you disintermediate the airline by chartering your own plane? This is possible but it's a lot more difficult for two reasons. Firstly because it takes you to a different level of granularity - you have to charter the whole plane, not just one seat. Secondly, the aeroplane-chartering domain introduces (makes visible) a lot of new complications. One way of putting this is that if you want to charter a plane, you have to learn a different Domain Specific Language (DSL).

In many (perhaps most) business sectors, the input DSL is different to the output DSL. So the information supply chain involves considerable processing (transformation).

Let's consider the pharmaceutical industry as a much more typical example of a complex supply chain. A drug company produces a drug, together with lots of information relating to the drug. There are several different categories of information user: the patient who takes the drug, the medical practitioner who prescribes and/or dispenses the drug, the health service or insurer that pays for the drug, and the regulator who monitors the safety of the drug. The translations and transformations between these information domains calls for careful negotiation, not just mechanical mapping.

Many of the SOA champions are over-simplifying the picture by using examples where there is a single domain. The trouble with this is that the examples aren't very interesting, and moreover invite disintermediation. To find sustainable business benefits from SOA, we need to look at more complex ecosystems. Like pharma.

(Anyone with good examples, or interesting problem domains, please contact me.)


Related posts: Straight-Through Processing 2 (April 2005), Straight-Through Processing 3 (March 2009)