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.
If you haven’t already, it is strongly recommended that you read this blog article about groups & permissions before you look into group footprints. Just to recap, a footprint defines the parts of the database that a group of users can see.
The “Hospital A” group can maybe just see their own data, and likewise the “Hospital B” group might be only able to see theirs, but an administrator would be able to see data across both sites. This is not the same as a permission: all three groups have read access to equipment (for example); the footprint defines the data that they can actually see.
If you are going to split a dataset up into different chunks that can be seen by different people, then you will need some discriminator. i.e. some way of identifying which users can see which chunks. For example, the e-Quip database might be used by several completely independent sets of users; such as: Medical Physics, EBME, Facilities etc. How is it best to say, “this supplier is here for the Facilities users“, “this model is here for Medical Physics users“, etc? In some cases this is easy. You might, for example, be able to say, “this data should only be visible to users at Hospital A“. However, it can rapidly get quite complex. It might be that a spare part must be visible to users at both “Hospital A” and “Hospital B”, but the individual bins should only be visible to the appropriate site.
Far and away the most commonly-used discriminator in e-Quip is the team. It is for this reason that almost every screen in e-Quip has a team field. In the simplest case we simply define teams for “Hospital A” and “Hospital B“. We will dig into how this works, why it sometimes doesn’t and then some more complex alternatives.
How is a Footprint Different from a Filter?
Would it be sufficient to just create a base filter (i.e. a filter that the user can’t remove) for each team? Could you just add a filter of “… AND Team = ‘Hospital A” onto every search that “Hospital A” users make? Well, you could, but you would have to do this for every single screen. e-Quip allows you to create a base filter for every screen for a group but this would be quite time-consuming to manage. This would work, but wouldn’t handle lookups properly, since lookups can work from any screen. For example, you might have an equipment filter that says “… AND Team = ‘Hospital A” so you can only see “Hospital A” equipment, but if you were selecting the location for a device using the location lookup, the location lookup isn’t aware of equipment filters and so the lookup would show locations at all hospitals.
What we really need is an “entity-specific” mechanism rather than a “screen-specific” approach. This means that when we specify “you can only see information for Hospital A“, this restriction applies not only to every screen, but also to lookups. This, essentially, is the purpose of the Footprint Manager. While filters are screen-specific (and do not apply to lookups), footprints are entity-specific (and do apply to lookups).
Inclusions & Exclusions
The Footprint Manager takes discriminators and says “you can only see …” (an inclusion) or “you can never see …” (an exclusion). If you use a footprint to say “members of this group will only see data where the Team = Hospital A“, then this applies across all screens and also applies to lookups. These users will only see equipment, jobs, contracts etc., which have been assigned to the team “Hospital A“.
You might also want to specify a footprint by saying what users can’t see. A footprint might say “members of this group will never see decommissioned equipment“. If we combined these this might mean that “members of this group will only see data where Team = Hospital A but never show decommissioned equipment“. This would apply to every screen, so if the user clicked Show All Records on the equipment screen they would only see equipment assigned to the team Hospital A which was not decommissioned. The same reasoning would apply when raising a job; it would not be possible for a user with this footprint to create a job for a device for a team other than Hospital A, or for a decommissioned device.
So, an inclusion means “you can only ever see …”, while an exclusion means “you will never see …”.
Would you ever have an Inclusion and Exclusion on the Same Data type?
Basically, no! Is it meaningful to say “You can only ever see data from Hospital A and you will never see data from Hospital B“? If you can only see data from Hospital A there is no need to say that you cannot see data from Hospital B.
Using the Footprint Manager
The Footprint Manager is extremely simple to use. It is an external application under the Tools program files menu (depending on your operating system). When you run it you will be asked to enter a username and password. Once you have logged in you will see a list of groups. To edit a group footprint just double-click on the group.
At the top of the screen you will see a drop-down list which allows you to choose the discriminator that you have decided to use.
In order to specify a team inclusion on “Hospital A“, click the lookup at the top of the screen and select team “Hospital A“. For a manager you might also select an inclusion on “Hospital B“.
This means that these users can only see data which relates to teams “Hospital A” and “Hospital B“.
You might, alternatively, choose to say that these users can see all data except that which relates to “Hospital C“. This would be achieved with an exclusion.
The differences between these choices can be very subtle.
What about NULLs?
If you specify an exclusion, that is fairly unambiguous. i.e. “you will never see any data where the Team = Hospital A“. Any data at all, equipment, job, contract, spare part, location, anything at all; if the team is “Hospital A” then you won’t see it.
Inclusions are a bit more problematic. Let’s say that we have a spare part which is used in both Hospital A & B. However, there are bins for this part in Hospital A and Hospital B. The bins are no problem, we just assign the appropriate team, but what about the spare part itself? If the part is associated with only a single team (maybe it is a boiler spare part for the Facilities team) then there is no problem, but in this example the part needs to be visible to several teams.
This forces us to interpret inclusions as “you will only ever see data where either the Team = Hospital A or the Team is empty“. You can also see why this is the case when you look at entity types which appear several times within one record. For example, on the equipment property page there is not a single supplier field. rather, there are fields for Original Purchase supplier, New Item Purchase Supplier, Spare Part supplier, etc.
This is a device which was originally purchased from Beaver Medical but which is now purchased from Cardiac Services. Contracts, however, are purchased from Philips. Could we just rely on inclusions for Beaver Medical, Cardiac Services and Philips Healthcare? No, because the spare part supplier, callout supplier, training supplier and loan supplier are all blank. In order to display this record the inclusions would have to be interpreted as:
Supplier = Cardiac Services
Supplier = Beaver Medical
Supplier = Philips Medical
Supplier is Empty
This will cause some headaches when we are looking at complex (or realistic) scenarios.
The team entity is the clear winner when it comes to choosing a discriminator which helps in “sharing out” your e-Quip database between different functional groups of users. However, there are alternative candidates.
Sites are commonly used for this purpose, i.e. “you can only see data where the Site = Hospital A“. For our non-NHS users the customer entity can also be useful, i.e. “you can only see data where the Customer = BUPA“.
e-Quip can handle many complex scenarios, but sometimes you may need to be very imaginative in how you decide to chop up your data.
You may have come across the series of articles about configuring e-Quip using the Role Manager. This is a really big subject and even when tackled in small chunks the articles are tending to become long which might give the impression that this is more complex than it actually is. For that reason we have moved some of the discussions about groups and permissions, along with the Footprint Manager, into separate posts.
In order to use e-Quip you must have a user account and that account will belong to a single group. Essentially a group defines your permissions or rights. i.e. what you are allowed to do within e-Quip. Almost always a group will have multiple members (i.e. user accounts) but remember, a user account is a member of a single group.
Item Permission Masks
Every data item in e-Quip is protected by a permissions mask which can be any combination of:
Read – This data can be seen
Write – This data can be edited
Add – New records can be created
Delete – Records can be deleted
Control – This grants the read, write, add & delete permissions and also allows records to be archived
Is the term data item the same as saying screen? For example, do permissions on the Location data type just refer to the location screen? No – these permissions apply across the whole of e-Quip. If a group has Add rights on locations, for example, then not only will the Create New Location menu on location screen be enabled, but the Add New button on the location Lookup control will be enabled everywhere it occurs, even in places like the QBE (Query by Example) utility.
Why is it called a mask? This is a bit of IT terminology used to describe something where the overall effect is defined by adding individual items, often called flags. Suppose that the read flag was represented by the number 1, write by 2, add by 4 and delete by 8. Using these flags, the mask 15 represents: 1 + 2 + 4 + 8. Thus 15 = read + write + add + delete. They are held this way (as ascending powers of 2) because computers can compare such masks very quickly.
The User Manager is responsible for defining the permissions associated with a group. To run this utility, click the Office menu (the round menu button in the top left-hand corner) on the dashboard screen and select Manage Users.
A screen will appear with two tabs, one to manage groups and another to manage individual users.
Group creation is trivial: simply click the New button and enter a code, name & description for the group. The code is largely unimportant and is used sometimes for advanced system customisations.
To open or edit a group, simply double-click on it in the grid. When a group is displayed, click the Permissions tab to see the rights mask for every data type.
Editing permissions is as easy as you would think; simply tick the boxes for the rights that you want to set. You can set the rights for multiple data types by selecting them in the list and then clickign Edit Selection. This will display the following screen:
Just tick the appropriate rights then click the Apply button and those rights will be applied to every selected data type.
When is it appropriate to delete a record from a database? I would start from “never” and then argue back very vociferously from there! My personal view is that if you create a job by mistake, then you should just set its status to Cancelled, not delete it, but that’s just my personal view. Incidentally, it isn’t possible in e-Quip to delete something that is referenced by something else.
Links Between Entity Types
Let’s suppose that a group has write & add permissions on jobs, so they can create new and edit existing jobs. What happens if those users need to a) add parts to a job and b) remove parts from a job that they may have added accidentally.
There are three separate data types involved here:
Part / Job Links
You can’t add parts to a job unless you can actually edit jobs in the first place. You cannot select from a list of spare parts if you don’t have at least read access to spare parts. But, to add a spare part to a job you also need write access to the Spare Part / Job Link entity. These are three distinct permissions. You might not be able to add new jobs, or create new spare parts, but you can still add spare parts to a job. There are separate rights masks for all three. have a look at the permissions below:
This group can see (i.e. read) spare parts but has read + write + add + delete rights to spare part job links, spare part model links and spare part supplier links.
This means that these users can:
Add a spare part to a job (“this spare part was used on this job”)
Add a spare part to a model (“this spare part is applicable to this model”)
Add a spare part to a supplier (“this spare part can be purchased from this supplier”)
It should be reasonably obvious that adding (i.e. creating) a spare part is not the same as linking an existing spare part to a job, model or supplier.
Notice that this group has permission to delete spare part links. This is not the same as being able to delete spare parts. If a user adds a part by mistake to a job then they need to be able to remove the spare part from the job. Similarly, if a supplier stops selling a particular part, removing it from the supplier is not the same as deleting the spare part itself. It will almost always be the case that if a group has the rights to add a link then they will also be able to delete that link.
Although groups primarily exist as a permissions mechanism, each group also has a Footprint, which defines the data which is visible to that group. If you’ve ever seen a Venn diagram then you’ll have a good idea what this means.
The “Hospital A” group can maybe just see their own data, and likewise the “Hospital B” group might be only able to see theirs, but an administrator would be able to see data across both sites. This is not the same as a permission: all three groups have read access to equipment (for example); the footprint defines the data that they can actually see.
This blog article explains how the Footprint Manager operates.
I have been experimenting over the weekend with a signature pad from a German company called StepOver. One of our major clients uses these pads for all of their service engineers. I have to admit that it’s a very neat solution and the signatures produced are legally valid.
It’s extremely simple to use. First you produce your job sheet (or whatever document you want to sign) from within e-Quip, then you print it. This is the clever bit. The signature pad comes with a virtual printer driver called the “StepOver PDF Converter“. Rather than sending the document to a printer it creates a PDF file from it and opens that file in an application called e-Signature Office.
This application has a button labelled Sign. When you click this you can then draw a rectangle anywhere within the document as shown below.
You then sign using the signature pad and that’s it. e-Signature Office saves the PDF document in such a way that it cannot be tampered with. More importantly the signature cannot be copied to another document.
The watermark in the picture above is because I was using the evaluation version of the software. In the final document you can double-click on the signature to see its validation details. All in all, a very capable solution. We are looking into their programming interface (API) to see if we can make it better still.
As part of the e-Quip login process a large amount of configuration data is read from the database and cached. This has never really impacted performance (unless you have a very slow server) but has been a real nuisance for users with remotely-hosted servers. For version 3.3.0 we have made two changes to dramatically improve this:
Using our support database as a test platform, the time taken to login remotely has gone from 30-35 seconds to 3-5 seconds, which is around a 90% improvement.
If you can remember the old SEMS system (long gone, but not yet forgotten), then you might recall that it provided a way of recording an engineer’s experience on a model-by-model basis. You could create coded levels of experience, such as “Manufacturer-Trained“, “Internally Trained“, “Completed more than 50 Jobs” etc, and then create links between personnel, models and these experience levels. We have now added this feature to e-Quip.
Also, to make it easier to assess an engineer’s experience we have added a new tab to the personnel property page to show all of the jobs that have been done by the particular person. The grid on this page shows all jobs and includes the model and number of hours. Auto-Pivot and Auto-Sum are turned on by default so you can just drag the model column to the area just above the grid and see the total number of jobs and the total hours that this person has worked on that model.
In order to do this we have had to completely redesign the personnel screen. The new version is shown below:
Adding to, deleting from and editing the experience tab is no different to every other sub-list. You can define the new Skill Levels using the Reference Data editor.
The job tab is shown below both with & without auto-sum and auto-pivot turned on.
Apart from the re-organisation and the new tabs, the only other significant change is that the field previously called “Short Name” has been renamed to “Display Name“. This is the name as it will appear in lookups.
Probably not what you think it does!
One of the most common requests that we get for calculated columns is for Mean Time Between Failure, or MTBF. This statistic seems to be embedded in the psyche of all biomedical engineers. How many of those, I wonder, actually know what it means? If someone asks for the MTBF of an individual asset that is a pretty sure sign that MTBF doesn’t mean what they think it means.
So you have a device with a published MTBF of 1,000,000 hours. Does that mean that if you have one of those devices then it is likely to run for 1,000,000 hours before it breaks? Of course not. It means that if you have 1,000,000 of those devices all running in identical situations, then the probability that one of the devices will fail within one hour is greater than 0.5 (i.e. more likely than not). Similarly, if you had 500,000 devices all running in identical situations, then it is more likely than not that one device will fail within two hours. You can do the maths for 2,000,000 devices (30 minutes until failure), or 250,000 devices (four hours before a likely failure). The first thing that it clear from this is that this metric is by no means an indicator for when (or how often) a device is likely to fail: simply change the number of devices on test and you change the probable time until a failure occurs.
Another factor that you might not be aware of is that MTBF is only a meaningful metric for a very particular part of the life-cycle of a device. When a device is first delivered there is a relatively high probability of it failing soon after commissioning. This is because of problems inherent in the manufacturing process and is rather depressingly known as “infant mortality”. I personally prefer the term DOA (Dead on Arrival) which is equally morbid but doesn’t conjure up the same sad visual imagery. Also, as a device gets older, it will wear out and will fail more often. If you plot the failure rate of a device graphically you will see the famous “Bathtub Curve”.
No, not that bathtub curve! This one:
MTBF only has any meaning within the section of this curve where the failure rate is constant. If you’ve got maths O-Level you’ll know that means “the flat bit”. Ideally, the failure rate would be zero, but life’s not like that.
So, if you’re thinking of using MTBF as some kind of reliability metric, remember:
a. MTBF only has meaning over the entire life-cycle of the device. i.e. it doesn’t really mean anything until you’ve decommissioned all of them
b. MTBF for a single device is a meaningless concept
c. You should ignore the first N breakdowns and the last N breakdowns, where N is known only to your spirit guide
Quite a few people might need to read some or all of those point again, especially the second. A single device does not have a MTBF. You may as well ask for the square root of a negative number, the colour of the wind or the specific gravity of sadness. MTBF is a measure of probability, and probability as a mathematical concept only has meaning when the number of trials tends to infinity (1 is not even close to infinity!).
If you toss a coin an infinite number of times in identical circumstances, the probability of heads or tails is 1/2. If you toss a coin once, maths won’t help you. Probability is simply not defined mathematically for a sample size of 1. As the number of trials tends to infinity, so the number of heads and tails will tend towards equality. This is actually the definition of probability. If you think that after a long sequence of “heads”, nature steps in and causes a run of “tails”, then I’m afraid you don’t understand how probability works (this is known as the Gambler’s Fallacy) and I would invite you to a game of Russian Roulette. If played by an infinite number of Russians, then 1/6 of them would die and 5/6 would survive (although I’m not quite sure that I can get my head around what 1/6 of infinity actually means, especially as 1/6 of infinity = infinity, but now we are straying into number theory and countable infinity versus non-countable infinity). But, as you slowly raise the revolver to your temple and your trembling finger wraps around the trigger, I’m afraid that you are a single trial and maths won’t keep you alive. MTBF works the same way. The only thing that you can be sure of is that if an infinite number of Russians are involved the catering is likely to be abysmal and the queues very long.
So why does e-Quip include a built-in MTBF function?
There are a few arguments that I have come to accept that I will never win. One is that there is no need for VAT in a spare parts catalogue, and the other is MTBF. In my opinion, and in the opinion of a great many reliability engineers, MTBF is a meaningless concept unless you are considering an assembly of individual components, where the sum of the MTBF of the individual components gives an indication of the probable reliability of the assembly.
Despite my protestations and appeals to common sense, a great many people insist that the spare parts screen includes VAT. It is not my job to force my opinions onto the users of my software: if you want VAT on the spare parts screen, then VAT on the spare parts screen you shall have! I’m working with my analyst / priest at getting past this. MTBF is similar. Lots of people want it, even though I suspect that they are not entirely sure what it means.
On a recent trawl of the web (and you thought that my life was a thrilling, white-knuckle ride), I found this comment from a manufacturer:
“MTBF measurement is based on a statistical sample and is not intended to predict any one specific unit’s reliability; thus MTBF is not, and should not be construed as a warranty measurement.”
“I concur”, as they say in all good television medical dramas. There are lots of MTBF definitions. According to Wikipedia there are at least: MIL-HDBK-217F, Telcordia SR332, Siemens Norm, FIDES,UTE 80-810 (RDF2000), and probably a great many more. You pays your money and you takes your choice. Either way, e-Quip gives you the ability to calculate MTBF, just be sure that it really means what you think it means before you make any decisions based on it.
Archiving is a much-misused term when it comes to asset-managent databases. Suppose that you were managing your inventory using old-fashioned paper files. You might have a file for each asset in which you kept all relevant information, ranging from the original purchase order, all its service reports etc. What would you do when the device was decommissioned? One approach would be to write “SCRAPPED” in big red letters across the front of the file and then put it back into your filing cabinet. You would be unlikely to shred it, after all you might still need to access the file for some time.
Time passes, and it’s now 10 years since you scrapped this item. By now, you probably have added a few more filing cabinets to your collection, as you not only have a file for every one of your active devices, but also for every device that you have scrapped over the last 10 years. As your collection of files grows you are faced with a choice – get a bigger office or do something about the really old files that you are unlikely to ever need again. Some companies have their own departments who will take these files off your hands and store them safely for you, although hopefully safer than in Dilbert’s company 🙂
Copyright (c) United Feature Syndicate Inc. 1997
This is what archiving means. An archived file is no longer in your filing cabinet; you can’t get immediate access to it but it is possible to get it back (eventually) in the rare situation when you need it. The analogy with computer files or databases is not much different. Once you no longer need immediate access to data it can be archived – i.e. removed from its normal location and stored off-line. Archiving a database record implies that it will be deleted from the database and copied elsewhere and you will no longer have immedidate access to those data. Arguably the concept of archiving data is not really that relevant these days. A database recording every job done on every device in every hospital in the UK since the founding of the NHS in 1948 could be handled by quite a modest server. As long as you can easily find what you’re looking for without old data getting in the way, there really is no compelling reason to archive data at all.
How Can you Stop “Old” Data Getting in the Way?
If you never archive old data, how do you stop it from getting in the way? Suppose that you have just scrapped an MS26 because it failed with fault code “AE32” (I just made that up, so don’t bother looking for it in the MS26 specification!) and can’t be repaired. Having written “SCRAPPED” in big red letters across the front of the equipment file; do you still need access to that file? Suppose you wanted calculate the average life and MTBF of the MS26 – you would need to be able to see every job that has ever been done on an MS26 in order to do this, so you would still need to see the files for all your scrapped MS26’s. What if in 2 years time another MS26 fails with fault code “AE32” and the engineer wants to find out how this was resolved in the past. Again the job details of the scrapped device would come in useful.
Delving a little deper, what does “getting in the way” actually mean? By far the most common searches in a database like E-Quip are for things like:
1. A particular asset
2. A particular job
3. All jobs for a particular asset
4. All jobs carried out within a specified date range (by model, location, team, technician etc)
5. All jobs planned within a specified date range (by model, location, team etc)
In all of these searches. no “old” information will be retrieved unless you are specifically searching for it. In fact, in practice, it turns out that all of this old information doesn’t really get in the way at all – people just have a perception that it does.
There is however, an exception to this. When users are entering data there is always the possibility of error. People aren’t computers – they make mistakes, and one situation where “old” data can be problematic is when it is referenced in error. For example, when raising a job a user might mistype an equipment serial number and inadvertently select a redundant asset. A mechanism is needed to prevent this.
There are many examples of errors that should be prevented, but some of the most common include:
1. Creating a job for a scrapped device
2. Creating a new asset using an obsolete model
3. Assigning a device to a closed ward
4. Assigning a technician who has left your employment
5. Using an obsolete spare part on a job
6. Using decommissioned test equipment on a job
7. Assigning a device to an expired contract
In E-Quip, these problems are solved by deactivating records. In order to deactivate any record simply select it in the appropriate summary screen and then choose “Deactivate Record” from the Office menu. What will this achieve? The most common way that users select data when creating or editing assets, jobs etc. is by using the lookup control. The primary effect of deactivating any record is that it will no longer appear in lookups. This is worth restating:
“The primary effect of deactivating any record is that it will no longer appear in lookups”
Notice that by default making a record inactive does not affect its visibility except when using the lookup control. For example, an inactive device may or may not appear on the equipment summary screen, depending on the system configuration. However, it will never appear in a lookup. All of the 7 examples listed in the previous paragraph are addressed by deactivating records.
Any record can be reactivated by selecting it in the appropriate summary screen and choosing “Reactivate Record” from the Office menu.
How are Inactive Records Displayed?
By default inactive records are displayed in summary screens in exactly the same way as active records, although conditional grid formatting can be used to display them in a different colour. However, the Role Manager can be used to configure roles so that inactive data is hidden by default. The status bar at the bottom of the summary screen will indicate whether or not inactive records are being displayed.
The default condition for any user will depend on the configuration of the role that the user belongs to. If the user is not a member of a role then the default will be ACTIVE, i.e. only active records will be displayed.
In order to change the current setting, press the F6 key, which will toggle the setting. i.e. if the current setting is ACTIVE, then pressing F6 will change it to INACTIVE; if the current setting is INACTIVE then pressing F6 will change it to ACTIVE. Note that after changing this setting you must refresh the screen (F5) for it to take effect.
When the status bar setting says INACTIVE, this means that both active and inactive records will be displayed.
Deactivating data records like assets, models, spare parts, locations etc as a means of preventing them from being selected by mistake is a simple enough idea to understand, but why is it possible in E-Quip to deactivate a job? What does an inactive job actually mean?
The PPM auto-scheduling mechanisms used by E-Quip means that future PPM jobs are created when current PPM jobs are closed. For example, if a device is on 2 PPM schedules, say a 6-monthly and an annual service. Completing the 6-monthly service will automatically generate the next 6-monthly job; completing the annual service will automatically generate the next, and so on. This means that there will always be 2 open jobs for this device. If this device is removed from service, then these 2 jobs will remain in the database forever. They will never actually be completed because you would never complete a PPM job on a decommissioned device.
Would it make sense to delete these 2 jobs, as they will never be done? Well, if you’re absolutely certain that the device will never come back into service, and you’re 100% certain that you have not accidentally decommissioned the wrong asset, then that might be a possibility. But if the device ever did re-enter service you would have to re-create the PPM jobs you have just deleted.
You could give the jobs a special status, something like “CANCELLED”, but then you would have to remember when planning future PPM work to exclude all “CANCELLED” jobs, which is extra work.
When an asset is decommissioned (i.e. its status is set to a value with ther status class of “Decommissioned“), then E-Quip takes the following actions:
1. The asset is deactivated
2. All non-completed jobs for the asset are deactivated
We can see now that deactivating jobs is simply a convenient mechanism for hiding jobs which will never actually be done because the device that they relate to has been decommissioned. This is the only reason that jobs should be deactivated.
Other systems that you may have seen use pseudo-archiving as a way of locking completed jobs, or to implement so-called “soft” deletes; both of which, in our view, are a thoroughly bad idea.