Electronic Long-Term Services and Supports (eLTSS) Release 1 - US Realm
2.0.0 - STU2 United States of America flag

Electronic Long-Term Services and Supports (eLTSS) Release 1 - US Realm, published by HL7 International / Human and Social Services. This guide is not an authorized publication; it is the continuous build for version 2.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/eLTSS/ and changes regularly. See the Directory of published versions

eLTSS Dataset to FHIR Release 4

Page standards status: Informative

Contents:

This Page contains three tables to aid in FHIR representation and use of eLTSS data.

  • The R4 mapping table indicates where eLTSS DAM data elements are to be placed/found in FHIR.
  • The R4 Useful elements table details important accessory data elements in meeting the eLTSS use case.
  • The Units table provides guidance on using units for things such as 'visit/week.'

R4 mapping table
eLTSS Grouping eLTSS Data Element Name Data Element Definition (includes examples, expected list of values and usage note where applicable) FHIR R4 Resource Element(s) FHIR R4 Resource Element Cardinality (with US Core Constraints) Additional Mapping Details Important change
Beneficiary Demographics Person Name The name of the person whom the plan is for. CarePlan → subject(Patient)

Patient → name → family
Patient → name → given
Patient → name → text		 CarePlan
...subject(Patient) 1
......name 1..*
.........family 1
.........given 1..*
.........text 0..1		 1) Will use CarePlan → subject to reference the Patient for the care plan being developed. FHIR requires that CarePlan includes a subject.
2) given is used for both first name & MI, so need more than one.
3) family is a string with the person's surname.
4) text is a string that contains the full name of the person.
5) Per US Core 1.0.1, each Patient must have at least one name, and each name must include family and given.
Beneficiary Demographics Person Identifier A string of character(s) used to identify the person whom the plan is for.

This may be the Medicaid ID number where applicable.		 CarePlan → subject(Patient)

Patient → identifier → value		 CarePlan
...subject(Patient) 1
......identifier 1..*
.........value 1
.........system 1		 1) Will use CarePlan → subject to reference the Patient for the care plan being developed. FHIR requires that CarePlan includes a subject.
2) identifier is of type Identifier. value is a text element.
3) Per US Core 1.0.1, each Patient must have at least 1 identifier, and each identifier must include a value and system. system is the namespace for the identifier value.
Beneficiary Demographics Person Identifier Type The type of unique identifier used to identify the person whom the plan is for.
Values include: Medicaid Number, State ID, Medical Record Number, Other (free text)		 CarePlan → subject(Patient)

Patient → identifier → type		 CarePlan
...subject(Patient) 1
......identifier 1..*
.........type 0..1		 1) Will use CarePlan → subject to reference the Patient for the care plan being developed. FHIR requires that CarePlan includes a subject.
2) If we have the identifier, we need to be know the type.
3) type is a CodeableConcept with an extensible value set with values defined here.
Medical Record Number is available in the documented code list. LOINC includes Medicaid Number (45400-9) and Social Security Number (45396-9). State ID is covered by the "SB" (Social Beneficiary) code value documented in the FHIR codeset at http://hl7.org/fhir/identifier-type. "Other" can be handled with the text element that is part of the Codeable Concept.
Beneficiary Demographics Person Date of Birth The birth date of the person whom the plan is for. CarePlan → subject(Patient)

Patient → birthDate		 CarePlan
...subject(Patient) 1
......birthDate 0..1		 1) Will use CarePlan → subject to reference the Patient for the care plan being developed. FHIR requires that CarePlan includes a subject.
2) birthDate is in the form "1951-06-04".
Beneficiary Demographics Person Phone Number The primary phone number of the person whom the plan is for, or his/her legal representative, where applicable. CarePlan → subject(Patient)

Patient → telecom → system
Patient → telecom → value		 CarePlan
...subject(Patient) 1
......telecom 0..*
.........value 0..1
.........system 0..1		 1) Will use CarePlan → subject to reference the Patient for the care plan being developed. FHIR requires that CarePlan includes a subject.
2) telecom is of type ContactPoint which contains elements to populate for the phone number.
3) system is required by FHIR if value is provided, and can be: phone | fax | email | pager | url | sms | other. For the eLTSS phone number, system should be provided as "phone".
4) Per FHIR, phone # should be formatted according to ITU-T E.123, so "(555) 675 5745" or "+22 555 675 5745".
Beneficiary Demographics Person Address The address of the person whom the plan is for. CarePlan → subject(Patient)

Patient → address → line
Patient → address → city
Patient → address → state
Patient → address → postalCode
Patient → address → district
Patient → address → text		 CarePlan
...subject(Patient) 1
......address 0..*
.........line 0..*
.........city 0..1
.........state 0..1
.........postalCode 0..1
.........district 0..1
.........text 0..1		 1) Will use CarePlan → subject to reference the Patient for the care plan being developed. FHIR requires that CarePlan includes a subject.
2) text is the full (not broken out) address.
3) line includes street name, number and suffix (e.g. 123 Main St.).
4) Information such as apt #, floor & room #, etc. also go into line, generally as a separate data element.
5) district covers county.
Beneficiary Demographics Emergency
Contact Name		 The name of the individual or entity identified to contact in case of emergency. CarePlan → subject(Patient)

Patient → contact → relationship
Patient → contact → name → family
Patient → contact → name → given
Patient → contact → name → text		 CarePlan
...subject(Patient) 1
......contact 0..*
.........relationship 1..*
.........name 0..1
............family 0..1
............given 0..*
............text 0..1		 1) Will use CarePlan → subject to reference the Patient for the care plan being developed. FHIR requires that CarePlan includes a subject.
2) Emergency contact is indicated using a relationship value "C".
3) If contact is provided, relationship needs to be provided to indicate this is an emergency contact.
4) given is used for both first name & MI, so need more than one.
5) family is a string with the person's surname.
6) text is a string with the full name of the person.
Beneficiary Demographics Emergency
Contact Relationship		 The relationship (e.g., spouse, neighbor, guardian, daughter) of the individual identified to contact in case of emergency. CarePlan → subject(Patient)

Patient → contact → relationship		 CarePlan
...subject(Patient) 1
......contact 0..*
.........relationship 1..*		 1) Will use CarePlan → subject to reference the Patient for the care plan being developed. FHIR requires that CarePlan includes a subject.
2) Emergency contact is indicated using a relationship value "C".
Other contact codes can be found here: https://www.hl7.org/fhir/v2/0131/index.html
3) The emergency contact would have two relationship data elements, one to indicate that it is an emergency contact and one to indicate the relationship between the patient and the contact (such as "next-of-kin").
4) There are other value sets that could be used to provide more detail, for example daughter or neighbor. Can use the value set http://www.hl7.org/implement/standards/fhir/valueset-relatedperson-relationshiptype.html
Beneficiary Demographics Emergency
Contact Phone Number		 The primary phone number (and extension when applicable) of the individual or entity identified to contact in case of emergency. CarePlan → subject(Patient)

Patient → contact → telecom → system
Patient → contact → telecom → value		 CarePlan
...subject(Patient) 1
......contact 0..*
.........telecom 0..*
............value 0..1
............system 0..1		 1) Will use CarePlan → subject to reference the Patient for the care plan being developed. FHIR requires that CarePlan includes a subject.
2) telecom is of type ContactPoint which contains elements to populate for the phone number.
3) system is required if value is provided, and can be: phone, fax, email, pager, url, sms, or other.
4) Per FHIR, phone # should be formatted according to ITU-T E.123, so "(555) 675 5745" or "+22 555 675 5745".
Beneficiary Demographics Emergency Backup Plan Description of how to address unforeseen events, emergency health events, emergency events, problems with medical equipment and supplies, and unavailable staffing situations for critical services that put the person's health and safety at risk.

This can be included as free text or attachment.		 CarePlan [emergency backup plan]
→ subject(Patient)
CarePlan [emergency backup plan]
→ description
CarePlan [emergency backup plan]
→ partOf(CarePlan) ["main" Care Plan]
 CarePlan
...subject(Patient) 1
...description 0..1
...part of(CarePlan) 0..*
 1) The CarePlan resource containing the emergency backup plan refers to the "main" CarePlan resource, rather than the other way around, by using the emergency backup plan CarePlan → partOf data element to reference the "main" CarePlan data element.
2) FHIR requires that CarePlan includes a subject.
3) description contains the text of the Emergency Backup Plan if provided as text.
4) type indicates the kind of document, but the documented preferred LOINC value set does not include anything corresponding to an emergency backup plan. Therefore we can use the Codeable Concept's text data element to indicate "Emergency Backup Plan". (type is mandatory in FHIR 3.0.1, but optional in the R4 draft.)
Goals & Strengths Goal A statement of a desired result that the person wants to achieve. CarePlan → goal(Goal)

