Hi Simon,
I placed some comments below. Regards,
Mario
Simon James wrote:
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.
That's right, and the encryption is handled separately from the
transmission via Argus. Again, if the clinical app uses the location
certs for encrypting, then I'd be concerned.
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.
The use of text fields as a data type in the db column for storage of
external documents of all sorts of types, unnecessarily limits your
choices of storage later.
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?
Documents in a medical/billing application have to be seen in context.
That's the reason we store the documents in the db, they can be indexed,
viewed, searched, retrieved, written, updated, deleted, etc. There are
several contexts that are relevant, but suffice to say that a practice
needs to slice and dice information in context, and this cannot be done
effectively unless your data is available in the db.
Furthermore, when you backup, there are no nasty surprises that the user
forgot to backup a particular folder. There is only one backup that
matters.
A final reason is practice data security, and I won't go into this one,
gets boringly technical.
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.
If the user can access the information in the file system, so can
anybody else, that's a big exposure. Also, just searching for a given
document can be a nightmare if you have lots of them in a folder, or if
you want to search for a given criteria the only way to do it is by
using a rdbms.
In our case, we do not lock-in our users, in fact we help them if they
want to migrate. (:-(
How small is small, I'm not sure, I think it might be more about how
long you wait for your backup to complete. In our case, a largish
medical practice takes under 15 secs to do a full backup at only a few Mbs.
I understand the db size limitations of some of our competitors, they
just can't ignore the big fat dancing elephant in the living room and if
they chose to dance with him, they have to dance the way the elephant
likes.
In our case db size licensing is not an issue, a practice can grow to
terabytes if necessary. I can say that a main teaching hospital here in
Sydney uses Insight on a 24 hours production basis during the last 18
months with very large db and no increase in complexity or support cost.
Regards,
Simon
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
