220 likes | 383 Views
Updated with new notes in blue on slides 8 and 9. Care Plan (CP) Team Meeting Notes (As updated during meeting). André Boudreau (a.boudreau@boroan.ca) Laura Heermann Langford (Laura.Heermann@imail.org) 2011-03-09 (No. 5). HL7 Patient Care Work group. Updated Agenda for March 9th.
E N D
Updated with new notes in blue on slides 8 and 9. Care Plan (CP) Team Meeting Notes(As updated during meeting) André Boudreau (a.boudreau@boroan.ca) Laura Heermann Langford (Laura.Heermann@imail.org) 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 • 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 • 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
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
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
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
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. • 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 • lack support of a realtime collaborative care plan management environment • master care plan managed and updated/maintained mainly by a care coordinator (e.g. GP) with contributions from participating care providers • interchanged care plan is essentially a snap shot of the master care plan at a point in time • communicated often together with referral/request for services to target care providers • 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?
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
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 • Goals, trajectory, plan, activities already schedules • A will provide update to B • There are commonalities • Structure, concepts, • Need to understand B to have a good, useful A • Care is dynamic, with conditions and branch points • Decision: A is likely our scope • We need to have a workflow? We don’t want to standardize the workflow. We will use workflows to understand the needs for A • Let’s start with stories that cover A and B • Nursing has lot’s of terms for care plan: documentation heavy • There are workflows that exist already • Need to decide scope: use cases of requirements
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
Last updated: 2011-02-09 Notes from Jay Lile – 2011-02-03 • 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.) • 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. • 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. • 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." • 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? • 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.
Last updated: 2011-02-09 What has been done
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)
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-1-AU.doc • See IHE wiki’s including PCCC and AU: work done in last 2 years • Community and chronic • To be updated
Last updated: 2011-02-09 Appendix
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.
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
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
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 • 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