I was having (yet another) sort out again just now and I came across some DOS directories on one of my hard drives. As always it was nice having a quick go with stuff that I had written many years ago. That is, "ancient" in today's terms.

In short, it is a hospital project database system, aimed at producing the various lists required:- Specs, BofQ, Item-by-Item, Room-by-Room etc. And then, later on, snag lists and good stuff like that.

Unlike equipment maintenance systems, it is primarily building based (rooms, room data sheets etc.).

For those who enjoy "stories", well here is the short version:-

The need for this program arose in September 1995 when I became involved in the design of a 100 bed private hospital at Qatif in Saudi Arabia.

The original version of (what became known as) Spex was coded using dBASE IV. Traditional structured programming was used (as that was the best you could do with dBASE IV anyway), as there was a need to have the thing up and running quickly to get the spec lists and room listings etc. done. That is, the client was in a tearing rush (as usual).

Both the Room_Code and Spec_No formats originate from that time. I simply sat down with paper and pencil (plus a cup of tea, of course) and those basic formats were never changed:-



During Ramadan 1996 (Jan-Feb of that year) a start was made on an event-driven, object-oriented version in dBASE 5. This was my first attempt at coding in that ("modern" at the time) fashion, and dBASE 5 was clever in that you could (and can) work in both traditional and OOP modes (and even mix and match between the two). Brilliant, really. Anyway, work continued only "now and then", but the system was presentable by the time the original lists were finalised in the summer of that year.

The program was taken up again almost a year later whilst on another project ... etc., etc. (details omitted). But it became clear that it could be useful in keeping track of work "at site" also.

Incremental improvements were carried out "as required" at various stages on various projects and a start was made on a Windows version some years later. However, the whole thing has withered on the vine these last eight years or so, as (regrettably) I haven't been involved in any New Hospital Projects since those days.

For an idea of what I'm talking about, take a look here.

Anyway ... getting to the "bottom line" here:- if anyone can make use of stuff like this, and doesn't shy away from the idea of using dBASE 5.0 for DOS (and is up to altering code pages, and stuff like that - it's working fine right now in the "DOS Box" on Windows XP, by the way), I would be happy to bundle it all up for them. But I can't promise too much in the way of support. Unless that is, someone can stump up some funding for me to crack on and finish off the Windows version (six months work at least).

Is nostalgia a thing of the past?

I just can't believe how quickly the time has flown by since those days.

Geoff, nostalgia is a thing of the future. As is Zimmer frames and care centers (if they will still be in existence)

Surely anyone who allows themself to get to that sort of state has already forgotten anything worth remembering anyway?

I've taken another look at this one.

I find that I compiled an .exe almost exactly eight years ago. It runs on top of DOS (or in a "DOS box" of a modern Windows machine).

Actually, it is still quite useful. That is, for anyone involved in hospital projects.

In essence it simply produces organised lists (BofQ, Item-by-Item, Room-by-Room ... etc.) from your data inputs. You can either enter existing data, or effectively "spec" your own hospital (as long as you have some basic architectural drawings to work from). We used to get people come along (but only now and then, of course) asking questions like:- "can you spec-out a 100-bed hospital for me"?

It has two basic modes:- Design, and Site (that is, post design, during construction ... for snagging lists etc.).

Unfortunately, the Windows version has had very little work done on it, and (as I say) would need something like six months to get it presentable. Frankly, I can't see that happening now.

Rather than just bin the whole thing, I think what I had better do is check out the DOS version, set up a "typical" (or example) data-set, and then pack it all up in a .zip file for anyone who wants it. It could be two packages:- a compiled .exe file plus data, or (if anyone really wants to have a *go), the source code plus data.

We are talking about producing a load of .txt files (lists) here, so I can't see that the DOS interface is such a big deal (not that it ever was - or is - for folk of my era, anyway).

* You would need dBASE 5.0 for DOS ... which should be more or less freely available these days, I would have thought.

Not until now, that is! I've found the need to add another digit to the Room_Code, which now becomes something like:-



