Dynamic Care Planning Meetings

This Profile team meets on Mondays 10-11:00 EST Please navigate to https://himss.webex.com for call in information.

Profile Supporting documents are here [1]

Monday November 30, 2015

Attendees:

• Anne Diamond
• Lisa Nelson
• Emma Jones
• Keith Boone
• Amit Popat
• George cole
• Denise Downing
• Elena Vio
• Gunther Meyer
• Did I miss someone?

Goal for Today's call 1. Need to determine the Use cases we will need 2. Discuss concerns with scope and infrastructure and what we were thinking about profiling in terms of CCS Capabilities

• Use Cases
  • Decided we should do two - transition of care and chronic disease management (Chronic disease management - can be useful in Canada)
  • To assist with marketing suggestion made to ensure we include support of MU CCDS
  • Recommendation made to not be specific with use of 'Post-acute' - need to keep it high level and more generalized. Post-acute means different things to different folks
  • Suggestion to flush out the use case before we work on the transactions and actors

• Scope and infrastructure
  • Reviewed the CCS capabilities we may need to support
  • Discussion about the scope of what we will profile - the CCS capabilities- this will be the actors and transactions.
  • Suggestion made to focus on care Plan management capabilities primarily
  • Discussion about combination of subscribing and publishing - can be logically and virtual
  • Discussion about not needing to do anything special to have a transaction that is to 'create the plan'. Let that be a pre-condition, one or more care plan exists and this is the process to get those plans aligned and centralized

• George presented the 'Back of the napkin' idea
  • Actor A provides content, actor B pulls data out of the care plan
  • Certain set of FHIR operations - can get multiple FHIR servers to synchronize their activities. There is a subscription resource in FHIR that can set up queries to query- resource describing a query
  • Discussion about resolving patient identity. Community EMPI, PDQ - use of PQm
  • First approach is to do a handshake about what patient we're talking about - we would have to profile this -
    • First we have to know the identity - an agreed upon identity Or Use chaining - care plan associated with patient.
  • Lisa presented her 'Star' idea
    • Federated - Use a network of some sort. Community exchange will handle the staring. Lisa's Star.

Call ended. Next meeting Monday Dec 7th

Monday Dec 7, 2015

Attendees

• Lisa Nelson
• George Cole
• Emma Jones
• Keith Boone

Lisa suggests adding this use case [2]as one of the purple boxes to the diagram Keith emailed http://wiki.siframework.org/electronic+Long-Term+Services+and+Supports+%28eLTSS%29+References#eLTSS

Discussion about Actor transaction with updator as an actor.

Various actions:

• Contribute
• Read
• Read various pieces and put in the reconcile view - the updator

• • Content updater is a combination of content creator and content consumer.

• • Content updator actor came into existence with ITI - XWD profile.

Discussion around the relationship to CP 211 Keith Question: For dynamic care planning, what are the systems trying to accomplish for their users?

CRUD - Create Read Update Delete

What are the different systems doing?

Discovery services is needed.

Main question - how do I find content for a patient?

• • Talk to the patient - this is just one way
  • Another case is when patients show up in care settings where the patients have never been seen before

Need a way to figure out who the care team is and how to get information from them.

Flesh out the Use Cases - here's a patient who doesn't have all the information and how to get the information Then from there, what do you ?

1. Connecting with a patient dynamic care plan 2. Content of the care plan - what meds they are on, problems, social history, etc.

Need to clarify the use case because this does not seem much different from QED Need to understand how this is different from other work that have been done?

• • How to fix the new thing.
  • Need a scenario and talk thru what's actually happening and how this dynamic care planning will help. How is this different from xds and QED

Action Item: Summarize existing story boards.

Next Meeting: monday Dec 14th

Monday Dec 14, 2015

Attendees

• Lisa Nelson
• George Cole
• Emma Jones
• Keith Boone
• Anne Diamond

