Re: [Care2002-developers] Care evolution
Hi Gugs Is it possible to use this features (Confirmation of inability to work, Charts folder, Diagnostic Results, Medocs, DRG (composite), Prescriptions, Notes Reports, Immunization, Measurements, Pregnancies, Birth details) when the patient is admitted as OUTPATIENT. I know is possible when the patient is INPATIENT. What I've noticed is that they are all in-active when the patient is OUTPATIENT , - Original Message - From: Tim Schofield tim.schofield1...@googlemail.com To: care2002-developers@lists.sourceforge.net Sent: Sunday, August 16, 2009 10:18:37 AM GMT +02:00 Harare / Pretoria Subject: Re: [Care2002-developers] Care evolution Hi, As Robert mentioned we now have a version that links completely with webERP from registration and admission through Radiology/Pharmacy/Lab through to billing, doing all the necessary accounting and stock entries automatically. I am now in the process of cleaning up that code and then feeding into sourceforge those parts that we would want in the main line. I think it is time that we start to bring the various Care2x versions together into one version. For instance having a flexible registration form that can be altered for different locations. Tim 2009/8/14 Robert Meggle meg...@merotech.de: Hi Frank, Thanks for that encouraging email! And it seems we have quite similar ideas. First of all we should focus the one release idea. By Monday next week I will upload the latest release we have done so far for the Arusha team. Tim and Beth worked long and hard to get a functional interface to webERP and now it is working. It contain even the pharmacy and stock interface and some other nice features. I am sure that Tim will comment his work by himself. This step is a quite interesting and now we are together when we talk about to centralize. At the end there should be one version and not branch what determine what could be used in what case. Also some other ideas in my mind what we could do, different scenarios I got from Hospitals. One example would be Equador who asked if there would be a way to start the implementation just with laboratory instead of registration. Other ideas are quite more easy to realize, when e.g. a internal department like the dentist clinic has appointments of patients not registered so far. Each testing step must be cleared and I am sure we will find quite many tester of our system. :-) First.. let show us together how we can use all to merge it. That would be the good step. Cleaning the code, as you mentioned, is also a needed step. Maybe we could call it code review and we have now a nice roadmap. Thanks Robert Am Freitag, den 14.08.2009, 16:59 +0300 schrieb frank tilugulilwa: Dear All, I am not intending to distort anything said below by Gjergi. Its a brilliant observation/email, please receive my appreciation. @ UCC Limited (Tanzania), i am the 3rd if not 4th developer to be given this challenge to study Care2X. It has not been an easy task. Suggestions : 1. To harness efforts/ skills of different programmers, we should have a central repository (for development version) where all changes are committed to it. No individual repos/ multiple copies. 2. There should be a way to have a Care2X stable release @ agreed interval 3. We should start cleaning the directory and file structure (what should be here and what there). we have to agree on the standards to be followed. 4. We should clean the code itself, unused code and re-arranging some. 5. We should also document the architecture and the existing modules 6. All bugs should be centrally reported. ( can use Trac etc), this will create a knowledge base as well 7. Feature requests should be communicated to the list, we should have some sort of a whitepaper before developing something for people to participate/ contribute to the idea. 8. Testing team should be identified. We can all test but at least few of us should be responsible for testing and reporting back. If we do 60% of these Care2X will be a killer application. Which leg to start now? left or right ? My few cents! Thanking you, Frank Tilugulilwa On Sun, 2009-08-02 at 20:52 +0200, Gjergj Sheldija wrote: hi all this mail was sent some time ago..i think thay i should resend it again.. A long time has passed since c2x appeared and a lot of things have changed over the years. PHP has become a more robust and business oriented language, a lot of tools are disposable for developers and a lot of new business strategies are available to help with the common day to day problems that we encounter. Localization and internationalization are now more easy that they used to be, and php 6 promises even further improvements via Unicode support. Creating user documentation is now much more easy via wiki’s
Re: [Care2002-developers] Care evolution
Hi, As Robert mentioned we now have a version that links completely with webERP from registration and admission through Radiology/Pharmacy/Lab through to billing, doing all the necessary accounting and stock entries automatically. I am now in the process of cleaning up that code and then feeding into sourceforge those parts that we would want in the main line. I think it is time that we start to bring the various Care2x versions together into one version. For instance having a flexible registration form that can be altered for different locations. Tim 2009/8/14 Robert Meggle meg...@merotech.de: Hi Frank, Thanks for that encouraging email! And it seems we have quite similar ideas. First of all we should focus the one release idea. By Monday next week I will upload the latest release we have done so far for the Arusha team. Tim and Beth worked long and hard to get a functional interface to webERP and now it is working. It contain even the pharmacy and stock interface and some other nice features. I am sure that Tim will comment his work by himself. This step is a quite interesting and now we are together when we talk about to centralize. At the end there should be one version and not branch what determine what could be used in what case. Also some other ideas in my mind what we could do, different scenarios I got from Hospitals. One example would be Equador who asked if there would be a way to start the implementation just with laboratory instead of registration. Other ideas are quite more easy to realize, when e.g. a internal department like the dentist clinic has appointments of patients not registered so far. Each testing step must be cleared and I am sure we will find quite many tester of our system. :-) First.. let show us together how we can use all to merge it. That would be the good step. Cleaning the code, as you mentioned, is also a needed step. Maybe we could call it code review and we have now a nice roadmap. Thanks Robert Am Freitag, den 14.08.2009, 16:59 +0300 schrieb frank tilugulilwa: Dear All, I am not intending to distort anything said below by Gjergi. Its a brilliant observation/email, please receive my appreciation. @ UCC Limited (Tanzania), i am the 3rd if not 4th developer to be given this challenge to study Care2X. It has not been an easy task. Suggestions : 1. To harness efforts/ skills of different programmers, we should have a central repository (for development version) where all changes are committed to it. No individual repos/ multiple copies. 2. There should be a way to have a Care2X stable release @ agreed interval 3. We should start cleaning the directory and file structure (what should be here and what there). we have to agree on the standards to be followed. 4. We should clean the code itself, unused code and re-arranging some. 5. We should also document the architecture and the existing modules 6. All bugs should be centrally reported. ( can use Trac etc), this will create a knowledge base as well 7. Feature requests should be communicated to the list, we should have some sort of a whitepaper before developing something for people to participate/ contribute to the idea. 8. Testing team should be identified. We can all test but at least few of us should be responsible for testing and reporting back. If we do 60% of these Care2X will be a killer application. Which leg to start now? left or right ? My few cents! Thanking you, Frank Tilugulilwa On Sun, 2009-08-02 at 20:52 +0200, Gjergj Sheldija wrote: hi all this mail was sent some time ago..i think thay i should resend it again.. A long time has passed since c2x appeared and a lot of things have changed over the years. PHP has become a more robust and business oriented language, a lot of tools are disposable for developers and a lot of new business strategies are available to help with the common day to day problems that we encounter. Localization and internationalization are now more easy that they used to be, and php 6 promises even further improvements via Unicode support. Creating user documentation is now much more easy via wiki’s and Java script libraries can help a lot with designing rich and practical UI. I thing that the time is right to start a small revolution in c2x; i’ll list here some suggestion that I think would be useful, they may be right, may not; it’s up to the community to decide. Printing I think printing should be centralized, we should use a centralized code to do that. Agatha with some improvements could ease the creation of new print forms without the need to specify pdf coordinated by hand as we actually do. Localization The current way c2x has of handling translation is very hard to maintain and error prone. A migration to gettext could ease the translation efforts and help c2x greaten it’s userbase. Besides that
Re: [Care2002-developers] Care evolution
Dear All, I am not intending to distort anything said below by Gjergi. Its a brilliant observation/email, please receive my appreciation. @ UCC Limited (Tanzania), i am the 3rd if not 4th developer to be given this challenge to study Care2X. It has not been an easy task. Suggestions : 1. To harness efforts/ skills of different programmers, we should have a central repository (for development version) where all changes are committed to it. No individual repos/ multiple copies. 2. There should be a way to have a Care2X stable release @ agreed interval 3. We should start cleaning the directory and file structure (what should be here and what there). we have to agree on the standards to be followed. 4. We should clean the code itself, unused code and re-arranging some. 5. We should also document the architecture and the existing modules 6. All bugs should be centrally reported. ( can use Trac etc), this will create a knowledge base as well 7. Feature requests should be communicated to the list, we should have some sort of a whitepaper before developing something for people to participate/ contribute to the idea. 8. Testing team should be identified. We can all test but at least few of us should be responsible for testing and reporting back. If we do 60% of these Care2X will be a killer application. Which leg to start now? left or right ? My few cents! Thanking you, Frank Tilugulilwa On Sun, 2009-08-02 at 20:52 +0200, Gjergj Sheldija wrote: hi all this mail was sent some time ago..i think thay i should resend it again.. A long time has passed since c2x appeared and a lot of things have changed over the years. PHP has become a more robust and business oriented language, a lot of tools are disposable for developers and a lot of new business strategies are available to help with the common day to day problems that we encounter. Localization and internationalization are now more easy that they used to be, and php 6 promises even further improvements via Unicode support. Creating user documentation is now much more easy via wiki’s and Java script libraries can help a lot with designing rich and practical UI. I thing that the time is right to start a small revolution in c2x; i’ll list here some suggestion that I think would be useful, they may be right, may not; it’s up to the community to decide. Printing I think printing should be centralized, we should use a centralized code to do that. Agatha with some improvements could ease the creation of new print forms without the need to specify pdf coordinated by hand as we actually do. Localization The current way c2x has of handling translation is very hard to maintain and error prone. A migration to gettext could ease the translation efforts and help c2x greaten it’s userbase. Besides that there are strange cases like js_lang_sex_title.php which is not used in any file. Manual / Help files We all know how hard it is to write, update c2x help files, that why not use a wiki engine ? It would easy the process of maintenance of the the help files, it’s much more easy to translate and this way we could create a much needed manual, and have it updated automatically. HL7 The actual implementation of HL7 is practically non existent. But the we should discuss here about v2 or v3, and if it has to be part of every module, or it should be and external library. The Code…. Here are a lot of things that should be changed and and lot should be deleted. * First there is a lot of code that should be rewritten, think about sql code inside the module code, which is not a good practice. * Second there is no real separation of modules, module files are scattered all around the directory tree, which makes even harder to apply updates and change code around. * Third , the code needs some major clean up; there is a lot of unused code all over which makes further improvements difficult. And a lot of other things that I didn’t mention. UI Major improvements should be done on the ui side, from simple things as changing the tab interface from using images to simple js, to new visualization of the ward, to the possibility of connecting a specific user or group of users to a specific module – an example is the Glasgow Coma Scale. The notification system used in the labs, pharmacy, depot, technical is a bit outdated, a little ajax could make it much more usable. A new theming engine css based could help much more and ease the creation of new UI. Other scattered ideas.. Other things that could be helpful is we should start to use automatic testing, modules can be installable from a central repository, the possibility of connecting specific users to specific modules,etc. Another thing is that we should avoid static configuration in files like
Re: [Care2002-developers] Care evolution
Hi Frank, Thanks for that encouraging email! And it seems we have quite similar ideas. First of all we should focus the one release idea. By Monday next week I will upload the latest release we have done so far for the Arusha team. Tim and Beth worked long and hard to get a functional interface to webERP and now it is working. It contain even the pharmacy and stock interface and some other nice features. I am sure that Tim will comment his work by himself. This step is a quite interesting and now we are together when we talk about to centralize. At the end there should be one version and not branch what determine what could be used in what case. Also some other ideas in my mind what we could do, different scenarios I got from Hospitals. One example would be Equador who asked if there would be a way to start the implementation just with laboratory instead of registration. Other ideas are quite more easy to realize, when e.g. a internal department like the dentist clinic has appointments of patients not registered so far. Each testing step must be cleared and I am sure we will find quite many tester of our system. :-) First.. let show us together how we can use all to merge it. That would be the good step. Cleaning the code, as you mentioned, is also a needed step. Maybe we could call it code review and we have now a nice roadmap. Thanks Robert Am Freitag, den 14.08.2009, 16:59 +0300 schrieb frank tilugulilwa: Dear All, I am not intending to distort anything said below by Gjergi. Its a brilliant observation/email, please receive my appreciation. @ UCC Limited (Tanzania), i am the 3rd if not 4th developer to be given this challenge to study Care2X. It has not been an easy task. Suggestions : 1. To harness efforts/ skills of different programmers, we should have a central repository (for development version) where all changes are committed to it. No individual repos/ multiple copies. 2. There should be a way to have a Care2X stable release @ agreed interval 3. We should start cleaning the directory and file structure (what should be here and what there). we have to agree on the standards to be followed. 4. We should clean the code itself, unused code and re-arranging some. 5. We should also document the architecture and the existing modules 6. All bugs should be centrally reported. ( can use Trac etc), this will create a knowledge base as well 7. Feature requests should be communicated to the list, we should have some sort of a whitepaper before developing something for people to participate/ contribute to the idea. 8. Testing team should be identified. We can all test but at least few of us should be responsible for testing and reporting back. If we do 60% of these Care2X will be a killer application. Which leg to start now? left or right ? My few cents! Thanking you, Frank Tilugulilwa On Sun, 2009-08-02 at 20:52 +0200, Gjergj Sheldija wrote: hi all this mail was sent some time ago..i think thay i should resend it again.. A long time has passed since c2x appeared and a lot of things have changed over the years. PHP has become a more robust and business oriented language, a lot of tools are disposable for developers and a lot of new business strategies are available to help with the common day to day problems that we encounter. Localization and internationalization are now more easy that they used to be, and php 6 promises even further improvements via Unicode support. Creating user documentation is now much more easy via wiki’s and Java script libraries can help a lot with designing rich and practical UI. I thing that the time is right to start a small revolution in c2x; i’ll list here some suggestion that I think would be useful, they may be right, may not; it’s up to the community to decide. Printing I think printing should be centralized, we should use a centralized code to do that. Agatha with some improvements could ease the creation of new print forms without the need to specify pdf coordinated by hand as we actually do. Localization The current way c2x has of handling translation is very hard to maintain and error prone. A migration to gettext could ease the translation efforts and help c2x greaten it’s userbase. Besides that there are strange cases like js_lang_sex_title.php which is not used in any file. Manual / Help files We all know how hard it is to write, update c2x help files, that why not use a wiki engine ? It would easy the process of maintenance of the the help files, it’s much more easy to translate and this way we could create a much needed manual, and have it updated automatically. HL7 The actual implementation of HL7 is practically non existent. But the we should discuss here about v2 or v3, and if it has to be part of
Re: [Care2002-developers] Care evolution
hi all, frank, you have read my mind :) i'll reply in line. but before that, i must say that before thinking of any code review we have to come out with a stable release, 2.6. this way we can have a clean, functional starting point. now some comments... frank tilugulilwa wrote: Dear All, I am not intending to distort anything said below by Gjergi. Its a brilliant observation/email, please receive my appreciation. @ UCC Limited (Tanzania), i am the 3rd if not 4th developer to be given this challenge to study Care2X. It has not been an easy task. Suggestions : 1. To harness efforts/ skills of different programmers, we should have a central repository (for development version) where all changes are committed to it. No individual repos/ multiple copies. which we have... 2. There should be a way to have a Care2X stable release @ agreed interval in principle yes..more on this later... 3. We should start cleaning the directory and file structure (what should be here and what there). we have to agree on the standards to be followed. i've started working on it..as soon as the tools i'm working on are more stable i'll release them... 4. We should clean the code itself, unused code and re-arranging some. see above.. 5. We should also document the architecture and the existing modules we have the wiki ready and functioning, although my idea is to separate the wikis, one for developers on the trac installation and the other for users.. 6. All bugs should be centrally reported. ( can use Trac etc), this will create a knowledge base as well it's there and ready... 7. Feature requests should be communicated to the list, we should have some sort of a whitepaper before developing something for people to participate/ contribute to the idea. we have to talk more on this...much more :) 8. Testing team should be identified. We can all test but at least few of us should be responsible for testing and reporting back. besides that there should be a web team and a documentation one..as a minimum.. If we do 60% of these Care2X will be a killer application. Which leg to start now? left or right ? My few cents! Thanking you, Frank Tilugulilwa that's all :) gj. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Care2002-developers mailing list Care2002-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/care2002-developers
