Medical Manager File Structure

From MirrorMed

There are about 250 files in current MedMgr releases, plus an index for almost every one of these files. The filename extensions may be .dat (for files in the early versions of the system), or .dme for files ADDED to versions released after Data Merge was released. The respective indices for these files had filename extensions of .ndx and .dmx respectively, as they still do up through what will probably be the final release of the classic product, Ver 10.xxx.

Prior to version 5.9 (an experimental version which I had the pleasure [or displeasure] of doing one of the first installs, the product was written in CBasic a partially compiled language). Ver 5.9 was an intermediate release, emulating Ver 5.2, and was written in C as an in-house training tool. C remained the base language up through Version 7 or 8, not sure any more, when Data Merge was released. Since then, all enhancements and additions were written in compiled Data Merge, in a configuration that allowed the .dmc files to run without a DML license, however all prior existing modules are still in the C language.

Since C didn't provide for proper sub-program overlays, the system suddenly became very large, no longer fitting on a single floppy diskette. It's currently distributed on a CD, which is almost fully self-installing.

Early versions had a separate physical files for each of the indices, sometimes as many as 5-7 for a single file. Current versions have only one .ndx or .dmx physical index file for each file that uses an index, but they are still called index 1, index 2, index 3, etc.

The URL:

http://docs.mirrormed.org/index.php/Medical_Manager_File_Structure

Says:

At the top of the file there are four numbers 

   * length of file
   * length of next record (each empty record points to the next empty)
   * last user to access file

That is not an accurate statement in any way. The header record contains 4 fields, all numbers, but the record length is the same as the rest of the file, all of which have varying lengths. Regardless of the operating system, all MedMgr files have an EOR of 13/10 (CR/LF).

The header record contains the following:

Pointer to first re-usable record (More on that later)* The highest number of records ever held by the file The number of active records in the file The MedMgr version number with the decimal point omitted (920 indicates Version 9.20 for example)

  • A "full file" (my words) might have a header something like:

0,678,677,920

The 0 indicates that there are no reusable records, there are 678 records in the file (including the header record), and 677 active records (the header is not considered an active record). In general files such as diagcode.dat, patfile.dat, servcode.dat will tend to be "full files".

On the other hand, you will see headers such as:

369,855,543,920

That indicates that the file still contains 855 records (at it's largest size), but there is an un-used (re-usable) record at record 369. The un-used records are linked one to the other by subsequent pointers in the first field. Any time a record is deleted from a file, the record is removed from all the indices and inserted into the vacancy list pointer chain after record 369.

All active records will have the negative of the user number who last modified the file.

This and much related data, including the file layouts, the index structures, etc., are readily available since they are included in the Installation and Appendices Manual, which goes out with each system, however the data is clearly marked as being copyrighted.


  • actfile.dat activity charges proc code pat and dep
  • amafile.dat ailment traffic accident date of onset etc etc
  • aptfile.dat appointment file
  • clihist.dat clinical history file user defined start of an EHR
  • clmfile.dat insurance plan file deals with plans
  • clncode.dat clinical code file clinical history
  • cmenu.dat where you are in the menu program ??
  • comfile.dat comment file two comments allowed on patient includes payments
  • control.dat major headache totals are kept here period to date obfustaced passwords many things printer deinfition
  • depfile.dat dependants
  • patfile.dat responsible party file OR patient file
  • diagcode.dat obvious
  • dlyfile.dat daily transations index
  • dr2file.dat more doctor information
  • drfile.dat doctor information
  • emcmgr.dat electronic media claim manager billing system target contains biling batches
  • encfile.dat encounter forms have been printed used and not used.
  • errfile.dat errors logs recorded here. Look like you know what you are doing....
  • extfile.dat extended patient information user defined
  • glxfer.dat general ledger transfer file
  • hospfile.dat hospital rounds sheet generator
  • insfile.dat insurance policy
  • iprfile.dat insured party information (when the insured party is not in the dep or pat file)
  • labfile.dat labels file
  • logfile.dat keeping track of whos logged on can get ghosts
  • mapfile.dat appointment maps file appointment constraints
  • mdlog.dat
  • mpihelp.dat
  • poscode.dat place of service
  • prohist.dat procedure history shorted records of all transactions
  • psrfile.dat service facility file
  • rclfile.dat
  • reffile.dat referring doc file?
  • remapmnu.dat
  • rhfile.dat
  • rpgdoda.dat report generator?
  • rsnfile.dat appointment reason file
  • servcode.dat service(procedures file)
  • terms.dat terminal definitions allows proper terminal emulations
  • translat.dat translate from another system
  • ubfile.dat ub92 billing stuff
  • patfile.dat patient information
  • medinit intialize medical manager - starts background server
  • med command is how everyone accesses the system

This is from a post to fedup medical managers list...

Dave,

Sorry about this post being more than a month after the fact, but I don't log into this site as often as I do the Medical Manager Users site. (and I don't log in over there very often)

What Joel said earlier is pretty much the case. The actfile.dat and pmtfile.dat get updated on a daily basis. The Daily Close then updates the prohist.dat file with the same entries. At the end of each month the actfile.dat and pmtfile.dat get purged out depending on whether or not the account has a zero balance and whqt the purge duration is set to in the install module. the prohist.dat file never gets purged unless you do it yourself through the purge utilities menu.

Unfortunatley, the prohist.dat file contains only a small portion of the data that was originally kept in the other two files. For example, prohist.dat only maintains the PRIMARY diag and drops the diags 2, 3 & 4 (if any). Information as to whether or not the claim has been billed, date it was billed, is emc eligible, etc. is also dropped.

I am not sure what type of report you are trying to produce, but the prohist.dat is basically a limited copy of what IS in or WAS in the actfile.dat or pmtfile.dat.

good luck, djc1309

Retrieved from "http://docs.mirrormed.org/index.php/Medical_Manager_File_Structure"