Gjergj Sheldija wrote: > list here some suggestion that I think would be useful, they may be > right, may not; it's up to the community to decide.
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. 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. 3. Drop care_cafe_* tables and supporting code RATIONALE: see point 1. and 2. above. 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. 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. 6. Drop care_currency table and supporting code, or integrate them in care_billing_* RATIONALE: see point 1. and 2. above. 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. 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. 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. 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. 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. 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. 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). 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. 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. 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. 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. 16. Is it really needed separate tables for care_type_unit_measurement and care_unit_measurement? 17. Is it really needed to have a care_version table to keep the current program version? Extracted from original work by J. Antas M. ------------------------------------------------------------------------------ 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 Care2002-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/care2002-developers
