WIXLIB

Requirement Gathering andFunctional RequirementSpecifications forPhysiotherapy specific EHRCopy Right: Manish JainSubmitted by:Dr. Manish Jain (PT)PG/11/048

The Organization- Fresco Informatics Fresco Informatics delivers the next generation of clinical careinformation systems solutions built upon best-of-breed andbest-in-class healthcare software. The Fresco Informatics solution creates a foundation forheterogeneous communication amongst healthcare providersthroughout the hospital as well as all caregivers within theHospital Network. Fresco EHR and MPI product suites empower and enablephysician practices to provide effective and integrated caredelivery.Copy Right: Manish Jain

About the Project The project was concerning the developmentof a Physiotherapy specific EHR. My role involved: Finding the requirements through the process ofrequirement gathering from prospective clients Preparation of functional requirement documentfor the development of consultation moduleCopy Right: Manish Jain

Project Objectives It will help a Physiotherapy clinic to have a whole range ofdata in comprehensive form. A good Functional Requirement Document clearly states theobjective of the project and defines its scope, to clarify whatthe project does and does not cover.Rationale To enhance health care delivery qualityTo facilitate clinical data exchange and retrievalMaintain confidentiality of the patient recordsEnhance the patient satisfactionCopy Right: Manish Jain

Software development lifecycle (SDLC) The software development life cycle, or development process, is astructure imposed on the development of a software product. Each software development project has to go through the followingstages:1.2.3.4.5.6.7.8.Requirement gatheringWriting functional specificationsCreating architecture and design documentsImplementation and codingTesting and quality assuranceSoftware releaseDocumentationSupport and new featuresCopy Right: Manish Jain

Requirement Gathering Requirement gathering is usually the first part of any softwareproduct. This stage starts while we are thinking about developing software. This phase, involves meeting customers or prospective customers,analyzing market requirements and features that are in demand.Types of Requirement Gathering ShadowingInterviewingFocus groupSurveyUser instructionPrototypingCopy Right: Manish Jain

Writing Functional SpecificationsAfter understanding the requirements of theprospective users and stakeholders the functionalrequirements are interpreted and written so that it canbe conveyed to and understood by the technical team.Copy Right: Manish Jain

Software Development Model usedat Fresco InformaticsAgile software development method- SCRUMCopy Right: Manish Jain

Programming Language used atFresco Informatics The programming language used at FrescoInformatics is JAVA. Java applications are typically compiled to bytecode (class file) that can run on any Java VirtualMachine (JVM) regardless of computer architecture. The Graphic User Interface (GUI) being used atFresco Informatics is HTML5.Copy Right: Manish Jain

Example of Java Codepublic class DocApp{public static void main(String args[]){System.out.println("Development of Doc Engage");}}Copy Right: Manish Jain

METHODOLOGY AND TOOLSUSED Study Type: Questionnaire based StudyNumber of Respondents: 50Respondents included: Working PhysiotherapistsMethod Used: Survey and Interviewingindividuals Data Type: Primary Tools Used for Functional specifications: MSWord and MS Visio Tool Used for Evaluation of Responses: SPSS16.0Copy Right: Manish Jain

Requirement gathering for the Physiotherapy SpecificEHR involved conducting a survey among workingphysiotherapists and visit to a renownedPhysiotherapy Hospital in Bangalore, Karnataka. Gap analysis of existing features of the assessmentprocedure being followed by physiotherapists wasdone to find out the features which should beincluded in the EHR. These features were listed down in some specificformats called the Functional Documents that can beunderstood by the technical team (SoftwareEngineers) while developing the EHR.Copy Right: Manish Jain

OBSERVATIONCopy Right: Manish Jain

FINDINGSAverage Numbers353025201530105430Number of patients coming Number of Physiotherapists Number of attendants andto the clinic per dayat the clinicother staff at the clinic454035302520151050Copy Right: Manish JainTime spent (in Minutes)4020AssessmentTreatment

Conducting Assessment33%Before start of treatment63%During course of treatmentBoth4%Working with Computer & Internet6%14%EasyModearteDifficult80%Copy Right: Manish Jain

Willing to adopt a computerized patientrecord system5%YES95%NOFeatures they want in the system12%88%Copy Right: Manish JainPatient Demographicdetails, History,Obseravations,Examinations, Treatment,PrognosisAll excpet the prognosispart

RECOMENDATIONS Physiotherapist loginCopy Right: Manish JainSnapshot of Login Screen Specifications

Copy Right: Manish JainSnapshot of Login Screen Design (User Interface Look)

Patient Appointment SchedulingCopy Right: Manish JainSnapshot of Appointment Screen Specification

Copy Right: Manish JainSnapshot of Appointment Screen Design (User Interface Look)

Patient Consultation ModuleCopy Right: Manish JainCopy Right: Manish JainSnapshots of the Consultation Module Specifications

Copy Right: Manish JainSnapshots of Consultation Screen Design (User Interface Look)

Copy Right: Manish JainSnapshots of Consultation Screen Design (User Interface Look)