Goal → description → text		 CarePlan
...goal(Goal) 0..*
......description 1
.........text 1
......subject(Patient) 1		 1) Will use CarePlan → goal to reference the Goal for the care plan being developed.
2) description is required by both FHIR and US Core, and is a CodableConcept whose text element, per US Core, must include a text description of the goal.
3) Each goal should go into a separate Goal element so each can potentially reference a step or action(s), or a service(s) that addresses the goal.
4) A Goal can be referenced from a Step or Action or from a service. For a goal related to a step or action, use extension(pertainsToGoal). For a service request specific goal, also use extension(pertainsToGoal). Logically, these goals are exclusive to each other and the same goal isn't duplicated at both levels.
5) US Core requires the use of Goal → Subject to reference back to the Patient. 		Replaced use of CarePlan.activity.detail, and emphasized the extension pertainsToGoal
Goals & Strengths Step or Action A planned measurable step or action that needs to be taken to accomplish a goal identified by the person. CarePlan → activity
→ reference(Resource) → note
→ text → extension(pertainsToGoal)		 CarePlan
...activity 0..*
......reference(Resource) 0..1
.........note 0..*
............text 1
.........extension(pertainsToGoal)		 1) CarePlan includes activity → reference, which can be a reference to ServiceRequest, Task or other Resource.
2) ServiceRequest would be used when the Step or Action is a task under a service. If the Step or Action is an informal support or an activity being undertaken by the patient/care recipient, the Task Resource, similar to a Patient Task used in the Gravity SDOH IG, can be used.
3) activity → reference(Resource) is linked to the Goal the step or action addresses through the pertainsToGoal Extension in the referenced activity.
4) activity → reference(Resource) includes a performer, author, participant with type or other data element that can be used to reference who is responsible for performing the step or action, such as to indicate that the person or a related person is responsible.
5) text is where the Step or Action text would be provided.
6) text is required by FHIR if note is provided.
7) Note that a stated goal may lead directly to a service, and not necessarily to an explicit Step or Action. For example, a person's goal could be to attend church regularly, and this would be achieved through a transportation service.		 Replaced use of CarePlan.activity.detail, and emphasized the extension pertainsToGoal
Goals & Strengths Strength A favorable attribute of oneself, his/her support network, environment and/or elements of his/her life. CarePlan → supportingInfo(Observation)

Observation → valueString
Observation → code → coding → code Observation → code → coding → system		 CarePlan
...supportingInfo(Observation) 0..*
......valueString 0..1
......code 1
........coding 0..*
..........code 0..1
............system 0..1
 1) Will use CarePlan → supportingInfo to reference the Observation containing the Strength.
2) code is required by FHIR, and is a CodeableConcept where coding → code can be set to "Strength" with the corresponding NEW code → system "http://hl7.org/us/eLTSS/CodeSystem/eltss-observation-code".
3) valueString is where the Strength text would be provided.
Person Centered Planning Assessed Need The clinical and/or community-based necessity or desire as identified through an assessment that should be addressed by a service. CarePlan → addresses(Condition)

Condition → code → text
Condition → category		 CarePlan
...addresses(Condition) 0..*
......code 1
.........text 0..1
......category 1..*		 1) Will use CarePlan → addresses to reference the Condition(s) for the care plan being developed.
2) code is required by US Core and is a CodeableConcept which per US Core is bound to the extensible Problem Value Set. That value set is based on SNOMED-CT and includes very specific values that do not line up with assessed needs. Per US Core's documentation on extensible CodeableConcepts, the CodeableConcept's text element can be used "if no suitable codes exist", so we can use the text element for the assessed need. Additionally, the Gravity SDOH FHIR IG has a value set of SDOH conditions.
3) Each assessed need should go into a separate Condition element so each can potentially be linked to a service(s) that addresses it.
4) Category is required by US Core and is a CodeableConcept which per US Core is bound to the extensible US Core Condition Category Codes value set (http://hl7.org/fhir/ValueSet/condition-category) which has values: problem-list-item, encounter-diagnosis and health-concern. The additional 'assessed-need' code can be used to relate that the Condition instance is about the clinical and/or community-based necessity or desire, as identified through an assessment, that should be addressed by a service. Consider also using the US Core 6.1.0 screening-assessment categories https://www.hl7.org/fhir/us/core/ValueSet-us-core-screening-assessment-condition-category.html.
5) An "assessed need" condition can refer to another condition via the condition-dueTo extension.		 Now using US CORE Condition Category value set element "Health Concern"
Person Centered Planning Person Setting Choice Indicator Indicator that reflects the setting in which the person resides is chosen by the individual. CarePlan → supportingInfo(Questionnaire)

Questionnaire → item → linkID
Questionnaire → item → text
Questionnaire → item → type
------------------------------------------
QuestionnaireResponse
→ questionnaire(Questionnaire)
QuestionnaireResponse → item → linkID
QuestionnaireResponse → item → answer
→ valueBoolean
 CarePlan
...supportingInfo(Questionnaire) 0..*
......item 0..*
.........linkID 1
.........text 0..1
.........type 1
------------------------
QuestionnaireResponse
...questionnaire(Questionnaire) 0..1
...item 0..*
......linkID 1
......answer 0..*
.........valueBoolean 0..1		 1) Will use CarePlan → supportingInfo to reference the Questionnaire for the care plan being developed.
2) QuestionnaireResponse references the Questionnaire.
3) QuestionnaireResponse and Questionnaire both include one or more item elements, where each item documents a question or answer to a question.
4) item includes a mandatory linkID used to link the response to the question it applies to.
5) valueBoolean is the actual response to the question.
6) text is the actual text of the question in the Questionnaire.
7) type is required by FHIR and indicates what kind of question this is. Values must come from the QuestionnaireItemType value set which includes: group, display, boolean, decimal, integer, date, dateTime, etc. The value "boolean" would apply here. Boolean "true" would indicate "yes".
Person Centered Planning Person Setting Choice Options The alternative home and community-based settings that were considered by the individual. CarePlan → supportingInfo(Questionnaire)

Questionnaire → item → linkID
Questionnaire → item → text
Questionnaire → item → type
------------------------------------------
QuestionnaireResponse
→ questionnaire(Questionnaire)
QuestionnaireResponse → item → linkID
QuestionnaireResponse → item → answer
→ valueString
 CarePlan
...supportingInfo(Questionnaire) 0..*
......item 0..*
.........linkID 1
.........text 0..1
.........type 1
------------------------
QuestionnaireResponse
...questionnaire(Questionnaire) 0..1
...item 0..*
......linkID 1
......answer 0..*
.........valueString 0..1		 1) Will use CarePlan → supportingInfo to reference the Questionnaire for the care plan being developed.
2) QuestionnaireResponse references the Questionnaire.
3) QuestionnaireResponse and Questionnaire both include one or more item elements, where each item documents a question or answer to a question.
4) item includes a mandatory linkID used to link the response to the question it applies to.
5) valueString is the actual text of the response to a question.
6) text is the actual text of the question in the Questionnaire.
7) type is required by FHIR and indicates what kind of question this is. Values must come from the QuestionnaireItemType value set which includes: group, display, boolean, decimal, integer, date, dateTime, etc. The values "string" (for a few words or short sentence) or "text" (potentially multi-paragraph) would apply here.
Person Centered Planning Plan Monitor Name The name of the person responsible for monitoring the plan. CarePlan → encounter (Encounter)

Encounter → episodeOfCare(EpisodeOfCare)

EpisodeOfCare → careManager(Practitioner)

Practitioner → name → family
Practitioner → name → given
Practitioner → name → text		 CarePlan
...encounter(Encounter) 0..1
...... episodeOfCare(EpisodeOfCare)0..1
.........careManager(Practitioner) 0..1
............name 0..*
...............family 0-1
................given 0-*
................text 0-1		 1) Will use CarePlan → encounter to reference the EpisodeOfCare that defines the plan monitor (care manager) for the plan.
2) EpisodeOfCare → careManager references the Practitioner who is monitoring the plan.
3) given is used for both first name & MI, so need more than one.
4) family is a string with the person's surname.
5) text is a string that contains the full name of the person.
6) The values for Plan Monitor Name and Plan Monitor Printed Name would include the same information.
Person Centered Planning Plan Monitor Phone Number The primary phone number (and extension when applicable) of the plan monitor. CarePlan → encounter (Encounter)

Encounter → episodeOfCare(EpisodeOfCare)

EpisodeOfCare → careManager(Practitioner)

Practitioner → telecom → system
Practitioner → telecom → value		 CarePlan
...encounter(Encounter) 0..1
...... episodeOfCare(EpisodeOfCare)0..1
.........careManager(Practitioner) 0..1
............telecom 0..*
...............system 0..1
................value 0..1		 1) Will use CarePlan → encounter to reference the EpisodeOfCare that defines the plan monitor (care manager) for the plan.
2) EpisodeOfCare → careManager references the Practitioner who is monitoring the plan.
3) telecom is of type ContactPoint (https://www.hl7.org/fhir/datatypes.html#contactpoint) which contains elements to populate for the phone number.
4) system is required if value is provided, and can be: phone, fax, email, pager, url, sms, other.
5) Per FHIR, phone # should be formatted according to ITU-T E.123, so "(555) 675 5745" or "+22 555 675 5745".
Person Centered Planning Preference Presents the person's personal thoughts about something he or she feels is relevant to his or her life experience and may be pertinent when planning. CarePlan → supportingInfo(Observation)

Observation → valueString
Observation → code → coding → code
Observation → code → coding → system
 CarePlan
...supportingInfo(Observation) 0..*
......valueString 0..1
......code 1
.........coding 0..*
............code 0..1
............system 0..1		 1) Will use CarePlan → supportingInfo to reference the Observation containing the Preference.
2) code is required by FHIR and is a CodeableConcept where coding → code can be set to "Preference" with the corresponding NEW code -> system "http://hl7.org/us/eLTSS/CodeSystem/eltss-observation-code".
3) valueString is where the Preference text would be provided.
Person Centered Planning Service Options Given Indicator States whether or not the person was given a choice of services outlined in the plan. CarePlan → supportingInfo(Questionnaire)

Questionnaire → item → linkID
Questionnaire → item → text
Questionnaire → item → type
------------------------------------------
QuestionnaireResponse
→ questionnaire(Questionnaire)
QuestionnaireResponse → item → linkID
QuestionnaireResponse → item → answer
→ valueBoolean
 CarePlan
