Electronic Long-Term Services and Supports (eLTSS) Release 1 - US Realm
2.0.0-ballot - ballot
Electronic Long-Term Services and Supports (eLTSS) Release 1 - US Realm
2.0.0-ballot - ballot
This page is part of the electronic Long-Term Services and Supports Implementation Guide (v2.0.0-ballot: STU2 Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. The current version which supersedes this version is 1.0.0. For a full list of available versions, see the Directory of published versions
| Page standards status: Informative |
| 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 beneficiary 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. 'Health Concern' 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. 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, or 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 ServicePlan.quantity of 5 [USD]/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 ServicePlan.quantity 5 with unit=[USD]/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. |
| 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. | |
| 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) | |||
IG © 2020+ HL7 International / Human and Social Services. Package hl7.fhir.us.eltss#2.0.0-ballot based on FHIR 4.0.1. Generated 2023-12-15
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change