Transcript HL7_Care_Plan_Meetg-_20110309c_with_notes

Updated with new notes in blue on slides 8 and 9.
Care Plan (CP) Team Meeting Notes
(As updated during meeting)
André Boudreau ([email protected])
Laura Heermann Langford ([email protected])
2011-03-09 (No. 5)
HL7 Patient Care Work group
Updated Agenda for March 9th
• Review inventory and examples of Care Plan (CP) use cases
(Laura)
 Still in progress
 Model developed for dynamic CP: see slide 6 and 7
o Laura will update to a more complete cycle for CDM (Chronic Disease
Management), with different sites of care within one system, and
different sites with different systems
o We need to include sites that need to be informed of CP without
delivering care per say
• Review material received on care plan types (dynamic,
interchanged) (Stephen)- done. See slide 8-9
• Review material received on care plan structure (Stephen)done -see slide 10
• Review IHE approach to care plans (André)- see attached
PCCP doc- postponed
Page 2
Tentative Agenda for March 16th
• Presentation by Canada (Ron Parker and Sasha
Bojicic) on the COPD use case they developed.
• Review IHE approach to care coordination and
planning, including the nursing perspective
• Start defining the in-scope and out-of-scope
contents and aspects of care plan
Page 3
Agenda items for March 2nd (progress made)
• Review the finding of the inventory (Laura/Dany): done
• Review some use cases and storyboard (e.g. diabetics,
multiple diseases, colon cancer): good summary by Laura,
detailed walk through of a IHE AU storyboard (diabetes and
mental health) by Peter MacIsaac
 See also slides…
• Discussion on the types of CP: dynamic, global, episodic,
interchanged: see slides…
• Initiate matrix of information elements in care plan (André)
 Review and update with the group
• OMG-BPMN
 Get an example from Canada Blueprint 2015 work: postponed
Page 4
Participants- Meetg of 2011-03-09
Name
email
Country
Yes
André Boudreau
[email protected]
CA
Yes
Laura Heermann Langford
[email protected]
US
Yes
Stephen Chu
[email protected]
AU
Yes
Peter MacIsaac
[email protected]
AU
David Rowed
[email protected]
AU
Adel Ghlamallah
[email protected]
CA
William Goossen
[email protected]
NL
Anneke Goossen
[email protected]
NL
Ian Townsend
[email protected]
UK
Charlie Bishop
[email protected]
UK
Rosemary Kennedy
[email protected]
US
Jay Lyle
[email protected]
US
Margaret Dittloff
[email protected]
US
Walter Suarez
[email protected]
US
Peter Hendler
[email protected]
US
Ray Simkus
[email protected]
CA
Audrey Dickerson
[email protected]
US
Ian McNicoll
[email protected]
UK
Elayne Ayres
[email protected]
US
Lloyd Mackenzie
[email protected]
CA
Danny Probst
[email protected]
US
Kevin Coonan
[email protected]
us
Serafina Versaggi
[email protected]
US
No
Notes
Yes
Yes
Yes
Yes
LM&A Consulting Ltd.
Page 5
Dynamic Federated Plan of Care Model provided
by Laura
Page 6
Dynamic Federated Plan of Care Model provided
by Laura- Discussion
• This model illustrates a collaborative care model where the
care plan is dynamically updated and maintained by multiple
organizations and providers
 Referral is connected to the plan
• The pink line shows the flow when there is no federated care
plan
 What is to be transmitted? The whole contents? Or the latest and
most relevant data for the target organization/provider?
• We need to look at a typical chronic disease case where
multiple organizations are involved without a federated care
plan and no common system
• Sweden is moving to a patient centric model with a central
dynamic care plan with greater fluidity of information among
providers
Page 7
Created: 2011-03-09
Types of care plans (provided by Stephen)
• Dynamic care plans
 Care plans that are developed, shared, actioned and revise realtime by
participating care providers via a collaborative (likely to be web-based)
care plan management environment supported by complex workflow
management engine.
o
o
o
o
o
o
dynamic and organic
coordinated by care coordinator (e.g. GP)
shared realtime
updated/managed realtime by all care provider
can contain other care plans
dynamic links to relevant patient information (where appropriate and feasible, i.e.
privacy and security permit) and evidence-based resources
• Interchanged care plans
 Care plans that are shared (preferrably via electronic exchanges) and
