A Patient Centric Approach to Medical Data using Containers

There are 300+ Electronic Health Record systems (e.g. EPIC, PACS etc) in the UK installed within individual trusts, hospitals and surgeries. These systems have poor interoperability, few standard APIs, and view data ownership as belonging to the care provider rather than the individual. The current UK EHR approach is poor for researchers because the lack of APIs and interoperability reduces research’s ability to glean discovery from the widest possible data sets. This impact on research also has a knock-on effect on diagnosis.

An alternative approach is to have the Patient owning their own medical data. This is not a new concept and has been criticised in the past for potentially allowing the hyper scalers (Google, Microsoft, Amazon, Facebook) to own patient data. There can be though a happy medium between EHR centralisation and commercial Health applications. This opportunity is provided by containerisation technologies like Docker and Containerd.

Current Fragmented Situation

The current EHR model in the UK is one of multiple deployments of bespoke non-interoperable solutions across different Trusts, Hospitals and GPs. Data often has to be manually re-entered between systems with a reliance on legacy methods of data transfer. Interoperability cannot be radically achieved in this model as the number of possible integrations becomes the Cartesian product of the number of EHR systems.

Current fragmented Electronic Health Record Systems

The introduction of NHS Number allows the mapping of data between EHR systems. But this form of keying without digital transformation means that the architecture is always in a request and wait approach. The receiver must request the data and await the provider to push the data. With this approach there is no way of discovering what data is available in advance or for verifying the data quality before it is received. This model also has an implicit long request time approach requested between systems. This causes waste in terms of data request times and can detrimentally impact the patient’s quality of care.

Patient Centric Model

The alternative is a patient centric model. In this approach the Trust, Hospital and GP surgery request from a ‘centralised’ (there can be multiple providers) which provides standard APIs for querying all relevant patient data. The same APIs provide a write-back mechanism. The same Read APIs can anonymise the data so that patients can choose to opt-in for research benefits.

Patient Centric Data Vault integrated with EHRs

In the Patient Centric model all of the patient’s data is held within a personal vault that can only be accessed externally by APIs at the discretion of the patient. The hospital, trust and GP surgery keep their existing EHR solutions in this model and consume the master data record from the personal data vault. The local EHR systems then write their data back to the master source.

Access control the personal data is provided by a Permissions, Grants and Attestations component. Permission to share and grants always time based and are at the discretion of the patient. Medical institutions can request data with attestations and history stored within the system. Any fraudulent authentication attempts are registered and flagged to the user. The API requests are keyed on multiple attributes including NHS Number, Citizen ID, Staff ID. Research permissions follow the same model with access requests keyed on verifiable research IDs including Institution ID and University IDs.

Structured & Un-Structured Data

Personal data can be held as a series of record ‘bundles’ in a file system format. Data is logically grouped by department definitions and can be extended for other areas such as Research, Demographics and Social Care. This data is accessed by Hospitals, Trusts & Surgeries using the APIs. These APIs provide semantically structured extensible data making use of Graph API technologies which provide the benefit of not requiring versioning.

The Graph APIs conform to the Open APII standard as expressed with the NHS UK’s Open API Architecture Policy. The APIs provide GET and POST functions for Patient and Record data. The bundle data is encapsulated within these Graph APIs.

The same Graph APIs can support anonymised Research functions for reading available research data. An academic institution would then register for this service and would be provided with a unique key for accessible data. The only accessible data would be the data permissioned by the patient which is discoverable by a final GET Research Available Data service.

Cloud & Containers

The key to this architecture is a cloud deployment of a unique ‘container’ per patient. The container represents a specific file system for each user. The technology used would be an actual Container technology like Docker of Containerd. The container would contain all of the patient data in its local file system.

60 million ‘Containerd’ patient data vaults

With millions of containers the solution needs to optimise the computing resource according to demand. This can be achieved by bringing containers to a hydrated ready state upon demand. To ensure guaranteed data availability all containers will be automatically backed up across two physically different data centres at any one time. All transactional updates will be persisted for 6 months in case of any necessary roll-back.

Conclusion

Building a Patient Centric Model would require centralised funding and competitive tendering allowing for multiple providers to provide services. The total cost would be lower for a majorly improved service than the current distributed EHR model. This approach would also create an internal market of AI driven application and self-care applications that can consume from the Patient API; MyUCLH is such an example.

To recap, there is considerable GDPR, personal analytical, data accuracy, early diagnosis and research benefits from such a model. This approach is conceptually different and would transform the quality of patient data across the NHS. It is implementable on provable solutions that can be reused from industry. It provides benefits to the Patient (proper ownership of data, ability to switch, GDPR), benefit to the NHS (ability to access multiple data, better architecture than any previous data collaboration model), and benefits for Research (access to open data).

