In my career directing laboratory and blood bank software, I have encountered software that had major features which were difficult to find (hidden in a nested menu system) or named ambiguously. To this day, I wonder what feedback was provided from the potential end-users—or if any had been requested by the developers. I will give some examples.
A major hospital system wanted to implement a third-party add-on to a new software covering all major disciplines. It would provide evidence-based diagnostic assistance (e.g. what algorithm to follow in diagnosing crushing chest pain). A lot of time was devoted to focusing it for local practices—physicians in many disciplines were involved. However, the end-users were not engaged in how this expert system was to be accessed. The end result was that only few physicians actually used the system. Even in the training period for the new hospital system, this important detail was not emphasized so most physicians did not know how to access it!!
A major hospital system including laboratory and nursing modules had nursing design/build the transfusion reporting system, i.e. recording the actual transfusion information: component type, start/end and frequency of transfusion. The nursing informatics staff did not understand anything about ISBT codes or frequency of transfusion. The transfusing nurses could type anything into the component type, ISBT field, specify frequencies of transfusion from one second to many years, and record different ABO/D types each time they checked the patient’s vital signs—and not compare to the historical or current blood types. We also discovered that the system could not read ISBT codes at all!
The system had been built without consulting Transfusion Medicine. We only discovered the errors it was demonstrated when we considered building therapeutic apheresis reporting into it. I refused to allow my apheresis nurses to use it, and eventually it was scrapped.
In my builds with Medinfo Hematos IIG, I early engaged my staff (medical, technical, and nursing) to review and critique—and help with the actual build construction to maximize its usability. This is very important when the staff have many primary languages to ensure that the everyone understands the wording properly.
The presentation of the data is very important to optimize pattern recognition and make proper decisions. If the data is scattered over many pages, interpretation is impeded. This is why I prefer a summary dashboard of information for both donor and patient data to facilitate my decision making.
In summary, make certain end-users with the appropriate background are engaged in the building/design process. They are not there for database design, but to promote usability. This will greatly improve the final product and facilitate patient and donor care.