Note: the ITI/DSTU 2 synchronization call is overlapping with this call - it's from 9-11 est. Call information is on himss.webex site. No need to change the dynamic care planning call time. PCC folks can call into the ITI/DSTU call for the first hour then come to the dynamic care planning call.

Review of the chronic conditions storyboard summarization (posted on the ftp site).

• Discussion:

• • Need to use 'verb' when describing actions on the dynamic care plan to make the concept clearer. Dynamic care planning is something that is continuously happening - a living moving thing.

Review of HL7 definition of Synchronization

• Discussion:
  • What does the 'made available' mean? What is the expectation?
    • 'Made' available does not mean 'locked'. We will not use the check-out, locked, update and check-in model (like sharepoint does with document editing)
    • We want to be able to see when someone is editing or changing the dynamic care plan. Be able to see posts. The closest example to experience this might by your interaction with google doc.
      • We talked about doing subscriptions. CCS Monitor Change Capability is subscription
      • Also need 24/7 access to the dynamic care plan

Dynamic care planning diagram

• Discussion:
  • A view collected from distributed content (distributed from various care planning)
  • The big circle involves all the little circles - as you bring into focus all of these little blue circles they could merge into a bigger blue circle
  • We need to be able to represent how different providers want different content in their view. Certain things they care about other things they don't care about. Like having different views of the same thing

Action Items:

• Diagram - Make the circles round and change plan to planning
• Lisa will provide example diagrams to show different views of the same thing (Emma will post on the ftp site)
• Emma will post use case summary on the FTP site.
• Emma will start updating volume one with the Use case
  • we will use the HL7 chronic condition use case and provide the summarization concepts to depict the dynamic care planning

Next call Monday Dec 21. Monday Dec 28 call will be cancelled due to the holiday.

Monday Dec 21, 2015

Attendees

• George Cole
• Lisa Nelson
• Emma Jones

Emma Presented the use case showing the 'dynamic-ness'. Goal is to show how this is different from QED Discussion Points:

• Our profiling should end up enabling this sort of dynamicness.
  • We need to come to grips with the data represented in the all view - is it hosted in one location or is the idea to profile in a way where the presentation of the views provides ability to find and update?
  • We don't want to post to a single repository

• Suggest taking a step back from google docs - is too suggestive of a singular place to store.

Lisa: everybody system my want to have your system make a more accurate picture by pulling in and retrieving and provide a view George: and potentially make an update and push the update to interested persons

Lisa: system that had the newer information acts as the master and other systems acts as the slave. The master batons always had the newer view. Very rapidly they all stay updated with each other. Every system need to have this type of capability. Without having this capability your system will have the triangular bar and need to update. The profile should tell you how your system should behave.

George: Lisa example of systems that need to update with integrated content. Imagine being able to move a level and how smooth do you need the curve to be. Users could run the process one hour before seeing the patient - This will serve the need to be proactive = run daily and prevent readmission.

• Do this to make sure they have the most updated

• Need a process of finding what's available, retrieving it and aggregate and reconciling it.

• Another use case of getting from one slice to another is to resolve conflicts, etc.

• We need to take a look at Derek integrated care pathways - all IHE documents. Lots of concepts here that applies.

George: we want to move towards finding actors and transactions that will -

• maintain in a distrbutable way
• Viewable
• subscriptions and updates/alerts
• support simplicity of check box support

Questions:

• How does your system know to where to go to ask for data for bob?

xds - what systems belong to an affinity domain? Should we automate finding all the places Bob has been? Need to make a statement if this is what we're doing. There should be one or more places in which content can be retrieved.

End of Call. Next Call Monday Jan 4, 2016

Monday Jan 4, 2016

Attendees: Denise Downing Chris Melo George Cole Emma Jones

• Dynamic care plan is a virtual concept and pieces might reside in different places. Need to make people think about this not in terms of implementation
• Clinical documents can be queried and found but how will it know which content is where?
• Need an open issue or statement that we're not trying to solve the problem where we don't know about all the providers that the patient has seen. We only know about the providers that the patient is known to have seen.
  • Any provider seeing this patient and their proxy have the ability of seeing a view of the whole care care plan.
  • There may be one central place or multiple places. Doubtful there will be one single place. Keep open the idea that disparate pieces are assembled together to provide a view.