...supportingInfo(Questionnaire) 0..*
......item 0..*
.........linkID 1
.........text 0..1
.........type 1
------------------------
QuestionnaireResponse
...questionnaire(Questionnaire) 0..1
...item 0..*
......linkID 1
......answer 0..*
.........valueBoolean 0..1		 1) Will use CarePlan → supportingInfo to reference the Questionnaire for the care plan being developed.
2) QuestionnaireResponse references the Questionnaire.
3) QuestionnaireResponse and Questionnaire both include one or more item elements, where each item documents a question or answer to a question.
4) item includes a mandatory linkID used to link the response to the question it applies to.
5) valueBoolean is the actual response to the question.
6) text is the actual text of the question in the Questionnaire.
7) type is required by FHIR and indicates what kind of question this is. Values must come from the QuestionnaireItemType value set which includes: group, display, boolean, decimal, integer, date, dateTime, etc. The value "boolean" would apply here. Boolean "true" would indicate "yes".
Person Centered Planning Service Selection Indicator States whether or not the person participated in the selection of the services outlined in the plan. CarePlan → supportingInfo(Questionnaire)

Questionnaire → item → linkID
Questionnaire → item → text
Questionnaire → item → type
------------------------------------------
QuestionnaireResponse
→ questionnaire(Questionnaire)
QuestionnaireResponse → item → linkID
QuestionnaireResponse → item → answer
→ valueBoolean
 CarePlan
...supportingInfo(Questionnaire) 0..*
......item 0..*
.........linkID 1
.........text 0..1
.........type 1
------------------------
QuestionnaireResponse
...questionnaire(Questionnaire) 0..1
...item 0..*
......linkID 1
......answer 0..*
.........valueBoolean 0..1		 1) Will use CarePlan → supportingInfo to reference the Questionnaire for the care plan being developed.
2) QuestionnaireResponse references the Questionnaire.
3) QuestionnaireResponse and Questionnaire both include one or more item elements, where each item documents a question or answer to a question.
4) item includes a mandatory linkID used to link the response to the question it applies to.
5) valueBoolean is the actual response to the question.
6) text is the actual text of the question in the Questionnaire.
7) type is required by FHIR and indicates what kind of question this is. Values must come from the QuestionnaireItemType value set which includes: group, display, boolean, decimal, integer, date, dateTime, etc. The value "boolean" would apply here. Boolean "true" would indicate "yes".
Person Centered Planning Service Plan Agreement Indicator States whether or not the person agrees to the services outlined in the plan. CarePlan → supportingInfo(Questionnaire)

Questionnaire → item → linkID
Questionnaire → item → text
Questionnaire → item → type
------------------------------------------
QuestionnaireResponse
→ questionnaire(Questionnaire)
QuestionnaireResponse → item → linkID
QuestionnaireResponse → item → answer
→ valueBoolean
 CarePlan
...supportingInfo(Questionnaire) 0..*
......item 0..*
.........linkID 1
.........text 0..1
.........type 1
------------------------
QuestionnaireResponse
...questionnaire(Questionnaire) 0..1
...item 0..*
......linkID 1
......answer 0..*
.........valueBoolean 0..1		 1) Will use CarePlan → supportingInfo to reference the Questionnaire for the care plan being developed.
2) QuestionnaireResponse references the Questionnaire.
3) QuestionnaireResponse and Questionnaire both include one or more item elements, where each item documents a question or answer to a question.
4) item includes a mandatory linkID used to link the response to the question it applies to.
5) valueBoolean is the actual response to the question.
6) text is the actual text of the question in the Questionnaire.
7) type is required by FHIR and indicates what kind of question this is. Values must come from the QuestionnaireItemType value set which includes: group, display, boolean, decimal, integer, date, dateTime, etc. The value "boolean" would apply here. Boolean "true" would indicate "yes".
Person Centered Planning Service Provider Options Given Indicator States whether or not the person was offered a choice of providers for each service. CarePlan → supportingInfo(Questionnaire)

Questionnaire → item → linkID
Questionnaire → item → text
Questionnaire → item → type
------------------------------------------
QuestionnaireResponse
→ questionnaire(Questionnaire)
QuestionnaireResponse → item → linkID
QuestionnaireResponse → item → answer
→ valueBoolean
 CarePlan
...supportingInfo(Questionnaire) 0..*
......item 0..*
.........linkID 1
.........text 0..1
.........type 1
------------------------
QuestionnaireResponse
...questionnaire(Questionnaire) 0..1
...item 0..*
......linkID 1
......answer 0..*
.........valueBoolean 0..1		 1) Will use CarePlan → supportingInfo to reference the Questionnaire for the care plan being developed.
2) QuestionnaireResponse references the Questionnaire.
3) QuestionnaireResponse and Questionnaire both include one or more item elements, where each item documents a question or answer to a question.
4) item includes a mandatory linkID used to link the response to the question it applies to.
5) valueBoolean is the actual response to the question.
6) text is the actual text of the question in the Questionnaire.
7) type is required by FHIR and indicates what kind of question this is. Values must come from the QuestionnaireItemType value set which includes: group, display, boolean, decimal, integer, date, dateTime, etc. The value "boolean" would apply here. Boolean "true" would indicate "yes".
Person Centered Planning Service Provider Selection Agreement Indicator States whether or not the person feels he/she made an informed choice in selecting the provider for each service. CarePlan → supportingInfo(Questionnaire)

Questionnaire → item → linkID
Questionnaire → item → text
Questionnaire → item → type
------------------------------------------
QuestionnaireResponse
→ questionnaire(Questionnaire)
QuestionnaireResponse → item → linkID
QuestionnaireResponse → item → answer
→ valueBoolean
 CarePlan
...supportingInfo(Questionnaire) 0..*
......item 0..*
.........linkID 1
.........text 0..1
.........type 1
------------------------
QuestionnaireResponse
...questionnaire(Questionnaire) 0..1
...item 0..*
......linkID 1
......answer 0..*
.........valueBoolean 0..1		 1) Will use CarePlan → supportingInfo to reference the Questionnaire for the care plan being developed.
2) QuestionnaireResponse references the Questionnaire.
3) QuestionnaireResponse and Questionnaire both include one or more item elements, where each item documents a question or answer to a question.
4) item includes a mandatory linkID used to link the response to the question it applies to.
5) valueBoolean is the actual response to the question.
6) text is the actual text of the question in the Questionnaire.
7) type is required by FHIR and indicates what kind of question this is. Values must come from the QuestionnaireItemType value set which includes: group, display, boolean, decimal, integer, date, dateTime, etc. The value "boolean" would apply here. Boolean "true" would indicate "yes".
Plan Information Plan Effective Date The date upon which the plan goes into effect.

Start date is required, end date is optional.		 CarePlan → period → start
CarePlan → period → end		 CarePlan 0..*
...period 0..1
......start 1
......end 0..1		 1) period includes a start and an end element, which are both dateTime formats which can be date, date-time or partial date (e.g. just year or year + month).
2) start is required by eLTSS.
Plan Signatures Person Signature The depiction of the person's signature as proof of identity and intent for the plan. CarePlan → supportingInfo(Contract)

Contract → signer → type
Contract → signer → signature → data
Contract → signer → signature → type
Contract → signer → signature
→ who(Practitioner | PractitionerRole |
RelatedPerson | Patient | Device |
Organization)		 CarePlan
...supportingInfo(Contract) 0..*
......signer 0..*
.........type 1
.........signature 1..*
............data 0..1
............type 1
............who(Practitioner | PractitionerRole |
RelatedPerson | Patient | Device |
Organization) 1		 1) Will use CarePlan → supportingInfo to reference the Contract containing the signatures, names, etc.
2) Can use a single Contract element to contain all signatures.
3) signer requires the signature and a type that indicates the contract signatory role.
4) FHIR includes a preferred coding for contract signatory roles, which map well to the eLTSS signatories. The primary one for the patient/beneficiary is "PAT" (patient), although implementers may use others as well. However, implementers must realize that type may be used to differentiate between the patient, service provider, planner, etc. so there need to be distinct role types utilized.
5) data is the actual signature content (XML DigSig. JWT, picture, etc.)
6) signature requires it's own type element that indicates why the entity signed the contract, and FHIR provides a preferred code list. Would probably use "1.2.840.10065.1.12.1.7" which represents "consent signature" in this case.
7) signature requires a who to indicate who signed, which can be a Patient, Organization, Practitioner, PrationerRole, RelatedPerson or Device, although in this case it would be the Patient.
Plan Signatures Person Printed Name The printed or typed name of the person. CarePlan → supportingInfo(Contract)

Contract → signer → party(Patient)		 CarePlan
...supportingInfo(Contract) 0..*
......signer 0..*
.........party(Patient) 1		 1) Will use CarePlan → supportingInfo to reference the Contract containing the signatures, names, etc.
2) In this case, party is a reference to the Patient, and Patient is already documented above to include a name.
Plan Signatures Person Signature Date The date the person signed the plan. CarePlan → supportingInfo(Contract)

Contract → signer → signature → when		 CarePlan
...supportingInfo(Contract) 0..*
......signer 0..*
.........signature 1..*
............when 1		 1) Will use CarePlan → supportingInfo to reference the Contract containing the signatures, names, etc.
2) when is required by FHIR, and indicates when the signature was created.
3) when is an instance type. An instant in time - known at least to the second and always includes a time zone. Note: This is intended for precisely observed times (typically system logs etc.), and not human-reported times - for them, use date and dateTime. instant is a more constrained dateTime.
Plan Signatures Guardian / Legal Representative Signature The depiction of the guardian or legally authorized representative's signature as proof of identity and intent for the plan. CarePlan → supportingInfo(Contract)

