Hello Kaloyan, Yes, I understand and got your point and fully agree with you.
Care_person will hold PID and maybe creation_date. All other fields are holding foreign keys pointing to their own table. Do we need a table with foreign keys or the suggestion of Amel might be better of having just one unique reference with PID? That would mean: The care_person holding just basic patient data: PID, creation date and an own field for a local used file number what makes integration to most of the hospitals much easier - they might have an own manually numbering format and don't want to rewrite all manual files... There are some other tables like Amel suggesting. There is one what is for default and you can add individual ones. All in all there is a good way what there could be now. That would make the migration parts to care2x much more easier. Robert > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] [mailto:care2002- > [EMAIL PROTECTED] Im Auftrag von Kaloyan Raev > Gesendet: Montag, 10. Juli 2006 18:47 > An: care2002-developers@lists.sourceforge.net > Betreff: Re: [Care2002-developers] Registration Page / Admission data > > Hello, > > Robert, your suggestion adds great flexibility to the data structure, > but unfortunately this way the db schema loses all logic of the data and > this has to be transferred to the php code. I don't like such approach, > because in my opinion the db schema should represent the model of the > data. > > I was thinking about some object-oriented style of representing the db > structure - using inheritance and polymorphism. This is closer to the > Amel's vision. > > Let's take the Patient record. Each patient is a record in the > care_patient db table and has the following attributes: > - ID (autoincrement) > - name (foreign key) > - citizenship registration (foreign key) > - date of birth (foreign key) > - sex > - social status (foreign key) > - contact info (foreign key) > - insurance (foreign key) > - etc. > > Everything that is denoted as 'foreign key' is an attribute that is > valid for every person in the world, but represented in different way in > each country. This means these are abstract attributes - abstract by the > means of OOP. > > The foreign key 'name' points to a record in the care_patient_name > table, where the structure is specialised to the concrete country - > example: first name, last name, or: first name, father's name, third > name, tribe. The same with all other foreign keys. > > So, each record of the care_patient table is represented in the php code > as an instance of Patient class. This class has methods as getName(), > getCitizenshipRegistration(), getDateOfBirth(), getSocialStatus(), etc. > which returns instances of PatientName, PatientSocialStatus, etc. > classes. > > Then the PatientName is an abstract class that is inherited by specific > subclass for each country like: > - USPatientName with methods getFirstName(), getLastName() > - TanzanianPatientName with methods getFirstName(), getFatherName(), > getThirdName(), getTribe(). > > Amel suggests that there is also presentation information in the > database like 'text', 'checkbox'... And this information has to be used > for automatic generation of the pages. In my opinion the database should > hold only the model and no presentation info. The presentation info > kills flexibility and is for the templates. Also not everything could be > automatically generated from the info in the database. For example, data > validation is hard to be done in the database, especially when you want > to be database independent. I would rather stick to the idea that every > db table has its own wrapping php classes like Patient class for > care_patient db table. > > This is just a rough picture. It can be extended to greater complexity > by using the OOP paradigms as inheritance and polymorphism. > > What we urgently need is the model. Good flexible model that is open for > the special characteristics of the healthcare in each country. > > Greetings > Kaloyan > > P.S. about performance: I think this should be the last thing to think > about. At least the hardware evolves faster than Care2x software at the > moment ;) > > On Mon, 2006-07-10 at 13:40 +0200, Robert Meggle wrote: > > Hello Reinier and Amel, > > > > Yes, maybe we'll getting some performance penalties. Maybe. My > experiences > > about these table structure is: > > When you keep care about the primary key it will not affect too much the > > query speed, that will not be the issue. I've tested such kind of table > > couple of times but there was not a measurable time penalty about the > query > > speed. Instead all 3rd normal form of databases would rise up speed > > penalties and this is not the case. > > > > More difficulty is the kind of queries you will need to answer a simple > > question. For the moment you just need one key and you'll get the > correct > > row in one line for that result. That's quits simple and very easy to > > understand. But if you have a kind of hierarchical tree, then you maybe > need > > one complex query or maybe two of them (depending what you want to > know). > > Other much more relevant point is that we will loose all kind of column > data > > types, the content is represented by a global column. Maybe we should > think > > about a combination of my idea and the idea of Amel. Then we could keep > most > > of the existing table structure. > > Other issue is that for the moment the PID is a primary master key and > the > > database keeps care that this key is unique. For my idea there must be a > > programmed php class taking care about and this could be risky. > > > > Maybe we should follow the idea of Amel. Any other ideas? > > > > Reinier, I want to avoid giving attachments to the mailing list when > there > > is an alternative way in a simple text mode. It would fill up the > inboxes of > > that developers using quite poor bandwidth for internet... > > Sorry that you had some troubles by reading it. (I gave it as plain text > and > > used spaces instead of TAB commands - tested it by outlook and firefox > and > > looks well in booth email clients). So sorry about it but in spite of > that I > > think you got my point. > > > > Robert > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: [EMAIL PROTECTED] > [mailto:care2002- > > > [EMAIL PROTECTED] Im Auftrag von Reinier > > > Gesendet: Montag, 10. Juli 2006 12:46 > > > An: care2002-developers@lists.sourceforge.net > > > Betreff: Re: [Care2002-developers] Registration Page / Admission data > > > > > > Hi Robert, > > > > > > In general, i think this would add a lot of flexibility to the > > > Registration of patient, which is good. There might be some performace > > > penalties, we'd have to see if they are manageble. > > > > > > The diagram does not come out very well in my mailclient. Maybe you > could > > > make a small ER or UML diagram with the tables that you propose and > the > > > links between them in a graphic program? > > > > > > > > > rgds, > > > > > > reinier > > > > > > > > > On Monday 10 July 2006 12:19, Robert Meggle wrote: > > > > Hello all, > > > > > > > > About the discussion in this list (-> patient registration and the > big > > > > vision to get a very flexible structure in it). I want to talk about > the > > > > data structure here, not about the GUI realisation part. > > > > > > > > Nearly all hospitals, counties, countries will have own ideas of > storing > > > > demographic data. > > > > > > > > What is the situation right now? The situation is that every > programmer > > > what > > > > have the aim of integration taking the table care_person and add > their > > > own > > > > columns. Or even misusing given ones for their own use. > > > > For a wider perspective I will suggest an idea. An idea of having a > > > better > > > > data structure... Please let's talk about it and give your comments > to > > > it: > > > > > > > > What is the requirement for a patient Table: > > > > -> The PID must be unique (is now realized of having an auto- > increment > > > > primary key column) > > > > -> The date-field of the creation date (date_reg) > > > > -> Optional fields... First name, last name, phone number, street, > PO- > > > Box, > > > > ZIP.... > > > > > > > > What do you think about having now following structure? > > > > > > > > care_person: > > > > ID | date_reg | parent | value | data > > > > 1 | 1998-01-01 00:00:00 | -1 | PID | 1 > > > > 2 | NULL | 1 | firstname | test > > > > 3 | NULL | 1 | lastname | nobody > > > > .. | ... | ... | ... | ... > > > > 10 | 1998-01-01 00:00:00 | -1 | PID | 1 > > > > 11 | NULL | 10 | firstname | test person 2 > > > > 12 | NULL | 10 | lastname | nobody 2 > > > > ... > > > > > > > > > > > > -> The content (firstname, lastname ...) will be described in an > > > > additionally table. > > > > > > > > Basic idea of this hierarchical structure: A non auto increment- > > > identifier > > > > (column: PID) will point to the primary key (column: ID) of the > table. > > > If > > > > the parent has the value -1 it will describe the root. If you want > all > > > > datas of this value pid 1 then you have to select this table > to > > > > ID=parent. > > > > The last table it is not clear for me (for the moment). Idea is that > > > every > > > > adaptation can insert there the possible values of the content > table. > > > > Additionally to that even the attribute value like checkbox, > input > > > > field, select box->and their possible values of it (maybe). > > > > > > > > This is quite an idea. Let me know what you think about. This change > > > will > > > > affect nearly all kind of modules of care2x (my hope: basically the > > > > class_core -> but it is quite a lot of work to be done when it > should > > > work!) > > > > > > > > What I do not like in my idea are following issues: > > > > -> The primary key-value points to an key (It´s might be okay, but:) > > > > -> the data column should have a global data type and I do not like > that > > > > idea. > > > > > > > > Any suggestions or ideas? > > > > Robert > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > ---- > > > - > > > > Using Tomcat but need to do more? Need to support web services, > > > security? > > > > Get stuff done quickly with pre-integrated technology to make your > job > > > easier > > > > Download IBM WebSphere Application Server v.1.0.1 based on Apache > > > Geronimo > > > > http://sel.as- > us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > > _______________________________________________ > > > > Care2002-developers mailing list > > > > Care2002-developers@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/care2002-developers > > > > > > > > > > > > > ---------------------------------------------------------------------- > --- > > > Using Tomcat but need to do more? Need to support web services, > security? > > > Get stuff done quickly with pre-integrated technology to make your job > > > easier > > > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > > > http://sel.as- > us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > _______________________________________________ > > > Care2002-developers mailing list > > > Care2002-developers@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/care2002-developers > > > > > > > > ------------------------------------------------------------------------ > - > > Using Tomcat but need to do more? Need to support web services, > security? > > Get stuff done quickly with pre-integrated technology to make your job > easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > Care2002-developers mailing list > > Care2002-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/care2002-developers > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Care2002-developers mailing list > Care2002-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/care2002-developers ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Care2002-developers mailing list Care2002-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/care2002-developers
