SafeMed Systems and Data

• MWImporter Automatic Ongoing Data Transfer to Medisoft System
• Discussions on conversion
• Flat ASCII report files
• OCR of hardcopy
• Engineering
• Cost of Manual Rekeying of data vs Direct Transfer


Only the most popular vertical software applications have automatic conversion capabilities built into themselves.  There is no standard, automatic "input" data format given the many differing sources for originating system information.

Source/Target Types

To get a better understanding of how SafeMed can assist in playing a conversion role, it would be useful to explore in some detail the options SafeMed has for connecting to the world of structured data.

Connecting Via Physical Data

The most basic method for SafeMed to connect to various data Sources and Targets for the purpose of performing a data conversion is by a link directly from SafeMed to the physical data file as it resides on the disk.

Connecting to data through such a direct interface generally requires a physical connection to the data.  This normally means the data resides on a local disk, but with LANs, WANs and remote disk serving protocols like NFS, the data can really be anywhere as long as SafeMed can reach it.  Of course if data is remote, users always have the option of a two-step process:  1) Physically transfer a copy of the data by some communications method down to a local disk; and  2) After the data has arrived at SafeMed's office begin the conversion.

There are two different modes which SafeMed uses to connect with data:

Raw Sequential

One connection mode that SafeMed is famous for is its ability to open any fixed record length sequential file , and peer inside (for example, the Medisoft, or Medical Manager, or DOMS data!).  SafeMed has the ability to read and parse flat files of any size or description.  This includes the ability to read ASCII or EBCDIC, and text or binary data of virtually any type or style (eg. COBOL packed, reverse byte-order, old floating point formats, blobs, etc.).  SafeMed uses proprietary mapping software which develops mapping rules governing a particular flat file and its record layout, and then is capable of extracting clean data records for conversion.

SafeMed uses other tools which allow for the binary reading of data files as a last resort when trying to get data out of an unknown raw file format sitting on your disk.  However, the majority of commercial applications store data records using fixed-length techniques.

For details, refer to "Binary" from the list of formats below.

Physical File Format

Another data file connection used successfully by SafeMed is to physically read and write the native internal storage format--xBASE files for example.  This approach is used when there is published information describing the internal storage format in detail.  In these cases, SafeMed can easily extract data given the specific hard-coded knowledge about the physical organization of the data in the disk file. An advantage in this kind of approach is fast access, high performance and cross-platform transferability.  A disadvantage of this approach is that SafeMed has to manually keep up with a growing library of physical file formats and changes.  This option is used less and less frequently for file formats belonging to popular packages, but will always remain an option for some file formats, particularly text formats, as well as older and/or obsolete formats.

Connecting Via a Native API

An increasingly popular connection mode available to SafeMed is for the developer of a particular data format to publish a formal interface definition for controlled, programmatic access to internal data from external third party programs (this is often referred to as an API - Application Programming Interface).  The Paradox Engine (used in Medisoft Advanced for Windows) is a good example of this kind of tool.  In these cases, SafeMed uses tools such as Access or Paradox to use data access linking methods, supplied by the vendor, for all read/write access to the file format.  The data is then extracted to fixed lengths for further processing prior to importation into Medisoft.

The general advantage in this method is that it isolates SafeMed from changes to the physical file format level.  The general disadvantage in this method is the dependence on vendors to produce robust and high-performing APIs and bring them to market in a timely and economical manner.  For most cases of Medisoft data conversion, this method is the preferred means of connecting to a data Source. There are some variations when SafeMed uses a Native API as the means to connect to a Source or Target.  With some APIs, the full complement of software necessary to establish a connection is supplied to SAFEMED will full redistribution rights, in which case SafeMed is all you need to establish a connection.  The database engine then becomes sophisticated enough to act as a gateway to permit SafeMed to connect to remote data anywhere.

Connecting Via ODBC and Other Middleware

An increasingly popular option to provide more connectivity to external data sources is through ODBC (Open Database Connectivity).  ODBC is a standard promulgated by Microsoft describing a generic interface layer to SQL type data sources.  In cases where SafeMed does not have physical or native API connectivity to a data Source or Target, ODBC can often provide that link. ODBC drivers are normally supplied by the Vendor whose data is involved as a Source, or in the aftermarket of add-on tools.  There are ODBC drivers for a wide set of data sources (just as an example, there are drivers for direct connectivity to the mainframe, giving SafeMed access to AS/400 and DB/2 data).  If SafeMed does not have native connectivity to a data Source through either physical drivers or an API, then SafeMed usually investigates further to research the availability of ODBC drivers--which usually exist.

