Discussion (2)2
Log in or sign up to continue

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...