This article was initially available on our podcast. Click here to listen.

We’re going to do a little review and a review in the sense of not a recap but analyzing or looking at the capabilities of one of the systems, meaning practice management systems and clearinghouses out there. That’s Open Practice Solutions. The system that they provide is called OpenPM.

All about OpenPM

First of all, I want to say some positive things about OpenPM and Open Practice Solutions. They have a clearinghouse attached to them, which is Etactics. The organization seems to be very data-oriented. We have worked with them via one of our clients for quite a few years. They are overall quite good at reporting. They have a module in their system that is browser-based, by the way. 

You can create custom reports. You can pick from an enormous number of fields and select them and things like that. So there’s a lot of good options there. They are very cooperative. They’re willing to make modifications to change reports. They’re eager to do development to help you get what you need. So there are overall very positive things to say about OpenPM.

Denials analytics

Concerning denials analytics specifically, we’ve also given them positive reviews overall, in general, because very few systems provide denials data, meaning denials codes in a report. We can get denial codes from OpenPM, and that’s great. You can also get a denial description, which is fantastic because we’d like to have both. Both are very valuable. Very few systems allow you to get that information.

We have mentioned in the past that there are some limitations. One of those limitations for OpenPM is getting this information (it is located in a text field called “Note”). For instance, you have to be able to not only ignore nulls and all kinds of other information that’s irrelevant because some of those records have information that you don’t want. However, even when it does contain a form that you’re interested in, you have to parse out the code in the description because it’ll say something like “CO133”. 

Then there’ll be a caret and then an explanation and then another caret and then a bunch of numbers. So you’ve got to parse those things out. They’re not even always in that format. Sometimes, there’s information and then the caret and then the denial code. It can be a little bit goofy. Overall, it’s great to have that information. You can get it out. We can parse out those codes using software to bill that. So it’s some work, but nothing that we can’t get through.


There is a more significant issue that we wanted to comment on to OpenPM, and that is that codes get smushed together. What do I mean by that? Well, I don’t mean that if you’ve got a CO109 and a CO133, you’ll get a CO133109 or something like that, or you’ll lose one of those things. What I mean is that typically, if you get, in an 835 file, which is an ANSI X12N format, an adjustment group like CO or PR and then you have a code like 133 or 109, 253, etc., then there is also a remark code like N220, MA27, N290, etc. There’s a lot of different remark codes.

With OpenPM, in a case where there was, for example, an adjustment group and a code like a CO133 and then a remark code like N220, we would get CON220. That would be the information delivered to us in that note field that we’d be parsing out. Or COMA27, for example.

Identify patterns

Ideally, we would get both the adjustment group, the remark code, and the remark code. Whether they’re separated or not or formatted – that’s less of an issue because, again, we can develop software protocols to identify those patterns and pull out that information and parse it. That would all be fine. The problem is, it’s missing. So in the example, we gave (like a CO133 and an N220), we’ve lost 133. That’s an issue. It’s an issue because, at root, we’re an analytics company, and we’re missing a critical piece of information. That information is precious.

Reverse engineering

Now, it isn’t a total loss always because even if it’s missing, we can sometimes reverse-engineer the adjustment code from the description. So if it says “Incorrect patient demographics” or “The patient termed” or whatever the narrative might be, we could reverse-engineer and say, “Ah, that’s a CO. That’s a 109 or 133 or 253 or 45,” or whatever it might be. So we can reverse-engineer a number of those.

Even that can be complex because payers tend to have widely varying, in fact, wildly varying descriptions. Therefore, you need natural language processing to handle all of those and then convert those to a lookup table for those adjustment codes. So it is possible, but it’s a lot of work. It’s challenging. Even with that, it doesn’t always work. You can’t always find the missing adjustment code.

Final thought

I’m going to pause there. We’ll come back and talk more about this particular issue for OpenPM in a follow-up podcast. So that’s a little bit of information about OpenPM and their denials management reporting.