Q: What is PLATOCODE CAC?

A: It is a tool for clinical coders to help them work better and quicker, allowing the facility to generate bills more quickly and save money.

Q: How does it work?

A: Charts are sent from your document management system(s) to a PLATOCODE server which codes the chart and returns the results. The results are stored at your facility until the coder is ready to review them. The coder then validates the results on her PC and the final set of codes returned for billing.

Q: Is there a diagram of the PLATOCODE CAC process available?

A: Yes.

The PLATOCODE CAC Process

Q: So the system needs a mechanism to get the charts, somewhere to store the results, and some software on the coder's PC?

A: Yes.

Q: Does Platocode CAC work on Windows 10?

A: Yes. Platocode Testing on the Windows 10 Preview was undertaken in May 2015, confirming that all releases of User and Server Win32 Platocode applications since January 2015 are working seamlessly under the Windows 10 Preview. You can confidently move to Windows 10 without reinstalling or reconfiguring your Platocode applications.

Q: What documents do you need?

A: CAC delivers most benefit if most or all documentation for a case is electronic. This is easiest to achieve for Outpatient Radiology Reports and Ambulatory Surgery op notes. If H&P records or other documents (histology, labs, discharge summaries) are available, we need those too.

Q: What format do the documents need to be in?

A: HL7, text, RTF or any human-readable text format is fine. Many facilities already have data engines to share information; the PLATOCODE system can make use of that output.

Q: Does the HL7 or document transfer need any special fields?

A: Age and gender make a difference to coding. Occasionally length of stay makes a difference too. A unique document id is needed. An episode number is needed so that the engine can code charts with more than one record. Most HL7 already contains these fields.

Q: Can I send PDFs or scanned documents?

A: Text can be extracted from PDFs if documents are sent in that format. OCR can be applied against scanned printed documents, but that needs to be done before the case is submitted to the PLATOCODE system. We would need to discuss this with you. Scanned handwritten documents can not be reliably read by any current OCR solutions these documents are not usually submitted to the PLATOCODE System for coding - although they can still be displayed in the PLATOCODE tools when being reviewed by a coder.

Q: How do I get the documents to the PLATOCODE server?

A: The PLATOCODE server is offsite, maintained by the PLATOCODE company. It receives encrypted charts and returns encrypted results. The usual transfer mechanism is SSL via HTTPS port 443. We supply you with a PLATOCODE "CaseSubmitter" application that automatically encrypts and sends your charts to the PLATOCODE server and stores the results.

Q: What exactly is the FileProcessor?

A: It is a small 32-bit Windows application that receives electronic charts from your facility's EHR systems and stores them in a PLATOCODE CAC Results Database located at your facility in preparation for sending to the PLATOCODE CAC engine for coding. It also compiles useful statistics for HIM Directors and others.

Q: Where does the FileProcessor run?

A: It runs at your facility, configured as a service or scheduled application on a Windows PC or Application server. It is a small 32-bit application that does not need its own server, though generally its machine is called the "PLATOCODE Application Server" to distinguish it from the coder PC. It is usually run on the same machine as the CaseSubmitter.

Q: What exactly is the CaseSubmitter

A: It is a small 32-bit Windows application that takes uncoded charts from the PLATOCODE CAC Results Database located at your facility, submits them to the PLATOCODE CAC engine for coding and stores the resulting codes back into the database.

Q: Where does the CaseSubmitter run?

A: It runs at your facility, configured as a service or scheduled application on a Windows PC or Application server. It is a small 32-bit application that does not need its own server, though generally its machine is called the "PLATOCODE Application Server" to distinguish it from the coder PC. It is usually run on the same machine as the FileProcessor.

Q: What machine specification is needed for the PLATOCODE Application Server?

The FileProcessor and CaseSubmitter can run on any appropriately resourced Windows machine. Minimum specifcation is:

Processor: Intel PIII 866MHz (minimum)/Intel P4 2.0GHz (recommended).
RAM: 1GB (minimum)/2GB (recommended).
Hard Disk: 200MB (minimum)/1GB (recommended). SCSI/RAID is not required.
OS: Windows 2000 Server (minimum) or Windows 2003 Server (recommended) and above.
Network: 100MB/s.
Server Virtualisation: Supported.

Q: What versions of Windows will the FileProcessor/CaseSubmitter run on?

A: The system can run on any 32-bit or 64-bit Windows Version since Windows 95. We would recommend Windows XP or later for client OS and Windows Server 2003 or later for Server OS.

Q: Does FileProcessor/CaseSubmitter run all the time?

A: The FileProcessor and/or CaseSubmitter can be scheduled to run as often as appropriate. Or it can run as a service in which case it runs all the time. The main benefit of running as a service is that results can be available within moments, 24/7. This may not be necessary at your facility. We would discuss and agree a mechanism with you during implementation.

Q: Will FileProcessor or CaseSubmitter affect other applications on the same machine?

A: The FileProcessor and CaseSubmitter use minimal resource. The memory use of each instance is unlikely to exceed 32MB. The CPU workload is minimal, essentially encrypting and sending cases to the PLATOCODE server and waiting for the result. They are unlikely to affect other applications on an appropriately sized Application server.

Q: How does the CaseSubmitter send documents to the PLATOCODE server?

