After further review of the play, this app is a touchdown.  

Great work/contribution @Dmitry Maslennikov 

Hi Adam,

Consider setting up a rule in your pipeline, so that it only executes if you merge to a particular branch.  I know your use case seems to be "PR approval" not merge, but the below rule will only execute on merges to main.

There are other free variables in the pipeline to maybe accomplish what you want.
 

  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "main"'`

This is a very good post on the subject that is exhaustive you may want to checkout:

https://community.intersystems.com/post/continuous-delivery-your-intersy...

variables:
  SESSION_NAME:
    value: "IRIS"
  NAMESPACE:
    value: "ACME"

stages:
  - deploy

deploy main:
  stage: deploy
  tags:
    - dev
  before_script:
    - export WORKING_DIR=$(pwd)
  script:
    - echo "Initializing ACME CI/CD Build DEV..."
    - echo "Deploying code ${CI_MERGE_REQUEST_SOURCE_BRANCH_NAME} branch to instance..."
    - |
      /usr/bin/irissession ${SESSION_NAME} <<EODEPLOY
      ${IrisUser}
      ${IrisPass}
      zn "${NAMESPACE}"
      w ##class(%SYSTEM.OBJ).LoadDir("${WORKING_DIR}/src","ck",,1)
      set sc = ##class(Ens.Director).UpdateProduction()
      EOFDEPLOY
  rules:
    # only runs if merged to main
    - if: '$CI_COMMIT_BRANCH == "main"'

I hit this too...

Instead of a query, try a dbtable with a query wrapper to a temp_table...

.option("dbtable", "(SELECT name,category,review_point FROM SQLUser.scotch_reviews) AS temp_table;") 

check this post for full in and out with jdbc to databricks.

https://community.intersystems.com/post/databricks-station-intersystems-...

I use these globals to take a peak at the calls:

	zn "YOURFHIRNAMESPACE"
	Set ^FSLogChannel("all")=1
    zn "%SYS"
    Kill ^%ISCLOG 
	Kill ^ISCLOG 
	Set ^%ISCLOG=5 
	Set ^%ISCLOG("Category","HSFHIR")=5 
	Set ^%ISCLOG("Category","HSFHIRServer")=5 
	Set ^%ISCLOG("Category","OAuth2")=5 
	Set ^%ISCLOG("Category","OAuth2Server")=5

then
 

zw ^FSLOG

in the fhir namespace.

Shows the route, params and helpful with oauth2/SMART where the route has to match the patientid in the token.
 

Michael, if you drop the generated token into https://jwt.io, does Okta have the the list of scopes in an `scp` parameter?

I recall having to do something like this in an Interaction Strategy to get ValidateToken() to work with Okta, wondering if the same is necessary for ValidateJWT().

 

		Do JWTObj.%Set("client_id", OktaJWTObj.cid)
        Do JWTObj.%Set("scope",OktaJWTObj.scp)

This illustrates a particular subject that seems to be getting some traction in the FHIR community as a "FHIR Interceptor"... personally I have implemented this competency using an api manager (Kong, API Gateway) through an integration layer (function) prior to hitting IRIS which works but splits the business logic in two differnet places.

Your way here keeps the "intercepts" in IRIS and the resource server which I like.

Here is the "intercept layer" concept ablaze: https://darrendevitt.com/building-a-fhir-intercept-layer/ 

This is ridiculously good work, the implementation of the custom operation and the fact it is a patient merge is fantastic.  I have found native object de-duping, deepdiff, and two line list de-duping in python to be a way to quickly get to the point with FHIR Resource pair manipulation. 

Thank you for taking the time on this, most likely going to have to read it a few times and load it up on my eReader.

One thing I'd add to tips and tricks from something I stole from someone somewhere:

     zn "<FHIRNAMESPACE>"	
    Set ^FSLogChannel("all")=1
    zn "%SYS"
    Kill ^%ISCLOG 
	Set ^%ISCLOG=5 
	Set ^%ISCLOG("Category","HSFHIR")=5 
	Set ^%ISCLOG("Category","HSFHIRServer")=5 
	Set ^%ISCLOG("Category","OAuth2")=5 
	Set ^%ISCLOG("Category","OAuth2Server")=5

Seems to give up a good mix of  token processing and fhir calls debuggery.
 

Fantastic write up @Steve Pisani , thank you.

This is a great resource, nice work and a top chapter in this series for sure.

There seems to be different ways to approach declared IRIS state by codifying things, you can codify the exported objects and import them or like you mentioned, use the installer method that builds things as code.... which I have had pretty good success with in the past, like Tasks below.

<Method name="CreateClaims">
<ClassMethod>1</ClassMethod>
<FormalSpec>pVars,pLogLevel,tInstaller</FormalSpec>
<ReturnType>%Status</ReturnType>
<Implementation><![CDATA[


Set configItems = $LISTBUILD(

$LISTBUILD(1,
"Return payload from customer",
"create 835 from adjudicated claims",
"NS.Package.Task.CreateClaim")


for i = 1:1:$LISTLENGTH(configItems) {

    Set item = $LISTGET(configItems, i)
    Set Task=##Class(%SYS.Task).%OpenId($LISTGET(item,1))

    if 'Task {

        Set Task = ##Class(%SYS.Task).%New()
        Set Task.Name = $LISTGET(item,2)
        Set Task.Description = $LISTGET(item,3)
        Set Task.NameSpace = "USER"
        Set Task.Type = 2
        Set Task.TaskClass= $LISTGET(item,4)
        Set Task.TimePeriod = 5
        Do Task.idSet($LISTGET(item,1))
        Set Task.RunAsUser = "intersystems"
        Set status=Task.%Save()
        $$$ThrowOnError(status)

    }

}

]]></Implementation>
</Method>

In the FHIR Accelerator you can head to "Data Management -> Bundle Operations" and find sample scenarios in there.  At the end of the day theses are bundles generated by Synthea so you can upload populations you create from that tool directly in for your use.  If you want some help generating a specific population give us a hint and can help with that during that hack.