Return to PA Resource Development
- SubjectOfCare.identifier [1..*] - The cardinality is 1..* because we cannot imagine usecases where patient data is communicated without a patient identifier.
- SubjectOfCare.subject [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)
- 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.
- SubjectOfCare.status - Are there any other states? We think not, so we will call this SubjectOfCare.active, which is a boolean.
- confidentiality, CodeableConcept [0..*] - We keep it in 80%.
- deceasedDate, dateTime [0..1] - For SoC, this is in the 80%.
- multipleBirthInd [0..1] - We think 80%. We will not rename this (drop the "Ind" suffix), to keep in line with v3.
- mutlipleBirthOrder [0..1] - We think 80%, together with BirthInd.
- coverage, Resource(Coverage) [0..*] - We think Coverage is a separate Resource.
- personalContact, Resource(Any) [0..*]
- otherInformation, Resource(Any) [0..*]
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:
Classes taken from the V3 R_Patient universal CMET, except:
- Citizen -> Nation (should be extension of Person)
- PatientOfOtherProvider - information can be searched via Person resource
- BirthPlace (should be an extension of Person)
- Employee (should be its own resource)
- Student (should be its own resource)
OtherInformation can e.g. be used for communicating the following information related to the SoC:
- Administrative Observations
- Blood group and other clinical observations
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
Changes from TCON 20121015:
- Rename PertinentObservation -> OtherInformation
- Rename PersonalRelationship -> PersonalContact (name to be discussed)
- Remove recordLocation (not in the 80%)
- Rename CareGiver in ProviderOrganization to CareProvider (+ resource)
- Remove OtherId (attributes are already present in HumanId)
Changes from TCON 20121022:
- Add Animal to the person. person itself is yet to be changed.