International Patient Access
0.1.0 - draft

International Patient Access, published by HL7. This is not an authorized publication; it is the continuous build for version 0.1.0). This version is based on the current content of https://github.com/grahamegrieve/ipa-candidate/ and changes regularly. See the Directory of published versions

StructureDefinition: IPARelatedPerson

Minimum expectations for a RelatedPerson resource when accessed via a International Patient Access API

The official URL for this profile is: 

http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-relatedperson

This profile describes how applications fetch RelatedPerson resources that provide information about other individuals that are involved in the care of the patient.

Example Usage Scenarios:

A patient’s record is full of records of events or planned actions where the actor of various kinds (informer, carer, etc) is a person related to the patient somehow who is not a care provider. Typically these are parents or other family, or guardians of some kinds, but the kind of relationship is not restricted. Clients that retrieve patient records will find references to these related persons, and a Patient Access SHALL make it possible for a client to access these resources.

These resources may be inlined as contained resources - this is not unusual for RelatedPerson records, where the source systems do not keep identifying information, and often has either name or role (or sometimes both). If a server only uses contained resources for such resources, it need not support this API.

If, however, the server does keep identifying records for such related parties, the server SHOULD NOT use contained resources, as data analytics is much more useful on identified records. When a server does not use contained RelatedPerson resources, it SHALL support this API.

Clients access related person records using this call:

GET [url]/RelatedPerson/[id]

where id is found in some other resource that refers to a RelatedPerson. The result of this search is a RelatedPerson resource, or an error there is no resource the client can access for that id.

The RelatedPerson SHALL have either:

  • a name
  • a code for the type of relationship (e.g. ‘mother’)

If a code is present, it SHOULD have a text value for easy display by a client that does not understand the codes used for relationship (which can be highly variable across systems).

Servers may choose to provide additional information, or may be required to do so by national or other additional profiles on patient that apply in the servers context.

Servers are not required to support search functionality on RelatedPerson, but may do so. If they do, the search SHALL be limited to RelatedPerson resources that relate to the patient in scope. Typical search parameters a Server could choose to support would be name and relationship

Formal Views of Profile Content

Description of Profiles, Differentials, Snapshots and how the different presentations work.

This structure is derived from RelatedPerson

Summary

Mandatory: 1 element
Must-Support: 3 elements

This structure is derived from RelatedPerson

NameFlagsCard.TypeDescription & Constraintsdoco
.. RelatedPerson I0..*RelatedPersonA person that is related to a patient, but who is not a direct target of care
... id Σ0..1stringLogical id of this artifact
... meta ΣI0..1MetaMetadata about the resource
... implicitRules ?!ΣI0..1uriA set of rules under which this content was created
... text I0..1NarrativeText summary of the resource, for human interpretation
... contained 0..*ResourceContained, inline Resources
... extension I0..*ExtensionAdditional content defined by implementations
... modifierExtension ?!I0..*ExtensionExtensions that cannot be ignored
... identifier ΣI0..*IdentifierA human identifier for this person
... active ?!SΣI1..1booleanWhether this related person's record is in active use
rp-1: Either a name or a relationship SHALL be provided (or both)
... patient ΣI1..1Reference(Patient)The patient this person is related to
... relationship SΣI0..*CodeableConceptThe nature of the relationship
Binding: PatientRelationshipType (preferred)
... name SΣI0..*HumanNameA name associated with the person
... telecom ΣI0..*ContactPointA contact detail for the person
... gender ΣI0..1codemale | female | other | unknown
Binding: AdministrativeGender (required)
... birthDate ΣI0..1dateThe date on which the related person was born
... address ΣI0..*AddressAddress where the related person can be contacted or visited
... photo I0..*AttachmentImage of the person
... period I0..1PeriodPeriod of time that this relationship is considered valid
... communication I0..*BackboneElementA language which may be used to communicate with about the patient's health
.... id 0..1stringUnique id for inter-element referencing
.... extension I0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!ΣI0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... language I1..1CodeableConceptThe language which can be used to communicate with the patient about his or her health
Binding: CommonLanguages (preferred)
Max Binding: AllLanguages
.... preferred I0..1booleanLanguage preference indicator

doco Documentation for this format

This structure is derived from RelatedPerson

Summary

Mandatory: 1 element
Must-Support: 3 elements

Differential View

This structure is derived from RelatedPerson

Snapshot View

NameFlagsCard.TypeDescription & Constraintsdoco
.. RelatedPerson I0..*RelatedPersonA person that is related to a patient, but who is not a direct target of care
... id Σ0..1stringLogical id of this artifact
... meta ΣI0..1MetaMetadata about the resource
... implicitRules ?!ΣI0..1uriA set of rules under which this content was created
... text I0..1NarrativeText summary of the resource, for human interpretation
... contained 0..*ResourceContained, inline Resources
... extension I0..*ExtensionAdditional content defined by implementations
... modifierExtension ?!I0..*ExtensionExtensions that cannot be ignored
... identifier ΣI0..*IdentifierA human identifier for this person
... active ?!SΣI1..1booleanWhether this related person's record is in active use
rp-1: Either a name or a relationship SHALL be provided (or both)
... patient ΣI1..1Reference(Patient)The patient this person is related to
... relationship SΣI0..*CodeableConceptThe nature of the relationship
Binding: PatientRelationshipType (preferred)
... name SΣI0..*HumanNameA name associated with the person
... telecom ΣI0..*ContactPointA contact detail for the person
... gender ΣI0..1codemale | female | other | unknown
Binding: AdministrativeGender (required)
... birthDate ΣI0..1dateThe date on which the related person was born
... address ΣI0..*AddressAddress where the related person can be contacted or visited
... photo I0..*AttachmentImage of the person
... period I0..1PeriodPeriod of time that this relationship is considered valid
... communication I0..*BackboneElementA language which may be used to communicate with about the patient's health
.... id 0..1stringUnique id for inter-element referencing
.... extension I0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!ΣI0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... language I1..1CodeableConceptThe language which can be used to communicate with the patient about his or her health
Binding: CommonLanguages (preferred)
Max Binding: AllLanguages
.... preferred I0..1booleanLanguage preference indicator

doco Documentation for this format

 

Other representations of profile: Schematron

Terminology Bindings

Terminology Bindings

PathConformanceValueSet
RelatedPerson.languagepreferredCommonLanguages
Max Binding: AllLanguages
RelatedPerson.relationshippreferredPatientRelationshipType
RelatedPerson.genderrequiredAdministrativeGender
RelatedPerson.communication.languagepreferredCommonLanguages
Max Binding: AllLanguages

Constraints

Constraints

IdPathDetailsRequirements
rp-1RelatedPerson.activeEither a name or a relationship SHALL be provided (or both)
: name.exists() or relationship.exists()