Discussion on Technical Assessments of Data Persistence

Visit the page.

For a server that will act as a central storage of patient's data a mysql equivalent database server is highly recommended. The use of sqlite or a flat file system will complement the central server if access is not possible due to network problem.

As a patient record may be copied from one device to another, there needs to be a way to let the system know if data in a USB is still valid or not, especially, if there is already an updated version. Human procedural/policy need to be in place to avoid two or more diverse records of a single patient found in different storage devices. A patient record then must be found in only one mobile storage device at any given time. Transfer of records from one USB device to the other is better, as opposed, to doing a COPY.

Another potential challenge is in assigning an ID (Generating Unique Patient Id) to a newly created record. A non-conventional approach has to be done instead of relying with the sequence-type of assigning unique numbers, if these id have to be generated as new records are placed in. If a sequence-type is desirable then human intervention is needed, this shall be a keeper/or custodian of pre-printed numbers that shall be used as record id for every new patient that arrives.

Thu Nov 8 19:22:17 2007 - nbjayme

I agree with Nathaniel that there is potentially a problem with assigning a sequence type unique number.

IN THE SHORT TERM, we are not looking at a central server problem. At present, in most departments in PGH (except Surgery), there is a single electronic record of the patient that exists at any one time. It is with a student in charge. Thus, it is already happening in the present system that only one electronic record exists at any one time. At a time this student has to shift out of the department, which usually happens every 2 weeks, such electronic record of the patient is passed on to the next student. So we're looking here at a setting where you have many many many autonomous holders of electronic data that do not have to interact at any one time. The interaction only happens during shifting and that is where there might be conflicts with the sequence type unique number. The new student in charge would have to import the data of patient from an outgoing student. I SUGGEST, that with this importation, the data is treated as a new record and is assigned a sequence type unique number as in a new record.

THE BIGGER PICTURE: WHat if the system is to be used on a central server already? Let's say a hospital wants this system. I SUGGEST that all new records have to be generated from that central server so that the sequence type unique number will indeed be unique. End users then adapt this unique number.

Hmn... maybe what we could do is for the module for importation to have an option whether to adapt the unique number of the imported file or to create a new unique number. Thus, in the short term, everyone shall use the latter option in importing patient files. If there is a central server in place, then the former option will be applied. (Generating Unique Patient Id)

Fri Nov 9 11:33:00 2007 - nbjayme (quoted from Pam Patdu's email to the project's mailing list)

Yes, I am now leaning on sqlite over a flat-file system. Managing file I/O and extendability of queries is robust and convenient using sqlite.

There is a way to easily transfer records of a patient with sqlite. That is, by creating one database per patient.

i.e. patient-10010.db

patient-10010.db

users can simply copy/move a patient's db. Therefore, the CSV/XML export script may be needed only if we will interface to external systems.

It took me some time to jazz up the project's wiki site. Trac, by the way, is a system that integrates the wiki and issue tracking. This will make it easier to link documentation to issues and/or vice versa.

Currently we have Sir Holden Hao administering the trac system. Thanks holden for saving some of my eyebrows (and precious crown hairs) from burning going through the extensive documentation of trac.

Fri Nov 9 16:49:00 2007 - nbjayme

Hi Jayme,

after checking SQLite, i must say SQLite will be best option. Created flat file i/o is good and challenging work which can be avoided by using SQLite, i can bet it will be much easier to maintain SQLite base system "f ever/whenever" XulRunner? may change function names rather then creating flat file i/o...

Fri Nov 9 17:50:00 2007 - nbjayme (quoted from Imran Khan's email to the project's mailing list)