Difference between revisions of "Person FHIR Resource Proposal"
| Line 105: | Line 105: | ||
<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this resource. They should demonstrate the full scope of the resource and allow exercising of the resources capabilities (full element coverage, inclusion & omission of optional elements, repeating and singleton repeating elements, etc.) --> | <!-- Provide a listing of the types of scenarios to be represented in the examples produced for this resource. They should demonstrate the full scope of the resource and allow exercising of the resources capabilities (full element coverage, inclusion & omission of optional elements, repeating and singleton repeating elements, etc.) --> | ||
| − | Patient/RelatedPerson linkages | + | === 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. | |
| − | This reduces the amount of data entry required for users, as it is known that this is the same individual. | ||
| − | Cross-Domain Patient Directory | + | === 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 | + | === 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 | + | === 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== | ==Resource Relationships== | ||
Revision as of 15:34, 18 February 2015
This page documents a Pending 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.
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
Expected implementations
- Cross-Domain Patient Directory
- Cross Domain Provider Directory
- Client Portal
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
