Objectscript for both Install and post configuration is here:
https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI...
Some of the examples in open exchange, like the iris-oauth-fhir one have very straight forward examples:
https://github.com/grongierisc/iris-oauth-fhir/blob/main/iris.script
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...
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)