User bio
404 bio not found
Cambridge, MA
Member since Feb 13, 2016
Pinned posts:
Replies:

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/ 

Open Exchange applications:
Certifications & Credly badges:
Global Masters badges:
Followers:
Following: