Home > Vendors > FAQ for software vendors
FAQ for Software Vendors
Q: Who is MDCodeWizards for?
Q: What features does MDCodeWizards include?
Q: How long would it take us to integrate MDCodeWizard claim scrubber with our program?
Q: Our software runs on a non-Windows operating system. Will it work with MDCodeWizard?
Q: What is a Request?
Q: What parameters do I submit with my Request message?
Q: What is a Response?
Q: What data will I receive from MDCodeWizard with my Response message?
Q: What are the priority/severity levels of the Error messages I receive and what do they mean?
Q: Have you measured the performance of your system? Can you give me some benchmarks?
Answers:
Q: Who is MDCodeWizards for?
A: MDCodeWizard is for software vendors who want to quickly include crucial medical coding and billing functionality in their software with minimum development effort and virtually no need for support. MDCodeWizard is always compliant and up-to-date.
Q: What features does MDCodeWizards include?
A: MDCodeWizard medical claim-scrubber includes the following modules:
- Medical claim-scrubber for professional (CMS-1500) claims
- Medical claim-scrubber for institutional (UB-04) claims
- Evaluation and Management (E&M) Code Wizard
- Medical Necessity Verification
- Medicare Fee Schedule and RVU Calculation
- Forward and Backward ICD-10 Crosswalk
- Search Medical Codes by abbreviation or keyword
- Medical Code Reference
Q: How long would it take us to integrate MDCodeWizard claim scrubber with our program?
A: The answer of this question really depends on the complexity of your software and the knowledge of the person implementing the integration. The integration of an average medical coding and billing program may take from minutes to a few hours. We provide you with sample code and documentation and our support staff is dedicated to make your integration a snap.
Q: Our software runs on a non-Windows operating system. Will it work with MDCodeWizard?
A: Yes. The communication with MDCodeWizard is not constrained by the operating system you are using. We rely on standard methods of communication for the web which makes our software available and open to all kinds of systems.
Q: What is a Request?
A: Request is an inquiry in the form of an XML message sent to MDCodeWizard's servers with all data from the medical encounter. The medical coding/billing software and MDCodeWizard communicate through Request and Response messages. The Electronic Medical Record (EMR) program sends Requests with the claim information and receives Responses with Errors, Instructions how to fix the errors and Automatic Crosswalk match for Procedures and Diagnoses.
Q: What parameters do I submit with my Request message?
A: We tried to keep the parameters you submit with your claims as close as possible to the real CMS 1500 form
Here is a list of the parameters which medical coding/billing programs must send to MDCodeWizard:
ProductID, ClientID - 2 codes which identify the user submitting the claim for validation
Encounter(s)- One or many medical encounters which include the following:
List of Diagnoses - List of ICD-9 Codes
List of Procedures - List of CPT Codes with their modifiers, dates of service and Diagnosis Pointers (if any)
Q: What is a Response?
A: Response is the result of validating user's medical claims. The Response message contains a list of Errors which the medical coder/biller should pay attention to and instructions how to fix them. The Response message also includes a list of Diagnosis Pointers (Crosswalk) that match the Procedures to the Diagnoses in the claim.
Q: What data will I receive from MDCodeWizard with my Response message?
A: The response from MDCodeWizard to your Coding or Billing Software contains mainly 2 things - Error messages for your claims with instructions how to fix them and Automatic Crosswalk for your Procedures and Diagnoses. Your Error messages contain Priority and Severity level to indicate the level of importance of each message. See your Developer's Guide for more detailed information.
Q: What are the priority/severity levels of the Error messages I receive and what do they mean?
A: There are 5 different levels of error messages that the software developer should be aware of. 4 of which are for the end-user and one indicates problems with the communication or the format of the messages.
| Priority | Severity | Explanation |
| 0 | Error | This type of messages are for the software developer. They should not occur during the everyday work. Indicates there is something wrong with the communication between the end-user Medical Coding or Billing system and MDCodeWizard. |
| 1 | Critical | This type of messages are for the medical coder. These are the most important and crucial errors in the medical claim. They should be fixed or the claim would most likely be denied payment. |
| 2 | High | This type of messages are for the medical coder. The claim may be denied payment if not fixed. |
| 3 | Medium | This type of messages are for the medical coder - they are fairly important but not crucial for the claim. |
| 4 | Low | This type of messages are for the medical coder and should be taken as warnings and additional info. |
Q: Have you measured the performance of your system? Can you give me some benchmarks?
A: For us the performance was one of the most important factors while we were designing and building the product. Our goal was to give the end-users not only the functionality but also the speed they deserved.
We did some thorough testing of MDCodeWizard API before releasing the product to make sure we achieved our goals.
There were many different scenarios and variables we took into consideration.
We tested with different client systems, different work load on the server, different number of claims sent with one Request, different number of procedures and diagnoses within the claims, and different number of error messages returned by the system.
There was no surprise in the results. We found out that some factors did not make any impact on the performance at all. The type of the client program and work-load of the server had little to no impact on the performance for the end-user. The same was with the different number of error messages returned.
|
|