When using ODBC as the connector between a data Source, SafeMed becomes a client using the ODBC driver to actually link to the remote data (similar to the native API implementation described above, but in this case the ODBC driver can act as an internetworking gateway to a whole world of remote data).  SafeMed has already obtained a very rich inventory of ODBC tools, already tuned and tested with a very large array of drivers.  Using ODBC to provide the basic connecivity between data Sources is a very effective option, and lets SafeMed expand its outreach to data beyond the physical and native API connectivity described above.

There are other non-ODBC middleware options (eg. IDAPI) being promoted by various vendors in the marketplace.  SafeMed can also reach out to external data Sources via some of these other middleware options.  Please contact SAFEMED with any specific questions in this regard.

General Data Conversions and Connecting Via Intermediate Import/Export Formats

It is often assumed (incorrectly) that SafeMed can only assist in the conversion of Source information directly to a Medisoft system.  This is not the case.  Even in situations where SafeMed may not be converting for a Medisoft system, there is still a very powerful service which SafeMed plays in helping you convert this data by working through intermediate import/export formats.

All programs, applications or software packages store data in their native internal format, but most also offer some primitive level of import and/or export support (eg. .sdf, .dbf, .wk1...) for reading and writing external data. Since SafeMed can read and write every dialect of known intermediate file (fixed ascii, delimited ascii, sequential, Lotus 123, Excel, xBASE...), it should be obvious how frequently SafeMed is called upon to tackle a data conversion problem on non Medisoft projects.

A very large part of the value of SafeMed is its ability to do the dirty work of mapping and massaging data between mostly unequal data Sources. This value is still present even when SafeMed does not connect directly to a Source or Target. Many users profit from SafeMed when they are facing a conversion via an intermediate import/export file (eg. delimited ascii), because much of the work in a such a conversion still involves spending expensive human time modifying the data structures (they are never quite right, with fields always needing rearranging, shrinking, expanding, adding and deleting), and also modifying the actual data contents (Names to be parsed, Dates to be rearranged, codes to be expanded, ...an infinite wish list of data scrubbing needs).

Because we built into SafeMed a highly visual interface with enormous power to solve exactly these kinds of data mapping and manipulation problems, users can dramatically reduce the time and money wasted wrestling with conversions, especially when working with inadequate and primitive import/export files! When you consider that there are hundreds of thousands of programs out there, most with very weak import/export services, you can see the importance of exploring every way to use the world's most powerful data conversion tool - SafeMed for Windows, to help bridge the data gaps between programs. There follows a brief explanation of using SafeMed to work with intermediate import and export file formats:

Importing Via Intermediate Data

Even when SafeMed cannot write data directly into the native format of your Target application, you will still find SafeMed very useful in helping to solve the Import problem. You will often find that your target application has a minimum, sometimes bare-bones facility for users to import external data files. The good thing about these built-in import facilities is that they can shield the user from the complexity of inserting data into what can often be a very complex internal native file system, while still catering for indexing, transaction control, audit trail updates, and other advanced issues. The bad thing about the built-in import facilities is that they frequently demand data to be pre-organized in certain formats and layouts, and of course the world's data is not magically already in this format.

That's where SafeMed comes in. As explained above, much of the value of SafeMed is its ability to work with your dirty source data and transform it quickly and easily into the exact format required for Import into your application.
SafeMed has special utility in the area of cleaning and formatting data for batch loading into SQL Databases (eg. Oracle, SQL Server, Sybase...). While SafeMed can directly convert data into SQL Targets (via the Native API or ODBC), SQL is notoriously slow when doing direct SQL Inserts of individual records into a database table. For large amounts of data therefore, the direct insertion of records is not very practical.

Most SQL Databases have an off-line batch loading facility (eg. bcp for Sybase and SQL Server, SQL Loader for Oracle, DBLoad for Informix). The good news is that these loader utilities have been optimized for the mass insertion of large amounts of data directly into database tables. The bad news is that these same loader utilities demand incoming data to be already arranged in a specific (and often arcane) format, and the world's data is not magically in this format. Consequently, there is a real role for SafeMed's universal mapping and manipulation capabilities to intervene and convert the foreign Source data into a format suitable for feeding the batch loader tools!

Exporting Via Intermediate Data

Even when SafeMed cannot read data directly out of the native format of your Source application, you will still find SafeMed very useful in helping to solve the Export problem. You will often find that your target application has a minimum, sometimes bare-bones facility for users to export an external data file. The good thing about these built-in export facilities is that they can shield the user from the complexity of grabbing data from what can often be a very complex internal native file system. The bad thing about the built-in export facilities is that they frequently dump data in a fixed, pre-organized format and layout, and of course the downstream need for the data is never in exactly this format.

That's where SafeMed comes in. As explained above, much of the value of SafeMed is its ability to work with your dirty exported data file and transform it quickly and easily into the exact format required for downstream use.