Contract → signer → type
Contract → signer → signature → data
Contract → signer → signature → type
Contract → signer → signature
→ who(Practitioner | PractitionerRole |
RelatedPerson | Patient | Device |
Organization)		 CarePlan
...supportingInfo(Contract) 0..*
......signer 0..*
.........type 1
.........signature 1..*
............data 0..1
............type 1
............who(Practitioner | PractitionerRole |
RelatedPerson | Patient | Device |
Organization) 1		 1) Will use CarePlan → supportingInfo to reference the Contract containing the signatures, names, etc.
2) Can use a single Contract element to contain all signatures.
3) signer requires the signature and a type that indicates the contract signatory role.
4) FHIR includes a preferred coding for contract signatory roles, which map well to the eLTSS signatories. There are multiple values that may be used depending on how states want to map. For example, the list includes: "POWATT" (power of attorney), "GUARD" (guardian), "HPOWATT" (healthcare power of attorney), etc. However, implementers must realize that type may be used to differentiate between the patient, service provider, planner, etc. so there need to be distinct role types utilized.
5) data is the signature content (XML DigSig. JWT, picture, etc.)
6) signature requires it's own type element that indicates why the entity signed the contract, and FHIR provides a preferred value set. Would probably use "1.2.840.10065.1.12.1.7" which represents "consent signature" in this case.
7) signature requires a who to indicate who signed, which can be a Patient, Organization, Practitioner, PractitionerRole, RelatedPerson or Device although in this case it would be the RelatedPerson.
Plan Signatures Guardian / Legal Representative Printed Name The printed or typed name of the guardian or legally authorized representative. CarePlan → supportingInfo(Contract)

Contract → signer → party(RelatedPerson)		 CarePlan
...supportingInfo(Contract) 0..*
......signer 0..*
.........party(RelatedPerson) 1		 1) Will use CarePlan → supportingInfo to reference the Contract containing the signatures, names, etc.
2) In this case, party is a reference to a RelatedPerson, and RelatedPatient includes a name.
Plan Signatures Guardian / Legal Representative Signature Date The date the guardian or legally authorized representative signed the plan. CarePlan → supportingInfo(Contract)

Contract → signer → signature → when		 CarePlan
...supportingInfo(Contract) 0..*
......signer 0..*
.........signature 1..*
............when 1		 1) Will use CarePlan → supportingInfo to reference the Contract containing the signatures, names, etc.
2) when is required by FHIR, and indicates when the signature was created.
3) when is an instance type. An instant in time - known at least to the second and always includes a time zone. Note: This is intended for precisely observed times (typically system logs etc.), and not human-reported times - for them, use date and dateTime. instant is a more constrained dateTime.
Plan Signatures Support Planner Signature The depiction of the support planner's signature as proof of identity and intent for the plan. CarePlan → supportingInfo(Contract)

Contract → signer → type
Contract → signer → signature → data
Contract → signer → signature → type
Contract → signer → signature
→ who(Practitioner | PractitionerRole | Organization
RelatedPerson | Patient |
Organization)		 CarePlan
...supportingInfo(Contract) 0..*
......signer 0..*
.........type 1
.........signature 1..*
............data 0..1
............type 1
............who(Practitioner |PractitionerRole | Organization
RelatedPerson | Patient |
Organization) 1		 1) Will use CarePlan → supportingInfo to reference the Contract containing the signatures, names, etc.
2) Can use a single Contract element to contain all signatures.
3) signer requires the signature and a type that indicates the contract signatory role.
4) FHIR includes a preferred coding for contract signatory roles, which map well to the eLTSS signatories. There are multiple values that may be used depending on how states want to map. For example, the list includes "AUT" (author) which aligns with author being the support planner for other eLTSS Dataset elements. However other role types may be appropriate as well such as "GUAR" (guarantor). However, implementers must realize that type may be used to differentiate between the patient, service provider, planner, etc. so there need to be distinct role types utilized.
5) data is the actual signature content (XML DigSig. JWT, picture, etc.)
6) signature requires it's own type element that indicates why the entity signed the contract, and FHIR provides a preferred value set, in this case could use "1.2.840.10065.1.12.1.1" for "Author's Signature".
7) signature requires a who to indicate who signed, which can be a Patient, Organization, Practitioner, PractitionerRole, RelatedPerson or Device.
Plan Signatures Support Planner Printed Name The printed or typed name of the support planner. CarePlan → supportingInfo(Contract)

Contract → signer → party(Practitioner|PractitionerRole|Organization)		 CarePlan
...supportingInfo(Contract) 0..*
......signer 0..*
.........party(Practitioner|PractitionerRole|Organization)		 1) Will use CarePlan → supportingInfo to reference the Contract containing the signatures, names, etc.
2) In this case, party is a reference to a Practitioner, PractitionerRole or Organization (for cases when the Organization of the SupportPlanner is needed), and Practitioner and Organization includes a name.
3) The values for Support Planner Name and Support Planner Printed Name would include the same information.
Plan Signatures Support Planner Signature Date The date the support planner signed the plan. CarePlan → supportingInfo(Contract)

Contract → signer → signature → when		 CarePlan
...supportingInfo(Contract) 0..*
......signer 0..*
.........signature 1..*
............when 1		 1) Will use CarePlan → supportingInfo to reference the Contract containing the signatures, names, etc.
2) when is required by FHIR, and indicates when the signature was created.
3) when is an instance type. An instant in time - known at least to the second and always includes a time zone. Note: This is intended for precisely observed times (typically system logs etc.), and not human-reported times - for them, use date and dateTime. instant is a more constrained dateTime.
Plan Signatures Service Provider Signature The depiction of the service provider's signature as proof they agree to the services they will provide. CarePlan → supportingInfo(Contract)

Contract → signer → type
Contract → signer → signature → data
Contract → signer → signature → type
Contract → signer → signature
→ who(Practitioner | PractitionerRole |
RelatedPerson | Patient | Device |
Organization)		 CarePlan
...supportingInfo(Contract) 0..*
......signer 0..*
.........type 1
.........signature 1..*
............data 0..1
............type 1
............who(Practitioner |PractitionerRole |
RelatedPerson | Patient | Device |
Organization) 1		 1) Will use CarePlan → supportingInfo to reference the Contract containing the signatures, names, etc.
2) Can use a single Contract element to contain all signatures.
3) signer requires the signature and a type that indicates the contract signatory role.
4) FHIR includes a preferred coding for contract signer roles, which map well to the eLTSS signatories. There are multiple values that may be used depending on how states want to map. The list includes "HPROV" (healthcare provider) which may be the best fit here, although others may be applicable. However, implementers must realize that type may be used to differentiate between the patient, service provider, planner, etc. so there need to be distinct role types utilized.
5) data is the actual signature content (XML DigSig. JWT, picture, etc.)
6) signature requires it's own type element that indicates why the entity signed the contract, and FHIR provides a preferred value set. In this case would probably use "1.2.840.10065.1.12.1.3" for "Co-participant's Signature".
7) signature requires a who to indicate who signed, which can be a Patient, Organization, Practitioner, PractitionerRole, RelatedPerson or Device.
Plan Signatures Service Provider Printed Name The printed or typed name of the service provider. CarePlan → supportingInfo(Contract)

Contract → signer → party(Organization |
Patient | Practitioner | PractitionerRole | RelatedPerson)		 CarePlan
...supportingInfo(Contract) 0..*
......signer 0..*
.........party(Organization | Patient |
Practitioner | PractitionerRole | RelatedPerson) 1		 1) Will use CarePlan → supportingInfo to reference the Contract containing the signatures, names, etc.
2) party is a reference to an Organization, Patient, Practitioner, PractitionerRole or RelatedPerson, all of which include a name. (Patient may not make sense in the context of a service provided by a care plan, but is allowed in FHIR.)
3) The values for Service Provider Name and Service Provider Printed Name would include the same information.
Plan Signatures Service Provider Signature Date The date the service provider signed the plan. CarePlan → supportingInfo(Contract)

Contract → signer → signature → when		 CarePlan
...supportingInfo(Contract) 0..*
......signer 0..*
.........signature 1..*
............when 1		 1) Will use CarePlan → supportingInfo to reference the Contract containing the signatures, names, etc.
2) when is required by FHIR, and indicates when the signature was created.
3) when is an instance type. An instant in time - known at least to the second and always includes a time zone. Note: This is intended for precisely observed times (typically system logs etc.), and not human-reported times - for them, use date and dateTime. instant is a more constrained dateTime.
Risks Identified Risk An aspect of a person's life, behavior, environmental exposure, personal characteristic, Social determinants of health, or other barrier that increases the likelihood of disease, condition, injury to self or others, or interaction with the criminal justice system. CarePlan → supportingInfo(RiskAssessment)

RiskAssessment → prediction → outcome
→ coding → code
RiskAssessment → prediction → outcome
→ coding → system
RiskAssessment → prediction → outcome
→ text		 CarePlan
...supportingInfo(RiskAssessment) 0..*
......prediction 0..*
.........outcome 0..1
............coding 0..*
...............code 0..1
...............system 0..1
............text 0..1		 1) Will use CarePlan → supportingInfo to reference the RiskAssessment containing the Identified Risk.
2) outcome is a Codeable Concept that includes a text element that can be used for the identified risk itself if no appropriate coding is available. (outcome was mandatory prior to R4 version 3.3.0.)
3) prediction describes the expected outcome for the subject, and is the "prediction" of the risk.
Risks Risk Management Plan Description of planned activities to minimize identified risks that endanger the person's health and safety.

