Implementing Hospital Information Support System to Keep All the Patients Data Records - Research Proposal Example

IT INFRASTRUCTURE PROPOSAL ASSIGNMENT Name Course DATE Background ‘The City’ a metropolitan hospital in the UK whose management board answered directly to government ministers was the favored organization to be a pilot site for the implementation of a Hospital Information Support System (HISS). This was commissioned in February 1989. HISS was a coordinated IT ambience that would foster operations in the hospital with emphasis to link up and facilitate information sharing between the various departments in the hospital. It was hoped that the healthcare professionals as well as their professional managers would be helped a great deal with the implementation of HISS in their routinely exercises at The City. The ambitious project would consequently link up the wards and the hospital support services. This way the exchange of information between these departments and transfer of orders would be greatly enhanced. The hospital’s software contractor, Delta was involved in the development of generic orders, results and reporting system, a key component of HISS. HISS would bring a lot of clinical and financial benefits as explained by the project team responsible for implementation of HISS. However, the ambitious project proved to be over-ambitious after implementation. HISS had been tried once and failed. It was then tried a second time after minimal changes compared to the pool of complaints received were made. 18 months after its implementation, it became apparently clear that drastic measures in The City had to take with regard to HISS. An audit report released in 1996 following several complaints and blame-games between the three entities involved in the HISS project showed that HISS experienced major problems. The project had exceeded its costly budget and considering its site – a hospital thus very crucial information is involved and should be treated with absolute care and keenness – proved to be high risk. Poor relations between Delta and the hospital saw poor management of HISS, with his not even living up to its expected financial gain. Comparison of the performance of HISS in The City and other five pilot sites across the UK, The City proved to be the most expensive yet pretty much unsuccessful. Nature of this Proposal HISS was a brilliant idea to coin. Unfortunately its design and implementation phases had nothing brilliant in them. HISS was able to enhance exchange of information between the wards and the laboratories although at a very slow pace. HISS was also successful in developing a database for The City containing relevant information regarding the departments involved in the project. After thorough reviewing of HISS’s case study, it is evidently clear that a couple of changes need to be done to realize HISS’s success. These changes are discussed below as the objectives of this proposal. To redesign the HISS project so as to cover all bases and make it as failsafe as they come. This will involve revising the interaction between the entities in this project as well as the flow of information from one entity to another. What kind of information is exchanged between two entities? What part of this information is relevant to a given entity? How does this entity process this information? All these represent some of the questions that need to be asked in the redesigning phase of HISS so as to avoid repeating the very same mistakes. This proposal also seeks to re-plan the implementation process of HISS so that all loop-holes are covered. Various malfunctions in the entire project were not entirely to be blamed on HISS but also the implementation process and team involved. For example poor training of the healthcare professionals using the system was instrumental in HISS’s failure. There was a lot of redundant information; the system processes such as printing a single report would take twice as long as it would take the professionals to manually fill up an order. And to fill up an order using HISS would take forever. There was also the problem of blending HISS with other systems already installed in The City, an example being the labsys internal system present in the haematology laboratory. Phasing off the current system could not be achieved overnight. Clear and well calculated measures have to be undertaken to realize this, a task that this proposal seek to address. To dictate who does what and when would be the other objective this reports seeks to address. Apparently it was unclear to whom would the responsibility of developing HISS be given during the first phases of the project development. Delta being The City’s software contractors were assigned this task by default, the end result was questioning the level of professionalism involved in the HISS project development and implementation after poor implementation characteristics surfaced. It was also very clear that there was a lot of lack of cooperation from the would-be users of HISS in The City and the various teams involved in development of the project. The hospital would therefore help a great deal by pledging and ensuring their support and thorough cooperation in the project development. Various ways of just precisely how this can be achieved are discussed in this report. HISS like any other project was bound to face challenges that would be used to determine it effectiveness in performance as well as success or subsequent failure. The project was also not rolled out in all the departments of The City but in a selected few. This is quite understandable given the fact that this was a pilot project. It would therefore be unwise to make a full-fledged roll-out operation in The City with HISS. HISS’s case study does not also mention anywhere the possibility of a room for future growth and expansions, key areas of any system implemented currently is the focus on future (Thiadens, 2008, 237) All details addressed in the case study treat HISS as a one time, all-encompassing and fully sufficient system. This proposal however has assumptions of its own. First and foremost is that this proposal assumes HISS failed not because it was a poor system but because of poor design and implementation that characterized it. In this regard, this proposal tries to point out what is to be changed in order to improve the development and implementation phases of the project. ICT governance framework The Australian standard Corporate Governance of ICT (2005) has defined ICT governance “as the system by which the current and the future use of ICT is directed and controlled. It involves evaluating and directing the plans for the use of ICT to support the organisation and monitoring the use of ICT to achieve plans. It includes the strategy and policies for using ICT within an organisation”. There are various governance framework used for various projects. However, for this study, we shall rely on COBIT (Control Objective for Information and related Technology). COBIT is a system that was developed by Information Systems Audit and Control Association (ISACA). The main aim of COBIT is to help the managers in linking the gap between control requirement, technical issues and business risk. COBIT has been designed in such a way that it acts as an integrator of the different key guidelines frameworks that exist by summarizing all the major objectives into one framework that tie-in governance and business resources. COBIT has component that touch all the aspect of the business as the following four main domains; Plan and organize. Any business needs to have strategy and tactics to achieve its objective. This domain mainly touches on management. This domain tries to identify how IT can help a business achieve its objectives. It seeks to know what resources should be acquired to achieve this. Also it aims at communicating planning and management of strategic vision of the organisation. Acquire and Implement. To realize the strategic vision identified under planning and organizing IT solutions need to be identified, developed or acquired, implemented and integrated into the business process. Besides introducing new solutions this domain looks into existing IT framework and how it can be changed or maintained to be in line with the new one so as to achieve business objectives. Deliver and Support. This domain deals with the working of the system in addressing whether it is actually meeting the user needs. The user needs here refer to whether it is prioritizing on achieving business objectives while delivering services, managing of data, and management security and continuity and user support service. Monitor and Evaluate. As with any other IT system it needs routine check up to ensure it is working as intended and formulated. This domain aims at detecting any problem earliest possible. Monitor and evaluate address performance management, monitoring internal control, regulatory compliance and governance. COBIT framework has got 34 processes that are responsible for planning, building, running and monitoring the IT of an enterprise. COBIT has 34 processes that any organisation may use verify the completeness of the activities but however doesn’t have to use all at the same time. It can choose any combination it deems fit and this depend from one organisation to another. For COBIT to be effective there are certain key areas to remember namely, it is there to link the different business requirements, identifying major IT resources to be developed, organize an enterprise IT activity into a generally accepted process model and lastly definition of the control objective to be considered. Any business leader knows that the most important business asset to a business that is often overlooked is IT and the risk associate with it. The core to IT governance is value, risk and control. Why use COBIT framework? As earlier stated, any successful manager of well doing enterprise knows that the most important asset in any business is the IT and is based on fact that COBIT framework was developed. Quoting from COBIT principle “To provide the information that the enterprise requires to achieve its objectives, the enterprise needs to invest in and manage and control IT resources using a structured set of processes to provide the services that deliver the required enterprise information.” COBIT has developed seven distinct information criteria to serve the quality, fiduciary and security requirement of any IT system and they are Effectiveness- Any IT systems need to deliver results as promised in the development stage. The system should be in line with the different needs of the business, Efficiency- for a system to achieve this it needs to provide optimal results at the most economical level as possible without compromising on the quality. Confidentiality- IT carries most inner secrets of an enterprise and is important to secure that information from the rest of the world. Integrity- The information on the IT system and the data been transmitted through it should be as accurate as possible and complete for it to make sense to the user, Availability- One of the reason for developing an IT system to make retrieval easy and timely as possible when one needs it without much delays. Under COBIT framework, the compliance with the law, regulations and the contractual agreements is an important aspect. Reliability- the IT system should provide appropriate and up-date information to the enterprise at all times. The above seven information criteria for COBIT make it suitable for use in this proposal to develop the HISS project. An effective ICT governance framework put in place will ensure proper risk management (Cruz, 2003); very critical in our case given it is a hospital. Analysis of HISS project When selecting software contractor the process wasn’t competitive enough since only one contractor applied to be awarded the tender. The hospital should have gone back to the drawing board and consulted far and wide, since most of the contractors expressed their concerns on the viability of HISS project. No proper training was conducted on staff as they expressed their dissatisfaction on the actual project implemented. They claimed that the contractor trained them on a different system other than the one implemented, and it took time for them to learn how to use it. The HISS was cumbersome to use. The system was not user friendly as the screen dialogue and other user interface such as prop up menus were not present. One particular complaint involved printing out of results if one keyed in one wrong letter the printer refused to react. The system was greatly inadequate on its data input capabilities as the staff felt that it wasn’t efficient enough and particular the bar code reader was troublesome to use. The system did not match the user needs. When been designed the system was configured to only handle two out of over a hundred hematological test could be ordered online. This implied that the rest continued to be handled manual, which was not the plan. The implementing team didn’t consult properly when both designing and implementing the HISS project or chose to ignore the ideas of the hospital staff. They already had a system called “labsys” in the laboratory. This system didn’t integrate properly with the existing infrastructure. When designing HISS the implementation team should have repaired and maintained “labsys.” The system was time consuming. The staff at times had to wait as the system process data. One doctor particularly lamented that it was faster to go to the laboratory in persons than relying on the system to get result or order results. This made their work particularly hard as they had to handle a lot of patients and the system didn’t support them well. The data integrity was not provided as the system could mix up the information or get lost as it was been transmitted. This was very undesirable particularly on a health providing institution. The support staffs after the system was implemented were not very helpful. In certain cases, it took them long time to repair and put the system up and running after a discrepancy are reported. The project was concluded to be not economical by the National Audit Office. Despite the huge resource allocation the project didn’t deliver as promised. When compared to other projects implemented under the HISS, ‘the City’ was the most expensive and yet the least productive. When introducing any new system the idea is making the operations of the enterprise a better service provide. However this HISS project didn’t match the requirements outlined in in the COBIT framework as outlined above in the challenges. The system was not efficient, effective, reliable, economical, and it integrity was greatly questioned. The user that is the hospital staff had great expectations in the new system but as stated it didn’t meet the user requirement. The proposal When designing any IT project such as the HISS, there are various steps that should be followed in order to achieve the objective of the organisation. After carrying the feasibility study and properly understanding the needs of the enterprise and understanding how IT can help the organisation, only then is it proper to start planning. The aim of this is to ensure that everyone involved in the project either directly or indirectly have full confidence in it. When planning, it is important that, all aspects of the organisation are properly articulated. The operations of the organisation should be discussed in detail and identify areas in which IT can come and into play. When designing the system, the new system should seek to address areas not currently catered by the existing system. If new system is going to be integrated with the existing one then know how to deal with the inefficiency of the current system. The next step is the system development. The program should be well documented. It should have a title and a program identifier, version and the author. It should have a brief introduction and a brief overview of what the program does in the business organisation. All assumption and restriction of the program should be outlined. The system should come with a manual especially if it is off-shelf software so that the users can learn how to use it. The functionality of the program should be easy. According to Lutchen (2004), Each and every user should be able to user with relative ease even if one has limited knowledge on computers. The way of inputting data and data outputting should not be cumbersome. For example instead of using barcode reader one could use the laser rays technology which is more efficient. On output if one is printing out results instead s of programing the printer not to react at all if wrong keys are keyed in the system should prompt the user to check again to correct the error. The system should be user friendly. The mouse and the cursor should be in place and easy to use. The screen should have ready-made shortcuts to make it easy to move from one application to another. The program should have prop up menu with a brief description to make the user more comfortable. The icons that shall be used should be easy to associate with particular application and have the option of changing them. The system should have means of encrypting and decoding the messages sent through it. The message should reach the recipient as sent without the slightest alteration. In addition it should reach the intended recipient only and this could be achieved through ensuring each user has an account which is password protected. The system should have a backup. What about the network architecture? Lucey defines the network architecture as basically a blue print of the entire flow of communication within the hospital organization and how this is implemented in HISS system (2004, 57). This means we consider the type of information being exchanged and between what members is this exchange taking place. At times we experience system failure and data not saved is all lost. When any user is in the system it should be regularly asking the user to save that data or save it automatically. In addition that data should be stored in a backup storage to be retrieved when needed. In case of a system failure, the system may have a command of shutting down to secure the information then rebooting again and identifying what caused the system failure. To ensure security of the whole system, a log of users should be kept. As stated above each user should have an account with an authorization code that is kept in secret and hence no intruder can get into the system. The maintenance personnel should too be monitored to ensure that any time they are in system their have the required authority. A good network architecture also ensures an almost failsafe security of the content handled by the system as argued out by Reynolds and Stair (2011, 118) Before deciding on any system it is important to check on the success rate of that particular application in the market. This may be achieved by checking with other people using similar software and what is their opinion. The reputation of the supplier should be checked too. IT team should decide between been proprietary software or tailor made application of organization and reputation of that particular supplier. Some other important considerations are the cost associated with the project. As previously stated the project should be economical and should consider the resource endowment of the organisation. The new system should be compatible with the existing hardware in place and should try to integrate the existing IT framework. One most important aspect is staff training or the user training. In an organisation everyone should be trained from the senior managers to junior staff. The management should be taught as they are the ones who will manage the system hence know the importance of the system (Committee of the Regions, 2003). The users are taught on how the system as they are ones who shall interact with the system on a daily basis hence they need to know how it operates. After the system is rolled out it is important that they be a post-implementation review. This include whether the system is in line with organisation objective. It also looks whether is working as intended. It is during this stage that any error is detected before it brings the system down. Recommendations Based on the above analysis using the COBIT framework IT governance, it’s recommended that the proposal in be adopted in the revised HISS project. This is after careful considerations of the potential of the system. In addition, the following recommendations should be followed; the tendering process should be open and competitive to attract more contractors. Before the tendering there should be a consultative forum on the best practices to ensure contractors have confidence with the system. Once the supplier has been identified, a review of the previous project should be done (Cumming, 2006). A meeting between the system developer and the users should be held and the users let express their opinions and ideas about what system should be in place. During the planning and design stage the concerns of the users should be addressed and agreed how their ideas will be implemented the system is developed. Proper user training should be conducted on the actual system and finally after implementation a review should be done and support team who are properly trained employed. To avoid future occurrences similar to what just happened, it is imperative that the management of The City try to ensure they pick the best of the best in the industry within their affordability to handle such complex tasks. This ensures certain level of professionalism and proper execution. Proper design is also guaranteed in the design phase of the system which translates to better implementation and operation of the system (Lee and Beng, 2010, 77). This is a system that could change the way the hospitals worldwide are managed and is worth investing in as it had the capabilities of keeping all the patients data records hence could be easily retrieved whenever needed. References Committee of the Regions, (2003). Governance and ICT: Innovative e-government actions at local and regional level. University of Michigan. Cruz, M., 2003. ramin communications Governance of Information and Communication Technology: Governance of IT. [online] Available at: Accessed on May 14 2012. Cumming, H, (2006), Management Information System for Information Age, Toronto, McGraw-Hill Ryerson. Lee, G. B., Beng, O. K., 2010. Pilot Studies for a New Penang. Southeast Asia: Institute of Southeast Asian Studies. Lutchen, M, (2004), Managing IT as a business: survival guidelines for CEOs, New Jersey: Hoboken Lucey, T., 2004. Management Information Systems. New York: Cengage Learning. Reynolds, G., Stair, R., 2011. Principles of Information Systems. New York: Cengage Learning. Thiadens, T., 2008. ICT Governance, Management and Organization. Lulu.com. Read More