EBME Forums Forums Management Medical Equipment Management Asset and PPM software design

Dear all,
I am new to this forum and am grateful for all the support and information everyone gives each other in all aspects I have come across. Highly dedicated people and thumbs up to all of you.

I am currently finalizing a new software I am writing for PPM and asset management that includes a new form of tracking and maintenance protocols,We include all GMDN and UDI according the international standards.
I am interested to know if any of you find missing items or lacking flexibility in the programs or system currently used that was bought or home grown made package that you feel is missing.

Welcome to the forum, Herman.

So ... you're writing a new program, and you want to know what features you need to include?


Care to elaborate a little about that one?

Lastly (for now), what language and platform(s) are you using?

There has been much discussion around this topic on here over the years. Have you taken a look at the Biomed Databases forum?

I could also add (and will) that we have seen a few "false starts" as well - an enthusiastic couple of posts about plans for a new system and then ... well, let's just say that we're still waiting for more news.

OK Herman, I notice that you say you are now finalizing your new system; so maybe I'm a bit late here - but anyway (and perhaps of interest to anyone else just starting out) here are a few random thoughts about points to consider when embarking on a new system (most of which I have probably mentioned before in the forum mentioned above):-

1) First of all, ask yourself what, exactly, you want your system to do. A sketch (or more likely, a number of sketches) with paper and pencil will probably be a good idea. Then go away for a couple of days and mull it all over. It's best that you try to get it right at the onset, otherwise you can look forward to a great deal of extra work in putting things right later on!

2) Web-based, hand-held (Smart phone, and/or other device), or stand-alone (PC etc.)?

3) Next, switch off the computer and sit down with pencil and paper and work out how you plan to organise your database. You will probably need a relational database, with the Equipment as the primary table; in which case you need to give serious thought to the format of your equipment codes. More advanced (complicated) systems will need many relational databases, especially if you plan to include Parts (stock control) and what-have-you.

4) The primary table should be indexed by your Key Field. You may think that it's all very well using a "universal" (or "global") equipment numbering system, but I would (and do) disagree. The interesting (?) thing about these "international standards" is that there are so many "unique" systems to choose from. For example:-

- CIVAB
- ECRI
- GMDN
- UDI
- UMDNS

... to name just a few! So I strongly recommend that you retain full control of your Key Field (that is, design your own); otherwise, not only shall you most likely end up choosing the "wrong" universal format (once it becomes no longer the "flavour of the month"), but also what will you do if (when) "they" change it ... or indeed, a new one comes along?

5) Is your system going to be Local (for use in your hospital only), or Global (as in, "Hello World")? If the latter, you need to ponder early on about how to ensure that the architecture of your system will suit easy (a relative term, of course) expansion in ways that may not be foreseeable at first - in other words, an "Open Architecture" (keeping "expansion hooks" in your main tables).

6) In any case, think about expansion:- importing, exporting, migrating and manipulation of data. Also the possibility of relating to (linking with) other sources of data. And don't forget that any database is only as good as the data you can extract from it - in other words, Reports (and again, possibly, the exporting of data).

Yes; there is a great deal to think about. Just take things in small, logical steps. Also remember that there's a lot to be said for simply starting off with a spreadsheet (eg, Excel), and developing the basics there - you will find that after using that for a while, the overall arrangements of your data will become apparent. It also gives you a chance to clean up your data. And in Excel, data structures and formats are quickly and easily changed - this may not be so easy once you commence serious development using a database manager.

Hi Geoff,
Thanks for your elaborate details, where do I start.....
Platform:English - windows for now.
Currently a PC and enterprise version that in final stage will be web based connected for mobile use. This will allow you to scan codes with your phone and send them to a work order.

Importing and migration of items is made easy, a stock keeper could add an asset but needs to be acknowledged by required stakeholders prior it becoming "live" , depending on your authority in the program you can move an device but may need to be approved by an accepting manager in an department or assigned manager. This way Biomed knows where it is used also. flags for all movement come up if you will move devices around.

