1 / 76

Care Plan Team Meeting (As updated during meetings)

Phone Number : +1 770-657-9270 Participant Passcode : 943377 2011-03-02 Mikogo session link: http://join.mikogo.com/?sp=&sid=211488249 Or login at : http://join.mikogo.com and e nter session code: 211-488-249 . NOTES: Action items can be found on slide 39

brooks
Download Presentation

Care Plan Team Meeting (As updated during meetings)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Phone Number: +1 770-657-9270 Participant Passcode: 943377 2011-03-02 Mikogo session link: http://join.mikogo.com/?sp=&sid=211488249 Or login at:http://join.mikogo.com and enter session code: 211-488-249 NOTES: Action items can be found on slide39 Agenda Items for March 2nd meeting are on the next page Care Plan Team Meeting(As updated during meetings) Key changes in the document (2011-02-23): P. 2: agenda for next meeting (March 2nd) P. 3: agenda and what was accomplished on Feb 23rd P. 16 and 17: new, on scope André Boudreau (a.boudreau@boroan.ca) Laura Heermann Langford (Laura.Heermann@imail.org) 2011-03-02 (No. 4) 2011-02-23 (No. 3) 2011-02-16 (No. 2) 2011-02-09 (No. 1) HL7 Patient Care Work group

  2. Agenda items for March 2nd • Review the finding of the inventory (Laura/Dany) • Review some use cases and storyboard (e.g. diabetics, multiple diseases, colon cancer) • See list p. 29 • Initiate matrix of information elements in care plan (André) • OMG-BPMN • Get an example from Canada Blueprint 2015 work

  3. Agenda items (and status) for Feb. 23rd • Validate the approach (was discussed) • Appendix 1: HDF DAP • Target/scope, existing, gaps, work plan to fill gaps, roles • Identify the business / clinical situations that we want the Care Plan interoperability to address • Discussed, see What Scope, page 16, and Range of stories for Care Plan on page 17 • Review what we have on hand (inventory of use cases, storyboards): not done • Decide on next steps: not done • Rework Project Scope Statement?

  4. Participants- Meetg of 2011-03-02

  5. Participants- Meetg of 2011-02-23

  6. Participants- Meetg of 2011-02-16

  7. Participants- Meetg of 2011-02-09

  8. Last updated: 2011-02-16 Participants- Profile notes - 1

  9. Last updated: 2011-02-16 Participants- Profile notes - 2

  10. Last updated: 2011-02-09 First Meeting(3-4) Objectives • Agree on where we are and where we want to go • Agree on the approach to get there • Identify what is available and what is missing • Identify tasks and develop realistic work plan • Agree on roles and mechanics • Note: these objectives will be replaced by another set as a result of the above

  11. Last updated: 2011-02-16 Contents • Care plan status update • Where we want to be • Methodology: how to get there • What has been done • Gaps • Team and roles • Conclusion • Next steps • Next meetings

  12. Last updated: 2011-02-09 Care Plan Status Update

  13. Last updated: 2011-02-16 Where we are • We have a Care Plan DSTU • We have an approved March 2010 Project Scope Statement • Questions were raised and discussed regarding development processes, artefacts to be created and the types of ballots • Use cases and storyboards have been collected • Some are on the wiki and HL7 PC WG page • Danny Probst is working with Laura to complete this inventory • Not standardized, not reviewed • More would be available • Canada (Blueprint 2015) • We have details on the methodology (see later) • Ask William Goossen for more details (add on next page)

  14. Where we are (William?)

  15. Last updated: 2011-02-09 Where we want to be (target)

  16. Last updated: 2011-02-09 Objectives of this phase • Get more familiar with HL7 chain of deliverables (HDF) • Consolidate and clarify business and clinical requirements • Under what circumstances is it necessary to communicate a care plan? • Include clinical guidelines • Distributed care planning as in Sweden: meta data needed • For what business purpose are organizations paying their employees to volunteer and develop this standard? • Assemble use cases and analyze • ?Develop DAM • Scope: decide whether the DAM scope should be restricted to the care plan or should reverse-engineer the entire Care Provision DIM • Update objectives once we have a better handle on our methods

  17. 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: Exchangeable 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

  18. 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

  19. 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.

  20. 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.  

  21. 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

  22. 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

  23. 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

  24. Last updated: 2011-02-23 Deliverables (to be updated after a few weeks of travel…) • NB: Care Plan wiki to be used for all documents • Laura and André to manage: YES • See HDF Domain Analysis- see description in Appendix 1 • Project Scope Statement • Eventually… • DAM • storyboard, use cases, structural models, dynamicmodels • Care Plan CDA? • Care Plan v3 message?

  25. Last updated: 2011-02-09 Methodology: How to get there

  26. Last updated: 2011-02-16 Approach to Follow • We will follow the Domain Analysis Process (DAP) of the HL7 development Framework (HDF) • See overview diagram on the next page • We need to familiarize ourselves with the approach • See Appendix 1 for a summary of the HDF DAP process and techniques • CIC DAM Development Guide HL7 PC 20110104Draft.pptx • Format for use cases, storyboards, activity diagrams and interaction diagrams - HL7Wiki.mht • Examples • EMS Domain Analysis Model VOORBEELD.pdf

  27. Last updated: 2011-02-09 HDF- Domain Analysis Overview Source: HDF_1.5.doc, page 37

  28. Last updated: 2011-02-09 What has been done

  29. 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)

  30. Last weeks Discussion – 2 “types” of CP • Global (Dynamic) Plan of Care that is continually updated • Lives within an integrated system • Accessed and reviewed by all caregiver types in all care settings • Updates made as needed and are reflected in all areas of care • Very dynamic • Episodic (Static) Plan of Care (frozen picture in time) (is this the PCCP as defined by IHE?) • Entire Content is sent from one system to another (either as discrete/coded data elements, document, or combination) • Content is reviewed by receiving care giver • Content may or may not result in updates to receiving system’s plan of care • Subset of Master Care Plan (episodic?, referral?)

  31. Pros/Cons • Persistent Plan of Care • Pros: • Latest information available to all care givers • Cons • Lack of connectivity, interoperability of systems makes this a challenge • Snapshot Plan of Care • Pros • Highly “interoperable” • Cons • Information may not be available • Information may not be consumable

  32. Last updated: 2011-02-09 Storyboards and Use Cases on Hand • Care Plan Storyboards - HL7Wiki.mht • PCCP – Chronic Care available • Care coordination usecases v-9 IHE Australia.doc • IHE-PCC_Profile-Proposal_Chronic_Care_Coordination-1-AU.doc • Dutch – Diabetes Care available • CarePlanTopicUseCasesDiabetesCare22-11-2010.doc • CarePlanPneumoniaStoryboard.docavailable • IHE – PPOC, eNS available • Care Plan Use cases - HL7Wiki.mht • PCCP – Chronic Care available • Dutch – Diabetes Care available • Goossenetal2004Jamia-nursingprocessHL7-186.pdf not found • See IHE wiki’s including PCCC and AU: work done in last 2 years available - see above • Community and chronic

  33. Care Plan Inventory • HL7 PCWG had asked for storyboards/use cases re: • Home Care • (IHE eNS) • Static Plan of Care • Chronic Illness • IHE PCCP – John Hilton, Australia • Static Plan of Care • More information available on IHE – Aus – wiki (see link) • Public Health • ? • Planned Care (i.e. planned surgery) • ? • Care for a Cancer Patient • ? • Perinatology • IHE Perinatal workflow and several other Perinatal Profiles • Static Plan of Care

  34. Other storyboards found • IHE e-Nursing Summary • Nursing Home Patient Admitted to Acute Care • PerioperativeCare • Home Health to Hospice • IHE Patient Plan of Care (PPOC) • ED admission – very short

  35. Last updated: 2011-02-09 Gaps and workplan

  36. Last updated: 2011-02-09 Gaps

  37. Last updated: 2011-02-09 Workplan • High level here, comprehensive on Excel • There was a work plan • PC CarePlanTopic Planning & Controllist_v02.xls

  38. Last updated: 2011-02-09 Team and Roles

  39. Last updated: 2011-02-09 Team and Roles (WIP)

  40. Last updated: 2011-02-09 Team and Roles- Notes • Resource issue - the need to fill the roles of HL7 modeling and vocab facilitators to progress the works

  41. CONCLUSION

  42. Last updated: 2011-02-09 Concluding notes • Approach is OK • Have 1 or 2 or 3 more calls to sort ourselves out • Weekly calls at 17h00 ET

  43. Issues/Questions as of 2011-02-16

  44. Action Items as of 2011-02-16/23

  45. Appendix 1- Domain analysis process (DAP) in the HL7 development framework (HDF) Source: HDF 1.5 R1 (Nov. 2009), Section 3- Domain Analysis Process (DAP): Analysis and Requirements Documentation

  46. HDF DAP Appendix Contents • Overview • Process • Business context analysis • Use case analysis • Process analysis • Information analysis • Business rules analysis • Quality criteria • Tools • Artefacts

  47. Overview- 1 • Domain Analysis produces a set of artifacts that clearly describe the healthcare business in a given domain in terms familiar to the people who work in that business area. This set of artifacts comprises a Domain Analysis Model (DAM). HL7 workgroups use these artifacts to develop V3 standard specifications. Each artifact in the DAM must be unambiguously stated in a way that can be well understood both by the domain experts and by the HL7 project members who are responsible for developing the specification. • This section presents a set of internally consistent processes and techniques for analyzing and documenting interoperability requirements. It allows domain experts to document requirements explicitly in a manner consistent with HL7 design. These processes make extensive use of the UML 2.1 standard notation and tooling (see sections 3.6 and 3.7). The process encourages project teams to focus on the underlying healthcare information and process requirements before designing a standard. While the focus of this chapter is to identify interoperability requirements for standard development, this process could be used to analyze requirements for other purposes or projects.

  48. Overview- 2 • Requirement/Domain Analysis is a task typically performed by domain experts and business analysts who represent the users and understand their system interoperability needs. The problem space for HL7 is defined by the interoperability requirements of stakeholders in a given domain of healthcare delivery or administration. This includes all sharing of information among healthcare stakeholders that may be required for the collection, aggregation, reporting, and other analysis of clinical, administrative, and financial data information that pertains to the business. • A DAM defines what needs to be done, not how to do it. It is important to separate the description of requirements from the design of the solution. Prematurely including technical and implementation details will compromise the clarity of the original problem and will result in standards that fall short of the business needs. The DAM is used to create standard specifications by harmonizing it with HL7 references including the Reference Information Model (RIM), structural vocabulary, and application roles.

  49. HDF- Domain Analysis Overview Source: HDF_1.5.doc, page 37

  50. 3.4.1 Business Context Analysis • The first sub-process in the Requirements Documentation process analyzes specific issues or requirements in the context of the healthcare business process that is to be improved either by developing new software or through HL7-based interoperability. • This is accomplished using one or more storyboards. A storyboard is a narrative that describes a representative scenario that illustrates the problem or requirement as well as identifying the interchange of information and the various actors involved. • The purpose of this sub-process is to capture the domain experts’ knowledge in a simple fashion and to document the business context for message exchange. The analysis of the business context is intended to identify a typical scenario (or storyboard) that describes the process intended for automation using the standard developed by the project.

More Related