Difference between revisions of "Person FHIR Resource Proposal"
| (18 intermediate revisions by 2 users not shown) | |||
| Line 3: | Line 3: | ||
<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div> | <div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div> | ||
<div style="background:#F0F0F0"> | <div style="background:#F0F0F0"> | ||
| − | This page documents a [[:category: | + | This page documents a [[:category:Approved FHIR Resource Proposal|Approved]] [[:category:FHIR Resource Proposal|FHIR Resource Proposal]] |
</div> | </div> | ||
</div> | </div> | ||
[[Category:FHIR Resource Proposal]] | [[Category:FHIR Resource Proposal]] | ||
| − | [[Category: | + | [[Category:Approved FHIR Resource Proposal]] |
| Line 36: | Line 36: | ||
<!-- Additional work groups that may have an interest in contributing to, or reviewing the content of the resource * [[Patient Care]] | <!-- Additional work groups that may have an interest in contributing to, or reviewing the content of the resource * [[Patient Care]] | ||
(optional) --> | (optional) --> | ||
| − | + | None | |
==FHIR Resource Development Project Insight ID== | ==FHIR Resource Development Project Insight ID== | ||
| Line 55: | Line 55: | ||
As a rule, resources should encompass all of these aspects. | As a rule, resources should encompass all of these aspects. | ||
--> | --> | ||
| − | + | 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== | ==RIM scope== | ||
| Line 63: | Line 75: | ||
==Resource appropriateness== | ==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. Person does not do this, but rather may be used to associate a number of different RelatedPerson resources to a single individual. | ||
| + | |||
| + | Similarly, Patient is a role of a person who is receiving healthcare services within a particular health setting defined by an Organization. The Person resource allows systems to associate Patient records maintained by different Organizations within a single containing Person resource. | ||
| + | |||
| + | '''Person is not a User''' | ||
| + | |||
| + | The Person resource is specifically intended for linking, with a degree of certainty, resources belonging to the same individual. It is NOT intended to be used as a general purpose user account for purposes of authentication or provisioning. | ||
| + | |||
| + | '''Person is not a substitute for Patient, Practitioner or RelatedPerson''' | ||
| + | |||
| + | Person cannot be referenced by other resources involved in healthcare events. | ||
| + | |||
<!-- Does the resource meet the following characteristics? | <!-- Does the resource meet the following characteristics? | ||
| Line 80: | Line 109: | ||
<!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent implementations. --> | <!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent 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== | ==Content sources== | ||
| Line 92: | Line 127: | ||
<!-- 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.) --> | ||
| − | Cross-Domain Patient Directory | + | === 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== | ==Resource Relationships== | ||
| Line 109: | Line 150: | ||
--> | --> | ||
The Person resource provides direct links to Patient, Practitioner, RelatedPerson, and Person (itself) | 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== | ==Timelines== | ||
Latest revision as of 20:50, 1 April 2015
This page documents a Approved 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. Person does not do this, but rather may be used to associate a number of different RelatedPerson resources to a single individual.
Similarly, Patient is a role of a person who is receiving healthcare services within a particular health setting defined by an Organization. The Person resource allows systems to associate Patient records maintained by different Organizations within a single containing Person resource.
Person is not a User
The Person resource is specifically intended for linking, with a degree of certainty, resources belonging to the same individual. It is NOT intended to be used as a general purpose user account for purposes of authentication or provisioning.
Person is not a substitute for Patient, Practitioner or RelatedPerson
Person cannot be referenced by other resources involved in healthcare events.
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