This can be included as free text or attachment.		 CarePlan → supportingInfo(RiskAssessment)

RiskAssessment → mitigation
RiskAssessment → extension(RiskAssessment Mitigation Plan)

 CarePlan
...supportingInfo(RiskAssessment) 0..*
......mitigation 0..1
...RiskAssessment
...extension(RiskAssessment MitigationPlan)		 1) Will use CarePlan → supportingInfo to reference the RiskAssessment containing the Risk Management Plan.
2) mitigation is a string and would contain the free text Risk Management Plan.
3) The new RiskAssessment -> extension -> RiskAssessment Mitigation Plan which is a DocumentReference resource would be used if the Risk Management Plan is being provided as an attachment rather than as text.
Service Information Service Name Identifies the paid and/or non-paid service provided to a person.
Include the code and display name plus any modifiers when a coding system (e.g., Healthcare Common Procedure Coding System (HCPCS), Home Health Revenue Codes) is used.		 CarePlan → activity
→ reference(ServiceRequest)

ServiceRequest → code → text
ServiceRequest → code → coding → code
ServiceRequest → code → coding → system		 CarePlan
...activity 0..*
......reference(ServiceRequest) 0..1
.........code 0..1
............text 0..1
............coding 0..1
...............code 0..1
...............system 0..1		 1) activity is part of CarePlan, so no references are required to link the two.
2) coding → code is the "code plus any modifiers" described in the eLTSS Dataset data element definition. system identifies the code system from which the code is from. For HCPCS, the system value can be set to "https://www.cms.gov/Medicare/Coding/MedHCPCSGenInfo/".
3) text is the "display name" described in the eLTSS Dataset data element definition.
4) Note that modifiers for CPT & HCPCS are appended to the code using a dash. So the entire code plus the modifier is a single string.
Service Information Self-Directed Service Indicator Indicates whether the individual chose to self-direct the service. CarePlan → activity
→ reference(ServiceRequest)

ServiceRequest → extension → url
ServiceRequest → extension
→ valueCodeableConcept → text		 CarePlan
...activity 0..*
......reference(ServiceRequest) 0..1
.........extension 0..*
............url 0..1
............valueCodeableConcept 0..1
...............text 0..1		 1) activity is part of CarePlan, so no references are required to link the two.
2) The procedure-directedBy extension is indicated by populating the url data attribute with the value "http://hl7.org/fhir/StructureDefinition/procedure-directedBy".
3) The text data element can be populated with the value "self" to indicate that this service is self-directed. Other values could be provided to indicate that someone else is directing the service. This is in addition to populating the proper element in the Resource indicated in CarePlan.activity.reference such as Task, Observation etc to indicate who is responsible or carried out the task.
Service Information Service Start Date The start date of the service being provided. CarePlan → activity
→ reference(ServiceRequest)

ServiceRequest → occurrenceTiming
→ boundsPeriod → start		 CarePlan
...activity 0..*
......reference(ServiceRequest) 0..1
.........occurrenceTiming 0..1
............boundsPeriod 0..1
...............start 0..1		 1) activity is part of CarePlan, so no references are required to link the two.
2) start is in dateTime format which can be date, date-time or partial date (e.g. just year or year + month).
Service Information Service End Date The end date of the service being provided. CarePlan → activity
→ reference(ServiceRequest)

ServiceRequest → occurrenceTiming
→ boundsPeriod → end		 CarePlan
...activity 0..*
......reference(ServiceRequest) 0..1
.........occurrenceTiming 0..1
............boundsPeriod 0..1
...............end 0..1		 1) activity is part of CarePlan, so no references are required to link the two.
2) end is in dateTime format which can be date, date-time or partial date (e.g. just year or year + month).
Service Information Service Delivery Address The address where service delivery will take place if service will not be provided at the person's address. CarePlan → activity
→ reference(ServiceRequest)

ServiceRequest → locationReference(Location)

Location → address → line
Location → address → city
Location → address → district
Location → address → state
Location → address → postalCode
Location → address → text
Location → description		 CarePlan
...activity 0..*
......reference(ServiceRequest) 0..1
.........locationReference(Location) 0..*
............address 0..*
...............line 0..*
...............city 0..1
...............district 0..1
...............state 0..1
...............postalCode 0..1
...............text 0..1
............description 0..1		 1) activity is part of CarePlan, so no references are required to link the two.
2) text is the full (not broken out) address.
3 line includes street name, number and suffix (e.g. 123 Main St.).
4) Information such as apt #, floor & room #, etc. also go into line, generally as a separate data element.
5) district covers county.
6) description can be used when the location is not a specific address, such as when support is being provided at a general location, such as someone providing assistance wherever the recipient grocery shops.
Service Information Service Comment Additional information related to the service being provided. This field could capture additional information of the frequency of the service, how the person wants the service delivered and only used when the comment provides additional detail of the service not already handled by another element.
CarePlan → activity
→ reference(ServiceRequest)

ServiceRequest → note → text		 CarePlan
...activity 0..*
......reference(ServiceRequest) 0..1
.........note 0..*
............text 1		 1) activity is part of CarePlan, so no references are required to link the two.
2) text is required by FHIR if note is provided, and is a string.
Service Information Service Funding Source The source of payment for the service. CarePlan → activity
→ reference(ServiceRequest)

ServiceRequest → insurance(Coverage)

Coverage → payor(Organization | Patient
| RelatedPerson)

Organization | Patient | RelatedPerson
→ name		 CarePlan
...activity 0..*
......reference(ServiceRequest) 0..1
.........insurance(Coverage) 0..*
............payor(Organization | Patient |
RelatedPerson) 1..*
...............name 0..1		 1) Will use CarePlan → activity → reference to reference a ServiceRequest, and insurance to reference a Coverage resource, which must include a payor that is a person or an organization.
2) Coverage resource may be used to register "SelfPay" where an individual or organization other than an insurer is taking responsibility for payment for a portion of the health care cost.
Service Information Service Unit Quantity The numerical amount of the service unit being provided for a frequency.

This element is slated to be used in conjunction with Service Quantity Interval and Unit of Service Type elements to form a full description of how often a service is provided. For example, a service being provided 7 units per week, the Service Unit Quantity = "7". For a service being provided 8 hours a day, the Service Unit Value = "8".		 CarePlan → activity
→ reference(ServiceRequest)

ServiceRequest → quantityQuantity → value
ServiceRequest → quantityQuantity → unit
or
ServiceRequest → quantityRatio → numerator
→ value
ServiceRequest → quantityRatio → numerator
→ unit
ServiceRequest → quantityRatio → denominator
→ value
ServiceRequest → quantityRatio → denominator
→ unit		 CarePlan
...activity 0..*
......reference(ServiceRequest) 0..1
.........quantityQuantity 0..1
............value 0..1
............unit 0..1
.........quantityRatio 0..1
............numerator 0..1
...............value 0..1
...............unit 0..1
............denominator 0..1
...............value 0..1
...............unit 0..1		 1) Will use CarePlan → activity → reference to reference a ServiceRequest.
2) quantityQuantity can be used to represent simple quantities such as "1 installation" or "5 trips". quantityRatio can be used to represent quantities with intervals such as "8 hours a day" or "7 units per week". Either quantityQuantity or quantityRatio can be used, but not both for the same ServiceRequest.
3) value is a decimal, and unit is a string.
4) numerator and denominator are used to represent a quantity with an interval. For example, to represent 8 hours a day, numerator → value would be "8" and numerator → unit would be "hour", while denominator → value would be "1" and denominator → unit would be "day".
5) See the "qty-unit-interval examples" worksheet in this spreadsheet for additional details.
6) Please also consider occurrencePeriod for use when the quantity is meant to be performed within a defined, simple start and end date. E.g. For May 31,2023 to June 10, 2023 give ServiceRequest.quantityRatio of 5 USD per day. AND, use occurrenceTiming for timing information that fluctuates or is sufficiently complex. The recipient may need to calculate end-date, or one can use occurrenceTiming.boundsPeriod to ascribe a start and end date. E.g. Give ServiceRequest.quantityRatio of 5 USD per day. with the occurrenceTiming.boundsPeriod of May 31, 2023 to June 23, 2023 on occurrenceTiming.dayOfWeek = Mon and Wed at occurrenceTiming.timeOfDay = 3 pm.		 Added guidance on ServiceRequest.occurrenceTiming and ServiceRequest.occurrencePeriod
Service Information Unit of Service Type A named quantity in terms of which services are measured or specified, used as a standard measurement of like services. Values include: minute(s), 8 hour(s), quarter hour(s), hour(s), half day(s), full day(s), day(s), week(s), month(s), dollar(s), meal(s), mile(s), visit(s)/session(s), installation(s), none, other (free text).

This element is slated to be used in conjunction with Service Unit Quantity interval and Service Unit Quantity elements to form a full description of how often a service is provided. For example, a service being provided 7 units per week, the Unit of Service Type = "units". For a service being provided 8 hours a day, the Unit of Service Type = "hours".		 see above see above see above
Service Information Service Unit Quantity Interval A period of time corresponding to the quantity of service(s) indicated. Values include: per day, per week, per month, per year, one time only, other (free text).

This element is slated to be used in conjunction with Unit of Service Type and Service Unit Quantity elements to form a full description of how often a service is provided. For example, a service being provided 7 units per week, the Service Unit Quantity Interval = "per week". For a service being provided 8 hours a day, the Service Unit Quantity Interval = "per day".		 see above see above see above
Service Information Service Rate per Unit The rate of one unit for a service. CarePlan → activity
→ reference(ServiceRequest)

