1 / 10

Hospital Information System (HIS) Stakeholder Consultation

Hospital Information System (HIS) Stakeholder Consultation. Mackenzie Health, Southlake Regional Health Centre and Stevenson Memorial Hospital. Agenda. Introduction Background Definitions Preparing for the Sessions Objectives of the Sessions The Process Next Steps . Background.

Download Presentation

Hospital Information System (HIS) Stakeholder Consultation

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. Hospital Information System (HIS) Stakeholder Consultation Mackenzie Health, Southlake Regional Health Centre and Stevenson Memorial Hospital

  2. Agenda Introduction Background Definitions Preparing for the Sessions Objectives of the Sessions The Process Next Steps

  3. Background

  4. Definitions Functional Requirement • Are the specific functions, tasks or behaviors the system must support, perform or enable. • “What you want the system to do” and “How does it support my work” Category / Sub Category • Clinical requirements are broken down into Categories / Subcategories (i.e. Clinical & Diagnostic Support Department Requirements  Laboratory  Hematology) • Any new requirements will need to be categorized Differentiator • A specific functional requirement that is seen as being of unique importance that distinguish an application or module. • Differentiators can be used in the RFP to create written responses that can be evaluated with more weight and they can be written into Use Cases to become part of vendor demonstrations Use Case • A use case is a software and system engineering term that describes how a user uses a system to accomplish a particular goal. A Patient Journey could be used to describe what the hospital would refer to as a use case.

  5. Preparing for the Session • Unit Managers and/or Process Leads have identified key stakeholders and have provided them with the agenda, examples of case scenarios and communicated context for the sessions. • Ideally, stakeholders should review examples of case scenarios provided, come prepared to discuss other scenarios that are relevant and have a high level awareness of the functional requirements related to their area. • A copy of the functional requirements (word document) that are relevant for each session should be available at the sessions so that participants can refer to the functional requirements if needed. • Stakeholders should be “freed up” to stay for the duration of their session.

  6. Objectives of the Sessions • Stakeholder sessions are the beginning of the Stage 2 pass (inter-disciplinary, inter-organizational, patient flow/advocacy, and operational efficiency perspective) for the three hospitals. These sessions: • Encourage dialogue/discussion among stakeholders about functional requirements that are essential in their workflow processes and patient journey. • Elicit discussion about high priority requirements. • May reveal ‘common needs’ across the continuum. • Bring forward recommendations for use case scenarios for vendor demos.

  7. The Process • There will be at least 1 facilitator at each site for every session. • Process Leads and Unit Managers will be at the sessions • Stakeholders will be provided (and you may bring forward) use case scenario(s) and will be asked to have dialogue / discussion on what functional requirements are necessary in the patient journey. • Reference can be made to the functional requirements document. • There will be a recorder assigned in each session to capture key functional requirements brought forward. • At the end of each session, both sites will report back on their discussion, functional requirements captured and will suggest use case scenarios for vendor demos • Once the sessions are completed, Healthtech will provide documentation that captures the stakeholder feedback and recommended use case scenarios for vendor demos.

  8. The Process (cont’d) Why are we doing this? • Your involvement is a critical success factor to this initiative and future adoption of the HIS. • You know your patient care areas and the patient journey • You know what the limitations are with your current systems • You have an opportunity to shape the future for the HIS Constraints • Limited by time in these sessions to review all possible scenarios and invite all possible stakeholders However, if there is any additional feedback that you would like to provide following these sessions, your are encouraged to contact the Process Lead identified in your session.

  9. Outcome of these sessions could: • Encourage further dialogue/ discussion with stakeholders. • Prompt additional sessions with different stakeholders. Process Leads and Core Team shall: • Use the feedback from these sessions to validate the requirements, identify additional differentiators, and recommend any additions, deletions or corrections to the functional requirements. • Determine which scenarios would be most appropriate and essential for vendor demos • Participate in finalizing the functional requirements, subsequent RFP questions, and enable a structured evaluation process. • Next Steps

More Related