> Hi Simon, > Thanks for that. I was originally thinking that the document remained > encrypted for the life of the document and one would need to be > decrypted once or more times at a later date after encryption. Clearly > that is not the case and the document is persisted in plain text form > (unencrypted).
Hi Mario, Yep, although once imported into clinical database, messages would come under the protection of what ever security measures the software has in place, including encryption in some cases. > On your other comment about the choice of "file system" or "blob" > storage, that is a product choice, and although Insight stores documents > in the db, other products do it on the file system. Again, with the products I'm familiar with, files that are imported into the database (as HL7/PIT/RTF or Microsoft Word) are stored in text fields, not blob/container fields. This is an important - after all, the whole point of using HL7 for clinical messages is that the data contained in HL7 messages is atomic and should be able to be used intelligently by the clinical software. As you allude to, some packages store scanned documents and photos in the DB, others in the file system. I'd be interested to know what was your rationale for storing these documents in the database with your product? Personally, I prefer attachments to exist in the file system in a sensible directory hierarchy. This allows incremental backups to be performed on these attachments, negates the possibility of vendor lock-in, and makes it easier for users to access the files via the OS or 3rd party tools. It also keeps the database size small, which may have cost and complexity implications for users of clinical software that rely on DBMS that tie licensing to db size. Regards, Simon > > Regards, > > Mario > > > > Simon James wrote: >> The solutions that I'm familiar with pick up unencrypted HL7 files, encrypt >> them, transfer them, unencrypt them and drop them into a folder ready to be >> for imported into the clinical package. >> >> As such, messages two years and older should exist in the clinical database, >> not in the file system - expired certificates shouldn't be a problem in the >> normal course of events. >> >> Regards, >> Simon >> >> >>> how do you decrypt your older messages after the current certificates >>> are revoked? usually every 2 years. >>> >>> apologies if you feel the question sounds silly. >>> >>> Mario >>> > _______________________________________________ > Gpcg_talk mailing list > [email protected] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