CONCLUSION There is no magical wand, no one answer, no perfectapproach method or technique to requirementsgathering. Developing a good requirements document is aboutgiving your project the best chance of success. To do so, you must reduce the risk of common mistakesthat arise from a lack of communication orunderstanding. Keep this in mind as you gather your requirements, andthe documentation — and project as a whole — willhave the best chance of success.Copy Right: Manish Jain

Recommendations for Requirement Gathering To be successful at requirement gathering and to giveyour project an increased likelihood of success followsthe given rules: Don’t’ assume you know what the customer wants,ASK Involve the user from the start Define and agree the scope of the project Ensure requirements are specific, realistic andmeasurable Gain clarity if there is any doubt Create a clear, concise and thorough requirementsdocumentCopy Right: Manish Jain

Confirm your understanding of the requirements withthe customer Avoid talking technology and solutions until therequirements are completely understood Get the requirements agreed with the stakeholdersbefore the project starts Avoid duplication of requirements in a functionaldocument Create a prototype if necessary to confirm or refine thecustomers’ requirementsCopy Right: Manish Jain

Mistake one should avoid Not prioritizing the User requirements , forexample ‘must have’ , ‘should have’ , ‘could have’, and ‘would have’ Not enough consultation with real users andpractitioners. Lacking a clear understanding and makingassumptions rather than askingCopy Right: Manish Jain

CASE STUDYFeedback and Evaluation of a HMS(Hospital Management System) in aPhysiotherapy Hospital in BangaloreCopy Right: Manish Jain

Hospital VisitedCopy Right: Manish JainHMS being used overthere

METHODOLOGY Meetings with the users of this software at RECOUPHospital were conducted to take their feedback onHealth Object. The users whose responses were recorded and analysedwere: Doctors Physiotherapists Front Office Staff System Administrators Separate discussions were conducted with all the usersto record their feedback and experience of using HealthObject. All of their views, opinions and responses were noteddown and evaluated.Copy Right: Manish Jain

OBSERVATIONS All the users had an opinion that the software is not user friendly at all Technical Details Technology being used: Microsoft .Net 3.5 Database being used: SQL Server Integration issues The most major issue and drawback which they face while using thesoftware is the integration issue of the software as it is not centralized. A patient coming and registered at one of their centre cannot be viewedas a registered patient at other centre and hence the patient has toundergo the process of registration all over again. The doctors and physiotherapists are not able to see the patient recordsand details who are visiting other centers as the system is notcentralized.Copy Right: Manish Jain

Data Entry Issues There is no specific template for recording patientassessment for the doctor and all the entry has to be madeby the doctor through typing only. The mode of all the data entry is in free text form where ablank prescription note is displayed on the screen wherehe enters all the details by typing only. This was found to be a major reason for the doctors beingirritated by the software and reporting it to be not at alluser friendly.Copy Right: Manish Jain

Backend Issues Doctors and physiotherapists reported of the softwarenot working properly when they are entering details init Users of the software often report of problem inaccessing and signing up in the system and that needsresetting the password again The billing department also reports of discrepancies inthe bill with wrong units being billed or a particulartreatment being billed multiple times. Data entered into the system has been reported forerrors and mismatch at multiple occasions.Copy Right: Manish Jain

It does not show the payments of the patient beingmade in advance on the landing page and the billingdesk has to go into billing details to check for it. At times the doctors and physiotherapists see that thedate of birth, gender and area location of the patienthas changed when they open the patient records tomake further addition to the patient assessment note. Sometimes the system does not save the data whichthe doctor has entered into the system and hence thedoctor has to enter all the data again which was notsaved.Copy Right: Manish Jain

RECOMMENDATIONS The following points are recommended for rectification inHealth Object to make it function properly and suitRECOUP’s needs: Centralization of the system Specific templates for recording of patient assessment The backend of the software needs to be rectifiedCopy Right: Manish Jain

CONCLUSION For a properly functioning HMS it is very essential tomake it user friendly which will ultimately help inincreasing the adoption rate of EMR achieve our goalof integrating healthcare and information technology. Therefore proper steps need to be carried out toensure that we present to the users a system which isuser friendly and suited to their needs andrequirements.Copy Right: Manish Jain

REFERENCES http://en.wikipedia.org/wiki/Electronic health record (Accessed on Date: 10/5/2012)www.frescoinformatics.com (Accessed on Date: 10/5/2012)www.physiotherapyindia.org (Accessed on Date: 10/5/2012)http://en.wikipedia.org/wiki/Physical therapy#Specialty areas (Accessed on Date:10/5/2012)http://en.wikipedia.org/wiki/Agile Modeling (Accessed on Date: 10/5/2012)http://en.wikipedia.org/wiki/Scrum (development) (Accessed on Date: 11/5/2012)http://en.wikipedia.org/wiki/SOAP note (Accessed on Date: 3/parts-physiotherapy-soapnotes.html(Accessed on Date: odels (Accessed on Date: RequirementAnalysis.asp (Accessed on Date:16/5/2012)Douglas Havelka and Sooun Lee (2002), Critical success factors for informationrequirements gathering, Information Strategy: The Executive's Journal, Summer Issue,Page- 98-105www.himss.org/content/files/Amb EHR Implemention081507.pdf (Accessed on Date:13/5/2012)Copy Right: Manish Jain