Difference between revisions of "Mumbai Lilavati Hospital"
Bradymiller (talk | contribs) (Created page with ''''<big><big><center>[http://lilavatihospital.com/web/ Lilavati Hospital] in Mumbai</center></big></big>''' <b>HMO Project in Mumbai, India (formerly Bomba…') |
Bradymiller (talk | contribs) m (1 revision: second) |
(No difference)
|
Latest revision as of 07:46, 26 August 2011
HMO Project in Mumbai, India (formerly Bombay)
Project leader: Dr. R. D. Lele
IT Administrator: Jain Suvienay
Dr.Lele, a Padmabhusan award holder (which is given by the government of India for excellence in respective fields), and the head of nuclear medicine and research at the Lilavati Hospital in Mumbai, India has started developing a Health Maintenance Organization in Mumbai, India. Jain Suvienay has proposed using OpenEMR for the electronic health record for this project.
The trial HMO will include 100 doctors managing the healthcare of 50000 families (4 members per family) spread over a WAN. The population lives in a slum area of India. We will have a central server which will be accessed by the GP's. Links to pharmacy and hospital will be also there.
Some of the requirements of the software include:
- 1) Doctors can view only their own patients and not all patients. Secondly if referral is given with access code, they can view other GP's patient also.
- 2) Calender to be modified so that only the calender of logged in doctor is shown.
- 3) Patient data to be exportable. We plan to give rewritable CD's to each patient so that they have their medical data with them wherever they are. This data can then be invaluable incase of emergencies where their primary provider is not available. The data should include all the data of the patient including demographics, encounters etc. Obviously, the data should be updated with each encounter
- 4) The prescription module needs considerable addons which are:
- a) there is no way to delete or delist medications?
- b) there is no time frame for taking a medicine i.e. start date and end date
- c) DRUG DRUG interaction check is CRUCIAL for us. This should be part of the database on the central server which is updated constantly. An alert should popup if any adverse drug reaction is present.
- d) CLINICAL DECISION SUPPORT SYSTEM to be built into the system. We have access to a wealth of information from research institutes, medical sources, colleges etc to build the database. This should be as an alert system. For example if a person above 65yrs with xyz disease is being prescribed abc drug and the preferred drug is zzz then an alert should popup that the preferred drug for this patient for this ailment is zzz. I am sure everyone will agree that this will be invaluable to healthcare
- 5) One major hurdle we see is that GPs' are not comfortable using a computer and will be reluctant to attend 'computer classes'. Therefore if possible the encounter screens can be made more graphical with point and click showing images instead of text where needed (for example if chest are is targetted, then a chest icon brings up relavant forms and information.
- 6) With the same computer literacy concern, the initial medical history capturing becomes a concern. What we are trying is to build an instant medical history program wherein a series of question (in vernacular) are asked the patients and they reply with simple yes or no. Intelligent branching can be used to choose only relevant questions. There are sources available for this, the links of which I will post shortly.
- 7) Upgrade ICD9 with ICD10 and the ability to add custom codes.
- 8) Since we are working on a family system, the patient database to be modified to include a family system with 2 parents and two children and the ability to link all the members of the family ie If I click on the male parent, then links to his wife, children are provided.
- 9) Security and encryption needs to be implemented.
I request all of the developers out there to help us develop these features. Everything will be released as GPL and I am sure that this can be an important landmark in medical history with OpenEMR. I understand that some development will require funding. Please send me your quotations for these features and also which feature will someone be willing to do for free. Ours is a not for profit HMO and targeting the poor. THe main purpose of this HMO is to bring good healthcare to the poor, who are in dire needs of good healthcare but cannot afford it.
We have bookmarked appx 3000 US dollars for the software for the trial.
Any advise and help will be highly appreciated. Thanks
Your items #2, 3, 7 and 9 are already implemented or would be easy to implement.
- 1, 4, 5, 6, and 8 are moderately to very difficult and even designing them to the extent that they can be quoted on would take a great deal of effort. I think a good way to move this forward would be for you to be much more explicit about how you would like to see things work. This would surely generate some interesting discussion and help to converge on good designs.
Your $3000 budget is not enough, but your needs are widely shared and perhaps some collaboration will make it happen.
-- Rod
Agreeing with Dr. Bowen, but with a couple of minor notes and corrections:
Medications as currently implemented do have both start and end dates. Like other "issues", they can also be associated with encounters and with a diagnosis. As Sam notes, what's missing is a direct association with prescriptions and so double entry is required, however this would not be difficult to fix.
There is also currently a feature to export patient data to an XML format. This is currently just demographics but could be easily enhanced.
ICD10 codes are easily adapted, as I implemented changes last year to abstract the billing code types. See openemr/custom/code_types.inc.php.
Family associations could be supported by adding a SQL table for that purpose, and of course some associated PHP code. Should not be difficult.
-- Rod http://www.sunsetsystems.com
Dr.Bowen,
The most important requirement is drug drug interaction check among the other minor to medium modications required.
The big ones, like you correctly pointed out are:
- 1)Graphical interface
- 2)Instant medical history capturing
- 3)Decision Support System (MAJOR)
We know that these will take time, but would like to make a start so that we get there in the future and do not just spend time 'talking' or 'wishing' as happens in many cases. Thanks all, Suvienay
Yes, we have a plan in mind when it comes to preparing the GP's for EHR adoption.
We plan to give them one laptop plus printer cum scanner so that they can access information and give prescriptions to the patients (in vernacular) and also additional information which educates the patients.
What we plan to do is provide the hardware and charge easy installments to the GPs' so that they own the hardware over a period of a year. This will ensure that they will take care of the hardware as we have seen that anything provided 'free' is misused and not taken care of.
The funding for the hardware will be taken care of when the need arises as it is part of the overall HMO proposal. Prior to that we need to have a workable EMR ready. Time frame 2-3 months.
I will get additional information about the project and mail you personally.
Thanks -Suvienay
hey,
Regarding drug interactions and clinical decision support systems:
Regarding drug interaction checker, seems like we should just utilize same strategy as OpenEMR's drug database, which does look up on-the-fly at http://www.rxlist.com. There seems to be a couple possible sites/servers options such as: http://www.drugs.com/drug_interactions.html I'd go for making this as an optional 'button', such as when adding/prescribing a med or to run a patient's entire list. I say optional, because these things can get really annoying(I work at VA some of the time on CPRS Vista, and occassionally get the urge to toss the computer out of the window because of excess warnings)
Regarding clinical decision support system, this term is very broad. Maybe a place to start would be a 'reminder' module. Could make flexible, so could be useful to primary care, specialist, alternative medicine, etc. Basically could allow the 'admin' to make 'rules', such as age, sex, frequency, and disease(if any). For example, at a primary care practice they could enter rules for routine screening/preventative care(vaccines, colonoscopies, PAPs, depression assess, smoking lecture, PSA discussion). By using entered 'rules' OpenEMR could generate the individualized reminders, and then practitioner could just 'click' on them when completed. This can also be extended to diseases such as DM(brings in a whole new panel of screening, and a reminder to consider aspirin) and CAD(make sure the patient is on all the good meds). It seems that all we need to do is create a easy way to enter the rules and enforce them, then the user can add/customize them as they choose.
later,
brady
Ballards has suggested looking at OpenCyc
For the decision support.