EBME Forums Forums Maintenance Biomed Databases EBME / Biomedical Databases

However brilliant (and expensive) it may be, it is very unlikely that any "off the shelf" database will prove to be all things to all people (biomed departments, hospitals).

In your case, Steve, you may even be better advised to stick with Access, and couple it with InfoPath (Billy's favourite) and/or Word templates (Joe's).

But, as you suggest, with anything like that, it's always nice to a have a bloke of Joe's calibre on hand to keep the thing going, and develop it further as the need arises. And, and you probably already know, it always does.

I've got quite cynical in ways regarding databases but I'd say its a fair point regardless that I have to say.

In a strange way you could say that ANY DATABASE WOULD WORK for our EBME colleagues. What I mean by this is that it would store information/attachments/links and whatever else you want to bury away into electron land.

Yep, that’s right, Msaccess, Excel and anything else loosely badged a database would do perfectly.

But... of course it would be no good because were not actually bothered about the database, we are bothered more about the retrieval of information and the tools that enable us to manage equipment.

Steve’s post and a few others talking about the management of the database requiring a lot of work should be a thing of the past! (other than the odd admin tweak or user modification of templates etc).

My own thoughts are that it is much more important for the software to be designed in a complimentary automated and streamlined manner!!

When looking at equipment procurement we evaluate both purchase/capital costs as well as running/service costs. If we applied the same robust principles to database procurement then we should evaluate not just the functionality of our database but the time-efficiency of completing tasks within it and the ease of use for a novice user.

Over the duration of your partnership with the database it should more than repay you that time back in efficiency, something we should all be looking to do given the press on the NHS for streamlined management, increased litigation and less staff

^^ Not a rant in the slightest, but hopefully a little beneficial to any wishing to evaluate or develop databases in the future.

Off the shelf you may be struggling to meet your entire needs, however if you can outsource 95% of the system to an off the shelf then you could concentrate a little on the 5% thats missing and ADD it though exports/reports etc.

Yes, I agree.

"One size fits all" can only mean ... "compromise" (and sometimes a great deal of compromise at that).

After a while all those knobs and whistles are likely to clutter up the whole thing with "features" that not everyone needs. When that happens, I suggest that it's time once again to return to First Principles (and yes, any old spreadsheet or *database manager will do).

The trouble is that as far as "biomed" databases are concerned (as it is with almost any other), there are people out there who are trying to make Big Bucks out of selling the Perfect System.

But if you evaluated the need and then looked at what was (is) available as you suggest Joe, my guess would be that (for most situations), that Perfect System (perfect fit) does not actually exist right off the shelf. So it's back to Home Grown (bespoke, whatever) supported by informed tinkerers like ... well, yourself Joe!

Either that or expensive proprietary systems that have to be constantly adapted (made to fit) ... usually by the same clued-up member of staff.

Your last point about the missing 5% is spot on. The Law of Diminishing Returns? Tell me about it! Not so sure about "a lot of work should be a thing of the past", though (although I appreciate that you're talking about that from the Power User's point of view - I think). Someone still has to be able to set it all up, and apply the tweaks as and when they are called for.

* dBASE III Plus will run happily in a Windows DOS-box, you know!

Surely a open source project written using modular programming could fit the "One size fits all" category without being a compromise?

Just a bare bones system to start with, adding the knobs and whistles as modules that could be either selected at compile time or run time.

Go ahead Chris ... then we shall see.

I have tried on here a couple of times before to seek the consensus about what is required. No joy yet, though.

In my experience, when it comes to software projects, "design by committee" just ends up with a bloated mess (with very few willing to do the actual work).

But with a small, tight, group of the right sort of people, perhaps what you're suggesting is "do-able".

Any volunteers?

1) Equipment Inventory
2) Open Close Service Orders
3) Generating PPM Service Orders
4) Equipment History Files
5) Depreciation Evaluation
6) Down-Time Evaluation
7) Contracts
Next Please

8) Parts?
9) Reports?

Not too much to it, but lots of ways of achieving the same results and that is where the problem lies.

I managed to create one for managing all the equipment in the hospital I am working in using MS Access. Thankfully I do have some VB knowledge as well, so it wasn't very hard for me to throw in some automation for reports and stuff.

Oh and just add, I'm also creating a little Android client for my on site needs so I can sort of "check in" the fault while being with the staff.

That's the spirit!

As with vegetables (and chickens?), "home grown" is always best!

Welcome to the forum, by the way.