This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "FHIR Person"

From HL7Wiki
Jump to navigation Jump to search
m
m
Line 6: Line 6:
 
The current v3 "Person" holds a whole range of properties that go well beyond just personal identification, like indications of religion, marital status or ethnicity. These attributes (and others) are very much necessary in some context (where registration might even be mandatory) but are of little use in actual international or even national communication due to the fact that these attributes are hard to interpret outside of their original context. It seems fair to move these attributes into extensions so they can be included in profiles where their context and thus their interpretation is clear.
 
The current v3 "Person" holds a whole range of properties that go well beyond just personal identification, like indications of religion, marital status or ethnicity. These attributes (and others) are very much necessary in some context (where registration might even be mandatory) but are of little use in actual international or even national communication due to the fact that these attributes are hard to interpret outside of their original context. It seems fair to move these attributes into extensions so they can be included in profiles where their context and thus their interpretation is clear.
  
 +
Since most of healthcare is focused around observing aspects of patients (and thus persons), the Person model is especially sensitive to the unwanted inclusion of attributes that are captured for reasons other than patient administration. For example, the current model includes an "Employee" role to express the fact that a person receives wages for working for an organization. This is firmly an "administrative" function. However, this "Employee" role is also used on patients to note facts about their working conditions to support medical assessments. In this latter case the actual employer might be irrelevant, as might be the salary, but both notions are collapsed into one. This kind of logic feels natural to people familiar with RIM modelling, but foreign to any outsider. I consider the first use to be correct for this attribution layer, whereas the second should be moved and modeled as an Observation done while taking a social or functional patient history.
  
 
+
===Handling roles===
 
 
 
Person can be used in multiple roles: as a patient, as a (care) professional or natural persons related to patients. Depending on these roles, some attributes might or might not be relevant, like disability 'professional' persons. This might suggest moving these attributes to resources representing these roles, but since some of them actually are aspects of the person, this is not normally a natural fit. E.g. 'disability' does not depend on being a patient in one hospital or another, so it makes no sense to move it there.
 
Person can be used in multiple roles: as a patient, as a (care) professional or natural persons related to patients. Depending on these roles, some attributes might or might not be relevant, like disability 'professional' persons. This might suggest moving these attributes to resources representing these roles, but since some of them actually are aspects of the person, this is not normally a natural fit. E.g. 'disability' does not depend on being a patient in one hospital or another, so it makes no sense to move it there.
  

Revision as of 13:53, 9 August 2012

Return to PA Resource Development

Person belongs to the group of attribution resources in Fhir which focus on the "who", "when" and "where" aspects of the information represented by Fhir. As such, its attributes are focused on the information necessary to support the medical and administrative procedures and but will not contain medical or care-related information itself. Person is a basic building block within the attribution layer, so it references other components from this layer (organizations, locations, encounters) but does not refer to higher-level constructs such as procedures or observations.

Analysis of the Person model in v3

The current v3 "Person" holds a whole range of properties that go well beyond just personal identification, like indications of religion, marital status or ethnicity. These attributes (and others) are very much necessary in some context (where registration might even be mandatory) but are of little use in actual international or even national communication due to the fact that these attributes are hard to interpret outside of their original context. It seems fair to move these attributes into extensions so they can be included in profiles where their context and thus their interpretation is clear.

Since most of healthcare is focused around observing aspects of patients (and thus persons), the Person model is especially sensitive to the unwanted inclusion of attributes that are captured for reasons other than patient administration. For example, the current model includes an "Employee" role to express the fact that a person receives wages for working for an organization. This is firmly an "administrative" function. However, this "Employee" role is also used on patients to note facts about their working conditions to support medical assessments. In this latter case the actual employer might be irrelevant, as might be the salary, but both notions are collapsed into one. This kind of logic feels natural to people familiar with RIM modelling, but foreign to any outsider. I consider the first use to be correct for this attribution layer, whereas the second should be moved and modeled as an Observation done while taking a social or functional patient history.

Handling roles

Person can be used in multiple roles: as a patient, as a (care) professional or natural persons related to patients. Depending on these roles, some attributes might or might not be relevant, like disability 'professional' persons. This might suggest moving these attributes to resources representing these roles, but since some of them actually are aspects of the person, this is not normally a natural fit. E.g. 'disability' does not depend on being a patient in one hospital or another, so it makes no sense to move it there.


Person properties

  • identifiers (Person.id)
  • names (Person.name)
  • addresses (Person.addr)
  • contacts (Person.telecom)
  • dob (Person.birthTime)
  • gender (Person.administrativeGender)
  • nationality (0..1) CodeableConcept (Person.asCitizen)

proposed extensions

  • disability, CodeableConcept (Person.disabilityCode)
  • livingArrangement, CodeableConcept (Person.livingArrangementCode)
  • religion, CodeableConcept (Person.religiousAffiliationCode)
  • race (Person.raceCode)
  • disability, CodeableConcept (Person.disabilityCode)
  • birthOrder, integer (Person.multipleBirthOrderNumber)
  • deceasedDate, dateTime (Person.deceasedTime)
  • maritalStatus, CodeableConcept (Person.maritalStatusCode)
  • isOrganDonor, boolean (Person.organDonorInd)

possible extensions

  • ethnicGroup (Person.ethnicGroupCode) - current definition is much geared to specific (us?) usecases.


remarks

  • Person.multipleBirthInd - propose to replace by DAR on Patient.birthOrder
  • Person.deceasedInd - propose to replace by DAR on Person.deceasedDate
  • Person.educationLevelCode - propose to replace by Person.qualifications

Person.Citizenship[1..*], proposed extension

Person.nationality does not cover multi-national or refugee/asylum situations. For these usecases, use Citizenship

  • period [1..1], Period
  • code, Coding [0..1], qualification of legal status within a nation
  • nationality, CodeableConcept [1..1]

Person.Employment[1..*]

  • identifier, HumanIdentifier[0..1] (Person.asEmployee.id)
  • period (Person.asEmployee.effectiveTime)
  • occupationCode


Proposed extensions

  • addresses (Person.asEmployee.addresses)
  • contacts (Person.asEmployee.telecom)

Possible extensions

  • jobClass (Person.asEmployee.jobClassCode)

Remarks

  • status - necessary?