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

Difference between revisions of "FHIR SubjectOfCare"

From HL7Wiki
Jump to navigation Jump to search
Line 21: Line 21:
 
''See [[FHIR_Person#Person.PatientOfOtherProvider|Person.PatientOfOtherProvider]] for a discussion -- Ewout''
 
''See [[FHIR_Person#Person.PatientOfOtherProvider|Person.PatientOfOtherProvider]] for a discussion -- Ewout''
 
*BirthPlace (should be an extension of Person) ''In telcon on 20120917 we decided this is most likely an extension on SoC''
 
*BirthPlace (should be an extension of Person) ''In telcon on 20120917 we decided this is most likely an extension on SoC''
 
 
= = = = =  STUFF STILL TO DISCUSS IS UNDER THIS LINE, DO NOT YET REVIEW = = = = =
 
 
*coverage, Resource([[FHIR_Coverage|Coverage]]) [0..*] - We think Coverage is a separate Resource.
 
*otherInformation, Resource(Any) [0..*]
 
*link - A linked patient record is a record that concerns the same patient. Records are linked after it is realised that at least one was created in error., Resource(SoC) [0..*]
 
(this attribute comes from the current FHIR Patient resource) options:
 
** x-link explicitly
 
** imply by id
 
** patientLink resource
 
** have a Patient.Link of type identifier....which is a UUID and is the same on all patients that are linked
 
 
SubjectOfCare extensions:
 
*effectiveTime
 
*veryImportantPersonCode
 
 
*Employee (should be its own resource)
 
''We seem to agree (discussion on mail and on Person page) that this is a separate resource, but outside the responsibility of PA. Scenarios like Dutch Youth Care can either
 
handle this using an extension, or as observations/questionnaires in a social anamnesis -- Ewout''
 
 
*Student (should be its own resource)
 
''I doubt that "Student" will be its own resource.  Student is generally only relevant in healthcare insofar as it affects Coverage, so the relevant details about being a student will likely be handled as attributes and extensions there. --Lloyd''
 
 
OtherInformation can e.g. be used for communicating the following information related to the SoC:
 
*Administrative Observations
 
*Diet
 
*Allergies
 
*Blood group and other clinical observations
 
''Shouldn't diet/allergies/blood group be handled by Obervations? -- Ewout ''
 
  
 
==SoC.ContactParty==
 
==SoC.ContactParty==

Revision as of 10:44, 8 February 2013

Return to PA Resource Development

SubjectOfCare properties

(2012-11-05)

  • SubjectOfCare.identifier [1..*] - The cardinality is 1..* because we cannot imagine usecases where patient data is communicated without a patient identifier. [WGM201301 It's now present on Patient]
  • SubjectOfCare.subject Resource(Person|Animal) [1..1] - We think Animal is not 80%. Leaving it out of the resource reference would lead to us have an attribute "patient" and an extension attribute "animal", which are mutually exclusive. That's not very practical so we leave the one subject attribute of type Resource(Person|Animal) [WGM201301 Patient now covers both humans and animals, we might need to look at its current properties]
  • SubjectOfCare.providerOrganization [1..1] - You're always a person in the context of an organization, so the cardinality is 1..1. The name of the attribute is somewhat long, but we want to distinguish between a provider "Person" (which is a resource) and providerOrganization. Open for suggestions. [WGM201301 It's now present on Patient as provider]
  • SubjectOfCare.status - Are there any other states? We think not, so we will call this SubjectOfCare.active, which is a boolean. [WGM201301 It's now present on Patient]
  • confidentiality, CodeableConcept [0..*] - We keep it in 80%.

We declared it an extension on Soc in our telcon of 20120913 [WGM201301 Currently, confidentiality is in the resource, remove?]

  • deceasedDate, dateTime [0..1] - For SoC, this is in the 80%.

Is time of death *really* something common in registry systems? If it's not in the 80%, then the time should be relegated to an extension. (The fact these are combined into one attribute in the RIM should have no bearing on how we represent them in FHIR.) - Lloyd We said this was extension on Person in our telcon of 20120913 -- Ewout

  • multipleBirthInd [0..1] - We think 80%. We will not rename this (drop the "Ind" suffix), to keep in line with v3.

We put this on Person and called it multipleBirth in our telcon of 20120913 -- Ewout

  • mutlipleBirthOrder [0..1] - We think 80%, we decided to put it on SoC in telcon of 201200913 -- Ewout

My recommendation would thus be to go with "multipleBirth", presuming that's actually a common industry term. You could even consider the dual-attribute approach of multipleBirth[Boolean|Integer] allowing you to say "false", "true", or specify the sequence. (A sequence would imply multipleBirth = true). However, this is only an option, not a requirement and may be overly complex. -- Lloyd [WGM201301 It's now present on Patient as a boolean, however have we considered Lloyd's suggestion?]

  • PatientOfOtherProvider - information can be searched via Person resource

See Person.PatientOfOtherProvider for a discussion -- Ewout

  • BirthPlace (should be an extension of Person) In telcon on 20120917 we decided this is most likely an extension on SoC

SoC.ContactParty

See the discussion on Person.ContactParty, Person.Guardian, Person.CareGiver

Within personalContact all formal and informal relationships for the SoC to other people can be communicated. The personalContact refers to a Resource-id within a Resource type. Within the context of this SoC resource only the actual valid relationships are communicated. Changes in PersonalContacts have to be made via their own Resources. The following Resource types are documented by the PA Work Group:

  • ContactParty
  • CareGiver
  • Agent
  • Guardian
  • Guarantor
  • GroupMember

I think GroupMembership is dealt with using a separate Group resource -- Ewout

[WGM201301 I added these types to the valueset of Contact.relationship, verify this with WG]

Person.Citizen

Citizenship information for a person, including citizen identifier and effective time can be sent in the Citizen class. The nation that scopes the Citizen role, as identified by Nation.code, is mandatory.

Proposal: represent Citizen, a Role in v3, as an extension on Person:

Person.Citizenship [0..*]

  • identifier [0..1], HumanIdentifier (Citizen.id)
  • period [0..1], Period (Citizen.effectiveTime)
  • code, Coding [0..1] (Citizen.code) - qualification of legal status within a nation
  • nation, Coding [1..1] (Citizen.politicalNation.code) - The code is required, there's no separate 'name' attribute other than the display value of the Coding

Remarks: identifier has been limited to 0..1.

(20120917) TCON decision is to have this information as an extension and most likely to SubjectOfCare rather than Person. It is not likely that you record this info for Providers and the like


Changes

Changes after email discussions Lloyd/Grahame:

  • All associations to other classes replaced by attributes within SoC itself
  • Naming convention: lower camel case
  • Active replaced by status No it's not, in the current ballot, it's "active" Y/N

Changes from TCON 20121015:

  • Rename PertinentObservation -> OtherInformation - Not there, what's this? administrative stuff that cannot be put into extensions? If these are administrative observations: TELCON (20121004) This relation is not core
  • Rename PersonalRelationship -> PersonalContact (name to be discussed) - renamed to just "Contact". Since we renamed "contact" to "telecom" because "contact" seemed to mean "contact person", that sounded reasonable.
  • Remove recordLocation (not in the 80%) - Ok, removed
  • Rename CareGiver in ProviderOrganization to CareProvider (+ resource) - Provider is an extension, but more probable, it belongs to PC
  • Remove OtherId (attributes are already present in HumanId)

Changes from TCON 20121022:

  • Add Animal to the person. person itself is yet to be changed. [WGM201301 This is now indeed combined]