ServiceRequest → supportingInfo(Claim)

Claim → item → unitPrice		 CarePlan
...activity 0..*
......reference(ServiceRequest) 0..1
.........supportingInfo(Claim) 0..*
............item 0..*
...............unitPrice 0..1		 1) Will use CarePlan → activity → reference to reference a ServiceRequest, and supportingInfo to reference a Claim.
2) item maps to a service.
3) unitPrice contains the charge or cost per point, which maps to the cost per one unit of the service.
4) unitPrice is of type Money, which is a descendant of the Quantity complex type and inherits value, unit, system, code, and comparator.
5) Workgroup in charge of ServiceRequest wants to work with the Claim workgroup to determine best approach. One potential approach is to update the scope of ClaimResponse since that reflects what has been approved rather than what is being asked for.
Service Information Total Cost of Service The total cost of a service for the plan. CarePlan → activity
→ reference(ServiceRequest)

ServiceRequest → supportingInfo(Claim)

Claim → item → net		 CarePlan
...activity 0..*
......reference(ServiceRequest) 0..1
.........supportingInfo(Claim) 0..*
............item 0..*
...............net 0..1		 1) Will use CarePlan → activity → reference to reference a ServiceRequest, and supportingInfo to reference a Claim.
2) item maps to a service.
3) net is the total cost of an item, which in this case is the total cost for the service.
4) net is of type Money, which is a descendant of the Quantity complex type and inherits value, unit, system, code, and comparator.
5) See above.
Service Provider Information Support Planner Name The name of the person (e.g., Case Manager, Care Coordinator, Plan Coordinator) who helped develop the plan. CarePlan → author(Patient | Practitioner | PractitionerRole | RelatedPerson | Organization | CareTeam)

Practitioner | Patient | RelatedPerson
→ name → family
Practitioner | Patient | RelatedPerson
→ name → given
Practitioner | Patient | RelatedPerson
→ name → text
Organization | CareTeam → name 		CarePlan
...author(Patient | Practitioner | RelatedPerson ) 0..1
......name 0..*
.........family 0..1
.........given 0..*
.........text 0..1
CarePlan
…author(Organization | CareTeam ) 0..1
......name 0..1		 1) Will use CarePlan → author to reference a Practitioner, PractitionerRole, RelatedPerson, Organization, CareTeam or Patient (in self-directed plans) who is the primary author of the care plan being developed.
2) Practitioner, Organization, CareTeam, RelatedPerson and Patient all include name.
3) PractitionerRole should be used when the Organization for whom the Practitioner works for is also needed.
4) given is used for both first name & MI, so need more than one.
5) family is a string with the person's surname.
6) text is a string that contains the full name of the person.
7) The values for Support Planner Name and Support Planner Printed Name would include the same information.
Service Provider Information Support Planner Phone Number The primary phone number (and extension when applicable) of the support planner. CarePlan → author(Patient | Practitioner | PractitionerRole | RelatedPerson | Organization | CareTeam )

Patient | Practitioner | PractitionerRole | RelatedPerson | Organization | CareTeam
→ telecom → system
Patient | Practitioner | PractitionerRole | RelatedPerson | Organization | CareTeam
→ telecom → value		 CarePlan
...author(Patient | Practitioner | PractitionerRole | RelatedPerson | Organization | CareTeam ) 0..1
......telecom 0..*
.........system 0..1
.........value 0..1		 1) Will use CarePlan → author to reference a Practitioner, PractitionerRole, RelatedPerson, Organization, CareTeam or Patient (in self-directed plan) who is the primary author of the care plan being developed.
2) Practitioner, PractitionerRole, RelatedPerson, Organization, CareTeam and Patient all include telecom.
3) PractitionerRole should be used when the Organization for whom the Practitioner works for is also needed.
4) telecom is of type ContactPoint which contains elements to populate for the phone number.
5) system is required if value is provided, and can be: phone, fax, email, pager, url, sms, other.
6) Per FHIR, phone # should be formatted according to ITU-T E.123, so "(555) 675 5745" or "+22 555 675 5745".
Service Provider Information Service Provider Name The name of the entity or individual providing the service.

For paid services use the organization/agency name, for non-paid services use the first and last name of the individual providing the service.		 CarePlan → activity
→ reference(ServiceRequest)

ServiceRequest → performer(Practitioner
| PractitionerRole | Organization
| Patient | Device | RelatedPerson
| HealthcareService | CareTeam)

Practitioner | PractitionerRole | CareTeam
| Organization | Patient | Device
| RelatedPerson | HealthcareService
→ name		 CarePlan
...activity 0..*
......reference(ServiceRequest) 0..1
.........performer(Practitioner |
PractitionerRole | Patient |
Device | RelatedPerson |
HealthcareService | CareTeam) 0..*
............name 0..1
----------------------------------
.........performer(Organization) 0..*
............name 1		 1) Will use CarePlan → activity → reference to reference a ServiceRequest, and performer to reference a RelatedPerson, Organization or HealthcareService. Other options listed are available in FHIR, but may not be appropriate here.
2) Per eLTSS Dataset element definition, performer would reference an Organization or HealthcareService for paid services, and RelatedPerson for a non-paid service.
3) Organization → name and HealthcareService → name are strings with the organization's name.
4) RelatedPerson → name is a complex data element that includes strings for the person's surname and first name.
6) name is required by US Core for Organization.
7) The values for Service Provider Name and Service Provider Printed Name would include the same information.
Service Provider Information Service Provider Phone Number The primary phone number (and extension when applicable) of the service provider.
CarePlan → activity
→ reference(ServiceRequest)

ServiceRequest → performer(Practitioner
| PractitionerRole | Organization
| Patient | Device | RelatedPerson
| HealthcareService | CareTeam)

Practitioner | PractitionerRole | CareTeam
| Organization | Patient | Device
| RelatedPerson | HealthcareService
→ telecom → system
Practitioner | PractitionerRole | CareTeam
| Organization | Patient | Device
| RelatedPerson | HealthcareService
→ telecom → value		 CarePlan
...activity 0..*
......reference(ServiceRequest) 0..1
.........performer(Practitioner |
PractitionerRole | Patient |
Device | RelatedPerson |
HealthcareService | CareTeam) 0..*
............telecom 0..*
.............system 0..1
.............value 0..1
----------------------------------
.........performer(Organization) 0..*
............telecom 1..*
.............system 0..1
.............value 1		 1) Will use CarePlan → activity → reference to reference a ServiceRequest, and performer to reference a RelatedPerson, Organization or HealthcareService. Other options listed are available in FHIR, but may not be appropriate here.
2) Per eLTSS Dataset element definition, performer would reference an Organization or HealthcareService for paid services, and RelatedPerson for a non-paid service.
3) telecom is of type ContactPoint (https://www.hl7.org/fhir/datatypes.html#contactpoint) which contains elements to populate for the phone number.
4) system is required if value is provided, and can be: phone, fax, email, pager, url, sms, other.
5) Per FHIR, phone # should be formatted according to ITU-T E.123, so "(555) 675 5745" or "+22 555 675 5745".
6) US Core requires at least one contact be provided in telecom for an Organization.
Service Provider Information Non-Paid Service Provider Relationship The relationship (e.g., spouse, neighbor, guardian, daughter) of the individual providing a non-paid service or support to the person. CarePlan → activity
→ reference(ServiceRequest)

ServiceRequest → performer(RelatedPerson)

RelatedPerson → relationship		 CarePlan
...activity 0..*
......reference(ServiceRequest) 0..1
.........performer(RelatedPerson) 0..*
...........relationship 0.*		 1) Will use CarePlan → activity → reference to reference a ServiceRequest, and performer to reference a RelatedPerson.
2) Per eLTSS Dataset element definition, performer would reference a RelatedPerson for a non-paid service.
3) relationship is a CodeableConcept, and FHIR provides a preferred value set whose values can be found in the PatientRelationshipType here: https://www.hl7.org/fhir/relatedperson.html. The list is very long and detailed, for example including not only sister, but stepsister, half-sister, twin sister, natural sister, and identical twin sister.

R4 useful elements
Data Requirements Not Specific to eLTSS Dataset Data Elements
This section documents data elements that are mandatory per FHIR XML schemas or US Core requirements, but that do not align with individual eLTSS Dataset data elements.
FHIR Data Element Name
Requirement Source		 Data Element Definition FHIR R4 Resource Element(s) FHIR R4 Resource Element Cardinality (with US Core Constraints) Additional Mapping Details
CarePlan Status
FHIR
US Core		 Indicates whether the plan is currently being acted upon, represents future intentions or is now a historical record. CarePlan → status CarePlan
...status 1		 1) status is required by both FHIR and US Core, and must use the RequestStatus value set (http://hl7.org/fhir/valueset-request-status.html). Possible values are: draft, active, suspended, completed, entered-in-error, cancelled, and unknown.
CarePlan Intent
FHIR
US Core 		Indicates the level of authority/intentionality associated with the care plan and where the care plan fits into the workflow chain. CarePlan → intent CarePlan
...intent 1		 1) intent is required by both FHIR and US Core, and must use the CarePlanIntent value set (http://hl7.org/fhir/valueset-care-plan-intent.html). Possible values are: proposal, plan, order, and option.
CarePlan Narrative Summary
US Core		 Text summary of the resource, for human interpretation. The narrative is an XHTML fragment with a flag to indicate its relationship to the data. CarePlan → text → status
CarePlan → text → div		 CarePlan
...text 1
......status 1
......div 1		 1) text is required by US Core.
2) status is required by FHIR and must use the NarrativeStatus value set (http://hl7.org/fhir/us/core/2019Jan/ValueSet-us-core-narrative-status.html). Possible values are: generated, additional.
3) div is required by FHIR and contains limited xhtml content that contains only the basic html formatting elements and attributes.
CarePlan Category
US Core		 Identifies what "kind" of plan this is to support differentiation between multiple co-existing plans; e.g. "Home health", "psychiatric", "asthma", "disease management", "wellness plan", etc. CarePlan → category → coding → system
CarePlan → category → coding → code		 CarePlan
...category 1..*
......coding 1..*
.........system 1
.........code 1		 1) Per US Core, one category must appear, and must include system with the value "http://hl7.org/fhir/us/core/CodeSystem/careplan-category" and code with the value "assess-plan".
2) US Core does not restrict the number of additional category elements that may appear.
CarePlan Activity Status
FHIR		 Identifies what progress is being made for the specific activity. CarePlan → activity → reference(Resource) → status
and
CarePlan→ activity → progress		 CarePlan
...activity
......reference(Resource)
.........status 1
and CarePlan
...activity
......progress
 1) status is required by FHIR in Resources Reference by CarePlan.activity.reference. Possible values are: not-started, scheduled, in-progress, on-hold, completed, cancelled, stopped, unknown, and entered-in-error.
