1 / 68

Care Plan Team Meeting (As updated during meeting)

NOTES: Action items can be found on slide 27 Agenda Items for Feb 23 meeting are on the next page. Key changes in the document: P. 2: agenda for next meeting Pp . 17-19: discussion with Lloyd on what is a DAM and the techniques to use

sirvat
Download Presentation

Care Plan Team Meeting (As updated during meeting)

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. NOTES: Action items can be found on slide 27 Agenda Items for Feb 23 meeting are on the next page Key changes in the document: P. 2: agenda for next meeting Pp. 17-19: discussion with Lloyd on what is a DAM and the techniques to use Pp. 38-68: description of the HDF DAP approach for a DAM, including artefacts Care Plan Team Meeting(As updated during meeting) André Boudreau (a.boudreau@boroan.ca) Laura Heermann Langford (Laura.Heermann@imail.org) 2011-02-16 (No. 2) 2011-02-09 (No. 1) HL7 Patient Care Work group

  2. Agenda items for Feb. 23rd • Validate the approach • Identify the business / clinical situations that we want the Care Plan interoperability to address • Review what we have on hand (inventory of use cases, storyboards) • Decide on next steps

  3. Participants- Meetg of 2011-02-16

  4. Participants- Meetg of 2011-02-09

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

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

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

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

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

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

  11. Where we are (William?)

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

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

  14. What scope? • Care plan vs all of patient care?

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

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

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

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

  19. Last updated: 2011-02-16 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 • There are free mind mapping tools available: Stephen will send info on one • The experience gained in this initiative should be communicated to HL7 to help clarify the methodology and the tools

  20. Last updated: 2011-02-09 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? • See HDF Domain Analysis- later • Project Scope Statement • Eventually… • DAM • storyboard, use cases, structural models, dynamicmodels • Care Plan CDA? • Care Plan v3 message?

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

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

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

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

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

  26. 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 • To be updated

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

  28. Last updated: 2011-02-09 Gaps

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

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

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

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

  33. CONCLUSION

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

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

  36. Action Items as of 2011-02-16

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

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

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

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

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

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

  43. 3.4.1 How to document the business context

  44. 3.4.2 Use Case Analysis - 1 • Use Case Analysis is used to identify the integration scenarios a project or artifact is intended to support.  • The Use Case Model formally identifies the actors and use cases illustrated in the storyboards and associates the actors with the use cases they participate in. It enables the project or committee to clearly identify the functional areas the system will cover and the actors involved. A Use Case Model may consist of multiple use cases and multiple actors. • Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. • Each use case focuses on describing how to achieve a single business goal or task. Actors are parties outside the system that interact with the system. An actor can be a class of users, roles users can play, or other systems. • Use cases treat the system as a "black box" and interactions with the system, including system responses, are perceived from outside the system. This policy is deliberate because it simplifies the description of requirements and avoids the trap of making assumptions about how the functionality will be implemented.

  45. 3.4.2 Use Case Analysis - 2 • A use case identifies: • Actors participating in the use case • Pre-conditions • Flow of events • Post-conditions • Derived events/interactions • Activity, Sequence, and/or State diagrams can be used to further elaborate the use case analysis.

  46. Analyze Use Cases The purpose of the following diagram is to describe the process used to identify the actors and use cases in a formalized structure that enables Domain Experts and Business Requirements Analysts to identify the functional interoperability scenarios. Document Actors' Actions: Analyze the storyboards to identify the systems, business actors, and functions/actions performed. Describe interoperability use cases: Describe the conditions under which information is exchanged and the responsibilities of each actor based on information received.

  47. Additional Guidance • Consider writing use case text only for those cases whose steps include interoperability to keep the analysis manageable. • Create the use case model with respect to the system that initiates the information exchange. The system that receives the message of interest is a secondary actor in the use case. • After writing the use case text, include one or more scenarios. • Create scenarios for the use case messaging success and failure conditions if there are any and they affect the contents of the message. A use case scenario illustrates a single instance of the flow through a use case. It typically does not include any options. You may rely on additional scenario to describe various options.

  48. 3.4.3 Process Analysis • The process flow shows the information exchange necessary for automation of a healthcare business process. In UML, Activity Diagrams are used to visualize the activities and flow of a healthcare business process as described by use cases. Each Activity Diagram may be represented using a Process Flow - see section "3.7 Artifacts, Process Flow" for details. • The purpose of this sub-process is to document how a project or committee may capture the behavior described in the business process in a structured notation (UML) using UML tools.

  49. Analyze Process Flow Refine the steps in the use case model: Clarify and expand the storyboard into an Activity Diagram. The Activity Diagram will visualize the activities and flow of a healthcare business process. The facilitator will use UML to document these process steps. Document Information Exchange: The process flow is broken into steps and then the message exchange is clearly illustrated. Special care will be paid to message processing rules and to identifying the business triggers. Review may require several iterations

  50. 3.4.4 Information Analysis • One of the most important aspects of requirements analysis is the development of a clear understanding of the business objects of interest, their associations, and their attributes. The purpose of this sub-process is to document the information shared between systems in order to support healthcare business processes. UML class diagrams are used to describe the information required to appear in messages. Documentation of the structure of a particular business process is done using a combination of an information model, represented as a UML Class Diagram, and a carefully written glossary of the terms used by domain experts to define the static elements within that process.

More Related