LTSS is currently a document-oriented exchange paradigm (i.e., consumers exchange the entire service plan as a document), however during outreach stakeholders expressed an interest in the ability to exchange portions of service plan data, query specific elements, receive notifications, etc. The aim of eLTSS is to enable those exchanges and features for LTSS data.

During the eLTSS Initiative, two user stories were developed and documented into the use case document:

LTSS Eligibility Determination, eLTSS Plan Creation and Approval

Sharing a Person-Centered eLTSS Plan.

The first user story would use FHIR Resources to generate an eLTSS plan in an LTSS case management system. The set of FHIR Resources to represent the eLTSS Dataset elements could include: Bundle, CarePlan, Claim, Condition, Contract, Coverage, DocumentReference, Encounter, EpisodeOfCare, Goal, Location, Observation, Organization, Patient, Practitioner, Questionnaire, QuestionnaireResponse, Related Person, RiskAssesment, ServiceRequest

Once an eLTSS plan is created using FHIR, there are 4 sample use cases that highlight the possible exchanges that an eLTSS Plan may be involved in (user story 2 above). The figure below illustrates these use cases.

Exchange eLTSS Plan from Support Planner (case management system) to Clinical and Institutional-based Provider (EHR system)

Purpose: The clinical and institutional-based provider is informed of what service(s) the Beneficiary is eligible for and to supply additional details around the services as well as the Beneficiary to enable better delivery of services and support.

eLTSS Data: Clinical and Institutional-based Provider may need cost information (Claim), emergency backup plan (CarePlan), full details on service quantities (ServiceRequest), etc. Important information includes contact information for a financial management worker (Practitioner).

Exchange eLTSS Plan from Support Planner (case management system) to HCBS Provider (provider system)

Purpose: To inform HCBS Provider of service(s) requested by Beneficiary, or are authorized for the Beneficiary, as well as to supply additional detail around those services and the Beneficiary to enable better delivery of services and supports.

eLTSS Data: HCBS Providers may need service and cost information (Units and Unit Costs, Effective Dates, etc.) (ServiceRequest, Claim), especially if there is a change (e.g., due to a re-assessment). This use case could be the vehicle to communicate these data elements to the HCBS Providers officially, even if the services (and quantity and rates) were previously negotiated. Signatures (Contract) may not be required; however, the eLTSS Signature Date data elements (Contract) indicating when the plan was approved (CarePlan) could be important.

Exchange eLTSS Plan from Support Planner (case management system) to Beneficiary (PHR)

Purpose: The Beneficiary has a complete record of what is either proposed or to be provided to them and by whom, and potentially be imported into the Beneficiary’s PHR.

eLTSS Data: Beneficiary may not need signatures (Contract) and may not need cost information (Claim).

Exchange eLTSS Plan from HCBS Provider (provider system) to Clinical Provider (EHR) (vice versa)

Purpose: The Clinical Provider is aware of the services the Beneficiary is receiving and what their goals/needs/risks are or have been. The HCBS Provider is aware of the Beneficiary's recent hospital/doctor visit and any discharge/treatment instructions to follow.