Architecture sets out how services fit together

How and why NHS Connecting for Health (NHS CFH) is creating a service-based enterprise architecture was explained by Jagdip Grewal, chief technical architect of NHS CFH, at the BCSHIF's April meeting. Helen Boddy reports.

Jagdip Grewal 'An enterprise architecture (EA) based on a service based model allows stakeholders to understand how everything fits together in the NHS,' said Jagdip. 'It means we all also use a common language; suppliers often have different terminology to us and this standardises what we mean.' 

In drawing up the enterprise architecture, NHS CFH defined a set of architecture domains for integration, security, channels, local and enterprises services.

Across these domains are a set of principles, standards, policies and guidelines (PSPG), and each domain consists of a set of conceptual services. These define at a high level what NHS CFH is trying to achieve for the customer in terms of business (e.g. care management) or technical services (e.g. national integration).

'We've taken our services and assumed the key thing is the customer,' said Jagdip. 'When we give the application to the user we have to know how it fits together for the user. We have to talk the same language. We took the high level aims and mapped them out.'

The NHS enterprise architecture is being drawn up so that it aligns with the cross government EA. This will help interaction with other government services involved in healthcare.

The conceptual services - business services at the top level - map back to  requirements. These conceptual services were then grouped into logical applications (e.g. patient administration) for specific areas. The physical instances of these logical applications are the systems deployed by our suppliers.

Once the way forward has been modelled, suppliers can be mapped onto the architecture and their conformance to PSPG evaluated. Standards are key for the technical service level.

'We have to have standards that allow interaction between suppliers' systems,' said Jagdip. 'We will never just have one supplier so we need a way of joining them up. By including guidelines and standards in the architecture, it is also possible to easily see which suppliers are not up to speed yet.'

All supplier contracts are around standards, which have been chosen so that it is possible to achieve interoperability. That means:

  • use of ebXML (https, SOAP, xml);
  • use of SNOMED CT;
  • use of HL7 v3 and HL 7 CDA v2.

Once the standards were set, it was possible to give detailed specifications to the systems designers.

'We have adapted Health Language 7's Clinical Document Architecture but using an evolving strategy that aims to get everyone to the end point,' said Jagdip.

'We are using a set of templates to tell suppliers how to code the information. Not all suppliers will be able to fully code the information from day one, but over time all will reach the required standard. We will be in a mixed economy for many years, with thousands of systems going through upgrades. Thus using standards will enable us, over time, to increase the compatible coding of clinical information flows, which are necessary between systems in different care settings.'

He gave the example of GP Systems of Choice (GPSoC) where this is a national framework using standards. The NHS has to make sure it sets the right standards, and then encourage suppliers along the maturity path to achieve certain points over time.

'The use of open standards (ebXML and HL7) has enabled us to expand the number of suppliers to the programme. We have now integrated hundreds of suppliers through open standards implemented by our national service providers,' said Jagdip.

There are 13,900 instances of systems integrated to national services, which produce 120,000 prescription messages per day, 17,000 bookings for Choose & Book and 1.4 million demographic queries.

Integration of a huge number of deployed web services presents certain challenges as suppliers are often interacting with different versions of web services.

'We therefore have to be careful how we define the services and get the versioning right,' said Jagdip. 'You can't expect everyone to upgrade all at one time. We need evolution of services, not revolution.'