Around the NHS, there is a lot of interest in the idea of using a portal to deliver a combined view of data in an electronic patient record. Yet I find that the definition of a ‘portal’ varies and is often unclear.
I think that before I can decide whether I want one, I have to decide what one is. The best definition I could find is: “A doorway, gate, or other entrance, especially a large and imposing one.”
At University Hospital Southampton we have a single sign-on to a product set that includes most of what people want to do, and that includes a view of the Hampshire Health Record, our local shared care record.
I don’t think of it as a portal, and usually try to explain that it isn’t a portal for a variety of reasons. However, when I was demonstrating some screen shots and talking about it recently, one enlightened individual said: “Well it looks like a portal to me”. So is it, and why does it matter anyway?
So why isn’t Southampton following a portal model?
I would make a distinction between pulling data from different sources into a view, and actually having native functionality that interacts directly with the source data at a read/write level.
There is a case for views on data, particularly on mobile platforms where we do not need access to complex data entry screens and so forth. And we do have some views of data, so I guess we do have a portal, or some parts of one.
But what happens when you are looking at a set of results or other part of a record in a “view” and you need to carry out an action, such as place a request, or add some data?
Sometimes that data will have a place (database field) in an underlying application; sometimes it will be relevant to many underlying applications (a data item such as weight); and sometimes it will be new, such as VTE assessments a couple of years ago. If a portal is just a view of the record, it can get out of its depth pretty quickly.
Sometimes, the approach is to build a repository, and call that a portal. Technically, the portal would be the view of the repository, which is where the relevant data from all the underlying applications is pulled into a new data model and treated like a superset of the data.
At this point, it is possible to add data fields to this model and start to build new functionality that could not be built before due to the disparate nature of the data.
This all sounds very well, but those underlying applications still exist, and their users will need to know what has been going on with certain data at the repository/portal level.
As soon as you go beyond views on data, you need the items on the screen to relate directly to the true source data.
This can either be a true direct relationship, where the application sits on top of the database, or can involve some kind of interfacing or synchronisation technology. In the second case, you put the data in the repository and then synchronise it back with those applications that know about the data item.
Although it’s easy to say that, nowadays, we can pass any data between systems, it is not that easy in practice. Often we need to know more data about the data for this to happen successfully, and for many of these data types there will be no standard way of doing it.
For most of what we do at University Hospital Southampton, data is entered directly into its true place in the electronic patient record database, and any view is created from there. This native functionality is why I am inclined to say we don’t have a portal.
Where an application such as electronic prescribing has its own database (in separate technology – Cache rather than Oracle), the application itself is run under a frame in the browser.
Although it means an encounter with a different user interface, the all important data remains consistent. Would most people call something a portal if a separate application is running in a browser window?
Are portals just for community access?
In an acute hospital, everything has to happen in real time. The consequences of inconsistent clinical data are both fast and dire.
The need to truly interact with, add to and modify source data is never far away. The risk tends to dilute as we look across the traditional organisational boundaries.
With a good level of use of the NHS Number, systems can mine data from the sources they need to produce the views, and present an overall picture of a patient that can be valuable. Is there a case for saying this approach is useful ‘here’ but not ‘there’?
Who is responsible?
An interesting issue that arises when data starts to be passed around and represented is ‘who owns it’ contractually.
If I have a contract with a prescribing vendor, then the data in its database is covered by the contract with them. If I take that data and put it into a repository, I am responsible for that copy always being an accurate version of the latest data.
Ensuring and proving that can be a tricky business. If I have a separate vendor for the clinical data repository, can I get that company to take ownership of it?
In the picture archiving and communications system world, the IHE standard for exchanging data is XDS (and XDSi). Within that, there is a full audit trail in a component called Audit Trail Node Authentication. Do we need to build more of this kind of thinking into what we do in portals?
Panacea
So, when I hear people saying “we are buying a portal”, I often wonder what they mean. Sometimes I think it is used as a throwaway line; and maybe some vendors are guilty of selling a panacea. I tend to think if something looks too good to be true it usually is. There is a case for portals, but it needs to be thought through very carefully.
Adrian Byrne
Adrian – Ade – Byrne is director of IM&T at University Hospital Southampton NHS Foundation Trust which, he says, has been working on its IT environment for 15 years.
On his LinkedIn profile, he says its aim is to “build an electronic patient record with full decision support, sharing data across disparate, so-called best of breed systems.” The trust is also developing a patient record and services, built on Microsoft HealthVault.