You might also find this HL7 benchmark post by @Mark Bolinsky useful, specifically the section titled "Disk Configuration", and the related "Table 2" there.

For convenience I'm pasting this table here (but read the original post for the full context, for example your scenario sounds more like the "T2 Workload" described there, rather than the "T4" one) -

Table 2: Disk Requirement per inbound HL7 T4 Message  

For the Mgmt. Portal side you can follow through @Yuri Marx's example (though it uses Google and not Keycloak but the principal is similar, you will need a ZAUTHENTICATE, you will find a sample there).

Re your question about accessing the Access Token, you can include in your ZAUTHENTICATE something like this:

 set isAuthorized=##class(%SYS.OAuth2.AccessToken).IsAuthorized(applicationName,sessionId,,.accessToken,,,.error)
 if isAuthorized {
    set sc=##class(%SYS.OAuth2.AccessToken).GetIntrospection(applicationName,accessToken,.jsonObject)
    ...
 }    
 // then you can access the jsonObject for getting info, e.g. (and this is from a KeyCloak example):
 set Username="OAuth2_"_jsonObject.username
 // or:
 set iterator=jsonObject."realm_access".roles.%GetIterator()
 while iterator.%GetNext(.key,.val) { 
    ...
 }

For the FHIR API you can look at @LuisAngel.PérezRamos's example (though it uses auth0, but again it should be similar).
In this case you don't have to worry about ZAUTHENTICATE because the FHIR Server infrastructure has you covered.

By the way, in v2024.3 which was just released, there's a new OAuth FHIR Client QuickStart you can use to set this up in an easier manner.

For other REST services this would depend on their nature and whether there is user interaction which allows for example the actions described in the two samples mentioned above.

Note, my colleague @Ariel Glikman and myself are in the midst of a project that includes interacting with KeyCloak, and possibly once it's complete we can share some insights, but this will take some time, so I wouldn't hold my breath waiting for this.

Another note, I believe that down the line (perhaps even with v2025.1) we will have more seamless out-of-the-box integration with these kinds of OAuth authentication flows, which will require less background work as you need to implement today with ZUATHENTICATE etc. Stay tuned...

I believe you need to use PasswordHash, see for example from Docs:

[Actions]

CreateUser:Name=SQLAdmin,
  PasswordHash="cec6638a357e7586fddfb15c0e7dd5719a1964e774cd37466fb0c49c05,
  323cb89148c887166dd2be61c107710539af2c01b43f07dccc8d030ac2c1a8cf7c5ace4a00d57e3780f,10000,SHA512",
  Roles="%SQL,%DB_USER"

Re PasswordHash see more details in the related Docs. For example:

$ docker run --rm -it containers.intersystems.com/intersystems/passwordhash:1.1 -algorithm SHA512 -workfactor 10000
Enter password:
Enter password again:
PasswordHash=0fad6b1a565e04efb5fe9259da8457456883e0a3a42c1a34acec49cbbc1fb8c4c40f1846559ce180c103898db836,dd0874dc346d23679ed1b49dd9f48baae82b9062,10000,SHA512