2) There is also CarePlan.activity.progress to add a free-text description of the progress, or note. CarePlan.activity.progress is an Annotation data type in FHIR, this means it can be dated and contain the identification of the person who uttered the text. This might be used, for example, when the status stays in the same state, i.e. 'in-progress,' but where there is a evolution of that progress.		 Replaced use of CarePlan.activity.detail, and emphasized the use of the status element in the referenced activity and CarePlan.activity.progress free-text annotation
CareTeam Status
US Core		 Indicates the current state of the care team. CareTeam → status CareTeam
...status 1		 1) status is required by US Core, and must use the CareTeamStatus value set. Possible values are: proposed, active, suspended, inactive, and entered-in-error.
CareTeam Subject
US Core		 Who care team is for. CareTeam → subject(Patient) CareTeam
...subject 1		 1) US Core requires one reference to a Patient using subject.
CareTeam Member
US Core		 Identifies all people and organizations who are expected to be involved in the care team. CareTeam → participant → member CareTeam
...participant 1..*
......member 1		 1) US Core requires care team members be listed in CareTeam → participant → member.
2) Note that the Plan Monitor eLTSS Dataset data element utilizes a participant → member as well, and this is documented in the eLTSS element mapping.
CareTeam Participant Role
US Core		 Indicates specific responsibility of an individual within the care team, such as "Primary care physician", "Trained social worker counselor", "Caregiver", etc. CareTeam → participant → role CareTeam
...participant 1..*
......role 1		 1) US Core requires each participant in the CareTeam have a role defined in the "CareTeam Provider Role Value Set" which includes values from NUCC Health Care Provider Taxonomy Code Set for providers and SNOMED-CT for non-clinical and organization roles.
2) Note that the Plan Monitor eLTSS Dataset data element utilizes a participant role as well, and this is documented in the eLTSS element mapping.
Claim Created
FHIR		 The date this resource was created. Claim → created Claim
...created 1		 1) created is required by FHIR. Could use date signers signed or agency authorized. Suggest using date/time that signers signed.
Claim Insurance
FHIR		 Financial instruments for reimbursement for the health care products and services specified on the claim. Claim → insurance Claim
...insurance 1		 1) insurance is required by FHIR.
Claim Insurance Sequence
FHIR		 A number to uniquely identify insurance entries and provide a sequence of coverages to convey coordination of benefit order. Claim → insurance → sequence Claim
...insurance 1
......sequence 1		 1) sequence is required by FHIR and is a positiveInt. Suggest using "1".
Claim Insurance Focal
FHIR		 A flag to indicate that this Coverage is to be used for adjudication of this claim when set to true. Claim → insurance → focal Claim
...insurance 1
......focal 1		 1) focal is required by FHIR and is a boolean. Suggest using "true".
Claim Insurance Coverage
FHIR		 Reference to the insurance card level information contained in the Coverage resource. The coverage issuing insurer will use these details to locate the patient's actual coverage within the insurer's information system. Claim → insurance → coverage Claim
...insurance 1
......coverage 1		 1) coverage is required by FHIR and references Coverage.
Claim Item ProductOrService
FHIR		 When the value is a group code then this item collects a set of related claim details, otherwise this contains the product, service, drug or other billing code for the item. Claim → item → productOrService Claim
...item 0..*
......productOrService 1		 1) productOrService is required by FHIR and must use the USCLS Codes value set (http://hl7.org/fhir/valueset-service-uscls.html). Suggest using the value "99555" for expense.
Claim Patient
FHIR		 The party to whom the professional services and/or products have been supplied or are being considered and for whom actual or forecast reimbursement is sought. Claim → patient Claim
...patient 1		 1) patient is required by FHIR and references Patient.
Claim Priority
FHIR		 The provider-required urgency of processing the request. Claim → priority Claim
...priority 1		 1) priority is required by FHIR and must use the Process Priority Codes value set (http://hl7.org/fhir/valueset-process-priority.html). Possible values are: stat, normal, deferred. Suggest using "normal".
Claim Provider
FHIR		 The provider which is responsible for the claim, predetermination or preauthorization. Claim → provider Claim
...provider 1		 1) provider is required by FHIR and references Practitioner, PractitionerRole, Organization. Suggest using Practitioner or Organization.
Claim Status
FHIR		 The status of the resource instance. Claim → status Claim
...status 1		 1) status is required by FHIR, and must use the Financial Resource Status Codes value set (http://hl7.org/fhir/valueset-fm-status.html). Possible values are: active, cancelled, draft, entered-in-error. Suggest using "active".
Claim Type
FHIR		 The category of claim, e.g. oral, pharmacy, vision, institutional, professional. Claim → type Claim
...type 1		 1) type is required by FHIR, and contains the extensible Claim Type Codes value set (http://hl7.org/fhir/valueset-claim-type.html). Possible values are: institutional, oral, pharmacy, professional, vision. Could use "professional", could extend code list, or could use text data element that is part of codeable concept.
Claim Use
FHIR		 A code to indicate whether the nature of the request is: to request adjudication of products and services previously rendered; or requesting authorization and adjudication for provision in the future; or requesting the non-binding adjudication of the listed products and services which could be provided in the future. Claim → use Claim
...use 1		 1) use is required by FHIR, and must use the Use value set (http://hl7.org/fhir/valueset-claim-use.html). Possible values are: claim, preauthorization, predetermination. Suggest using "preauthorization"
Claim Item Sequence
FHIR		 A number to uniquely identify item entries Claim → item → sequence Claim
...item 0..*
......sequence 1		 1) sequence is required by FHIR, and is a positive integer.
Condition Verification Status
US Core		 The verification status to support the clinical status of the condition. Condition → verificationStatus Condition
...verificationStatus 1		 1) verificationStatus is required by US Core, and must use the ConditionVerificationStatus value set. Possible values are: provisional, differential, confirmed, refuted, entered-in-error, and unknown.
Condition Clinical Status
US Core		 The clinical status of the condition. Condition → clinicalStatus Condition
...clinicalStatus 1		 1) clinicalStatus is required by US Core if the value of verificationStatus is not "entered-in-error". FHIR requires that the values come from the Condition Clinical Status Codes value set, which has values: active, recurrence, inactive, remission, and resolved.
Condition Subject
US Core		 Who has the condition. Condition → subject(Patient) Condition
...subject 1		 1) subject is required by US Core, and is a reference to a Patient.
Coverage Beneficiary
FHIR		 The party who benefits from the insurance coverage; the patient when products and/or services are provided. Coverage → beneficiary Coverage
...beneficiary 1		 1) beneficiary is required by FHIR, and is a reference to a Patient.
Coverage Payor
FHIR		 The program or plan underwriter or payor including both insurance and non-insurance agreements, such as patient-pay agreements. Coverage → payor Coverage
...payor 1		 1) payor is required by FHIR, and is a reference to a Organization, Patient, RelatedPerson.
Coverage Status
FHIR		 The status of the resource instance. Coverage → status Coverage
...status 1		 1) status is required by FHIR and must use the Financial Resource Status Codes (http://hl7.org/fhir/valueset-fm-status.html). Values include: active, cancelled, draft, entered-in-error. Suggest using active.
DocumentReference Status
FHIR		 The status of this document reference. DocumentReference → status DocumentReference
...status 1		 1) status is required by FHIR and must use the DocumentReferenceStatus value set. Possible values are: current, superseded, and entered-in-error.
Encounter
Status
FHIR		 Indicates the status of the encounter. Encounter → status Encounter
...status 1		 1) status is required by FHIR, and must use the EncounterStatus value set. Possible values are: planned, arrived, triaged, in-progress, onleave, finished, cancelled, entered-in-error, and unknown.
Encounter
Class
FHIR		 Indicates the classification of patient encounter. Encounter → class → code Encounter
...class 1
......code 0..1		 1) class is required by FHIR, and is defined to use the extensible V3 Value SetActEncounterCode value set. Possible values are: ambulatory, emergency, field, home health, inpatient encounter, inpatient acute, inpatient non-acute, observation encounter, pre-admission, short stay, and virtual.
Encounter Type
FHIR		 Specific type of encounter (e.g. e-mail consultation, surgical day-care, skilled nursing, rehabilitation). Encounter -> type Encounter
...type 1		 1) type is required by US Core and codes SHALL be taken from US Core Encounter Type; other codes may be used where these codes are not suitable.
EpisodeOfCare Status
FHIR		 Indicates the status of the episode of care. EpisodeOfCare → status EpisodeOfCare
...status 0..1		 1) status is required by FHIR, and must use the EpisodeOfCareStatus value set. Possible values are: planned, waitlist, active, onhold, finished, and cancelled.
EpisodeOfCare Patient
FHIR		 The patient who is the focus of this episode of care. EpisodeOfCare → patient(Patient) EpisodeOfCare
...patient 0..1		 1) patient is required by FHIR, and is a reference to a Patient.
Goal LifecycleStatus
FHIR
US Core		 The state of the goal throughout its lifecycle. Goal → lifecycleStatus Goal 0..*
...lifecycleStatus 1		 1) lifecycleStatus is required by both FHIR and US Core, and must use the GoalStatus value set which has values: proposed, accepted, in-progress, etc.
Goal Subject
FHIR
US Core		 Identifies the patient, group or organization for whom the goal is being established. Goal → subject(Patient) Goal
...subject 1		 1) subject is required by both FHIR and US Core, and is a reference to a Patient.
Location Name
US Core		 Name of the location as used by humans. Does not need to be unique. Location → name Location
...name 1		 1) US Core requires a name for the Location.
Observation Status
FHIR		 The status of the result value. Observation → status Observation
...status 1		 1) status is required by FHIR, and the values are: final, preliminary, registered, cancelled, amended, corrected, entered-in-error, and unknown.
Organization Identifier
US Core		 Identifier for the organization that is used to identify the organization across multiple disparate systems. Organization → identifier Organization
...identifier 1..*		 1) At least one identifier is required by US Core. NPI is preferred. Tax id is allowed. Local id is allowed in addition to 'authoritative' identifier.
Organization Active Indicator
US Core		 Whether the organization's record is still in active use. Organization → active Organization
...active 1		 1) US Core requires one boolean value in active.
Organization Address
US Core		 An address for the organization. Organization → address Organization
...address 1..*		 1) US Core requires at least one address. The contents of address are not specified by US Core.
Patient Administrative Gender
US Core		 The gender that the patient is considered to have for administration and record keeping purposes. Patient → gender Patient
...gender 1		 1) gender is required by US Core and must use the AdministrativeGender value set. Possible values are: male, female, other, and unknown.
Practitioner Identifier
US Core		 An identifier that applies to this person in this role. Practitioner → identifier Practitioner
...identifier 1..*		 1) At least one identifier is required by US Core. NPI is preferred. Tax id is allowed. Local id is allowed in addition to 'authoritative' identifier.
Practitioner Name
US Core		 The name(s) associated with the practitioner. Practitioner → name Practitioner
...name 1		 1) US Core requires one name for a Practitioner.
QuestionnaireResponse Status
FHIR		 The position of the questionnaire response within its overall lifecycle. QuestionnaireResponse → status QuestionnaireResponse
...status 1		 1) status is required by FHIR and must use the QuestionnaireResponseStatus value set. Possible values are: in-progress, completed, amended, entered-in-error, and stopped.
Questionnaire Status
FHIR		 The status of this questionnaire. Enables tracking the life-cycle of the content. Questionnaire → status Questionnaire
...status 1		 1) status is required by FHIR and must use the PublicationStatus value set. Possible values are: draft, active, retired, and unknown.
RelatedPerson Patient
FHIR		 The patient this person is related to. RelatedPerson → patient(Patient) RelatedPerson
...patient 1		 1) patient is required by FHIR.
RiskAssessment Status
FHIR		 The status of the RiskAssessment, using the same statuses as an Observation. RiskAssessment → status RiskAssessment
...status 1		 1) status is required by FHIR, and must use the ObservationStatus value set. Possible values are: registered, preliminary, final, amended, corrected, cancelled, entered-in-error and unknown.
RiskAssessment Subject
FHIR		 Identifies the patient, group or organization for whom the goal is being established. RiskAssessment → subject(Patient) RiskAssessment
...subject 1		 1) subject is required by FHIR, and is a reference to a Patient. (Optional prior to R4 version 3.4.0.)
ServiceRequest Intent
FHIR		 Whether the request is a proposal, plan, an original order or a reflex order. ServiceRequest → intent ServiceRequest
...intent 1		 1) intent is required by FHIR, and must use the RequestIntent value set. Possible values are: proposal, plan, order, original-order, reflex-order, filler-order, instance-order and option.
ServiceRequest Status
FHIR		 The status of the request. ServiceRequest → status ServiceRequest
...status 0..1		 1) status is required by FHIR, and must use the RequestStatus value set which has values: draft, active, suspended, completed, entered-in-error, and cancelled.
ServiceRequest Subject
FHIR		 On whom or what the service is to be performed. ServiceRequest → subject(Patient) ServiceRequest
...subject 0..1		 1) subject is required by FHIR, and is a reference to a Patient.