A 5G Data Fabric

February 28, 2019 mustnotgrumbleLeave a comment

Most 5G deployments will not be greenfield. But a successful 5G deployment is not limited to simply deploying new radio on existing sites. It requires a new approach to telecom IT that can both simplify the telco’s estate and prepare for the new business opportunities of 5G. A complete data fabric (for 5G or for everything) will support both the business opportunities and the network complexities of 5G.

A data fabric includes all of the necessary data services for operating a mobile network and providing connectivity and ‘beyond connectivity’ services. This means offering the many different persistence storage toolsets to your business logic layer (as represented by micro-services in docker). An application can then utilise the most appropriate persistence technology for their requirements. For example, this could mean exposing a RDBMS for structured data, a Graph for modelling topologies and document storage for persisting YANG documents.

Data Fabric for a Micro Service Architecture

The business value of the data fabric is that it allows the clever telco to disassociate their software requirements’ from the data plane. Thus enabling a micro-service architecture that can manage a virtualised network; and then on top of that expose services to their customers.

Key data fabric use cases for 5G include:

A network planning architecture for geo-planning cell site deployments including in-building
A network topology architecture that can model a highly complex network and enable Self Organising Networks
A time series streaming architecture that can model events coming off a network and a customer’s deployments and enable effective Machine Learning driven autonomic improvements
A network orchestration architecture for a virtualised network (full or partial)
A network slice management and guarantee architecture (with support for a blockchain based service level guarantee)
A subscriber data management architecture for unified value added services and subscription

The following is my description of a logical data fabric for a 5G implementation. I am publishing it because it can help network operators to push their software vendors to decouple the software’s logic from its data persistence. Below are all the logical tools needed:

RDBMS for ACID based transactions that are useful for physical inventories, managing subscription updates (less so reads) and all other structure data
Graph database for modelling network topologies, relationships and dependencies. Very useful for machine learning, root cause analysis and spotting previously unknown interconnected loops between items
Wide column database for dealing with unstructured extensible datasets that include all the different devices supported on a 5G network. Very useful within IoT and customer network experience.
OLTP NoSQL database for offline analytical processing including network topology efficiency modelling and network performance analysis as part of an ITIL Problem / Change Management process
Document datastore for managing Infrastructure as Code and Virtual Network Function deployment descriptors in the form of YANG documents. Useful in blockchain contracts and services.
In Memory Datastore for fast reads and data caches
Geo-spatial database for modelling RAN deployments and radio propagation. Incredibly important as RAN efficiencies have a major bottom line impact. Increasingly need to support in-building information for small cell deployments. Needs to work together with other radio technologies including 5G.
Time series database for performance monitoring which can be implemented within the customer network experience function of a wide column database and with use of Grafana and Prometheus

Some 5G Data Fabric Use Cases:

	RDBMS Database	Graph Database	Wide Column	OLTP	Document Data Store	In Memory Database	Geo-spatial Database
Network Plan & Build and Analysis	Y			Y			Y
Physical Network & Static Inventory	Y						Y
Virtual Network & Dynamic Inventory		Y			Y
Fast Read Inventory		Y				Y
Streaming Fast Analysis		Y	Y
Offline Event Analysis		Y		Y
Subscription Management & Entitlements	Y					Y

In conclusion, most telcos have bought siloed commercial off the shelf products for individual specific use cases. This has meant that the telco has often only used as little as 40% of the intrinsic value of their commercial software licences. The cost of building 5G will be high, and the greater share of the prize will go to the most agile operators. It is therefore incumbent on mobile operators to drive the greatest efficiencies from their software investments.

5G is a great driver for change. The most effective 5G operators will be those that can get their data architecture right first time. Telecom operators must start moving to a data fabric.

Bringing IT (OSS) all together

March 2, 2018March 2, 2018 mustnotgrumbleLeave a comment

I try and fit components together logically so that they can make the most of what the technology offers. I work predominantly in the OSS world on new access technologies like 5G and implementations like the Internet of Things. I want to achieve not just the deployment of these capabilities but to also to let them operate seamlessly. The following is my view of the opportunity of closed-loop remediation.

For closed-loop remediation there are two main tenets: 1. you can stream all network event data in a machine learning engine and apply an algorithm like K-Nearest Neighbour 2. you can expose remediation APIs on your programmable network.

All of this requires a lot of technology convergence but: What’s actually needed to make everything convergent?

ClosedLoop

Let’s start with Streaming. Traditionally we used SNMP for event data, traps & alarms and when that didn’t work we deployed physical network probes. Now it’s Kafka stream once implementations where a streams of logs of virtualised infrastructure and virtualised functions are parsed in a data streaming architecture into different big data persistence.

