e-Referral Pattern: Roles and responsibilities of the actors involved

To recap:

In a previous blog post I introduced the concept of the e-Referral pattern - as an atomic structure. The most basic premise of the pattern is that there is communication between 2 parties via a channel of some sort.

At either end of the channel are trusted points of data/information production and consumption. The channel by which the end points communicate is can be anything, the key consideration is that the channel is not trusted (to be secure, private or reliable).

Security is not the same as privacy and reliability has nothing to do with either security or privacy.

Let's mitigate reliability first by assuming that any channel can be made to provide a reliable transfer. By way of example, HL7 uses ACK/NAK messaged, SMTP could use return receipts and messages, MOM layers use abstracted logic and a telephone company may have a SLA (Service Level Agreement), etc.

For example purposes I have implemented this pattern using Microsoft Office Outlook and Word (2007).

So the three actors involved in this process are:

1. Producer
2. Channel
3. Consumer

The functions each of these deliver to the solution requirements

1. Producer
   1. Select consumer
   2. Create data
   3. Sign data
   4. Encrypt data
   5. Send to channel
2. Channel
   1. Transport data
   2. Assure reception
3. Consumer
   1. Receive data
   2. Acknowledge reception
   3. Decrypt data
   4. Validate data
   5. Review data
   6. Store data

Using a gap analysis technique to review these requirements for risk profiling, we are able to see that there are 3 levels of functional responsibility:

1. Bespoke code: code which has to be written from scratch as the underlying base (OOB) functionality does not present this.
2. COTS sequencing: code which links basis functional points in a specific sequence to deliver solution requirements
3. OOB functionality: "Out-Of-the-Box" functionality or basis functionality. Operations which the software delivers without any further development required.

If we assume that the most dangerous point in any development is Bespoke code then we are able to equate a simple risk profile to the amount of solution core functionality that needs to "hand developed". Any bespoke code needs to be thoroughly tested and QA assessed for implementation.

In this solution there are 13 functional points for development, of these 5 are bespoke. The (estimated) risk profile is 5/13 = 38%. Compare this to having to develop the producer and consumer code in total (not including the word processing capabilities) and the risk profile there is 11/13 = 84%.but that is my own mad way of thinking and not something official.

I have already made this work in this way using Microsoft Office Outlook and Word 2007, so I know it can work. The beauty of the e-Referral pattern is that is can be applied to any producer-channel-consumer sequence, on any platform and using any technology (even a letter!)