Importers for Au

EMR is widely used in AU. Like many cottage industries, we have a pack of EMR players with one lead wolf. The other wolves have to play importer for the lead wolf's schema. Fortunately, the lead wolf was originally designed by a GP , and the data schema is succint and not too complicated.

The client/importers directory has an early au importer . ( client/importers/au/md2/a)

The importer is in 2 parts :

dbf_2_pg is a command line tool for pointing to a directory containing the source data, and loading a specified blank postgres database. It basically translates a directory full of dbf and fpt files into postgres tables on a postgres database. There are a few options: a config file specifies some default options, like which memo data of which tables should be treated as binary , which at the moment is a little inefficiently imported as compressed base64 encoded character data. (-memobase64 and -base64tablename) . Running "python create_pgdb.py" will give the command line options.

import_gnumed is a translator tool for translating a particular dbf schema stored by dbf_2_pg/create_pgdb.py into gnumed's v2 schema. It has the basic options -to and -from which specify the pgsql DSN for the source postgres database to the gnumed_v2 database .

e.g. python import_gnumed.py -from 192.168.1.4::test1:gm-dbo:gm-dbo -to localhost::gnumed_v2:gm-dbo:gm-dbo

this reads from dbf_2_pg created database on 192.168.1.4 test1 database, to the localhost gnumed_v2 database.

another option is -start , where the ur_no offset can be specified.

Currently , the importer imports the progress notes, the history, the patients, the doctors, and the patient documents , so it makes gnumed as a fairly usable tool , but needs pathology and radiology result import to be minimally useful as a document storage system.

Design Notes

It is attempting to be both a merge tool and an initial importer, so it tries to follow the idempotent principle, which means a unique piece of data should only be imported once, no matter how many times the importer is run.

It does this by checking the metadata for blob objects, and the attributes of encounters, and the md5 signatures of narratives. It then shifts any encounters whose sum of md5 of narratives are the same to just one encounter, as well as any other attached data on the other encounters. Currently , idempotency hasn't been implemented for the other data types, as this part of the importer hasn't been done yet.
Topic revision: 16 Sep 2006, JamesBusser
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark