While this can be implemented as a "solution type" the fact that incidents cannot be related to to a solution means there is no ability to see the effect of the known error on the service. 

Requirements:

• It should have custom fields for the client to create their own data types against the record (the status of the error, severity, system etc) 
  
• It should be able to be linked to a Request - i.e. like a problem record or a change record
  

Discussion on differences from  http://www.theitsmreview.com/2012/04/7-benefits-of-using-a-kedb/

Is the KEDB the same as the Knowledge Base?

This is a common question. There are a lot of similarities between Known Errors and Knowledge articles.

I would argue that although your implementation of the KEDB might store its data in the Knowledgebase they are separate entities.

Consider the lifecycle of a Problem, and therefore the Known Error which is, after all, just an attribute of that Problem record.

The Problem should be closed when it has been removed from the system and can no longer affect users or be the cause of Incidents. At this stage we could retire the Known Error and Workaround as they are no longer useful – although we would want to keep them for reporting so perhaps we wouldn’t delete them.

Knowledgebase articles have a more permanent use. Although they too might be retired, if they refer to an application due to be decommissioned, they don’t have the same lifecycle as a Known Error record.

Knowledge articles refer to how systems should work or provide training for users of the system. Known Errors document conditions that are unexpected.