Hi Mark, Mark Alan wrote: > Taken from the notes of someone who knows the Care2x project far better > than what I was able to learn up until know: > > 1. Reduce from 144 tables to no more 70; > RATIONALE: Clinical data is, by nature, hierarchical. To represent it > by a relational DBMS model some kind of semantic losses must be > accepted. If the relational DBMS model needs to be bended in the > process, so be it. We need a lot less tables in order to keep the > project manageable. > on the clinical side, i completely agree..on the coding side..the majority of them are needed - to ease report development - to ease the life of the programmer.. some very deep improvements are required here.. > 2. Aggregate the care_billing_* tables in 2 tables: one to keep DBMS > architectural definitions and the other to keep the data. > RATIONALE: see point 1. above. If dificult, drop the care_billing_* > tables and modules altogether, they aren't doing much anyway and a > simple interface to a proper ERP would most probably be of much greater > value. > all this is going to be handled by weberp..so they can be completely removed > 3. Drop care_cafe_* tables and supporting code > RATIONALE: see point 1. and 2. above. > maybe move them to some sort of utility module.. > 4. Aggregate the care_category_* tables in 2 tables: one to keep DBMS > architectural definitions and the other to keep the data. > RATIONALE: see point 1. above. > same as point 1 > 5. Aggregate the care_class_* tables in 2 tables: one to keep DBMS > architectural definitions and the other to keep the data. > RATIONALE: see point 1. above. > same as point 1 > 6. Drop care_currency table and supporting code, or integrate them in > care_billing_* > RATIONALE: see point 1. and 2. above. > see point 2 > 7. Aggregate the care_drg_* tables in 2 tables: one to keep DBMS > architectural definitions and the other to keep the data. > RATIONALE: see point 1. above. > agree completely on that > 8. Aggregate the care_encounter_* tables in 2 tables: one to keep DBMS > architectural definitions and the other to keep the data. > RATIONALE: see point 1. above. > see point 1 > 9. Aggregate the care_icd10_* tables in 2 tables: one to keep DBMS > architectural definitions and the other to keep the data. > RATIONALE: see point 1. above. The ICD codes are by definition > universal. There is a localization component that mus be addressed. > Ideally it should be addressed by gettext (or gettext-like) mechanism. > Given the right few lines of code any set of localized ICD text could be > properly imported and inserted in the general ICD data table. > or much better, install only the needed one. the problem here is that the majority of the countries adapt the icd to they're needs. a better idea should be maybe, have them as a plugin(?) and provide a sort of online editor ..
> 10. Drop care_mail_* tables and supporting code > RATIONALE: see point 1. A simple interface to the server's/OS email > subsystem would be far better. The email subsystem is now a potential > dangerous piece of code and should be considered serious enough to be > dealt by specialized, properly maintained and widely available applications. > > because they're completely useless..although internal messaging is needed..external module supporting jabber ? > 11. Aggregate the care_med_* tables in 2 tables: one to keep DBMS > architectural definitions and the other to keep the data. > RATIONALE: see point 1. above. > my idea here is to rewrite completely that part...med's flow and properties should be rethought ... > 12. Aggregate the care_ops301_* tables in 2 tables: one to keep DBMS > architectural definitions and the other to keep the data. > RATIONALE: see points 1. and 9. above. > see point 9...a lot of countries don't use or have ops as an standart.. > 13. Aggregate the care_person_* and care_role_person tables in 2 tables: > one to keep DBMS architectural definitions and the other to keep the data. > RATIONALE: see point 1. above. ALSO: there is no such thing as a > person and a person from the personnel (staff). At any given moment any > staff member may become ill and become a person (patient). > another idea should be to rethink all that part..manage all the hr side in a separate module..should have more sense this way.. > 14. Aggregate the care_pharma_* tables in 2 tables: one to keep DBMS > architectural definitions and the other to keep the data. > RATIONALE: see point 1. above. > see point 11 > 15. Drop care_tech_* tables and supporting code > RATIONALE: see point 1. A simple interface to a proper ticketing > system would be far more effective. Give the user a screen to enter the > event/malfunction/accident data and let a simple routine to wrap that > into code that a proper external ticketing system can understand. The > same to show the status of the reported event. Or better yet let the > ticket subsystem talk with the email subsystem and address all these > matters by simple emails. > external module...maybe integrate with some sort of jabber module..could be much more useful > 14. Aggregate the care_test_* tables in 2 tables: one to keep DBMS > architectural definitions and the other to keep the data. > RATIONALE: see point 1. above. Be careful with this one: Lab, Pat and > Radio data are different things. Radiology data is usually dealt by a > separate subsystem (PACS), not because it is significantly different, > but because CAT, EMR, 3DSonography tend to saturate networking resources > and to black hole use huge resources of storage hardware. > again here the idea of having separate modules makes much more sense. as an example the chem lab has more types of data entry than a simple textbox..so it will need a more sophisticated analysis description ( i'm working on this, i'll soon publish on the svn what i've done so far ) on the radiology side, i think having a RIS integration here would make more sense > 15. Aggregate the care_type_* tables in 2 tables: one to keep DBMS > architectural definitions and the other to keep the data. > RATIONALE: see point 1. above. > as a programmer i disagree here.. it is one of the few pieces of code that is in 3NF :) > 16. Is it really needed separate tables for care_type_unit_measurement > and care_unit_measurement? > > it is complete nonsense in fact > 17. Is it really needed to have a care_version table to keep the current > program version? > > a simple file is much much better > Extracted from original work by J. Antas > > M. > > this kind of critics is very appreciated. it helps thinking of the project on a different perspective. as you have noticed, i've replied to your question on my point of view as a programmer which tries to solve concrete problems. and on the practical side, 3NF is very very helpful when you need reports, parameterizing..and helps a lot in improving db speed. on the clinical side, an option would be to start having some simple semantic web features in c2x...you can find some interesting experiments here : http://www.w3.org/2001/sw/hcls/ well, there is obviously more to discuss here..those were just some simple and short answers.. gj. ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Care2002-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/care2002-developers