• Not saying that points of care are not discoverable if not caring for the patient - there are other ways to discover where the patient has been seen - NWHIN and CommonWell - has patient locator services that are fed by encounter interaction feeds by participants. There are other things that are like that. UTAH HIE services, Vermont, etc.

• • Will need to lay the ground work that we are not profiling a record locating service.
• Questions about the architecture about this?

• • Profile a transaction called update care plan
  • will profile the content
  • not profiling how to send the transaction. We're not doing xds assembly domain.

• Dynamic care planning is open ended
  • cardiac profile - how is this applicable in that scope? Something to think about but can't do it all. This profile will rely on other profiles also.

• Need to write a grouping with the recon agent because different providers give different pieces for the care plan.

Action item: Do a Doodle Poll for a new time.

Next Call Jan 18, 2016

Monday Jan 18, 2016

Attendees: Chris Melo, Denise Downing, George COle, Emma Jones

• Visio diagram reviewed - shows how the data is flowing. Does not show the actors/transactions. Share care plan information is data flow

• Patient updates: We don't show that the patient registers for updates - is it an unsolicited update? In IHE swimlane diagrams, each arrow should have IHE directions. Arrows show direction of initiation - the arrow goes in the direction in which the transaction is initiated. The arrow head is on the target. Only time it's different, is when there is a pull.

Arrow represents the transaction mechanism. [domain-transaction] little number. Need one arrow per step. If there are steps hidden can make it preconditions (serve like assumptions).

• • Need to do the actors transactions diagram then need to come back and see what need to change in the visio diagram
  • The boxes on the top are actors name but might let it be systems

The profile has 2 actors - dynamic care plan actor and duplicates of the other actors (creator and consumer).

• Need to know that the 3-4 other boxes are instances of the other actor.
• Our actor transaction diagram might just have 2 boxes (care plan manager - but do we need new PCC actors or can we get by with content creator and consumer?
  • Only issue with care plan consumer is that the requirement for care plan consumer has been minimal. How far can we extend content consumer? But it almost looks like it's a content creator also.
• Trend from the WF document has content updater has a content manager. There is also a report assembler actor who at their base is a content creator which does extra scenario.
  • Basically it's knowing how to create, consume and update.
  • This profile is one of many that seems complicated but not really.

Volume 2 - will profile FHIR. "Need to know what the deliverable is from us? What is the mechanics of all of this.

• In the profiling space - Trifolia, forge, main FHIR team
  • No different than CDA - schema starts off being the base resource of FHIR.
  • FHIR profile is a big xml blob - comes out as a structured definition
• Thinking we need to understand search and quary
  • How granular does it gets
  • The backbone element is pink glue

Dynamic care planning - need to explore the resource content - volume 3 and 4 (is valuesets) Volume 2 - will it be traced to a FHIR get or FHIR push. Need to know more about the granularity or the plain vanilla plan Will there be plain valilla FHIR to do the Get or Is it I need 3 goals but only the goals of a care plan - think it may be plain vanilla FHIR or may need to add more syntax Basic DRUD - get, put , update or delete May be using something like get carepln.goal.goal42 Can write a query to get the related plans that fulfills this one. If using FHIR, will If find something that we can't do with this, then will need to profile a new operation (GAO wrote an new operation 'evaluate') Operations are listed per resource but sometimes operations are defined and cross reverates - https://www.hl7.org/fhir/operations.html Post is when you want to give data to a service. You can give data with a get if you have parameters. Volumes 3 & 4 Need a way to scope it so that for this sprint - when we get done will only do this one small thing. What needs to go in Vol 1,2,3,4 - When we get to our volume we have cardinality to profile - Have to have a subject, have to have an author Hand pic the Don't change the meeting Next - next week will use time to talk agenda George will do the actor transactions.