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)

Great discussion/question...

Disadvantages that come to mind:

  • support of $all operation is on the patient resource
  • yet another resource to consider for merges and outside of newer ops like $merge
  • "RelatedPerson" is built on a codified Relationship type you should ensure meets the use case.
  • Patient has a relationship that rolls up to the Account object (guarantor), Person does not.

In general on the mapping of known classifications implemented in our practices:

Account = Guarantor
Patient = A "Person" with at least one: visit or encounter or claim or social need/fulfillment.
Person = Established identity with no visits or encounter, used for proxy access to records, not tied to the account , but exists for oauth2 scopes.
RelatedPersons = known children or persons without workload relevance. (use this in SDOH heavily)

As an example of our lastest use case of the Person resources:

Social needs web wizard, that collected QuestionairreResource responses and tied them to a "Person" as the identity was not proofed until contact was met with the "Person" by the Social Navigator.  Upon contact, a more formal "Patient" record was created to attach the ServiceRequest to.

hope some of that helps, mostly brain dumping here...

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.
 

Thats really good work, even follows the adapter guidelines.  Pointing the community your way before preceding down the post.

Looks like my process for pre-post searches to look for duplicate content needs a re-think:

https://community.intersystems.com/smartsearch?search=dbt

https://openexchange.intersystems.com/?search=dbt&sort=r

These were goose eggs, so I proceeded down the path... however glad I played with duckdb and the plugins anyway.

@Regilo Regilio Guedes de Souza , late 2020 dropbox deprecated long lived tokens , and went to a refresh_token approach instead.  If you use the dropbox sdk the transition gets handled for you, but if not (and pretty sure we do not), what it entails is adding `token_access_type=offline` to the token request... this may need to be included a little deeper under the hood.

I see the MFT api has "IsAuthorized()" so it would be possible to do a check before hand in a process and manually invoke something, but I dont see the magic behind the UI's "GetAccessToken" in the UI.

Ill keep you posted!

 

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.

 

Follow up here,  apache conf needed a directive for the move forward.

The previous Gateway/IRIS combination did not require the below apache directive, but the upgraded setup certainly required.

<Location />
CSP On
</Location>


Docs do not really show it called out directly to turn on this apache directive for the root at all in the documentation but that is what was done to make it compatible in the declared version combination in case you run into this combo on similar configurations.

Thanks to Connie at the WRC for taking an in-depth look in short order.

Follow up here on the implementation of @Eduard Lebedyuk 's suggestion for the community and Google Geuse...

New $Namespace
Set $Namespace = "%SYS"
Set tSC = $$$OK
Set tSC = ##class(Security.Roles).Create("VSCODE")
Set tQuery = "GRANT EXECUTE ON %Library.RoutineMgr_StudioOpenDialog TO VSCODE"
Set tStatement = ##class(%SQL.Statement).%New()
Set tSC = tStatement.%Prepare(tQuery)
Set tResultSet = tStatement.%Execute()
Set pProp("MatchRoles")=":%EnsRole_Developer:VSCODE"
Set tSC = ##class(Security.Applications).Modify("/api/atelier", .pProp)
Quit tSC

Interoperability productions with Python and Cloud connectors? YEEEESSSSSSS.

However, containers.intersystems.com is giving up bad credentials.... or am I the sole brunt of cruelty here?

(base) sween @ dimsecloud-pop-os ~
└─ $ &#x25b6; docker login -u="ron.sweeney@integrationrequired.com" containers.intersystems.com
Password: 
Error response from daemon: Get https://containers.intersystems.com/v2/: unauthorized: BAD_CREDENTIAL