A: It submits them as HTTPS messages. The message is additionally encrypted using Blowfish 448 or AES. Results are encrypted and returned as a standard HTTPS response. The CaseSubmitter stores the encrypted results in the PLATOCODE CAC Results database at your facility until a coder is ready to review them.

Q: What happens if the CaseSubmitter can't connect to the PLATOCODE server for whatever reason? Will it lock up?

A: No. Please contact us for a technical document about CaseSubmitter's failsafe features.

Q: Some applications can freeze a machine while they wait for an internet response. Does CaseSubmitter?

A: No. The CaseSubmitter uses minimal resource while waiting for an internet response. The keyboard and all other applications remain responsive. The CaseSubmitter is a non-blocking process.

Q: Where does the CaseSubmitter store the results?

A: In a PLATOCODE CAC Results Database at your facility.

Q: What gets stored in the Results Database?

A: Document identifiers and the encrypted results from the PLATOCODE server are stored in the Results database. The database also optionally stores information for management reporting, system security and administration.

Q: Does it need its own database server?

A: No. We recommend using an existing Database Server at your facility.

Q: What data volumes are generated?

A: The amount of space that is required on your Results Database is dependent on several factors:

The volume of cases that will be coded by the PLATOCODE CAC system.

The types of cases (radiology, outpatient surgery etc) that will be coded by the PLATOCODE CAC system.

If you want to store detailed information on coder statistics for reporting purposes.

A simple rule is that a radiology case requires 8KB storage per case and that an outpatient surgery case requires 16KB storage per case. If your facility codes 25000 radiology cases and 12000 outpatient surgery cases per year then the storage requirements for one year's worth of data is:

25,000 * 8KB + 12,000 * 16KB = 392,000KB ~ 382MB per year

If you choose to store detailed information on coder statistics for reporting purposes then this number effectively doubles to 764MB per year.

Q: Do I need to open holes in the firewall so that the CaseSubmitter can connect to the PLATOCODE Server?

A: CaseSubmitter connects using Port 443 which is the standard HTTPS port. If outgoing port 443 is not already open on your firewall you would need to open an outgoing port 443 from the Application Server's IP or to the external PLATOCODE server's IP.

Q: What sort of database is it?

A: The Results Database can reside in a Microsoft SQL Server 6.0 or later, Oracle, MySQL 4.0 or later or file based database (not recommended for more than 5 users).

Q: What are the HIPAA implications of the Results database?

A: The database is maintained by you at your facility using your standard database protection measures. Patient Health Information (PHI) in the database is encrypted, meaning it is not accessible except via the PLATOCODE system. The PLATOCODE system decrypts and presents the information to the coder when she starts coding a case, at which time the patient's records are already available to the coder in your other systems. Clearly the Results Database is not a designated dataset. These characteristics minimize your HIPAA documentation requirements.

Q: How do I install the PLATOCODE CAC System?

A: You simply download the PLATOCODE CAC Setup application, install it on your application server and run it. It will then ask you a series of questions (such as the location of your database server) and then ask you to provide your PLATOCODE Authorization File. It will then download and install all the software required for your facility and install the database for you. This should not take more than 30 minutes depending on the speed of your internet connection.

Q: How does the coder review the results?

A: We supply a set of applications and tools that the coder can use to access results. The tools supplied can be integrated into your existing coding workflow or can be used as stand alone review tools. We usually like to discus with you your specific needs and identify a tool set that will work best for you.

Q: How do I Install the PLATOCODE Viewer?

A: We supply an auto installer, though this may require Administrator privileges to run on Vista, Windows 7 or locked-down PCs. If run from a server or via Terminal Services you may not need to do anything else. You can also run the PLATOCODE Viewer directly from the Application Server. We would discuss and agree a mechanism with you during implementation.

Q: Where is the PLATOCODE Viewer installed?

A: It can be installed on the Coder's PC, run from a Server, or run using Citrix or Terminal Services.

Q: What are the minimum PC specifications for the PLATOCODE Viewer?

Processor: Minimum that the host OS supports.
RAM: Minimum that the host OS supports.
Hard Disk: 1.2GB
OS: Windows 95 and above.
Network: 100MB/s.

Q: How does the PLATOCODE Viewer access the Results Database?

A: It uses the standard ODBC driver for the database you select. Usually this is already available on the coder's PC.

Q: What is the PLATOCODE Viewer?

A: The PLATOCODE Viewer is a 32-bit application/dll used by coders to validate CAC Results as part of an existing coding process and return them to your other systems for billing. It is integrated between an existing billing/abstraction system and an existing 3rd party encoder.

Q: Do I need an ODBC DSN on each machine?

A: No. The system uses connection strings.

Q: Where are the connection string stored?

A: It's encrypted (a reply you'll hear often when speaking with PLATOCODE technical people!) and stored in a location you choose. We supply a configuration application to allow you to set the connection string.

Q: How does the PLATOCODE Viewer interact with other systems?

A: We supply "plugins" for the system to work with prevalent Abstractor and Encoder tools.

Q: What happens if the PLATOCODE Viewer can't access the Results Database? Can the coder still work?

A: Yes. Please contact us for a technical document about the PLATOCODE Viewer's failsafe features, including the ability to identify and report problems or unresponsive applications.