Page History

What is the Care Coordination Track

The Care Coordination track focuses on patient and person-level information exchange across acute, ambulatory, post-acute care settings, community-based organizations, and patient digital mobile devices with the goal of generating, sharing and updating an electronic care plan to support multiple chronic conditions (MCC).  Care coordination helps facilitate the appropriate and efficient delivery of health care services both within and across clinical and non-clinical systems.  Care coordination activities align with and support other areas of care, such as the following:

• Clinical Decision Support (CDS):  focuses on applying evidence-based clinical practice guidelines at the point of care (refer to Care Management track https://confluence.hl7.org/display/FHIR/2020-09+Care+Management+Track)

• Electronic Long-Term Services and Supports (eLTSS) and Post-Acute Care Transitions:  focuses on supporting access to longitudinal information to help inform clinical decision making and promote coordinated patient care; improving discharge planning and health information exchange; and enabling data comparison across healthcare settings (refer to PACIO-eLTSS-Post Acute Care Transition Summary track https://confluence.hl7.org/display/FHIR/2020-09+PACIO-eLTSS+Post-Acute+Care+Transition+Summary)

• Social Determinants of Health (SDOH):  focuses on the capture and exchange of social risk data within clinical care settings (refer to Gravity SDOH track https://confluence.hl7.org/display/FHIR/2020-09+Gravity+SDOH-CC+Track

Submitting WG/Project/Implementer Group

This track will be hosted by the Multiple Chronic Conditions (MCC) electronic Care Plan Project in collaboration with implementer communities testing several other FHIR IGs focus on and relevant to care coordination, including: 

• HL7 FHIR Gravity Social Determinants of Health in the Clinical Care Setting (sdoh-cc)
• PACIO Functional Status Assessment IG and Cognitive Status Assessment IG
• HL7 FHIR Electronic Long-Term Services and Supports (eLTSS)
• IHE Dynamic Care Planning
• HL7 FHIR Bidirectional Service Request (BSeR) IG
• Clinical Practice Guidelines (CPG)
• CDS Hooks, on-patient-view
• SMART on FHIR
• US Core

FHIR Version

This track will use R4 version of FHIR.

Specification(s) this track uses

• MCC IG: https://trifolia-fhir-dev.lantanagroup.com/igs/lantana_prod_hapi_r4/MCC-IG/index.html

• US Core Team: http://hl7.org/fhir/us/core/STU3.1/StructureDefinition-us-core-careteam.html

Artifacts of focus

• MCC eCare Plan Profile: https://trifolia-fhir-dev.lantanagroup.com/igs/lantana_prod_hapi_r4/MCC-IG/StructureDefinition-mccCarePlan.html
  
  • Note: MCC is re-using US Core profiles, The project will use the errata release version of USCore when it is published. 
    
• US Core Care Team Profile: http://hl7.org/fhir/us/core/StructureDefinition/us-core-careteam
• US Core Goal Profile:http://hl7.org/fhir/us/core/StructureDefinition/us-core-goal addressing (goal.addresses) MCC defined conditions and labs, base nutrition order (http://hl7.org/fhir/R4/nutritionorder.html), etc
• Chronic Kidney Disease Condition Profile: https://trifolia-fhir-dev.lantanagroup.com/igs/lantana_prod_hapi_r4/MCC-IG/StructureDefinition-ChronicKidneyDisease.html - as the core of the care plan (CarePlan.addresses) 
• CarePlan.activity.outComeReference, referencing MCC defined conditions and labs 
• Stretch Goal 1: FHIR Questionnaire Resource / QuestionnaireResponse within (brought into) Care Plan https://www.hl7.org/fhir/questionnaire.html and https://www.hl7.org/fhir/questionnaireresponse.html or CI ( (Note: as we get closer - maybe we can recruit some folks from the Questionnaire track to come play))
• Stretch Goal 2: Use of applicable select BsER referral request profiles (TBD) from: http://hl7.org/fhir/us/bser/ or the CI Build

Clinical input requested (if any)

Does your track have a need for input from the clinical community? If so, what are the needs?

• Health and social services integration within a clinical care setting
• Hoping for support and participation from EHR actors
• Need assistance with populating certain scenario information into the EHR sandboxes

Related tracks

• 2020-09 Care Management Track
• 2020-09 Gravity SDOH-CC Track
• 2020-09 PACIO-eLTSS Post-Acute Care Transition Summary

Track Leads

• Evelyn Gallego Evelyn.Gallego@emiadvisors.net 
• Gay Dolin gdolin@namasteinformatics.com 

Expected participants

Connectathon attendance sheet

• Jenna Norton- NIDDK MCC
• Arlene Bierman - AHRQ MCC
• Gay Dolin - Namaste MCC
• Tom Hicke- Cognitive MCC
• Joe Bormel- Cognitive MCC
• Jerry Goodnough - Saperi Systems MCC
• Evelyn Gallego EMI MCC
• Katiya Shell EMI MCC
• Dan Vreeman - RTI MCC
• Lisa Nelson - Max MD MCC
• Nancy Lush, Patient Centric Solutions 
• David Hill, MITRE, PACIO-eLTSS

• Becky Gradl - Academy of Nutrition and Dietetics

• Margaret Dittlof - Academy of Nutrition and Dietetics

Zulip stream

Participants can follow the Zulip chat: https://chat.fhir.org/#narrow/stream/220328-Care-Plan.2FCare.20Coordination for relevant information

System Roles

Describe each type of system that could participate in the track. The participants/organizations that will play these roles will be updated

Please include information here regarding how much advance preparation will be required if creating a client and/or server.

Scenarios

Please go to this link to see the GET statements for the scenarios below

Test Scripts

GITHUB: Connectathon Demo Data and scripts for loading resources

Security and Privacy Considerations

Please contact track lead to learn more about the connectivity requirement for the Hub

For all scenarios the FHIR server is referenced by {ServerBase}.

There is an open logica fhir server at: https://api.logicahealth.org/MCCeCarePlanTest/open/metadata

Secure Server end point https://api.logicahealth.org/MCCeCarePlanTest/data

General Data:

MCC IG US Core Patient Example: 

Scenario 1: Retrieve Patient’s Chronic Kidney Disease Care Plan from an EHR

Action: A Client calls the EHR server to request a CKD focused MCC care plan from the Server

Precondition: Patient and Care Plan exist on server.

Success Criteria: The Client receives the care plan as expected based on the in parameters provided to the server and successfully displays the data

Bonus Point: Query using MCC Chronic Condition Value Set (2.16.840.1.113762.1.4.1222.159)

Basic Query Flow: 

1. Find the Condition for the patient matching the CKD 
2. Find CarePlans that address this Condition

Basic Query - By Steps:  

1. {Server}/Condition?subject={subject-id}&code=709044004
2. Extract condition-id (i.e. Condition id, e.g cc-cond-pnoelle-ckd)
3. {Serve}}/CarePlan?condition={condition-id}
4. Extract the Care plan id as careplan-id

Example: 

1. GET https://api.logicahealth.org/MCCeCarePlanTest/open/Condition?subject=cc-pat-pnoelle&code=709044004
2. GET https://api.logicahealth.org/MCCeCarePlanTest/open/CarePlan?condition=cc-cond-pnoelle-ckd

Basic Query - Chained:  

1. GET {Server}/CarePlan?subject={subject-id}&condition:Condition.code=709044004

Bonus Query:  (Not working on our test server)

1. {Server}/Condition?subject=cc-pat-pnoelle&code:in=2.16.840.1.113762.1.4.1222.159
2. Extract condition-id (i.e. Condition id, e.g cc-cond-pnoelle-ckd)
3. {Server}/CarePlan?condition={{condition-id}}
4. Extract the Care plan id as careplan-id

As Chained Query:

1. GET {Server}/CarePlan?subject={subject-id}&condition:Condition.code:in=2.16.840.1.113762.1.4.1222.159

Scenario 2: Update Client MCC CKD Care Plan CKD Condition (Health Concern) Supporting information from CKD stage 3 to CKD Stage 4

Action: A Client calls the EHR server to request for (CKD Condition) updates within CKD focused MCC care plan and/or from the EHR Server Problem List

Precondition: Patient and Care Plan exist on server. Problem list (or encounter occurred(??)) where a CKD Stage 4 Condition/Problem was added to the Problem list or added as Health Concern to Care Plan in an EHR Care Plan.

•         Note: ChronicKidneyDiseaseCondition (stage 3) has Condition.abatement.DateTime that equals the ChronicKidneyDiseaseCondition (stage 4) Condition.onset.dateTime

Success Criteria: The Client receives the added stage 4 CKD problem as expected based on the in parameters provided to the server and successfully displays the updated data

Process flow:

1. Fix-up existing CarePlan addresses by code 709044004 (Bundle Scenario_2_setup_bundle.json) Adds Stage 3, Updates CarePlan, inactivate prior CKD,
2. (GET) Retrieve CarePlan addressing stage 3(e.g. GET {{Server}}/CarePlan?subject={subject-id}&condition:Condition.code=433144002)
3. (PUT/POST) Add Stage 4 Condition
4. (PUT) Update Addresses Stage 4, and add Stage 3 to Supporting Info
5. (GET) Retrieve CarePlan addressing stage 4(e.g. GET {{Server}}/CarePlan?subject={subject-id}&condition:Condition.code=431857002)

Specific Resource Bundles:

 Bonus Point: NA (Note, for the NEXT connectathon we could test querying for stage in condition.stage vs as precoordinated code

 Scenario 3: Retrieve patient CKD relevant labs from EHR

http://hl7.org/fhir/us/mcc/StructureDefinition/EstimatedGlomerularFiltrationRate
or
https://trifolia-fhir-dev.lantanagroup.com/igs/lantana_prod_hapi_r4/MCC-IG/StructureDefinition-EstimatedGlomerularFiltrationRate.html

See example:https://trifolia-fhir-dev.lantanagroup.com/igs/lantana_prod_hapi_r4/MCC-IG/Observation-EstimatedGFR.html

 Action: A Client calls the EHR server to request for chronic pain conditions for EHR Problem list (or encounter documentation (??)).

Precondition: The lab observations exists in the EHR server

Success Criteria: The Client receives the Observations from EHR server

•  GET {Server}/Observation?subject={subject-id}&code=50044-7

•  GET {Server}/Observation?subject={subject-id}&code=2160-0 

Scenario 4:   Retrieve MedicationStatement or MedicationRequest - BONUS

 Action: 

1. Fetch Active  Medications for Subject 
2. Fetch Med associated with CarePlan 
3. Fetch Active Medication Statement

Precondition: 

Success Criteria: 

GET {Server}/MedicationRequest/?subject={subject}&code=245133

Bonus Point:

1. Add to care plan activities - GET Care plan
2. Examine Activities to see if it is present
3. Add if not present 

 Scenario 5: Retrieve QuestionnaireResponse for pain perception from EHR

 Action: A Client calls the EHR server to request for chronic pain conditions for EHR Problem list (or encounter documentation (??)).

Precondition: A completed lHC Form for https://loinc.org/75259-2/ exists in the EHR server

Success Criteria: The Client receives the completed FHIR R4 Compliant QuestionnaireResponse from EHR server

Bonus Point: Contain Pain perception QuestionnaireResponse on CarePlan.supportingInfo.Condition.ChronicPainConditon in Condition.evidence.detail (QuestionnaireResponseResource)

      GET {{Server}}/QuestionnaireResponse?subject=cc-pat-pnoelle&questionnaire.identifier=75259-2

 Options:  use QuestionnaireResponse resource or Observation Derived from a QuestionaireResponse

Main

1. Fetch from Right Questionnaire Response
2. Add Condition based Questionnaire 

Bonus

1. Scan Questionnaire for Correct Item
2. Fetch Response
3. Get Right Item

 Scenario 6: Retrieve Patient’s Chronic Pain Condition from EHR and add to Client MCC Care Plan

Action: A Client calls the EHR server to request for chronic pain conditions for EHR Problem list (or encounter documentation (??)).

Precondition: A chronic pain condition has been added to the problem list in the EHR

Success Criteria: The Client receives the chronic pain condition (profile instance) as expected based on the in parameters provided to the server and successfully displays the data

Bonus Point: Contain Pain perception QuestionnaireResponse on CarePlan.supportingInfo.Condition.ChronicPainConditon in Condition.evidence.detail (QuestionnaireResponseResource)

•        GET {Server)}Observation?subject=cc-pat-pnoelle&code=102481003

Scenario 7: Retrieve Patient’s Weight observation from EHR and add to Client MCC Care Plan

Action: A Client calls the EHR server to request for a body weight observation.

Precondition: A body weight observation has been added in the EHR

Success Criteria: The Client receives the body weight observation (profile instance) as expected based on the in parameters provided to the server and successfully displays the data

Bonus Point: NA

•          GET {Server)}Observation/?subject=cc-pat-pnoelle&code=29463-7
•          {{Server}}/Observation/?_sort=-date&_count=1&subject=cc-pat-pnoelle&code=29463-7

 Scenario 8: Retrieve Patient’s Weight Goal from EHR and add to Client MCC Care Plan

Action: A Client calls the EHR server to request for a patient weight goal

Precondition: A patient weight goal has been added to the EHR Care Plan

Success Criteria: The Client receives the weight goal (profile instance) as expected based on the in parameters provided to the server and successfully displays the data

• GET {Server)/Goal/?subject=cc-pat-pnoelle
• Search Targets of each goal since target is not a search parameter (Issue)

Bonus Point: NA

Scenario 9: Retrieve Patient’s Dietitian Referral (BSeR) - BONUS

Specific BSeR Profile used within the MCC Care Plan:

http://hl7.org/fhir/us/bser/STU1/StructureDefinition-BSeR-ReferralServiceRequest.html

https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1099.45/expansion/Latest

http://hl7.org/fhir/us/bser/StructureDefinition/BSeR-ReferralServiceRequest

Action: A Client calls the EHR server to request for a dietitian referral OR referral is created and sent

Precondition:  Referral exists or can be created and sent in EHR

Success Criteria: Referral is retrieved and can be seen in Care Plan

Bonus Point: NA

•         GET {Server}/ServiceRequest?subject={subject}&code=408289007

Track Report Out

Click here to contribute or review the care coordination track repot out