actioned by participating care providers
o lack support of a realtime collaborative care plan management environment
o master care plan managed and updated/maintained mainly by a care coordinator
(e.g. GP) with contributions from participating care providers
o interchanged care plan is essentially a snap shot of the master care plan at a point
in time
o communicated often together with referral/request for services to target care
providers
Page 8
o can contain other care plans as attachments
Created: 2011-03-09
Discussion on CP Types
• HL7 is in the messaging business
 Thus: interchanged CP through messaging
• But trend may be for a central dynamic CP updated by
multiple provider/organizations
• Structure of both would be identical? Very likely
• Contents would be different: exchange would be focused on
the relevant data for the target, if a referral
 If not a referral, then would likely transfer the whole
 But does a care plan include the medical record summary?
 Is it not preferable to limit the care plan to the specifics of the plan and
leave the medical history, allergies, alerts, medications, etc. to the medical
record summary?
 Required to provide the context and ensure clinical safety, especially in
interchanged CP
 Important question – should such information be included as integral
components of CP or as separate health summary attachment?
Page 9
Created: 2011-03-09
Care Plan Structure (provided by Stephen)
• Ref file: CarePlan-Structure-V0-6_2011-03-03 fm Stephen.xls
• Stephen presented the 19 sections of the complete Care Plan that he
has developed and validated with numerous colleagues in AU
• Discussion
 These include what is strictly the care plan (section 19) plus demographics
and administrative data (sections 3 to 5), a medical/health care summary
(section 7 to 12), and some care plan characteristics and context (sections
13 to 18)
 This is very good work to help us see the breadth of contents that could be
found in a care plan
 We will need to determine the frontier of the scope we want to tackle
Page 10
Last updated: 2011-02-23
What scope?
• Identify the business / clinical situations that we want the Care Plan
interoperability to address

Care plan vs all of patient care?
• 2 choices:


A: Interchanged care plan: a snapshot sent through messaging
B: Dynamic, organic updatable care plan: single instance, longitudinal evolution,
grows into complex entity
o Goals, trajectory, plan, activities already schedules


A will provide update to B
There are commonalities
o Structure, concepts,
o Need to understand B to have a good, useful A
o Care is dynamic, with conditions and branch points

Decision: A is likely our scope
o We need to have a workflow? We don’t want to standardize the workflow. We will use workflows
to understand the needs for A
o Let’s start with stories that cover A and B
o Nursing has lot’s of terms for care plan: documentation heavy
o There are workflows that exist already
o Need to decide scope: use cases of requirements
Page 11
Last updated: 2011-02-23
Range of stories for Care Plan
• What scope?
• Continuity of care (exchange of care plan between
practitioners, organizations)
 For chronic diseases
 For complex acute care (multi organizations)
• Information model
 Goals, criteria, tasks, outcomes, planned activities
 Same needs for various diseases, health problems
 Nursing details
• Need to restrict the number of diseases?




Take one disease and follow it through from one end to another
We need a few to ensure sufficient coverage of data in a care plan
Diabetes
Pneumonia
Page 12
Last updated: 2011-02-09
Notes from Jay Lile – 2011-02-03
1. INFORMATION: The DAM should inform a constrained model (DIM/DMIM/RMIM), which is
then used as the basis for specifications (CDA, message, etc.). If we build a DAM, we'll
presumably use it to update the Care Provision DIM. The updated DIM should be in the
list of balloted deliverables. (This is much clearer in PSS 4d, but the sections should be
in harmony.)
2. SCOPE ISSUE: We will also need to determine whether the DAM scope should be
restricted to the care plan or should reverse-engineer the entire Care Provision DIM.
3. PSS (Project Scope Statement) UPDATE: The Scope section (4a) discusses semantic
scope, but it does not lay out the scope of work. I'd suggest that the text currently in 2a
be removed from 2a, expanded, and added to 4a.
4. GUIDELINE: The term "DSTU" is being used to refer to deliverables. I find that
confusing: DSTU is a status, not an artifact. It would be clearer to me if artifacts were
referred to as messages, cda documents, DAMs, and DIMs, and ballot status were used
to modify those artifacts. E.g., "the purpose of this project is to develop a Care Plan CDA
document, with all necessary antecedent artifacts [list them], and to ballot this
document as DSTU."
5. DELIVERABLES: Modeling the information space will almost certainly be useful, but I'm
still in the dark about the use cases. Under what circumstances is it necessary to
communicate a care plan? For what business purpose are organizations paying their
employees to volunteer and develop this standard?
6. PSS UPDATE: External collaboration (6) could use more detail. That would also make it
less necessary to mention this slightly distracting information in previous sections.
Page 13
Last updated: 2011-02-09
WHAT HAS BEEN DONE
Page 14
Last updated: 2011-02-09
What do we have
•
•
•
•
Approved PSS that needs revision when we are ready
Use cases and storyboards (next page)
Glossaries: HL7, EHR WG
CEN Continuity of care P1 and P2
 CEN docs are published
 Information model and processes and workflow