Units
Definitions for Columns of the eLTSS Dataset Element Mapping Spreadsheet
Column Definition
eLTSS Grouping Indicates the top-level group of data elements defined in the eLTSS Dataset.
eLTSS Data Element Name Name of the data element as defined in the eLTSS Dataset.
FHIR Data Element Name
Requirement Source		 FHIR resource and data element name. Italics indicates whether mandatory requirement is from FHIR and/or US Core.
Data Element Definition eLTSS element mapping tab: The definition of the data element as defined in the eLTSS Dataset. Includes examples, potential lists of values, and usage notes where applicable.
mandatory FHIR data elements tab: The definition of the data element as defined in FHIR.
eLTSS Datatype / Format The type of data for the eLTSS Dataset data element, including format where applicable.
FHIR R4 Resource Element(s) The data elements from FHIR Release 4 that correspond to the eLTSS Dataset data element. The "→" notation indicates the hierarchy. So for example, "Patient → name → family" means that the mapping includes the FHIR "Patient" data element which has the FHIR data element "name" as its child, and "name" has the FHIR data element "family" as its child.

For FHIR data elements that are references to other FHIR resources, the type of resource that is being referenced is included in parenthesis. So for example, the notation "Contract → signer → party(Patient)" indicates that "party" data element references a Patient resource. Where the reference can be to different types of resource, the "|" is used, for example "CareTeam → participant → member(Practitioner | Patient)" indicates that the "member" data element can reference either a Practitioner resource or a Patient resource.
FHIR R4 Resource Element Cardinality (with US Core Constraints) The cardinality of each data element listed in this column. US Core requires a number of data elements, so cardinality may different between the FHIR specification and US Core requirements.

"1" means the data element is mandatory and can appear only once.
"0..1" means the data element is optional, and if it occurs can only occur once.
"0..*" means the data element is optional, and if it occurs can occur any number of times.
"1..*" means the data element is mandatory, and if it occurs can occur any number of times.
"0..x" where 'x' is a number means the data element is optional, and if it occurs can occur up to 'x' number of times.
Additional Mapping Details Provides addition detail regarding the data mapping, including references that are required to link all the data elements, information on data types, notes such as why the additional related data elements may be useful, values available in a referenced code list, etc.
Quantity, Unit and Interval Examples
eLTSS Dataset Elements FHIR quantityQuantity Elements FHIR quantityRatio Elements
Example Svc Unit Qty Unit of Svc Type Svc Unit Qty Interval value unit unit code and system numerator value numerator unit numerator unit code and system denominator value denominator unit denominator unit code and system
8 hours a day 8 hour per day 8 Hour hr | UCUM (http://unitsofmeasure.org) 1 Day d | UCUM (http://unitsofmeasure.org)
adult day care - full day every day 5 full day per week 5 full day d | UCUM (http://unitsofmeasure.org) 1 Week wk | UCUM (http://unitsofmeasure.org)
adult day care - half day twice a week 2 half day per week 2 Half day d/2 | UCUM (http://unitsofmeasure.org) 1 Week wk | UCUM (http://unitsofmeasure.org)
30 minutes a day 30 minute per day 30 Minute min | UCUM (http://unitsofmeasure.org) 1 Day d | UCUM (http://unitsofmeasure.org)
5 quarter hours weekly 5 quarter hour per week 1 Quarter hour hr/4 | UCUM (http://unitsofmeasure.org) 1 Week wk | UCUM (http://unitsofmeasure.org)
1 day a week 1 day per week 1 Day d | UCUM (http://unitsofmeasure.org) 1 Week wk | UCUM (http://unitsofmeasure.org)
1 visit a week 1 visit per week 1 Visit C25716 | NCIT (http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl) 1 Week wk | UCUM (http://unitsofmeasure.org)
10 physical therapy sessions 10 visit (blank) 10 Visit C25716 | NCIT (http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl)
5 meals a week 5 meal per week 5 Meal C80248 | NCIT (http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl) 1 Week wk | UCUM (http://unitsofmeasure.org)
50 meals 50 meal (blank) 50 Meal C80248 | NCIT (http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl)
Hospital bed for the home (delivered) 1 none one time only 1
Doorbell installation for a deaf person 1 install one time only 1 Deploy C81906 | NCIT (http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl)
Transportation to the doctor 10 times 10 other
(trips)		 (blank) 10 Transportation C141286 | NCIT (http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl)
Transportation to church every week 1 other
(trips)		 per week 1 Transportation C141286 | NCIT (http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl) 1 Week wk | UCUM (http://unitsofmeasure.org)
Transportation 100 mile per week 100 Mile C71183 | NCIT (http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl) 1 Week wk | UCUM (http://unitsofmeasure.org)
Medical Alert System Monthly Payment 9.95 dollar per month 9.95 Dollar C173108 | NCIT (http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl) 1 Month mo | UCUM (http://unitsofmeasure.org)