When Dalo, the project manager, received the call that morning, she did not expect that it would last for so long. Frida, the IT manager at the hospital, was frantic: someone has been changing the prices of prostheses in some of the invoices sent to the insurance company. How was this possible? The billing application used an advanced access control and security system.
Before ending the call, Dalo promised to investigate the matter and revert during the day. She put the phone down and worked her way through the workflow. She was looking now at the screen that allowed the billing manager, or his replacement, to verify the bills before sending them to the insurance company. It was only at this point that the security subsystem allowed price modifications. Only two people had the permission to access this field on the screen.
Dalo recalled a conversation with Frida about an audit trail. She remembered Frida’s reluctance to invest in an expensive feature that will call on a member of her team to produce audit reports, full time. This would satisfy every whim and fancy of the auditors and the hospital management. The application had thousands of tables, the preparation of audit reports, although abated by the report designer, would need the creation of views to relate numerous list of values to their descriptions, and this was tedious, lengthy, and time consuming.
However, today, this would have been handy, as the system would have logged the modifications, their author and other interesting tidbits… Frida could have caught the culprit in no time, vindicating the long days of report writing.
Nevertheless, Frida forgot that so many things could change in a flash. Does she or the IT administrator have the time to look through the multitude of reports that the audit trail will generate?
This is a real story. Businesses face similar situations every day. Wouldn’t it be nice if such a feature were included in applications, especially if it did not require the dedication of a programmer? How about being able to create, on the fly, all the associations between SKU’s and their description, customer codes and their names, invoice headings and their lines, items and their serial number and a lot more…?
It would also be great if we could look at the history of all events related to the fields on a display, on the multitude of tabs (modern user interfaces include these to simplify our life, so they say) attached to this screen, and, the hidden database information affected by visible changes. Moreover, for those who prefer to read it on paper, a full disclosure report, without writing a single line of code, would have been be nice. Could we alert Frida of these changes? On the spot, on her screen, by email, SMS or through a daily report delivered, every morning, in her inbox.
As usual, there is also the clever one who will want to audit the user-defined fields: right? These should also be included again, without wasting the precious time of Frida.
Dalo suggested these features to Frida. And Frida, in a despondent mood, would not end the conversation on a positive note: she wanted other features added to the application, because she said, we should also protect the secrecy of the patients’ information. Only the personnel of a specific ward should be able to see the files of the ward’s patients. At last, the “data masking” request! A feature that legislators dream of and analysts debate upon waking-up from its nightmare. What else?
Our major concern, she thought, was that, even if we could include these features in the new application we were developing, how to apply it to all the modules of the base application?
The project director had the answers… he was in a predatory mood… these requirements, and others, we discovered, were the facets of a single issue: how to develop once and use everywhere…
Comments are disabled for this post