The Machine Learning engine, I’m keenest of FlinkML at the moment, works on the big data persistence providing the largest possible corpus of event data. The ML K-NN can analyse network behaviour and examine patterns that are harder for human operation teams to spot. It can also predict timed usage behaviours and scale the network accordingly.

I am increasingly looking at Openstack and Open Source Mano as a NFVO platform orchestrating available virtualised network functions. The NFVO can expose a customer facing service or underlying RFSs. But to truly operate the ML should have access to the RFS layer. This is the hardest part and is dependent upon the underlying design pattern implementation of the Virtual Network Functions. This though is a topic for another blog post.

M2M ARPU Requires A Reference Architecture

October 7, 2014 mustnotgrumbleLeave a comment

The GSM Association (GSMA) put the M2M market size at $1.2tn revenue with 12 billion connected mobile devices by 2020. These numbers alone are enough to excite the most conservative of operators and wobble the subscriber-centric business models that currently prevail. The existing model adopted by MNOs that the more subscribers it has, the more successful and profitable it is considered to be, is about to be tested by this massive new market. This is mainly because the Average Revenue Per User (ARPU) in the M2M business is on average below ten cents per device, but on the other hand the connection density can be virtually endless. So success will depend on how dynamically the CSP reacts to provide new and flexible platforms to support the every-day new devices, applications and verticals that M2M will address.

Because of the low ARPU and massive market multiplier many MNOs should be prepared for a shake-up of their OSS which will have to fulfil and provision at bulk and at low cost.

IPv6 addressing will also make M2M services not just a mobile proposition, but applications that can work seamlessly across both mobile and wired broadband connections. eUICCs and wifi hand-off will have to be included in the new OSS. Furthermore Near Field Communication will require its own billing model.

Never before has a reference architecture been so required for M2M.

All of this does not just apply to the MNOs anymore.

BSS for the IoT: You Don’t Have To Be A Mobile Network Operator To Do It

September 22, 2014October 1, 2014 mustnotgrumbleLeave a comment

The Internet of Things is not predicated on mobile or fixed-line operators. It is predicated on the value derived from the interplay between different sensors and actuators. In the history of mobile telecommunications it was the mobile network operators who provided a service that brought together radio waves and handset manufacturers. The success of mobile telecommunications has led to a 93.5% global saturation rate (source Informa) with the conglomerate operators China Mobile Vodafone. Airtel and Verizon etc being the big winners.

Continue reading “BSS for the IoT: You Don’t Have To Be A Mobile Network Operator To Do It” →

A Scottish Safe Harbour for Identity Management

September 10, 2014October 1, 2014 mustnotgrumble1 Comment

The Data Protection Directive (officially Directive 95/46/EC) regulates the processing of personal data within the European Union and also provides the criteria for Safe Harbour privacy for companies operating within the European Union. The Safe Harbour regulations forbid sending of customer’s personal data to countries outside the European Economic Area unless there is a guarantee that it will receive adequate levels of protection. There are no Safe Harbour considerations for EU companies with services deployed to Scotland while Scotland is part of the UK and when Scotland has become independent of the UK and joined the EU as an independent country. However there may be a period of time between Scotland becoming independent and joining the EU (as an independent country) when Safe Harbour requirements really matter. At this time no EU company will have a Safe Harbour agreement with the newly independent Scotland. Therefore any company with Identity Stores (or business systems containing personal data) deployed in Scotland will be in breach of the Data Protection Directive. Scotland Id Store 7 PNG

Continue reading “A Scottish Safe Harbour for Identity Management” →

Identity Broker Service in SAML: Supporting Multiple Identity Providers & Service Providers

August 4, 2014August 4, 2014 mustnotgrumble1 Comment

This blog is part of a series comparing the implementation of identity management patterns in SAML and OpenID Connect:

Identity Broker Service in SAML

A federated organisation may have multiple distinct services (service providers) where each service is protected under a distinct trust domain. The same organisation may wish to trust multiple external & internal identity providers and allow the end user to select their preferred identity provider. Furthermore the same federated organisation may require greater levels of certainty for specific services and may wish to limit the available identity providers for a specific service or enforce step-up authentication on the identity provider. This pattern is useful for governments and enterprise’s wishing to move away from a Push Model for Enterprise Identity Architecture.

In order to support multiple services and multiple identity providers and possible multiple rules an Authentication Broker Service is required. This model is often known as either a Hub Service or Chained Federation. The following sequence diagram explains how the pattern would working using <saml:AuthnRequest> (SAML 2.0) and <saml:Response> between four parties (User Agent, Service Provider, Authentication Broker Service and Identity Provider):