Connecting Via Interim Text Files

SAFEMED had added a brand new toolset to the arsenal of weapons to solve the problem of getting data out of one program and formatted for another. We all know users wrestling with the challenge of extracting structured data from text files and reports. Users needing to transfer data from one application to another are often challenged with how to get useful data out of the Source Application. Methods to extract data via native connections and intermediate import/export formats have been illustrated above, but are sometimes not available or not appropriate. In such cases, there is a fallback technique where SafeMed services and technology can come to the rescue and perform the conversion. Almost all applications have the ability to print information to paper. As an option to get data out of an application, users can re-direct the printout to a disk file, a technique whereby structured data can be 'exported' to an ASCII text file (in fact our technology also works with EBCDIC files).

Now the problem becomes a more classic data conversion problem, where the Source file is the printout or report captured as a raw text file (but containing an inherent structure). Employing advanced pattern-recognition technology SafeMed creates unique programs to extract data fields from the raw text lines, and assemble those fields into clean records of data.

The beauty of SafeMed's approach is that once a conversion is made and saved, it can be easily integrated into future SafeMed conversion programs which saves everyone time and money. In this case these conversion routines are used as a pre-process in SafeMed to work on the incoming Source text file (the report "printed" from your application), and flatten it into a more normal row and column structure so that SafeMed can apply full data mapping used in the conversion. This combination is truly a breakthrough in the search for more powerful and convenient ways to automate the migration of structured data to Medisoft or any system for that matter. We are very excited by this new technology, and predict that it represents a huge leap forward in the effort to make SafeMed the Ultimate Data Conversion Service Provider for Medisoft.

SafeMed's entry into OCR document scanning:

The issue is short when it comes to accuracy of OCR processing.

Our primary goal is to quickly and accurately scan in information from hardcopy data source(s).  To do this SafeMed has utilized technology which relies on a solid hardware platform of document fed scanners and rapid process networked software.

For a long time people dreamed of how to teach machine human knowledge, e.g., create a machine able to read. During the last 50 years this dream started coming true. Optical Character Recognition is one of the most favorable applications of artificial intelligence. There exists a solution that is close to human ability to read: it uses recognition principles of living systems. This is the technology of adaptive integral purposeful perception.  SafeMed Systems uses this technology to grab client data which exists only on paper!
Engineers

All programmers and technicians who want to work at the company have to take three tests: the first is the entrance examination, then a monthly trial period and finally — the qualification exam. For 6 months, each trainee studies instructions, listens to the course on programming methods used in the company to control data and — this is most important — works on real projects. Each trainee works under supervision of an experienced engineer whose task is to teach the trainee things that can‘t be formalized in instructions. But a quick mind and professional skills are not enough. The projects are developed and finished during 2-10days and require about 25-40 man-days of programming labor. That means the corporate work of dozens of programmers has already been done before the scanning begins. Employees of SafeMed Systems must be able to work in a team.

Data Transfer Tools for Live Systems

The discussion of data transfer into Medisoft DOS or Windows (up to this point) refers to "one time" batch transfer of Source data files into a new, empty Medisoft system.   Source data files from a normally functioning, non Medisoft medical practice management system are processed and transferred into a Medisoft Advanced data set. Data entry is then continued using Medisoft.

MWImporter, is a new generation SafeMed software import utility. MWImporter is tailor made to allow for unlimited frequent merging of Source data file entries, from another medical billing application, to an active Medisoft Windows system for EMC or paper billing. It applies to repeated "one of a kind" source data feeds (currently for Medisoft Windows only).

Heretofore incompatible medical sysem data is transmitted on a regular basis to a central Medisoft Server, where it is reviewed and edited for completeness. The user has the option to put any record "on hold" for further data gathering. Otherwise, the source data can be automatically accepted for importing to the central server's Medisoft data set for medical billing.  Records which are put on hold are aged so that the user can determine which records need further data gathering. Held records can be "released" from hold for importing into Mediosft.

Medical EOB's and reimbursement payment deposits are subsequently applied using the regular payment application procedure within the central server Medisoft system. MWImporter reduces the need for highly trained personnel at the remote site and eliminates the need for dedicated highspeed telecomm connections and hardware.

MWImporter, a wide area network replacement tool with the benefits of online dedicated processing and none of the management overhead, personnel training or WAN hardware and software costs.

MWImporter is a custom made solution (for non-Medisoft data sources) which solves the issue of bringing incompatible data into Medisoft on a regular basis. Users of this tool are capable of central EMC or paper medical billing for multiple locations, and providing consolidation of the several remote sites into one centralized Medisoft data set.   Consolidation of medical practice management records just got easier.  The MWImporter system controls duplicate entries and generates user reports on demand.