Factory for report handlers
Not sure if that's going to improve the maintainability index, but


You're misimplementing Inversion of Control. IoC is when your dependency (namely, IReportHandler) is given to you from outside the class. It isn't the case here. It defeats the whole purpose of having an abstract dependency instead of a concrete one.

Read up on Inversion of Control and Dependency Injection and how they can improve code maintainability and testability. Don't use them unless it is an educated choice to do so.
You're using a Factory where it has no benefit. 

Read up on the different kinds of factories (Factory from DDD, Factory method and Abstract Factory from Go4). Don't use Factories except where there's a clear advantage to doing so.
The code is too complicated for what it does. 

Why the factoryId, switch statement and magic value 1? 

The url parameter is never used. 

Why the intermediate variables documentsDataJSON when you could just return &lt;expression&gt; and save one line of code for more clarity?
Naming is awkward and violates the Principle of Least Surprise. 

Why would you expect a ReportHandler to Create a report, while ReportFactory creates a... ReportHandler? 

Why does FetchDocuments() not return a list of Documents, but a list of DocumentMappers?


Don't try to mimic code samples or game a maintainability analysis tool. Learn about the philosophy behind the big design principles/patterns and decide for yourself if, where and how to apply them.