Difference between revisions of "RelatedPerson FHIR Resource Proposal"
Ewoutkramer (talk | contribs) |
|||
Line 41: | Line 41: | ||
==Scope of coverage== | ==Scope of coverage== | ||
− | Covers persons involved in healthcare, but that are not the target of healthcare, nor have a formal responsibility in the care process. | + | Covers persons involved in healthcare, but that are not the target of healthcare, nor have a formal responsibility in the care process. Typically these are friends, relatives or others with a personal or non-healthcare-specific professional relationship to the patient (e.g. attorney, guardian, etc.). For animal patients, relationships might include owner, trainer, etc. |
Line 56: | Line 56: | ||
==RIM scope== | ==RIM scope== | ||
− | + | Role[classCode=REL] | |
<!-- Identify the formal RIM mapping for the root concept of the resource. The expectation is that the RIM mapping will be sufficiently precise so as to not overlap with any other resource definition. --> | <!-- Identify the formal RIM mapping for the root concept of the resource. The expectation is that the RIM mapping will be sufficiently precise so as to not overlap with any other resource definition. --> | ||
==Resource appropriateness== | ==Resource appropriateness== | ||
− | + | These persons are of interest because they may have responsibility for healthcare decisions, require notification of healthcare events or be responsible for the capture of reporting of healthcare information, however the information to be captured and tracked about these persons differs from that typically recorded for Patients or Practitioners. Commonly captured using "next of kin" and similar structures | |
<!-- Does the resource meet the following characteristics? | <!-- Does the resource meet the following characteristics? | ||
Line 77: | Line 77: | ||
==Expected implementations== | ==Expected implementations== | ||
− | A subset of health information systems that keep track of identified related persons. | + | A subset of health information systems that keep track of identified related persons. Required by several resources used within CCDA |
<!--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. --> | ||
==Content sources== | ==Content sources== | ||
− | + | ROL, NK1 in v2, RelatedPerson in v3, possibly also affiliate specifications, OpenEHR | |
<!-- List all of the specifications (beyond those in the "standard" (FHIR_Design_Requirements_Sources) list of source specifications) that you’re planning to consult | <!-- List all of the specifications (beyond those in the "standard" (FHIR_Design_Requirements_Sources) list of source specifications) that you’re planning to consult | ||
Line 92: | Line 92: | ||
* A contact for a patient or organization | * A contact for a patient or organization | ||
* A neighbour bringing a patient to the hospital | * A neighbour bringing a patient to the hospital | ||
+ | * Owner of a horse | ||
<!-- 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.) --> | ||
Line 115: | Line 116: | ||
ewoutkramer | ewoutkramer | ||
<!-- Identify the userids who will require commit access to gForge to maintain the resource. (Ensure all users have registered for gForge.) --> | <!-- Identify the userids who will require commit access to gForge to maintain the resource. (Ensure all users have registered for gForge.) --> | ||
+ | |||
+ | ==Issues== | ||
+ | * Adjusted scope and rationale a bit, added one example |
Revision as of 13:55, 14 June 2013
Contents
- 1 RelatedPerson
- 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
- 1.13 Issues
RelatedPerson
Owning committee name
Contributing or Reviewing Work Groups
None
FHIR Resource Development Project Insight ID
925
Scope of coverage
Covers persons involved in healthcare, but that are not the target of healthcare, nor have a formal responsibility in the care process. Typically these are friends, relatives or others with a personal or non-healthcare-specific professional relationship to the patient (e.g. attorney, guardian, etc.). For animal patients, relationships might include owner, trainer, etc.
RIM scope
Role[classCode=REL]
Resource appropriateness
These persons are of interest because they may have responsibility for healthcare decisions, require notification of healthcare events or be responsible for the capture of reporting of healthcare information, however the information to be captured and tracked about these persons differs from that typically recorded for Patients or Practitioners. Commonly captured using "next of kin" and similar structures
Expected implementations
A subset of health information systems that keep track of identified related persons. Required by several resources used within CCDA
Content sources
ROL, NK1 in v2, RelatedPerson in v3, possibly also affiliate specifications, OpenEHR
Example Scenarios
- A patient's wife or husband
- A contact for a patient or organization
- A neighbour bringing a patient to the hospital
- Owner of a horse
Resource Relationships
None
Timelines
Considered for the sept 2013 DSTU ballot, but might be delayed until after that.
gForge Users
ewoutkramer
Issues
- Adjusted scope and rationale a bit, added one example