The floor level now has two digits, thereby allowing nine "basements" (-1 to -9) and a hundred floors (from 0 to 99). Should be enough!

Meanwhile, following an enjoyable month of "late nights" (and with another one in prospect), I really need to get this one wrapped up for a while. If anyone is interested in it, please feel free to get in touch.

Thats a lot of digits, we can still get by with 7, and that includes the hospital, clinics and associated housing.

Why so many (ten million rooms - wow!)? You can get 9,999 rooms out of four digits!

The short (easy) answer is:- Room Number versus Room Code.

For project work, that Room Code has to be (reasonably) universal. The large city hospital - or the dialysis annexe to the bush clinic. It also needs to be consistent (and of fixed length) in order to relate to other projects and other databases.

In a code string an individual alpha position gives you 26 possibilities, whilst a digit only gives ten. But the trouble is that when you use A-Z characters, the eye (brain) can't help but seek out meanings, and/or patterns (sometimes rendering "unintended consequences", such as "ECG" meaning something other than "ECG", or even something rude or offensive in someone else's language, culture, religion, world-view ... whatever). That's another reason that I like to restrict alpha strings to clusters of three only (ie, no "four letter words" allowed)!

If you used only alphas, you would end up with something like:-

HA-KTN-AB-AZ ... which looks more like an aircraft registration number than a project room code (or, as intended in this case, a room in the main hospital kitchen)!

In my room code the AAA cluster is a 3-character "department" code that is semi-meaningful. Anything else would have been inelegant, in my view.

The 3-digit segment to the right of the department code is the room number (within the department). Obviously this allows for up to 999 rooms in any department. 99 may be enough in many cases, but anything less (that is, up to ten) would simply be insufficient! All design is compromise, and when laying out databases such decisions have to made early on (especially as it can be a mountain of work to revamp it all later).

Looking at a floor-plan (drawing), or even on the ground at site, I usually go around each department in clockwise fashion, starting at the entrance, numbering every room as I go. 001, 002 ... etc. whilst ignoring the original "architects'" room numbering (apart from noting it in the database alongside my own room code). I have often found original room numbering schemes to be an incoherent mess, sometimes missing out some rooms altogether (small ones, for instance ... and sometimes even large ones as well - such as main lobbies and unusual stuff like tunnels, mechanical shafts and the like)!

The right-most 3-digits relate to room type(s). Again, there has to be more than a hundred of those (I'm looking at a list of 645 at the moment)! You probably don't need to mention "room type" in a room numbering scheme once the hospital is operating, but you do when you're at the design stage and/or trying to produce a decent BofQ.

The first three (left-most) positions point to a physical area within a project (eg, which building, and floor level). Again it seems to work OK.

Sorry Neil, but bearing in mind its intended use (new hospital projects and similar) that room code is as good as any (and better that most I have ever come across). Believe me I have given stuff like this a fair amount of consideration over the years. So much so, that to my mind at least, it is (c) Geoff Hannis!

Anyway, how about the Item Code:- BFX-010 (for example - and currently pointing to "Bar: Grab: Straddle: Toilet" of all things)? Perfect, or what?

Again:- three alphas giving "Package" grouping (eg, BFX for "Building Fixtures and Fittings")* and 3-digits for consecutive numbering (that is, up to 999 spec items in each grouping). Also my own original work over many years, and largely in response to appallingly poor efforts by others!

OK ... that's enough for now. Time for a cup of tea, and then to crack on with writing up the Users' Guide. As Huw has mentioned, the most tedious (but necessary) part! To which I would add that (in my own experience at least) that is when the most glaring snafus leap up and slap you in the chops!

* Full Package list (presently of 62 codes) available on request!

First 2 digits = Building
Third digit = Floor level
Last 4 digits = area and room number

and you have 12 digits, wow that can account for every address in the world, including China

Yeah ... I'm thinking of licensing out my room code format to *Domino's Pizza!

But only (up to) ten floors, Neil? Wouldn't do for Guy's in London, then (to name but one well known high-rise hospital building).

* Other home-delivery pizza franchises may apply in your area.