I have almost certainly posted about this before but the topic came up again recently so I thought I’d just run through the differences in e-Quip between geography and organisation. Have a look at the home page of a typical hospital – your own web site probably looks very similar.
Take a look at the sections that I’ve highlighted in red boxes. At the top, right-hand corner is the Trust name (“The Leeds Teaching Hospitals NHS Trust“). In e-Quip, this is known as a Health Care Provider, or just Provider for short. Why don’t we call it a Trust? Well, for you it might be a Trust, but in Scotland & Wales these are known as Health Boards, but you would also use this field for CCG’s, private healthcare providers etc.
In e-Quip, a provider may comprise many sites and services. On the web page above you can see links to “Our Hospitals” and “Our Services”.
Hospital are referred to as as Sites in e-Quip. Why site rather than hospital? Not all sites are hospitals – they could be ambulance stations, community health centres etc. Sites are geographic place that you can physically visit. You could probably find them on a map.
What about “Our Services”? These are organisational entities, not geographical. For example “Children and Young People’s Services” may operate across many different hospitals across the Trust. You won’t find services on a map. You can’t actually go to “Children and Young People’s Services” (although you might go to one of their wards, clinics or offices, or maintain equipment for them).
What about those wards, clinics or offices, where do they fit into e-Quip? Although it’s not shown on this web page, there is a “Patients & Visitors” link which takes you here:
These are physical, geographic places that you can visit. You will often find them on way-finding boards around a hospital. In e-Quip these are held as Locations.
So, from an organisational perspective, Healthcare Providers are made up of one or more Services, while in geographic terms, Sites are made up of one or more Locations.
That is all very simple but at first glance appears a bit limited. How can we say that “Ward L12” is on the 3rd-Floor in “Jubilee Wing”? Older systems used to often have a fixed level hierarchy, like “hospital – building – floor – ward” but this was never a good idea; it forced you to use multiple levels even if you didn’t want to and restricted you to a maximum number of levels. e-Quip gets around this by making allowing parent & child locations. Rather than having 3 separate screens (building, floor & ward), you create 3 separate locations (Jubilee Wing, 3rd-Floor & Ward L12) and then link them so that:
Ward L12 is a child of 3rd-Floor
3rd-Floor is a child of Jubilee Wing
Remember that you don’t necessarily need to use multi-level locations. If everyone knows where Ward L12 is, then don’t bother with this extra complication. When working with multiple levels, equipment is normally assigned to the lowest level (Ward L12, in this example) although you can make exceptions if things move around. For example, if a Mobile C-Arm is normally parked in a corridor on the 3rd floor of Jubilee Wing, then you could assign that as its location. Perhaps the most common situation where people make use of this feature is in operating theatres where a theatre block is made up of several individual locations (Theatre 1, Theatre 2, Recovery etc) with some equipment fixed and others which move around within the block.
Multi-Level Sites & Services
Locations aren’t the only multi-level items in e-Quip; sites and services also support this capability. With services, then the idea of multi-level departments is quite common: NHS Divisions & Directorates are effectively multi-level services.
The concept of a hierarchical site is not quite so natural. A location within a location is easy to imagine, but a hospital within a hospital? Multi-level sites (we call them virtual sites) are normally used when users want to group sites together. Large organisations find this particularly useful:
This makes it very easy to find all equipment in a given area.
There are also reasons for smaller organisations to use virtual sites. You might manage devices for many GP’s Surgeries, which you would record as individual sites. It is useful to create a virtual site called “GP Surgeries” and make the individual children of that. In that way you can easily search for all equipment in every GP surgery.
Linking Geography and Organisation
From the Leeds website we can see that there is a service named “Children and Young People’s Services“. This service has devices in many locations, such as Ward L10 (Children’s Renal, Liver & Gastrology) and L11 (Children’s Dialysis). In e-Quip it is possible to link a location to a service. This means that all devices added to those locations will automatically be assigned to the appropriate service, although this can be changed.
Overlaps Between Geography and Organisation
It is not uncommon for there to be a location and a service with the same names. It is important to bear in mind that they are different things. For example, a Trust may have a Radiology Service and a Radiology Location. How are they different? First of all the Radiology location is a physical, geographical place; it will be part of a specific site. The Radiology service is an organisational entity- it may manage locations (one of which would doubtless be the Radiology location) at multiple sites.
Look at the device below:
It is physically located in the Radiology location at the Leeds General Infirmary – that is its geography. However, it is the responsibility of the Radiology service at the Leeds Teaching Hospitals NHS Trust. That location may contain devices which are not managed by the Radiology service and similarly, that service will manage many other devices apart from those in that location. Although these two entities have the same name they are fundamentally different concepts.
What is a Base Filter?
A base filter is a normal filter (it has to be saved as shared) that is applied automatically by e-Quip in addition to any filter that the user sets. Users can’t see base filters, and they cannot override them. Base filters are created and edited in exactly the same way as any other filter, although they can only be assigned by administrators. You can assign up to three base filters for each screen at the following levels:
a. User: applies to an individual user only
b. Group: applies to all members of a group
c. Role: applies to all members of a role
Suppose that a user is a member of a role called ‘Engineers‘ which has an equipment list base filter of [Equipment Status Class = ‘Active’]. The user is a member of the group ‘East Cambs Engineers‘ which has an equipment list base filter of [Site = ‘East Cambs Hospital’]. A particular user within that group might be responsible only for servicing defibrillators and the administrator may assign him a user-level base filter of [Category = ‘Defibrillator’]. When using the equipment screen, every search that the user makes will always be prefixed by:
[Equipment Status Class = ‘Active’] AND [Site = ‘East Cambs Hospital’] AND [Category = ‘Defibrillator’]
There is nothing that the user can do to prevent this. The user himself may have an individual default filter of [Team = ‘EBME’](note that a user’s default filter is not the same thing as a base filter). On opening the equipment summary screen he will see all active defibrillators at the East Cambs Hospital assigned to the EBME team.
What would happen if the user tried to circumvent this by searching for all infusion pumps? Although he might set a filter like [Category = ‘Infusion Pump’], the filter that would actually be applied would be:[Equipment Status Class = ‘Active’] AND [Site = ‘East Cambs Hospital’] AND [Category = ‘Defibrillator’] AND [Category = ‘Infusion Pump’]
This would never return any data, as it is not possible for a device to be both an infusion pump and a defibrillator.>
A base filter is not the same as a default filter. Base filters are always applied in addition to any user filters. While users may create their own default filters, base filters are imposed by administrators. Users cannot see base filters and in general would be unaware of their existence.
As such, they are used to restrict users’ view of the database, in much the same way as the Footprint Manager.
Why not use the Footprint Manager Instead?
The Footprint Manager is an extremely powerful way of restricting the dataset that a user can see. However, despite its power it has some limitations.
a. It is entity-based, rather than screen-based
In the Footprint Manager you might for example, define an inclusion on [Site = ‘East Cambs Hospital’]. This inclusion works on every screen, so that the user will only see equipment at East Cambs Hospital, will only see locations at East Cambs Hospital, will only see jobs at East Cambs Hospital, spare parts at East Cambs Hospital, and so on. You might want the user to only see equipment at East Cambs Hospital, but still allow him to view spare parts at other sites. This cannot be done with the Footprint Manager.
b. The problem of missing data
Suppose that an engineer works only on Philips equipment and you set an inclusion on [Supplier = ‘Philips Medical Systems’]. Note that there is more than 1 supplier field on the equipment screen; there are at least 6 separate suppliers: the original purchase supplier, new purchase supplier, spare part supplier, training supplier etc. If a user can only see data where the supplier is Philips Medical Systems, then every one of these supplier fields would have to be set to Philips Medical Systems. This is not going to happen in practice. For a large number of records many of these suppliers fields will be empty.
So if there is a device which was purchased from Philips but for which no training supplier has been set, this means that if users with this inclusions are to be able to see the device then they must be able to see devices where a supplier field is either Philips Medical Systems or is empty. This is problematic, because now these users can not only see Philips equipment, but any equipment where any supplier field is empty. This is a considerable problem,
c. Hierarchical Data
Suppose that a group of users work from a workshop associated with Operating Theatres, and are only interested in equipment located within the theatre block. If the Theatre Block is comprised of multiple locations (Theatre A, Recovery, Theatre B, Recovery, etc), then using the Footprint Manager, each individual location must be added as an inclusion. If a new location is added, then it must also be added to the inclusion.
Ideally, it would be better to have a filter of [Location Path starts with ‘/Theatres/’], which will pick up all sub-locations of Theatres, but this is not possible with the Footprint Manager.
How do you Assign Base Filters?
The User, Group & Role Managers have been modified to allow you to assign base filters at the appropriate level.
Base filters can be a much simpler way of restricting a users’ dataset. They can be used on their own or in conjunction with the Footprint Manager to give you very fine control over what data users can see.