Dynamic Care Planning Meetings: Difference between revisions
No edit summary |
No edit summary |
||
| Line 191: | Line 191: | ||
End of Call. Next Call Monday Jan 4, 2016 | End of Call. Next Call Monday Jan 4, 2016 | ||
==Monday | ==Monday Jan 4, 2016== | ||
Attendees | 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: | |||
Revision as of 19:48, 17 January 2016
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]
Meeting Minutes
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
- What does the 'made available' mean? What is the expectation?
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: