In the good ol' sensible fashion of computers there are a number of ways to do this, including building something in an Ensemble production to send these out, by monkeying around with the Namespace Global Mappings, etc.  However, the following will most likely answer your question ... with 3 answers.  Enjoy! 

Via SQL:

EnsPortal_MsgFilter.SavedSearch if you are using SQL, or if you want to move the data you will probably have to copy the global it produces.  If you want to move it, you can create the appropriate update statements with the data in this table and move it to another place. 

<Warning>  For these next options, you will need to understand that this will overwrite what is in your target namespace.  So if you have any created in the target namespace you might want to go back to "Via SQL" as your best option.  Not to mention there is no undelete if you use one of the next two options.  If you are working on a production system even if you know what you are doing, you might want to add a step of saving off the target namespace's global before overwriting with the new. </Warning>

Via the SMP:

Go to System -> Globals and change your namespace to the source namespace.  Find the global named ^EnsPortal.SavedSearchD ... I did not misspell that, I assure you.  you can use the global filter of EnsPortal* to drastically shorten the length of the results to look through.  Once you find it, you need to select the check box to the left of the name, then click Export.  Next, on the same screen in the SMP, change your namespace to the target namespace.  Now click the Import button and select the file you created.

Via the Console (advanced):

NOTE:  If you do not know what the console is or how to change namespaces, you probably want to resort to one of the methods above.  Also, be very, very careful and do not GI when you meant to GO, if you know what I'm saying ... if you do not know what I'm saying, just ignore all this like your never read it.  I even made them a lighter font so  if you squint your eyes you will probably not even see this.

If you go into console, get into the source namespace and run:

DO ^GO

(Global Output) to output to a file of your choosing the actual global containing this information.  Global name is ^EnsPortal.SavedSearchD ... I still, did not misspell that.  Make sure you make note of the file location you choose.  , then run: 

DO ^GI

(Global Import) to import the global in the file you created.

Yes, this should work.  You need to create an X12 File Business, but do not use a "Doc Schema Category", as this will force Ensemble to inspect the ISA segment for what DocType and Category it should be in.  Also, set this to send "Whole Batch" so everything stays together.  Create a Router and a rule that will have the following constraint: 

msgClass=EnsLib.EDI.X12.Document

This will only accept an X12 formatted document.  Next you want to check the Document Type Version with a "When" node with a condition where Document.TypeVersion Contains "401" for 4010 (NOTE:  These seem to no have the leading zero and we could have simply used Contains "4" for the same effect).  You can pass the message through a DTL or you can pass it directly to another Business Process or Operation to do the specific work for that type.  Make sure you include a "Return" at the end of your "When" logic, then create a second looking to see if Document.TypeVersion Contains "501" and send it to it's corresponding Business Process or Operation.  This should work given you are getting a well formed Interchange (ISA) segment with everything in the right place.  If not, you may have to create a DTL just to pull that piece out of the ISA, then you can set it to the version by creating a "Set" target.TypeVersion=4010 or target.TypeVersion=5010, which you can just pass back into your router with this set appropriately.    Lots of folks don't realize you can set properties in the DTL since it doesn't show the properties in the visual diagram, but you can ... and you can also set variables which I may cover another time, if someone else hasn't already.

You could even create a DTL to convert 4010 to 5010, so that you don't have to have two completely different, but almost the same "wheels" to work with, where the "wheel" is the business logic.  It will allow you to not have to sift through two versions of the same logic if a change needs to be made, although,  I have not fooled with any 4010, so I'm not sure how do-able that would be, but I would expect your 4010 -> 5010 DTL logic to be pretty static once you worked it out, while your 5010 processor would continuously be updated due business logic changes over time.  Just food for thought.  Good luck, and let me know if you encounter any issues.