I've used ChatGPT for some IRIS related things.. Sometimes it's been useful and some times its simply made up stuff, it made up the names of classes in IRIS that have never existed and do not exist in the most recent version.  Other times it's provided me some information that wasnt boiler plate to copy and paste but led me down a path that allowed me to find the solution.

There is in fact a global on the Registry that has a record of the Patient data each time it is changed, the global is ^HS.Registry.Patient.OldHistory

the way to understand this is to determine what resource is required to access the database associated with /database/db4/syb/.  You can find this out by going to System Administration->Configuration->System Configuration->Local Databases and view the table that is associated with /database/db4/syb/.  You should see something like

find your and find the Resource then add the Resource to the Role you are connecting with.  While adding %All as a role will prevent the error it will also grant a whole lot more permissions than just the <protect> error.  

If you are describing your globals in a class and they do not use default storage, but rather SQL Storage(%Storage.SQL) you can define your storage to include extended references.  This is a technique that I have used in the past.  How you loop thru the extended references is up to you.  In my case we took advantage of the ability to SetServerInitCode which is called once when the connection is made to the server, there is an equivalent capability in DeepSee/Analytics.  In our ServerInitCode we populated an array of the different extended references we needed to access and our storage map firstly looped thru this structure and then the actual global.

If those fields are not used in the ReportDisplay, ie the HTML or PDF output, you could consider removing them from the ReportDefinition.  If on the other hand, you do need these fields then leave them in.  However, something else seems to be going on.  I commonly have this style of ReportDefinition

The usage of <macrodef > just allows me to have a single set of code that injects the same attributes into the <Master> node.

When running the report in XML mode it produces

<Master runDt="10/13/2022" footerDate="October 13, 2022" runTm="08:47AM" runBy="_SYSTEM" Draft="" ISCPrime="0" Instance="HEALTHSHARE" Namespace="HSEDGE1" Server="LAPTOP-ET8APOSR" InternalURLLinkPrefix="http://localhost:52773" CustomerName="Ready Computing, Inc" CoverPageDate="October 13, 2022" CustomerLink="" PageNumbering="1" SystemMode="" FilterSpecDisplay="" ReportName="Ensemble Message Management" HeaderLine2="" Top="9999999999999" ReportClass="RC.Ens.Report.MessageManagement" ZVERSION="IRIS for Windows (x86-64) 2021.1.2 (Build 336_0_21564U) Tue Apr 12 2022 12:13:45 EDT" ReportTitle="">

I don't think attributes found in the root node, in my case Master, are emitted to the Excel file.

If I run the report in MODE=XLSX mode it produces.. note it does not show the attributes 

so this is answering your question regarding your attributes at the top level.  Your question regarding the elements at the ProssData node is something different.  In my example, if I change 

to 

and then run the report in XLSX mode the attributes Namespace and TaskId do not appear in the Excel file.  However, I would have to change the ReportDisplay so that I now reference

@Namespace and @TaskId

if I want the PDF and HTML output to work properly.

Can you elaborate on what you mean by "hide" any component under ReportDefinition.  The ReportDefinition is where you define the XML document that will be created that is later used by ReportDisplay to output the data for a PDF report, Excel utilizes the ReportDefinition.   Just because you have an entity(element/attribute/group) in a ReportDefinition doesn't mean it will be utilized in the ReportDisplay.