HS2061 IS Project Management - Free Samples to Students

Operational Feasibility – There are two ways in which the proposed MedRec can be developed and implemented. One method in which the organization shall be handling the entire development to deployment in their premises only by hiring resources to handle the project. In other method, instead of handling all the development work in its premises, the blockchain-EHR can be outsourced and just have an expert in-house to monitor the development. Both ways are under the reach of the organization. The project would be feasible because it will have all the required resources of organization (Tegarden, Dennis and Wixom, 2013).

Requirements Analysis

Functional requirements includes the key features of the system which should be performed by it i.e. it specifies the behaviour of the system. Following are key functional requirements of proposed MedRec system:

• Patient / doctor / 3^rdparty  should be able to create an account on the system.
• Patient / doctor/ 3^rdparty  should login in order to gain access to the system.
• Patient should be able to create privilege on the medical records. Only patient can have full access to one’s medical records. However, patient should not have access to all provider records (Scott, 2017).
• Users can create record-onboarding exceptions i.e. they should be able to limit access to same record to different providers / patients.
• System should be able to provide data as and when required by care providers, patients and regulatory bodies only after proper authentication.
• System should allow managing of prescriptions of the patients.
• Patient should be able to share data with a doctor of the choice. And the access to a doctor cannot be shared with other doctor.
• Doctor should be able to enter the private code/key and authenticate to access a shared record.
• Doctor should be able to unlock patient records.
• All users should be able to logout from the system (Kendall and Kendall, 2015).
• All users should be able to revoke access privilege in one instance.
• When a record is shared with any other party, a notification should be sent  to both sender and receiver.

Non-functional Specification 

Non-functional requirements are those aspects of the system which are not related with the behaviour of the system. These requirements define how the system is supposed to be. Following are key non-functional requirements of proposed MedRec system:

• System should not crash under any load of transactions with the database.
• System should be able to function properly with low Internet speed.
• System should be easy to use with very low learning curve.
• System should ensure that all data remain encrypted and accessed only when a valid code / key is entered.
• System should allow patients to secure their data while sharing.
• System should encrypt every piece of data before storing it in the database.

Project constraints 

Following are key constraints of proposed MedRec system:

• Even though healthcare demands privacy and authentication based  HER records, but there are still many health systems and users who do not want to adapt with the technology. Hence, MedRec should be implemented first in those hospitals where user are open for change or else the required goal shall not be achieved.
• The development and implementation of MedRec system is limited to government authorized hospitals and other arbitrary medical centres are not allowed to be a part of it. This is because blockchain system is recognized through an unique patient identifier or a big prime number.
• The project requires resources which are committed throughout the implementation project. Any resource leaving in-between not only hampers the project’s speed but also rapid advancements in medical history can  make it difficult to find a replacement of the resource.
• The implementation of MedRec should get completed either a day before Go-Live or extra resources should be assigned in order to finish the work on time. However, it can increase budget.
• The project should be completed within the assigned deadline and if deadline is to extended then it should be avoided by adding new resources (Dennis, Wixom and Tegarden, 2015).

Project Work Breakdown Structure 

Work Breakdown Structure is the process of decomposing the project tasks into smaller manageable pieces of work. Each decomposed work is assigned a resource or resources to perform it.

Conclusion 

MedRec system seems promising and feasible system as it stands on all the three aspects of feasibility study. However, there are still areas of concerns which have not been raised in the report. First is that blockchain has been made to be flexible with different databases but custom integration is still a challenge. Secondly, in order to implement such system, constant connection with hospitals and providers are required. So, that constant change in the needs can be studied and necessary modifications to the proposed system can be made. Need for MedRec has proved that centralized database or data store is dangerous for any organization which is looking for resolving security and privacy issues of the organization. MedRec proves to be a perfect de-centralized solution.

References

Alman, S., 2018. Blockchain. 4th ed. Chicago: Amer Library Association, pp.12-14.

Dennis, A., Wixom, B. and Tegarden, D., 2015. Systems Analysis and Design. 2nd ed. New York: Wiley, pp.12-14.

Karame, G. and Androulaki, E., 2016. Bitcoin and blockchain security. 3rd ed. USA: Pearson, pp.67-68.

Kendall, K. and Kendall, J., 2015. Systems analysis and design. 2nd ed. USA: Wiley, pp.67-69.

Scott, T., 2017. Blockchain. 1st ed. USA: Lulu COM, pp.12-14.

Tegarden, D., Dennis, A. and Wixom, B., 2013. System analysis design UML version 2.0. 2nd ed. Singapur: Wiley, pp.12-15.