| Version 41 (modified by , 14 years ago) ( diff ) |
|---|
Table of Contents
Next for: Hospital Management System with Request Management System
nursix says: The nice thing about testing this system in Sri Lanka, developing it in Sweden and deploying it in the United States is that this happens clockwise - and thus you can always finish breakfast before it's getting urgent :P
Notes by nursix
- IMPORTANT - Disambiguation:
- "Shortages" in the current Prod HMS version will be replaced by a functionailty like/equal to the RMS
- this integrated "RMS" shall be called H-RMS for now, it is completely independent from the ordinary RMS
- this wiki page is not about the original RMS
- all requirements/bug reports targeting the H-RMS shall be directed to HMS, not RMS
- all requirements below targeting RMS actually mean H-RMS
Implementation branch:
- Current Instances/Branches:
Nick Purpose URL Branch Comment KABAP Pre-Production http://haiti-hms.sahanafoundation.org/live/hms lp:sahana-eden/haiti-release Final Production Branch PROD Production http://haiti.sahanafoundation.org/prod/hms lp:sahana-eden/haiti-release Final Production Branch
VITA Demo http://vita.sahanafoundation.org/sahana/hms lp:sahana-eden/vita Main Development Line for HMS VITA-HMS Demo http://vita.sahanafoundation.org/hms/hms lp:sahana-eden/haiti-hms obsolete
globaliist says: I thought KAPAB was based on lp:s3/haiti-release code? Check with TimClicks. This should function as a test/UAT environment for integrating with the other systems that are a part of this project. Once KAPAB is ready to go live, will need to flush and set up sync with production.
nursix says: yes, sure, sorry - didn't update the table
Workflow
Incoming
- Discussion: https://bugs.launchpad.net/sahana-eden/+bug/513648
- Discussion: https://bugs.launchpad.net/sahana-eden/+bug/513649
- Discussion: https://bugs.launchpad.net/sahana-eden/+bug/513651
Feedback/Question/Discussion
- Security - enable role management
- this is an urgent requirement assigned to sysadmin team: Praneeth (lead), Tim & Dan.
- Need written recommendation sent to mark by e-mail by 1600Z on 28 January 2010; meeting in #sahana-py at 1700Z on 28 January.
- Background:
- Security for personnel on ground makes it inadvisable to publish publicly the needs and fulfillment information that might be embedded in the HMS - i.e. publishing that medical supplies are to be delivered to this place at this time might put the shipment and relief workers lives at risk.
We need a plan to implement role-based access to different Sahana libraries I need the sysadmin team to advise which of the following requirements is possible to do through front-end configuration of SahanaPy security settings (preferred) and which will require coding changes (not preferred). Alternatives are welcome.
nursix says: Role-based access control is already there (in the web2py framework) but needs implementation of a front-end to set user roles in the admin module. So, code changes are required in any case.
The team should also evaluate and advise on the impact shutting down read-only public access to parts of sahana will have on our feeds of data on hospital locations and hospital management data. Requirements:
- Public/anonymous access: Read only access to OR, RMS Twitter and 4636 Messages.
- Option to make HMS hospitals feed with location and general information - but not the shortages table - publicly available
- Can we hide individual fields (like beds available, security status, facility status) from public view without code changes?
- Registered users: Read only access to entire system (adding PR and HMS / HMS shortages)
- Entry users: Registered users who are given add/edit/update/delete access to OR, PR, HMS
- Options to create additional groups that have add/edit/update/delete access to each individual registry - and bundle people that way. e.g. Tim has write privileges to OR and PR but not HMS or RMS; Praneeth has write privileges to RMS but nothing else; Dan has write privileges to RMS, OR, and PR but not HMS.
- Add Link to Bed Capacity, Services, Shortages, Contacts to main ADD Hospital form @ /hms/hospital/create
Notes from dzubey
Need to establish who are our user groups? Then based on that what rights should they NOT have.
- nursix says: I added the following roles (auth.group):
Role proposed for HMSViewer basic access to HMS HMSOrg additional ability to view facility status/requests/pledges and to submit pledges HMSFacility additional ability to update facility status and submit requests HMSOfficer additional ability to update requests and pledges HMSAdmin access to everything in HMS
globaliist says: I like role-based systems. Thanks. Is this too complex? How does it address above requirements which include OR, PR, RMS (not H-RMS) but this seems to create a level of complexity that will be hard to administer or is that more straightforward to implement based on the above requirements
If the main concern is keeping certain data away from the general public, and we are time crunched, then a generic anonymous / read-only / read-write structure is fine...but this makes it very hard to change in the future. There is an more optimal method of assigning flags to users, which indicate what capabilities they are allowed, as opposed to role-based (nursix thinks: role-based ACL is a proven good solution, implemented by the web2py framework, so nothing we have to develop, and you can always add one "role" per user and thus establish an individual ACL)
we've already leaked a good quantity of data to various search engines and blogs and whatnot. I imagine this current push is to secure future data we capture.
globallist says: dzubey.... the requirements come from what I already explained - it has to do with the safety and security of relief workers... not because the data is otherwise sensitive.
Accepted
Solved
- Add Register for new account and Login Links prominent on home/splash page
In Progress
Implemented
- We need to manage additional "medical facilities" beyond hospitals. I think we can do this now without further modification as one is not prohibited from entering something that is not a hospital after you select "add hospital".
- For HMS - Locations:
- Other feature classes that we can expect will be added to the HMS are: "field hospitals", "clinics", "pharmacies", and "helipads". While it is easy to add these are locations and give them a different feature class and marker, there is no category within the HMS record itself, unless we pull it from the location feature class... Can we do that?
- Road Status (comment field to describe road access to the facility).
- Add Operating Room Status to list of services on Hospital entry/edit form - similar to Emergency Room, Clinical, Facility, Security fields now.
- For RMS - additional fields needed:
- Tick-box - "For Further Review" - this will tag a request as needing review by SOUTHCOM - based on current set of daily priorities - they will want to see a list of those items marked "For Further Review" and will manually want to validate the information as actionable.
- Tick-box - "Validated" - once a request marked "For further review" has been validated, this will be used to identify validated actionable requests for immediate tasking by SOUTHCOM
implemented as "Status" option field for wider workflow control => replaces the verified/validated checkboxes
- For HMS - additional fields needed for hospital data:
- Ability to attach multiple meta-data tagged files (e.g. photos of the facility, scanned maps of the area and surrounding roads).
- Provenance of data - without adding any fields (at this time), we need to display the last time data records were updated and by whom - we should be able to pull from the last modified column and the registered user who made the modification. This is especially important to allow for evaluation of how old data is and how often it is being updated. Maybe a big bold splash on upper right when viewing a hospital record would say "Last modified on DDMMYY at HH:MM UTC by <Registered User>". Or just show the data as additional field in form view or column in table view.
