Person FHIR Resource Proposal
Contents
- 1 Person
- 1.1 Owning committee name
- 1.2 Contributing or Reviewing Work Groups
- 1.3 FHIR Resource Development Project Insight ID
- 1.4 Scope of coverage
- 1.5 RIM scope
- 1.6 Resource appropriateness
- 1.7 Expected implementations
- 1.8 Content sources
- 1.9 Example Scenarios
- 1.10 Resource Relationships
- 1.11 Timelines
- 1.12 gForge Users
Person
Owning committee name
Contributing or Reviewing Work Groups
None
FHIR Resource Development Project Insight ID
pending
Scope of coverage
An individual has identity outside of a healthcare setting. The Person resource is used to capture data about the person (demographic and non-healthcare identifier information), and to relate the person as an individual to other resources that do have a health-related context.
The individual may also be recorded in different types of records, and this resource provides a way to actively link the Patient, RelatedPerson and Practitioner records together. (The joining of the practitioner with the other record types may not be presented for information privacy reasons, but some systems do actually record this)
Note that this resource is not intended to replace the functionality or usage of the "Link" property within the Patient record, but rather compliments patient-to-patient linking within a specific patient identity domain to extend this capability across organizational boundaries.
De-normalized Data
Most of the properties of the Person resource are replicated across the resources that are related to one another using the Person resource "Link" property. This is intentional and recognizes the disconnected nature of resources within a particular healthcare setting, as well as the reality that individuals are active across different healthcare settings. The Person resource provides an essential mechanism for relating data about individuals within closed systems and across organizational boundaries.
Within a closed system not many systems actually implement a shared Person record, and as such the data it manages using traditional data entities DO become out of sync with each other. The Person resource permits a capability for these systems to identify other instances of an individual person's data via a centralized registry that can assist in keeping things up to date across its related resources.
In a data sharing network that spans organizational boundaries, where custodianship for particular resource data is distributed across the various organizations participating in the network, the system responsible for coordinating access to data and identifying relationships across this distributed network can manage those relationships with the Person resource.
RIM scope
This Person Resource is not covered by the RIM directly.
Resource appropriateness
Person as distinguished from Patient, Practitioner and RelatedPerson
The Person resource represents an actual human being that might be linked to Patient, Practitioner and RelatedPerson roles. Person is not directly related to any healthcare events.
RelatedPerson, for example, is a role that allows relatives, neighbors, friends and other non-practitioner individuals to be involved in healthcare events as performers, reporters, witnesses, etc. Its sole purpose is to allow linking of resources involved in healthcare events.
Some systems label Patient as Client, StudySubject, Person or other things. They're still interested in them in a Patient role. Patient is fundamentally a person (or animal) who is receiving or may receive care. The Person resource is just "A Person (or animal?)" - they might receive care, provide care or have incidental involvement to someone else's care.
Expected implementations
- Cross-Domain Patient Directory
- Cross Domain Provider Directory
- Client Portal
- Master Person Index (Health Insurance Subscriber/Member lists)
- Patient Administration Systems (linking Patient and RelatedPerson)
Content sources
None.
Example Scenarios
Patient/RelatedPerson linkages
In many systems an individual entered as a RelatedPerson entry is also linked to a Patient entry when entered. This reduces the amount of data entry required for users, as it is known that this is the same individual. In a clinical workflow, the same transitive link from a RelatedPerson resource to the Patient resource provides a path to patient informaton from one patient to that of the related person.
Cross-Domain Patient Directory
In a data sharing network, finding the location of patient records across different systems is a necessary pre-requisite for accessing external patient data. Using the link element of the Person resources, the system responsible for the directory associates Patient resources from the organization providing the patient data. The assuranceLevel associated with the link provides a way for a system to qualify its confidence in the asserted link. For example, a relationship from the Person to a Patient using a probabilistic matching algorithm may be represented using a link with an assurance level of 1, while a relationship established using a government-issued photo ID may be created with an assurance level of 3.
Cross-Domain Provider Directory
Similarly, providers working in multiple healthcare service settings may be linked across different organizations using the link element. The various Practitioner resources can be related using a common person resource with a link for each of the Practitioner resources located in other organizations.
Client Portal
In a client portal used by the consumers the Person record could be used to form a kind of "Account" within the system and links to all the other related systems where their data is stored/referenced.
Resource Relationships
The Person resource provides direct links to Patient, Practitioner, RelatedPerson, and Person (itself)
There are no links created that point towards the Person resource.
Timelines
This resource has been worked on by the workgroup and reviewed in the for comment ballot just reconciled.
gForge Users
brianpos, ewoutkramer, grahameg