The User Agent access a specific Service (There can be N+ service providers depending on the organisation)
The Service Provider sends a <saml:AuthnRequest> to the registered Authentication Broker Service (limitation that an SP must be mapped to one Broker)
The Authentication Broker Service holds a list of Identity Providers trusted by the Service Provider and returns this list to the User Agent
The User Agent selects their preferred Identity Provider provided as a list by the Broker
The Broker service generates a new <saml:AuthnRequest> which it forward to the selected Identity Provider
The Identity Provider challenges the user agent
The Identity Provider authenticates the user agent
The IdP returns the <saml:Response> to the Broker for the authenticated principal
The Broker returns the <saml:Response> to the Service Provider (which may choose to match against any mapped identity)
The Service Provider grants access to the User Agent

Note a slightly different pattern would be to pass a reference to a SAML artefact between the Broker and the SP. This would use the <saml:ArtifactResolve> element in the message passed back from the Identity Provider. This pattern would require a direct service between the SP and the IdP to resolve the attributes in the artefact. This pattern extension is only recommended when the authentication request can be deferred when multiple profile attributes are required from the identity provider.

Example: UK Government Identity Assurance Hub Service SAML 2.0 implementing the OASIS SAML V2.0 Identity Assurance Profile

Nomenclature: Terminology differences between OpenID Connect & SAML

Remote Control Soufflés: Challenge of M2M Authentication & Authorisation and Mobile data offloading

July 14, 2014 mustnotgrumbleLeave a comment

Some M2M devices will always connect to the internet using a fixed network connection / Wifi and others will always connect using a mobile network connection using an eUICC but there will be some that will offer both wifi and mobile network. It is these devices that will need to support wifi offloading where possible. It is for these devices where providing a standard API gateway and AuthN & AuthZ capability will be most complex.

For example, my oven is always positioned in my kitchen and connects to the wifi network to allow me to view inside by a mobile app so that I don’t have to open the oven door during the fifteen minutes a soufflé takes to rise that would cause the temperature to change and my soufflé to collapse. This way I can inspect and control the temperature remotely. It also mean I have an excuse to check my phone during boring dinner parties. Only my app is paired to the oven so only I am authenticated and authorised to remotely check on my soufflé thus there is no potential risk of a malicious guest could accessing my oven app and destroy the soufflé by changing the temperature.

Remote viewing would decrease flop rate — An M2M oven with embedded camera would decrease flops

The majority of my home m2m devices will be static devices, I rarely travel with my oven, and these will in the majority of cases be Wifi enabled. Unfortunately I cannot guarantee wifi coverage throughout my architect’s ivory tower so some mobile internet devices will need to connect over 3G/4G (for example the BBQ in the lower field). The problem for my oven and BBQ manufacturers is that they would need to support both Wifi and the GSMA standard for M2M / smart device SIMs (eUICC). It would then be responsibility of the m2m device to support wifi offload where available.

Authorisation may be necessary when the function of the device is shared amongst a group with one or many people acting as the super administrator. If I sell my oven all of my authentication and authorisation permissions have to be removed from the M2M device but as I will likely buy a new oven with more soufflé capacity I would like to keep my existing settings. Furthermore if my soufflé skills increased I may take a job in Paris and would need to reregister my oven’s eUICC or wifi connection. In this case I would definitely want to keep all of my authorisation permissions and maybe grant further permissions for all the extra soufflés I’d be baking.

Device resale and device portability are supported by the eUICC specification as they are necessary for widespread adoption of M2M devices. What is less supported is a common standard for AuthN & AuthZ that would allow me to keep my device preferences when I either move with or my devices or sell them and replace them with newer devices.

This is where OpenID Connect may be useful as it enables profile information on top of the authorisation model provided by OAuth 2.0. OpenID Connect 1.0 extends OAuth 2.0 so the client can verify claims about the identity of the end user, get profile information about the end user, and log the user out at the end of the OpenAM session. OpenID Connect also makes it possible to discover the provider for an end user, and to register client applications dynamically. OpenID connect services are built on OAuth 2.0, JSON Web Token (JWT), WebFinger and well-Known URIs.

It remains to be seen whether OpenID Connect will be integrated with the standards for eUICC as part of the GSMA Mobile Connect. Furthermore it will need to be supported by the wifi offloading devices (e.g. my BBQ’s manufacturer) as the standard for all M2M AuthN & AuthZ. It seems likely at first that device authorisation and later home M2M gateways will implement proprietary technologies and will maintain identity in individual walled gardens. My architecture ivory tower has a few of those too.