mS-cube Software Requirement Specifications
Contents
1. private Person Patient lt usage gt private Person healthworker Attributes Causality AS public string Name private st private Loc Attributes public string Address public string Phone i ing Email Attributes private string Name 5 4 1 Gathering of Diagnosis and Syndrome data Table 3 attributes of visitation data collection from the providers by the health workers Sender ID Single Value A unique identifier to Health system assigned unique ID associate the data with the healthcare Name National ID number worker submitting the data National ID Number Facility Single value Healthcare provider provider name Kurnegala Base hospital clinic GP community healthcare Hospital center etc where the data will be collected provider type Hospital from This element will help identify provider location Kurunegala location or source of the health record It is anticipated that the patient will be from the near by area It is possible that a patient from outside of the area mat visit the provider Disease Single value Name of the disease the Dengue Diarrhea Parkinson s practitioner concludes diagnoses based on unknown if not diagnosed the patient s symptoms and signs Symptoms Multiple values The complaints made by fever joint aches vomit blood rash the patient to the doctor The same Dengue diagnosis for two different patients may not fever joint ache Dengue a2. e Subsequent third party implementers or developers of the mS cube mobile application can use this document as a basis to understand the specifications The document contains information in relation to the mS cube and should be read in the prescribed sequence to get a comprehensive picture of the software solution overview of S3 and the basic functionality S3 associated user requirements specifically for disease surveillance use cases depicting the actors subsystems and dependencies sequence of functions between actors and objects of the work flows software classes outlining the procedures attributes and parameters database schema of the entities housing the static and transactional data external interfaces that are required for operationalizing the integrated system Seo OT ew mp The mS cube project follows from the success of the Real Time Biosurveillance Program RTBP hence the reader is encouraged to refer to the literature in 5 6 7 and 8 from the RTBP as a prerequisite to this SRS The RTBP literature discusses the present day disease surveillance and notification system in Sri Lanka as well the requirement specifications for mHealthSurvey mobile application and the back end Sahana Biosurveillance Modue that can be adopted for the use in this software design 1 3 Product Scope Sentinel Site Surveillance S3 procedures 1 are a popular public health practice in many countries including Sri Lanka 2 Priority he
3. There in not much of a difference in the software features between these three programs except for the differences in a few data attributes For example the special disease investigation would require the patient s address and contact information that is not required in the other two The SDI and IPD will capture the patient s name which is optional in the OPD data collection process The collected data would be shared with the Sahana Biosurveillance Module which would warehouse the transaction data and store the implementation specific static data The case records received through mS cube and stored in Sahana would be accessed by T cube for health event detection analyses OpenMRS and DHIS2 other are possible solutions for data management ESPHealth is a tool intended for disease outbreak detection The relational database will be MySQL to begin with but then later adopt other available RDBMS like SQLite and PostgreSQL In order to support semantic interoperability the data will be stored in XML with the header tags and data Those XML files will be serialized to store as text in a single attribute in the respective database table For the sake of managing OPD IPD and SDI the schema requires only case diagnosis facility person location and contact information SRS for mS cube ICD 10 SNOMED CT data dictionary Semantics UMLS HL7 data standard Outpatient eats Programs Postgreslq SQLite DHIS2 ESPHealth OpenMRS
4. Town 1 Village or town within the Kuilyapitiya Kurunegala Pannala District the provider operates in or is licensed to operate operates in or the facility is established road GIS coordinate GIS Long amp Lat coordinates of Long 10 1234 Lat 7 0987 the location of the provider facilit Long 34 1234 Lat 23 1122 raphical coverage definitions with hierarch Table 7 Geog g Tamil Nadu Rajasthan Maharashtra Division Block Blck Thirupathur Division Pannala Kuliyapitiya Wariyapola po dtbedewa And ls rs o 6 Appendix A Glossary CLDC Connected Limited Device Configuration DHIS District Hospital Information System ESPHealth Electronics in Support of Public Health GP General Practitioner HL7 Health Level Seven ICD International Classification of Diseases IPD Inpatient department JSR Java Resource Specification LOINC Logical Observation Identifier Names and Codes MIDP Mobile Information Device Profile MOH Medical Officer of Health mS cube Mobile Sentinel Site Surveillance OPD Outpatient department OpenMRS Open Medical Record System PHI Public Health Inspector RMS Record Management System RTBP Real Time Biosurveillane Program 3 Sentinel Site Surveillance Sahana Sahana Disaster management Software SDI Special Disease Investigations SNOMED CT Systematized Nomenclature of Medicine Clinical Terms SRS Software Requirement Specification UMLS Unified Medical Language System URS User Requireme
5. department may record the patient s name However the mandatory data elements such as disease symptoms signs case date facility location age and gender are common to both The mandatory data elements will contribute to the following uses of S3 but not limited to only those where some of the data can be used to validate findings of other S3 uses e quantitative estimates of the magnitude of a health problem e portraying the natural history of disease e detecting epidemics e documenting the distribution and spread of a health event e planning Explanation of the use cases shown in Figure 4 for a healthcare worker to submit a health record they must first install the mS cube software then download index values lookup values health terms etc Thereafter they can register as a user and identify facilities they work in The download index values register users and define facility processes exchange data with server through set data and get data processes The data exchange must connect to server to send and receive data from the central data warehouse The server side controller storage has a process that can exchange data with mS cube which in turn interfaces with the warehouse through SQL read write from to database main menu actions data communication server side controller storage download index values connect to exchange data network with mS cube define register facilities as user get data User read write submit
6. illness in close contacts 5 2 Disease Symptom and Sign relationships for SDI This section defines the set of attributes associated with the data elements and database Table 2 Sample of Diagnosis diseases symptoms and signs Diagnosis Disease Cholera Watery Diarrhea Nausea Dehydration Tachycardia Vomiting Muscle ramps Thirst Drowsiness Yellow Fever Polio Myelitis Acute Flaccid Paralysis Diphtheria Fever with Chills Headache Fatigue Diarrhea Chest pain Vomiting Muscle aches Cough with blood stained sputum Fever Headache Muscle aches Nausea Loss of appetite Dizziness Abdominal pain Fever Headache Vomiting Diar rhea Fatigue Constipation Diffi cult to swallow Difficulty in breathing Sore throat Painful swallowing Difficulty in breathing Fever Chills Malaise Abdominal cramp Nausea Vomit ing Fever Diarrhea Blood stained stools Mucous stained stools Buboes Bleeding from mucosal tissues Gangrenes Pneumonia Coma Red eyes Red tongue Yellowing of skin Yellowing of sclera Bleeding from nose Heart arrhythmias Liver failure Kidney failure Delirium Seizures Coma Neck stiffness Back stiffness Muscle spasms Increase sensitivity to touch Paralysis of the limbs Cranial Nerve palsy Facial muscle paralysis Features of bulbar pals Hoarseness Swollen glands Grey membrane covering throat Red infected wound Wound with gray patchy material Eye signs Ab
7. in the field_option xml These lookup values must be uploaded in to the mS cube prior to starting any of the functions Configure user profile with login and other account details The user profile information such as the name identifications contact information are stored in the persons xml Define affiliated working facilities The working facilities must be defined for each of the healthcare jurisdictions location or site names and area names The health facility name i e hospital clinic name is stored in the facilities xml that is also related to the locations entity with other geocoding information Refresh lists of health terms The user must frequently update the health teams like disease symptom and sign names as well as their relationship that are maintained by the administration and store in the diagnosis xml file Enter OPD cases IPD cases and SDI cases data Rog Sahana Software Foundation http www sahanafoundation org Electronics in Support of Public Health http esphealth org redmine District Hospital Information System http www dhis2 org Opem Medical Record System http openmrs org The OPD IPD and SDI case record generation is dependent on health terms working facilities user profile and look values The disease symptom and sign relationships are defined in the diagnosis xml file 6 Submit case data in mobile memory to server for storage The case data is sequentially transp
8. javarosa javarosa wiki Home 5 Sahana Biosurveillance Module specifications available here http lirneasia net wp content uploads 2009 06 srs shn bsm v05 pdf 6 Real Time Biosurveillance Program s project overview proposal and technical report available here http lirneasia net projects 2008 2010 evaluating a real time biosurveillance program 7 Real Time Biosurveillance Program User Requirement Specifications are available here http lirneasia net wp content uploads 2009 02 user requirements v 10 pdf 8 Real Time Biosurveillance Program s mHealthSurvey Software Requirement Specifications are available here http lirneasia net wp content uploads 2009 06 srs mobile application rtbp v20 pdf 2 Overall Description 2 1 Product Perspective The mHealthSurvey Java 2 Micro Edition J2ME midlet was developed as part of the RTBP for the purpose of collecting OPD and IPD patient case information This software in the simplest form was developed solely for the purpose of the project Although it scales well in adapting to other countries for the purpose of disease information collection the software did not follow a specific generalized architecture or object oriented model Hence mS cube is a revision of mHealthSurvey Mind Map of the mS cube Prospective The mind map in Figure 1 shows the broader scope of mS cube Those elements that are covered by a cloud are the key elements that would be discussed in version 1 0 o
9. org Promote Binary XML for lightweight data transfer along bandwidth constrained networks lt lt Surveys gt gt SSS Program Epidemiology lt lt Dissemination gt gt SSS Program Epidemiology lt lt App Framework gt gt mS cube J2ME lt lt Meta Framework gt gt JavaRosa J2ME c Network Network Cellular Cellular SMS lt lt GSM gt gt HTTP SMS XForms XForms lt lt Schema Definition gt gt XML HL7 lt lt RDBMS gt gt MySQL sCube Figure 2 mobile client network and server components Mobile Applications Communications Servers 2 2 Easily interface besides Sahana with other back end systems such as ESPhealth DHIS2 OpenMRS Product Functions First we introduce the key actors their roles and the functionality required for supporting data collection analysis and reporting Secondly we introduce the minimal set of attributes required to attain the system requirements for collection of health data Ideally the product should contain all functions for collecting and disseminating data in relation to all S3 programs including antenatal postnatal immunization priority disease etc Figure 3 illustrates the basic product functions required described 1 7 below for the preliminary phase of the project 1 Download lookup values after installing software The lookup values or static implementation specific values like gender age groups are stored
10. streams i e database linkages On the contrary The most commonly used passive systems are disease notification systems which require disease reports that are sent from physicians to a central institution Such diseases are notifiable usually by legislation Sites are medical clinics hospitals health centers individual practitioners and primary health care physicians which cover certain populations at risk Events are measured occurrences of disease outbreaks diseases that occur frequently and detection of rare events such as acute flaccid paralysis Health surveys are the frequent review of statistics Linking databases such with insurance companies or over the counter pharmaceutical sales could reveal other trends that can complement and validate the findings Communication of surveillance information to those that need it the most can utilize to be better prepared and act swiftly in mitigating the consequences The information can be in the form of just in time threats of eminent disease outbreaks or periodic indicator based reports of the health status in the respective regions In order to use S3 to estimate incidence of special diseases the seropositivity rates for the special diseases at each sentinel site can be applied to the case counts within the geographical region the site represents This stratified analysis can then be aggregated to produce a reasonable country wide estimate The most useful evaluations will reveal diffe
11. with the next steps Else alert user with the respective server side or client side error message with instructions to rectify the problem Failing they should consult the administrator 3 2 Register User Profile 3 2 1 Description and Priority For the purpose of accountability the user information is necessary for associating each health record with the person creating the health record The user registration process will produce a unique identifier that will be appended to each health record If mS cube is implemented at a national level then centrally creating and managing user accounts for the thousands of users is complex The users being health workers may change be assigned to other duties etc Therefore mS cube should allow for the user to register themselves Upon a new registration submission the system will alert the administrator ot designated authorized person to verify and authenticate the user The user is then granted permissions to continue with the mS cube functions 3 2 2 Stimulus Response Sequences Explanation of the sequence diagram functions in Figure 6 User executes register user function User is presented a GUI with attributes to capture their professional information User enters the required information Then save the information in the mobile phone s RMS It will also trigger mS cube to send the information to the server side controller Controller writes the profile information to the database Controlle
12. 544 SIT H544 EN eiu Special Investigation F orms Register MOH Infectious H399 completed by Field oes or Diseases end of week Investigation Pot ROO Register S pecial investigation forms H399 H411a Epidemiological Unit m S pecial Investigation Forms Letter Outward Register H411 completed per each case confirmed Figure 9 Disease surveillance and notification system in Sri Lanka image copied from book Routine and Sentinel Surveillance methods http tinyurl com 24cpkry 5 Published Weekly epidemiological Reports are available here http www epid gov Ik wer htm 5 4 Recommended data elements and their relationships The partners or teams designing and developing the necessary standards software and protocols are expected to use the tables below as a guide to developing the precise specification which will be documented in the SRS It is evident that the designers and developers will need to expand on this and introduce more attributes and relationships to build the working solution H Location Person eusage e Attributes Attributes private string Name public string Name private string Type public string Identifiers Disease Attributes private string Name private string Code e edel Si er el m Attributes private Disease Disease lt usage gt private Symptpm Symptoms Symptom private Signs Signs private Causality Causality
13. Clinics External Interfaces Lian Say ro NU Functions Version 1 0 C Caeci s b Dissemination ous P transports c Ethernet QUU e reads ae Special disease investigations Arthritis Chronic Diabetes Antenatal Maternity Postnatal a Routine Imunization EI Special Figure 1 mind map of mS cube design elements Waidyanatha LIRNEasia Page 7 of 32 The aim of mS cube is to Whenever possible adopt the functions of mHealthSurvey and experience from RTBP Generalize the software with a cleaner abstract class structure for scalable development Make it a self contained product suite that could work independently to accommodate the data collection and dissemination requirements of S3 Develop a mS cube framework for modular expansion i e to easily integrate other S3 programs such as immunization maternal health child health programs Offer a comprehensive but generic set of mS cube applications that are easily adapted and are independent of the implementation i e independent of the country S3 programs Instantiate across multiple mobile platforms in the future such as parallel developments for Android and Windows mobile operating systems Criteria is to adopt global standards Make the mS cube applications interoperable through XML based data structures Possibly adopting existing global health semantic interoperability standard such as HL7 http www hl7
14. R Be aeeie 11 2 6 User Documentation oce ade n tee i p er e d e t E sec E nee 11 2 7 Assumptions and Dependencies eese ies indies tete sienne tentent nate ete EE cab seeded 12 3 System Features edd Or TURO E EntON OU eate um E IN 12 3 1 Download index values nerd te er Le cela cael teretes eee eei ic resti Peso ete pue sett eo 13 3 2 Register User Profile orae Pg prar ded n E re e Or pede SES 15 3 3 Define Affiliated Faciliti s 2 rire inde eee tto oio rop edes Hae eb es e Pe Pee ARUBA 17 3 4 Submit Case Records suoi hc e ic eg eee ceres dette e 19 4 Other Nonfunctional Requirements eee ee ecce esee eene eene seen esten esten asse eaae seen sese eaae eno 21 Al Performance Requirements 5 2 cmd eid ner ER Pee ri ede urhe EH KEETA aO EEEE 21 AD S curiby Requirements e eee aces sepes erret eot eon OU ER suc per ee or EE ee etre sut roe e shee 21 4 3 Software Quality Attributes ipe toe Poet e o Po ep Deo eL Ideen 21 5 Other ROG UIP SINC TAES eC 22 5 1 Special Disease Investigation software logic eene enne nennen 22 5 2 Disease Symptom and Sign relationships for SDL eene 22 5 3 Present disease surveillance and notification system in Sri Lanka esee 24 5 4 Recommended data elements and their relationships eere 25 5 4 1 Gathering of Diagnosis and Syndrome data eere 25 5 4 2 Typical a
15. Software Requirements Specification for Mobile based Sentinel Site Surveillance mS cube Version 1 0 Prepared by Nuwan Waidyanatha email nuwan at lirneasia dot net EN J LIRNEasia N www lirneasia net for OpenRosa Code In Country Grant www openrosa org Managed by Dimagi Inc 2011 August 17 SRS for mS cube Version 1 0 Table of Contents PEN TMOG CHI OM Nec T 1 LA PULP OSE iiie a E EENAA AE AEE ENN E E T 1 1 2 Intended Audience and Reading Suggestions eeeseeesseesssssesresestssestsreststrtistsstsrestsessesteeestsessesrees 1 13 Product Scope nere Hn tete ted RE Re tei ure dem de ung CORR te Pe ote dete ene 2 I Edd Lr 3 2 Overall Descriptions oie oe ee rcu yE eres aum eee een ken en ae NN PPANM SUE ARM NN ME AN NN isdk viss ve gees su VN TY e M usual 4 2 1 Product Perspective 4i edes to tete ether ep ete cta rae elect etes tance boe une Een e eh tee ve ete e ege S 4 2 2 Product Punctioris ein esee teer eerie mE sang ventas cours Ses ete EE eren Heer toa e ce eL ge seg a eee 8 2 3 User Classes and Characteristics eie tete ertet deret e DHL ee eet espe iet etin 9 2 4 Operating Environment d i acte tUe Urt e eerte eee Dri Ree pese nd ene pee 10 2 5 Design and Implementation Constraints esee eere nete 10 2 SL Erase 10 2 5 2 Vechnology limitations eee tee at etel teg eque 10 2 5 3 Software design considerations oreet det tini eet ie boe case eto Een Pe Rhe E
16. alth data communication case site investigations and statical reporting are the key preliminary operations The present day paper based procedures do not provide the much needed timeliness in completing these tasks The mS cube will complement the present day procedures by offering a mobile phone based technological approach to overcome the paper and labor intensive challenges Surveillance is defined as ongoing systematic collection analysis and interpretation of data and the distribution to those who need to know which is a typical classified as bioinformatics applications Uses of S3 e quantitative estimates of the magnitude of a health problem e portraying the natural history of disease e detecting epidemics e documenting the distribution and spread of a health event e facilitating epidemiological and laboratory research e testing a hypothesis e evaluating control and prevention measures e monitoring changes in infectious agents e monitoring isolation activities e detecting changes in health practice e planning The S3 program should not be event driven and should be selected through the systematic identification of diseases and risk factors that are determined on the criteria including frequency severity cost preventability communicability and public interest The S3 is active in nature where the sentinel systems include sites events and providers as well as serial health surveys and integration of multiple information
17. case exchange data from to records with server database Figure 4 use case of S3 OPD and IPD patient case record submission 3 1 Download index values 3 1 1 Description and Priority Connect to to the central database through GPRS Request for all index values lookup values Some of these values are healthcare worker types location types gender labels age groups Most importantly receives the disease symptom and sign relational data Downloading the index values is a mandatory primary function The configuration process cannot proceed without these values being in the RMS of the mS cube midlet on the mobile phone The process is also an initial test for connecting and transmitting data between mS cube instance and the server Since the user will execute this function frequently to update the list of disease symptoms and signs the mS cube must make sure that the function can be executed as and when needed The process must ensure that any failure in the process such as the connection breaking during the data request will not disrupt the continuity of the already functioning version of mS cube 3 1 2 Stimulus Response Sequences Explanation of the sequence diagram functions in Figure 5 DEA pet s ae User executes the download function The mS cube midlet sends a request for index values Controller executes a query to retrieve data from database Controller stream each compiled dataset to the mobile phone The mS cube receiv
18. connection is established alert user to try after establishing a good GPRS or SMS connection Send the data across to the server controller The controller will filter the facilities by the jurisdiction type and jurisdiction name from database to create a data set with facility name and identifiers Thereafter return the dataset to mS cube If the query returns no results from the database then return an error message indicating server failed to retrieve working facilities 3 4 REQ 6 The mS cube received facilities data is stored in the respective RMS file REQ 6 Once the process is complete alert user indicating the working facilities were successfully saved in to the mS cube instance else alert the user to enter the information and try again or consult the system administrator Submit Case Records 3 4 1 Description and Priority Note This feature will work if and only if the previous three steps 3 1 3 3 were completed Patient case records are mostly gathered from OPD and IPD departments SDI are an extension of the OPD and IPD processes Health workers in these departments will digitize and submit the data The typical attributes are patient name visitation date gender age diagnosis if any disease symptoms signs and reporting facility Each facility may submit as many as two hundred records each day In the absence of connectivity the case records will be stored off line in the mobile RMS When cellular conn
19. dominal tenderness Pertussis Runny nose Sneezing Mild cough Whooping Low grade fever Dry cough Enteric Fever Fever Headache Fatigue Sore throat Abdominal pain Diarrhea Constipation Rash High fever Distended abdomen Delirium Typhoid state 5 3 Present disease surveillance and notification system in Sri Lanka Figure 9 shows the present day system work flow that monitors approximately 25 communicable diseases termed as notifiable disease When a patient is suspected or confirmed with a diagnosis at a health facility in relation to any of the notifiable diseases the policy and procedures require that the patient s personal details with contact demographics and disease syndrome information be recorded in the H544 form The form is then mailed or hand delivered to the relevant Public Health Inspector PHI to carry out on site house investigations and other preventive actions Thereafter the PHI would hand deliver the report with the confirmed results of the investigation again through the H544 form to the Medical Officer of Health department This information is transferred to several other documents H399 and H411a for reporting the statistics to the National Epidemiology Unit and the Regional Epidemiology Unit once again through the snail mail system The manually processed district aggregates are published in the Weekly Epidemiological Report WER Hospital ward H544 Ward Notification Register Weekly H
20. dules and Health Officials functionality including managing users and mS cube Trainers Support staff information Senders Creation and submission of upstream electronic health Nurses Health staff records basically case records with rights to add and __ Medical Officers edit records using the mobile phone applications Recipients Creation and submission of downstream health Public Health information namely issuing alerts and sharing information with patients or other relevant health workers with rights to add and edit information using server applications Inspectors Clinicians Nurses Health Officials 2 4 Operating Environment Mobile phone e Mobile phones standard or smart Java enabled devices e Operating systematic Symbian or Android e Memory minimum 512Kb e Java Resource Specifications JSR MIDP and CLDC HTTP File Database server e Processor Intel Pentium IV or higher AMD Athalon II or higher e Random Access Memory 4GB or higher e Hard Drive 80GB or higher e Operating system Linux 32 64 bit e Webserver Apache e Software PHP e Database MySQL 2 5 Design and Implementation Constraints 2 5 1 User aptitude System administrators working in the government health institutions have very basic computing and networking skills therefore the installation customization and maintenance of the software hardware and network should be simplified Due to the large gap between the health worke
21. ectivity is established the records will be submitted to the central database This can be executed without the user s intervention i e submit the records automatically when connection is established 3 4 2 Stimulus Response Sequence Explanation of the sequence diagram functions in Figure 8 User executes the case record function Then mS cube will display the GUI with the patient case record entry attributes User enters the information The record is saved for submission When connectivity is present mS cube will submit the records including those stored in the off line RMS The controller will insert or update the case record in the database The database write status is returned to the controller The controller will return the health record submission status to mS cube The status is displayed on the mobile screen WRWNP Do N D A HealthWorker present attributes enter info Controller save info query insert update Figure 8 sequence of functions for submitting a patient case record 3 4 3 Functional Requirements Refer to the use cases in Figure 4 REQ 1 REQ 2 REQ 3 REQ 3 REQ 4 Execute mS cube and click on Survey menu item and then the OPD or IPD sub menu item according to the program or department data is submitted from Invoke the health survey class and present a GUI to enter or select information for case date facility gender age disease symptom and signs The
22. er controller If user exists then the user details are updated and the existing login information is returned If user is new then insert the new user and return the new login 3 3 information If either condition fails then return an error message indicating server failed to register the user REQ 6 Once the process is complete on the server side alert user was successfully registered or re registered else alert the user to enter the information and try again or consult the system administrator REQ 7 Once the user is verified and authenticated by the administrator or designated authorized person the authorizing person will issue an SMS text with the login information Define Affiliated Facilities 3 3 1 Description and Priority The patient case record must be related to a health facility When the healthcare worker enters a patient case record they will select the name of the facility that the patient made the complaint at To avoid loading the particular healthcare worker s instance of mS cube with the hundreds of health facilities in the country the system will allow for the user to identify the working jurisdiction such as a district division or area then those facilities belonging to that particular jurisdiction is loaded on to the mS cube instance Thus minimizing the list size for selecting a health facility 3 3 2 Stimulus Response Sequence Explanation of the sequence diagram functions in Figure 7 User execute
23. es values and stores in the RMS User is displayed the status Ji Controller Health Worker execute download request index value return data stream store in RMS display status Figure 5 download sequence of functions 3 1 3 Functional Requirements Refer to the use cases in Figure 4 REQ 1 Execute mS cube setup menu item and then the download index values sub menu item REQ 2 Connection object is invoked to link with the server side controller through GPRS or SMS using the technology set as default If default fails then try the next option If neither connection is established alert user to try after establishing a good GPRS or SMS connection REQ 3 Request for index values and lookup values and health terminology with disease symptom and sign relationships If download does not complete or some datasets are empty null then alert user that download was unsuccessful and the user should consult the administrator REQ 4 The controller will invoke the field_options person facility and diagnosis objects sequentially to retrieve the data from the database Then compile the dataset to be streamed to mS cube REQ 4 Download function will unfold the received datasets and then store them in the respective RMS files designated for each index value dataset REQ 5 Once the process is complete alert user with a download successful message and they may proceed
24. f this document When scaling the product to adopt other elements then this SRS must be modified accordingly The designers developers and implementers should be aware of the broader product scope and should generalize in order to accommodate for product enhancements A brief description of the elements and their relationships e Semantic interoperability is an important and highly recommended electronic health system requirement ICD 10 UMLS SNOMED CT and LOINC see Appendix Glossary are some of the data dictionaries available for adoption They define the health terminology such as the diagnosis Health Level Seven HL7 sets the data standard or schema for interoperability HL7 uses the aforementioned data dictionaries The patient case records should comply with the applicable HL7 data standard e There are two main functions that mS cube offers on its mobile platform Those are health data collection and knowledge dissemination The focus of this SRS is on the data collection There are no software requirements described in this SRS for the dissemination e For the sake of redundancy and also choice based on service availability and cost mS cube would provide two options for transporting the data between the central server and the mobile device They are GPRS and SMS data transport technologies e The mS cube application is developed to enable technology in support of the S3 programs The focus of this SRS is on OPD IPD and SDI
25. health survey class will use the facilities gender age group disease symptoms and signs index lookup values If the patient is diagnosed with a SDI see section 5 at the OPD or IPD and the diagnosis is entered in to mS cube as the disease name then the mS cube logic would prompt the user to enter additional SDI related information such as the patient s contact address guardian name date of birth national identification number etc Execute the submit button to send the data to the server If mandatory fields are null or inappropriately entered then alert user to retry Connection object is invoked to link with the server side controller through GPRS or SMS using the technology set as default If default fails then try the next option If neither connection is established alert user to try after establishing a good GPRS or SMS connection 4 2 4 3 REQ 5 Send the survey data across to the server controller It will write the data to the database If either insert or update of the patient case fails then return an error message indicating server failed to register the user Otherwise return the case identifier which indicates success REQ 5 Once the process is complete alert user with the patient case identifier indicating the case was successfully stored else alert the user with the server or client side error message then mentioning to try again or consult the system administrator Other Nonfunctional Requirements Pe
26. idemiology Unit staff will notify the decision makers e g MOH or CE of the potential threat Thereafter the decision maker will decide the priority level and authorize the detection and monitoring staff to issue a bulletin alert to those health officials in the vulnerable areas The weekly reports are regarded as low or high priority bulletins reports and the immediate notifications alerts are regarded as urgent priority bulletins Table 5 Weekly reports and urgent alerts issued by RA Epidemiologist to all healthcare workers Attributes Examples Headline Single values A head line describing one Rains increase mosquito born or more significant event s diseases Chinkengunya appears in North Central province Unusual fever like disease emerging among children Priority Single value indicating the urgency 1 low severity and certainty of the emerging 2 high disease with priority levels high 3 urgent healthcare worker should access alternate resources to learn more about the emerging disease and be vigilant perhaps inform community low healthcare worker should be vigilant but does not need to take any action or urgent if message is intended for the healthcare worker i e affects area healthcare worker is in then take immediate intervention and prevention actions Multiple values to identify the Western and Central Provinces geographical areas the significant event ha
27. lways accompany the same symptoms bloody stools Diarrhea by the practitioner doctor Discoloration of tongue Single value Male Female or Unknown Age Group Single value Age categories it at the Adult Child discretion of the implementers as to how 0 10 11 20 91 100 they wish to define the age categories Infant 0 1 Child 2 12 Teenager 13 19 Youth 20 25 Adult 26 50 Elder 50 100 Case Date Single Value The date the patients or the 2011 07 25 cases were recorded by the provider i e visitation date or admitted date 5 4 2 Typical attributes of health record stored in database The relation database must have a record of the attributes defined in Table 2 The table structure will contain more attributes than described in Table 2 as well as related data and preserve data integrity The data gathered health records of patient diagnosis and syndrome by the healthcare workers from the provider will be stored in this database The same data will be made available for the purpose of analysis Table 4 Information stored in the database Same as in Table 2 EDEN Disease Same as in Table 2 can be null The database will try to resolve suggest a BEEN diagnosis based on the received symptoms Symptoms SameasinTable2 canntbenul Signs Same as in Table 2 can be null J o y O Same as in Table 2 If the input value is MEN NULL then will defa
28. makers and provision for access to information by all authorized personnel at any time from any place Based on the business study we have proposed a Mobile based Sentinel Site Surveillance mS cube It is a set of mobile interfaces to be used by healthcare workers in managing S3 standard operating procedures The suite of mS cube applications would be developed using the JavaRosa framework 4 The Sahana Disaster Management Software System s Biosurveillance Module will support the back end relational database schema for data warehousing 5 However the mS cube should not be limited to Sahana but should be standardized to interconnect with other eHealth computer systems To begin with we recommend that developers concentrate on the following set of S3 application that would provide a rich data set to reliably detecting public health events e Outpatient OPD and Inpatient IPD case records e Special Diseases with investigations SDIs e Immunization programs e Laboratory results However version 1 0 of the mS cube SRS only discusses the specifications for OPD IPD and SDI These three S3 programs share a common schema and processes 1 2 Intended Audience and Reading Suggestions The document is intended for but not exclusive to e Software developers and domain experts e Immediate beneficiaries are LIRNEasia OpenRosa and Dimagi e Also intended for sharing the mS cube developments with members of the JavaRosa FOSS community
29. n which otherwise would require addition of specialized resource persons Similarly the architecture and operations of mS cube should stay within the same cost bounds Data transport options should be flexible allowing the implementation to provide at least two option such as SMS and GPRS In Pakistan SMS is preferred as it is the same cost as GPRS but SMS precedes network coverage over GPRS In Sri Lanka and India GPRS is much cheaper than SMS 2 5 3 Software design considerations Although health sector working language is English there is a need for localization Health workers can submit clinical information in English but any health information shared with patients may need to be in the local language such as drug intake instructions and antenatal postnatal information Important that health terminology is consistent especially for statistical inferencing Whenever possible use standard ontologies such as SNOMED CT UMLS ICD 10 codes etc Although flexibility should be given for entry of free text to accommodate those irregular case drop down lists with option to select is strongly recommended This would also help reduce the data entry time 2 6 User Documentation User manuals will be in two flavors 1 comprehensive user manual with details of all elements and 2 quick reference guides In addition a set of standard operating procedures for implementation maintenance and support of the products will be provided The list of p
30. nt Specification WER Weekly Epidemiological Report JAR Java Archive JAD Java Decompiler
31. orted over GPRS or SMS to the server The case data typically comprises case date facility patient name contact address gender age disease symptoms signs service status 7 Store data in database MySQL All cases data comprising case date facility name healthcare worker id gender age group disease symptoms signs patient name address and contact information is stored in the cases xml file person xml lookup values field_options xml cases xml working facilities facility xml diagnosis xml Figure 3 data flow diagram of mS cube 2 3 User Classes and Characteristics In general the users are the healthcare workers government or private Although the names titles assigned to the healthcare workers for the purpose of disease surveillance in Sri Lanka may differ from other countries the roles and responsibilities are quite similar Table 1 User classes with the expected privileges for the resource types User Class Privileges Resource Types Administrator Add Edit Disable Linux server and database users and Systems Administrator assign full access to the software and operating system Software Engineers Implementer __ Direct access to the database to Add Edit Disable Health professionals records full access to the mS cube software for Business Analysts implementation specific configuration Super User Complete access to all mS cube mo
32. r receives the database process status An acknowledgement is sent by the server side controller to the mS cube That status message is displayed on the mobile screen 10 Login information is retrieved by controller 11 Login information is sent to user as an SMS text message 12 Upon viewing SMS the login information is displayed CONAN RYWNS A HealthWorker execute register present attributes enter info save info query insert update SMS login show login Figure 6 register profile of user sequence of functions 3 2 5 Functional Requirements Refer to the use cases in Figure 4 REQ 1 REQ 2 REQ 3 REQ 4 REQ 5 Execute mS cube Setup menu item and then the register user sub menu item Invoke user authentication class in mS cube and present a GUI to select the healthcare worker type and enter the preferred login name password name identifiers and contact information After entering the required information the user execute the submit button to send the data to the server If mandatory fields are null or inappropriately entered then alert user to retry Connection object is invoked to link with the server side controller through GPRS or SMS using the technology set as default If default fails then try the next option If neither connection is established alert user to try after establishing a good GPRS or SMS connection Send the user profile data across to the serv
33. rent trends age sex seasonality within the sentinel sites Assuming close similarity to a larger geographical region in various respects these trends may be extrapolated and generalized Evaluation of S3 is advisable on a cyclic basis and should be done objectively Projects which fail to measure up should be redefined and redesigned or terminated Proposed tasks include describe public health importance describe the system objectives health events case definitions flow chart components and operations evaluate usefulness i e resultant action taken assess attributes simplicity flexibility acceptability sensitivity predictive value positive representativeness timeliness resource analysis conclusion recommendations 1 evaluation of surveillance systems also refer to the source Guidelines for evaluating surveillance systems Morbidity and mortality weekly report supplement 1988 37 S5 1 4 References 1 Routine and Sentinel Surveillance methods http www emro who int publications emhj 0201 06 htm 2 Manual of Guidelines for Sentinel Site Surveillance in Sri Lanka http tinyurl com 2dbxok5 3 Sampath C Ganesan M Waidyanatha N 2010 mHealth Revolutionizing public health an economic 5 Communication Policy Research south CPRsouth 2010 December 11 13 2010 Xi an China Available at SSRN http ssrn com abstract 1725165 4 JavaRosa Repository on Bitbucket is available heare https bitbucket org
34. rformance Requirements mS cube must support real time systems Creating a patient case record should take less than ten seconds Applications must work in the presence and absence of network connectivity Information reliability must be 90 or more to detect reliable adverse events like disease outbreaks Security Requirements Access to the mS cube installation files i e JAR and JAD files should be secured for download and installation by authorized personnel only i e provide a dynamic login to the public domain to download the installation files Any personal information related to the user or the patient should be safeguarded and should not be accessible an unauthorized person using the mobile device mS cube should be able to flush any redundant information that is cached in memory or be able to clear all data from the phone if necessary The server side data should be secure and not be accessible by unauthorized persons Usual system and database administration practices should be followed for system or database restoration Software Quality Attributes Operating the mS cube should be self intuitive with minimal training or orientation instructions Support service must be provided to handle any unusual mS cube operational issues The mS cube software must be modular and easy to enhance i e add new features It is highly recommended that mS cube adopt XML or binary XML schema to enable interoperability e The software should op
35. roducts with user manuals and standard operating procedures e Install configure and operate the mS cube e Quick reference guide to using the mS cube applications e Server software installation and implementation e System administration and support 2 7 Assumptions and Dependencies e Evidence points to relatively older health workers to be shy in using text based mobile applications hence the health workers may reject the technology e Emphasis on interoperability my become a complex problem to solve especially tying to incorporate binary XML may not be feasible in this phase of the project e Incorporating standard health ontologies may also be too complex e Given that the S3 programs may vary between countries striving for a generic suite of applications may not be realistic As a result additional documentation would be required to outline the implementation specific criteria e The mS cube application framework relies on the stability of the underlying JavaRosa framework Bugs or shortcomings in the JavaRosa framework may become a drawback or require additional investments in rectifying those issues first 3 System Features The system features document in this version of the SRS are for the OPD IPD and SDI case information collection applications Both the OPD and IPD can use the same submit case record feature A slight difference might be is that the OPD department may not record the patient s name where as the IPD
36. rs to patients ratio especially in OPD clinics health workers are already overwhelmed with routine work The technology intervention should increase productivity and reduce the workloads The technology should be designed to take less than 10 of their overall working time Moreover health workers in developing countries are uncomfortable with text based technology applications Therefore the applications should simple and self intuitive 2 5 2 Technology limitations Broadband is still making its way through a predominant portion of the developing countries Therefore the applications should work on the mobile device relying less on connectivity Example of what is not recommended is a pure web based application that require a continued connection Network coverage is restricted by shadow areas within health facilities The application should function off line Thus be able to process and store health records until such time connectivity is established and data is shared with the central data repository Cost factor is crucial and should take in to consideration that typically people spend approximately 7 of their house hold income on communications The economic analysis of RTBP also points to the technology component to be less than 8 of the overall total cost of ownership Utilizing standard market common mobile handsets opposed to computers or smart phones provides the environment for health workers to maintain the phones on their ow
37. s Pannal Wariyapola Divisions emerged in or is affecting Kuliyapitiya Nathandiya Pannala Towns Description Single values Table of at most top 5 1 Dengue 23 Malaria 15 Flue diseases and their counts or the most 145 significant urgent priority adverse event and Chikengunya 12 a description of the incident be advised 12 cases of Chikengunya identified in Kurunegala district rapidly spreading take immediate action Resources Multiple values http link to website with http www epid gov lk WER full report for users to access to obtain http www sahana lk DS GIS W further information and instructions ER IVR 9198555123123 Deputy Director Health Services 914455599889988 Table 6 Attributes associated with the Healthcare Worker identification Provider Description Example Attribute Name Registered name of the healthcare Asiri hospital Pannala Community provider or facility Health Center Dr Roshan Hewapathirana MD Chennai Family Clinic Type The type of the healthcare provider Hospital Clinic Community Health defined by the country s healthcare Center Maternity Home General system Practitioner State Province 1 State or Province within the Tamil Nadu Rajasthan Western country the provider operates in or is Central licensed to operate District 1 District within the State or Sivaganga Kurunegala Kandy Province the provider operates in or is licensed to operate Village
38. s the define facilities function User is presented a GUI with attributes to enter the information Then submit the request to retrieve the set of health facilities Request is submitted to the server side controller Controller retrieves the filtered data from the database Selected results are returned to the server side controller Server returns the compiled data to mS cube Received health facility data is stored in the RMS Status message is displayed on the mobile screen MOsgou Qv UA xo NO A HealthWorker execute facility present attributes enter info get facilities query select display status Figure 7 Sequence of functions to define a working facility location 3 3 3 Functional Requirements Refer to the use cases in Figure 4 REQ 1 REQ 2 REQ 3 REQ 4 REQ 5 Execute mS cube and click on setup menu item and then the facilities sub menu item Invoke facilities class and present a GUI to select the health jurisdiction administrative area like PHI area MOH division or Health District and enter the jurisdiction name area name typically the town s name Execute the submit button to send the data to the server If mandatory fields are null or inappropriately entered then alert user to retry Connection object is invoked to link with the server side controller through GPRS or SMS using the technology set as default If default fails then try the next option If neither
39. timize on battery power such as establishing network connectivity as and when needed or dimming the screen when idling e The data transmitted over the network should be optimized to save network utilization expenses i e minimal data loads 5 Other Requirements In addition to the requirements for the OPD and IPD a few extra features are required for SDI This would entail prompting the user to enter that additional information if the disease entered is one from the list of diseases that require special investigations 5 1 Special Disease Investigation software logic Diseases that require special investigations are 1 Poliomyelitis Acute Flaccid Paralysis 8 Leptospirosis AFP 9 Dengue 2 Diphtheria 10 Encephalitis including Japanese 3 Pertussis encephalitis 4 Tetanus Neonatal tetanus NNT 11 Cholera 5 Measles 12 Human Rabies 6 Rubella Congenital Rubella Syndrome 13 Mumps CRS 14 Meningitis 7 Viral Hepatitis 15 Chicken pox If health record based on a patient s diagnosis contains majority of the symptoms or signs that are the criteria for selecting patients with ILI then the user should be alerted of the suspected case and possibly prompt user to enter the additional information same as in the SDI Criteria for selection of patients for ILI Influenza like Illness 1 Acute onset at least within 4 days 5 Myalgia 2 Cough 6 Prostration weakness 3 Fever 7 Redness of throat 4 Rigors or chills 8 Similar
40. ttributes of health record stored in database eee 26 5 4 3 Alerting and reporting of emerging disease outbreaks sene 27 6 Appendix A GLOSSARY jose oe eri tier ente et reor teen ato eee Devi pee e eua oe eain vv ee pesa on Gu Dua nui e0 EM pue RN Nue E YE TE Ee RU qR 29 Revision History Reason For Changes Version Nuwan Waidyanatha LIRNEasia 2011 08 17 Page ii 1 Introduction 1 1 Purpose The purpose is to address the user requirement derived from the close analysis of the current Sentinel Site Surveillance S3 in Sri Lanka 1 and 2 The three main weaknesses deduced from the business analysis are 3 1 The existing system purely thrives on a set of known diseases labeled as notifiable diseases and not on detecting emerging diseases or other adverse health events 2 The time taken in delivering the vital health information both upstream and downstream through paper phone and fax based system is greater than 10 days 3 Present disease surveillance and notification system in Sri Lanka is costly labor and paper intensive process Summarized user requirements in the efforts to address the three weaknesses 1 design a comprehensive system to detect all adverse public health events thus collect all patient health information for analysis and dissemination in a timely manner 2 design a system that can directly communicate health information from the point of care to the key decision
41. ult to Unknown AgeGroup __ Same as in Table 2 cannot be null J Date SameasinTable2 canbenull ICD 10 Single value International Code for A01 0 Typhoid fever Diseases version 10 the database will A90 Dengue Fever resolve the value based on the relationship B01 Varicella chickenpox of the codes associated with the diagnosis none some diseases are not disease The healthcare workers will not classified So none should be a be required to submit this data but the valid option internal processes will fill in the voids Long Lat Two values GIS longitude and latitude e Lon 8 1414 Lat 3 4123 will be resolved by the database by looking up the values from the pre registered GIS location information of the provider village town or other location identifier Other Multiple values other attributes the user 1 Spatial Scan can set or processes the user can execute to 2 WSARE detect adverse events 3 Tipmon 5 4 3 Alerting and reporting of emerging disease outbreaks Required attributes to generate weekly disease surveillance reports such as the WER and issuing alerts of potential threats such as emerging disease outbreaks The RA or epidemiologist will extract a summary of the weekly report e g WER and send the report to the healthcare workers each week In the event of detecting a significant health threat the resources associated with detection and monitoring e g RA or Ep
Download Pdf Manuals
Related Search