•
•
•
•
Care plan DSTU of 2007
IHE models of the PPOC (Patient Plan of Care)
To be updated with a good inventory (see next page)
NB: we need all the assets in one location (or at least links to
other locations would be found in that spot)
Page 15
Last updated: 2011-02-09
Use Cases and Storyboards on Hand
•
•
•
•
•
•
•
Care Plan Storyboards - HL7Wiki.mht
Care Plan Use cases - HL7Wiki.mht
CarePlanPneumoniaStoryboard.doc
Goossenetal2004Jamia-nursingprocessHL7-186.pdf
Care coordination usecases v-9 IHE Australia.doc
CarePlanTopicUseCasesDiabetesCare22-11-2010.doc
IHE-PCC_Profile-Proposal_Chronic_Care_Coordination-1AU.doc
• See IHE wiki’s including PCCC and AU: work done in last 2
years
 Community and chronic
• To be updated
Page 16
Action Items as of 2011-02-16/23
No.
Action Items
By Whom
For
When
Status
1.
Clarify procedure and obtain rights for André/Laura to update CP wiki
William?
Active: Procedure obtained
2.
Do an inventory of use cases and storyboard on hand
Laura
(Danny)
Active: Underway
3.
Ask William for an update (add in a diff colour to the appropriate pages)
André
Outstanding - Request
made
4
Prepare summary of the steps from HDF to produce the DAM
André
Done. See Appendix 1
5
Obtain and share the published version of the CEN Continuity of care P1 and P2;
obtain ok from ISO
Audrey/Laura
Outstanding
6
Provide copy of the DAM presentation in Sydney and the name of a free mind
mapping tool
Stephen
Done. Sent to list.
Page 17
Last updated: 2011-02-09
APPENDIX
Page 18
Last updated: 2011-02-??
What is a DAM?
• The rules around what constitutes a valid DAM, how to put
boundaries around them, or even what the tools are slim to
none. What that means is you can largely do whatever you want - at
least for now.
Page 19
Last updated: 2011-02-16
Lloyd Mackenzie: Observations on DAMs -1
• Presently, a DAM is not something well defined in HL7. It is not a
single artefact but a variable collection of artefacts: functional
requirements, use cases, behavioural models, activity diagrams,
interaction diagrams, etc.
• There are 3 levels of design: conceptual, logical and implementable.
The DAM is at the conceptual level
• For the conceptual level:




Capturing requirements is key
Requirements must be intuitive to the user community and verifiable
This level is more detailed that the logical level
It must be well bounded because conceptual models tend to be large
• The conceptual information model
 The challenge is arriving at a language and set of well defined concepts
accepted by the broad community of stakeholders/ clinicians
 Definitions are critical: include usage notes, examples and aliases
 Note: ISO Continuity of care concepts (NWIP being balloted to merge the 2
parts) could be one key input to speed things up
 The model must be mapped and validated against the RIM to ensure
completeness
Page 20
Last updated: 2011-02-16
Lloyd Mackenzie: Observations on DAMs -2
• We need to decide which artefacts we will produce
 HL7 does not have a formal set of tools nor predetermined publication
format
 We need to speak to the Publications WG early in the process to ensure
that what is prepared can be handled for ballot
• For the models, 2 major options
 Concept maps (e.g. mind maps): easy for clinicians to understand, less
technical looking
 UML diagram: they are more precise, with cardinalities; can be ‘scary’ for
non technical folks; could come after the concept maps
• Datatype: do we want to specify? If so, which ones? R2? They are
very technical and could be added at a later point.
• Key: decide on core objective: capture requirements and validate
with user community
 Find ways to make this easier
Page 21
Last updated: 2011-02-23
Discussion with Lloyd
• References to look at
 Wiki on Conceptual Information model: this is not firm, has not been
reviewed nor accepted
o Link??




HDF
SAIF
Other sources
Our imagination
• We have to make our own choices to arrive at our objectives. HL7
has not resolved the techniques and tools
• Group decision: start with a concept map, get acceptance by
clinician, then move to class diagrams/UML
• In Sydney, an updated presentation was given on DAM guidelines:
Stephen will send- OK received. Post?
• There are free mind mapping tools available: Stephen will send info
on one- OK link received
• The experience gained in this initiative should be communicated to
HL7 to help clarify the methodology and the tools
Page 22