Yes the :universal" had us thinking a bit and we plan to make unique coding based on facilities. and each asset code to be linked to corresponding "universal" codes in the software itself. As we intend to provide it all over we start with country code - facility code ( based on CoC).- asset code - unique UDI and serial. This way everyone can ID a device to their own facility and thus no lost/founds issues. Or "borrowed" devices that move to elsewhere.
The database is active and makes it easy to change or clean up if you are authorized. Manipulating date is less easy made to prevent checks "done" that may not have been performed. Thus not adding an EST to a certain device may not allow you to move on through the program.

It will be a Global "hello World" version. database can currently build for 5 mln items per facility, this so instruments can be included after adding a 2 D matrix.

All pages are open in architecture to ensure expansions are possible.

Language is " C Sharp " by the way

Interesting.

I note that you are including (inflicting?) a fair number of permissions in there. All to the good, really; although I must admit that my own approach has always been to assume that the user (generally lonely biomeds) had sufficient mukh - المخابرات - to make use of the system - access to the "tools" - without too much "control" (not the same as error-trapping, by the way). "Giving them enough rope", you might say.

However, as our world has become nowadays - increased levels of regulation, litigious environment, and what-have-you, I acknowledge that a new system needs to include access permissions at various levels and for various operations.

It seems that we agree on the issue of international numbering systems devised by others - GMDN and its friends; a look-up table (cross-references) is probably the best approach.

But your own internal code(s) sounds a bit long, by the way. How many characters is that? And, what about location (department, room number) within each facility? Why not just use a unique number internally within the program? But changing location by "simply" changing a few characters within the unique equipment string (have I got that right?) sounds good.

OK, more questions. Where is the data held? On a server at each site?

2D matrix? Relational database?

Parts usage and stock control?

And what about PM? Does your system include PM Procedures? How do you handle that (those)?

Is C# any good for database management then? I have never tried it myself (and, at my stage of the game, am hardly ever likely to), but I used to "enjoy" C back in the Good Old Days (of DOS). As you probably know, a lot of the languages back then (dBASE et al), as well as many DOS commands themselves, were written in C.

Does your new system have a name yet?

How about GateKeeper ... due to the permission barriers (or gates) you mention.

Hi Geoff,
Internal codes are actually short but has a lot of room for additional data. Thus easily to allocate items to areas.
Currently the date is held in the facility, if they have a maintenance contract with us we keep the same to ensure per user we are able to locate a device incae they want us to come over.
As we include instruments in facilities that do not allow large codes, we can mark them with 2-D matrix to allow track and trace that we can also do. as CSSD program. Part and stock control is included, and has space for pictures of the actual parts used or in stock if they want to use it.
Yes we have a name, hope to announce it through linked in soon so we can set a launch date to go along with it.
Currently I keep the name to myself as we need to register it for protection.

Wow! It all sounds very serious.

But, with regards to your opening post, if we don't know what your system does, and what features you have already included, how can we sensibly (and briefly) suggest further *additions?

So, you are a maintenance contractor and have developed a system you plan to use as and when other contracts are won? Good; that's how I started off myself back in 1990 (dBASE IV back then). Does anyone out where you are still remember Nafitha? Those were the days!

But you are also hoping to sell the system to others? That's something I never achieved (or even chose to try).

Anyway, Good Luck!

* For instance, linkage to RFID.

Our system in short:
Creates unique bar codes for devices, links them to all data required for Biomeds, keeps track of all maintenance and history incl. where you got the parts from and contacts. Produces work orders that can be flagged internally or can be flagged to us in case of job requirements. flags up maintenance to departments to prevent them using it prior maintenance, allows kit exported for repair, and shows the status of repair . so a department head can see if a piece of kit is in your shop, if you already started, parts ordered , expected arrival parts, etc.
for the place we work in its a non sell item, as we provide it free of cost if they are in contract with us.yes we would sell it outside of the GCC for a low price just to get many out. It develops through a facility depending on the type and modules can be modified to a specific type of facility. Actually we think to look into having a couple of people try i out for us if they can contribute in a way, even if its marketing to get our name out.