How To Manage Change In A Health Information Network (Ohio)

Transcription

1 UHIN STANDARDS COMMITTEE Version 2.3 Change Management Specification The UHIN Change Management Specification is compatible with all HIPAA requirements. Purpose: The purpose of this Specification is to detail a formal process by which change to the UHIN community network is implemented. Changes can come in the form of National Standards, commercial/governmental payer or provider needs, Board of Directors or Executive Committee directives. Goal: The goal for this Specification is to detail the process for managing change to the UHINet II (gateway) and UHIN branded products. This will allow UHIN members to meet deadlines together (as much as possible) using a coordinated approach for the benefit of the UHIN community. Responsibility: The Change Management Subcommittee will be responsible for managing the development methodology and implementation procedure which adheres to this Specification. In order to meet this responsibility the committee will need to meet on an on-going basis to develop community test plans for all changes. This committee will coordinate the necessary resources for each community organization to implement test plans. UHIN Staff is responsible to coordinate with vendors for the implementation of the change management process. Authority: Change Management Committee must have participation, from member organizations, representing Standards and Technical interests. Participants will be developing the change management process and are expected to have sufficient knowledge to create the project plans. The organization representative(s) must have the authority to influence the commitment of resources for the testing portion of the change management process. Representatives must be able to communicate with the appropriate internal authorities for resource allocation for development, testing and implementation. Change management has responsibility to report to the UHIN Standards Committee the changes and request the commitment of resources from the Executive Committee/Board. Applicability: This Specification applies to all changes that are required within the UHIN community for implementation of Electronic Data Interchange for all health care related data. Items addressed by this Specification include but are not limited to the following: Utah Health Information Network Transactor (UHINT) Utah Health Information Network Net (UHINet II) Clinical Health Information Exchange Hub UHINSpeedi UHINTracker UHIN e-lite Written documentation for products and services o Design documentation (i.e. scope, functional and technical) o UHINet Connectivity Documents Technical Reference Manual (TRM) for UHINet II o UHINet Web Portal User Manual o UHINT User Manual o UHINSpeedi User Manual o UHINTracker User Manual o UHIN e-lite User Manual o Other documents as developed/approved 1

2 Processes for timelines, monitoring, testing and implementing change in UHIN network systems in compliance and accordance with UHIN Standards and Specifications. Formal process for converting the current systems/processes from test to production. TIME LINE FOR SCHEDULED CHANGES TO UHINET AND UHINT Figure 1 UHINet and UHINT release time charts. October Release 2 nd Tuesday Gather changes, scope and functional documentation for October release Change Management Prioritizes Changes and creates test plans Forward work to Standards for approval UHIN Staff UHIN Staff Negotiate w/ vendor for changes UHIN Staff α-test β-test RELEASE 2 nd Tuesday April Release 2 nd Tuesdsay Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep OCT May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar APR UHINet and UHINT Products 1. UHIN has two scheduled major releases per year; one in April and one in October. 2. Non routine changes will have to be approved by Executive/Board and incorporated to the prioritization process for changes. 3. The Change Management Subcommittee coordinates the way in which changes, updates and testing are completed for UHINet and UHIN branded products. 4. Change Management will meet as necessary prior to the beta testing time period to develop the community test plan. 2

3 Figure 2 UHINSpeedi Change Schedule May Release 2 nd Tuesday Gather changes, scope and functional documentation for November release Change Management Prioritizes Standards approval Negotiate Changes α-test β-test RELEASE 2 nd Tuesday Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May November Release 2 nd Tuesday Additional System Updates Elysium Changes (Axolotl) As of August 25 th, 2009, monthly releases will occur when needed during this preproduction period. Once we are in full production this will be revisited. e-lite Changes (Axolotl) As of August 25 th, 2009, monthly releases will occur when needed on Wednesday mornings (2:00am 5:00am). Once we are in full production this will be revisited. Programming Error Fixes As of August 25 th, 2009, Programming Error Fixes shall occur on the 2 nd and 4 th Tuesday of the month. There is a caveat that an update on the 4 th Tuesday will be done only if needed and is not an end of the month date. Appendix B provides the schedule for all system and application updates. 3

4 Process Flow for Change Requests 4

5 Details of process flow for requested changes to the UHIN community network 1. All requests are taken by UHIN staff and determined whether they are programming/service problems or new services. 2. Requests for changes will be taken to the Standards Committee for review in regard to Standards or Specification work (Standards/Specifications will follow the Standards process flow) Budget constraints Time or resource constraints If a change request requires additional funding or based on investigation cannot be incorporated into the request list those requests will be forwarded to the Executive/Board for approval. 3. Those that do not require Executive/Board approval or have obtained approval will then be provided to the Change Management for prioritization 4. The Change Management Committee prioritizes the list of change requests and sends list back to the Standards Committee for final approval. 5. Standards Committee approves, comments or renegotiates with Change Management on list of changes 6. The approved list is sent forward to UHIN Project Team for negotiations with vendors 7. UHIN Project Team provides the completed negotiated list to Change Management and the Standards Committee. Those items that are not negotiated for will be kept in queue by the Change Management Subcommittee for the next release date or for inclusion into the UHIN budget process. 8. Change Management Subcommittee creates implementation plans for the roll out which includes but is not limited to Type of testing Testing partner coordination Defined timelines for testing Defined Timelines for release. 9. Changes will follow the detailed implementation plan process. 10. Change Management Signs off on completed changes. 11. Notification is sent to the community. 5

6 1. Development of new apps/version releases. There are may be times when testing new applications and version releases will occur outside of the normal release schedule. The Change Management Subcommittee is committed to following the Routine release schedule as often as possible. When a change or new product is released outside of the routine time line then the Change Management Subcommittee will expect that the application will be tested/accepted in the following manner and documented in the implementation plan. UHIN offers unique environments for Alpha and Beta testing of new applications or version releases. Please see Appendix A for an explanation of these environments. Quality Assurance Product Service testing in the Peruvian environment 2-3 week time frame 1. Unit testing will be done primarily by UHIN Staff and community members when requested. This stage of testing should be based on each requirement within the technical Specification. This testing is done to ensure that the specific requirements of the negotiated changes have been completed and has not impacted the existing programming. UHIN staff, by policy set by the Executive Committee, is not allowed to have PHI therefore some community members may be requested to participate. 2. Load testing may be completed by Community members, but is not required. 3. UHIN Staff will not test connectivity items. Product/Service testing in the Solitude environment 2-3 week time frame 1. UHIN Community Quality Unit Testing. This stage of testing is to verify the product functionality. This testing is completed by the UHIN Community This stage of testing should be based on completion of the plan created by Change Management. 2. Regression/User Acceptance Testing. This stage of testing is a front to back test of the modified applications and systems. This testing is the final test to ensure that any change did not disrupt another portion of the software. This include but is not limited to New feature Critical existing features Load testing Testing bug fixes Communication pathways This testing is coordinated by Change Management Subcommittee with key stakeholders. This testing coordination will be incorporated into the testing plan. It is assumed that the stakeholders will be available for testing based on scheduled release dates and the Change Management timeline. In the event issues that were in the Specification were not met the application or version/upgrade will be returned to Strategic partner/vendor for re-programming. 2. Testing Plan The testing plan will be created by the Change Management to address the specific testing types and activities which will include but not be limited to types of testing, testing timelines and notification issues. The timelines for testing will, as much a possible, follow the guidelines outlined in the UHINet and UHIN Branded Products release time charts in Figure 1 above. 6

7 3. Testing Sign Off UHIN Change Test Results and Sign Off Description of Change Change No Product/Service: Date: Detailed Description of Changes to be tested: (attach additional pages if needed) Testing Plan: (attach additional pages if needed) Testing Partners for this test plan Contact Name Organization TPN/Environment Contact Name Organization TPN/Environment Contact Name Organization TPN/Environment Contact Name Organization TPN/Environment Environments requiring Test: UHIN Internal Staging Prestaging Mirrored Production UHIN Internal Staging Development Production Testing Results: 7

8 For Test Sign Off or Return to Vendor for additional fixes: Tested/Approved By: Disagree Comment Tested/Approved By: Disagree Comment Tested/Approved By: Disagree Comment Tested/Approved By: Disagree Comment Tested/Approved By: Disagree Comment Tested/Approved By: Disagree Comment 8

9 Documentation 1. All documentation distributed by UHIN will accurately reflect what the current process is or incorporates. 2. UHIN Committees will be given draft copies for comment and review. 3. Final documents will be available and distributed through the UHIN web site or UHIN list serves. 4. Implementation Issues: 1. Any contractual negotiations will be completed by UHIN Management as needed. 2. The Executive Director may re-prioritize the implementation of changes based on (1) budgetary constraints and (2) usefulness of the implementation to the majority of UHIN Subscribers. 3. UHINet and UHIN branded products will meet all deadlines set in approved Standards and Specifications. Implementation Date: History: (MM/DD/YY) Original A* 1 A 2 A3 A 4 ORIGINATION DATE 01/01/04 05/24/07 08/27/09 APPROVAL DATE 5/12/04 2/6/ /02/09 EFFECTIVE DATE 6/12/04 3/6/ /02/10 * A = Amendment 9

10 Appendix A UHINet Environments 10

11 UHIN Testing Environment Request for the chie UHIN understands that we currently have two servers, a test server and one for production. If we understand correctly currently the demo and production environments both reside on the production server and test on the test server. We prefer to keep the test and production environments on separate servers and isolated from each other as much as possible. We do not want the risk of test and production data becoming inadvertently mixed. Having test and production on separate servers is the method that the UHIN community has asked for in the past and is accustomed to having. As background, below is a description of the environments currently in use for the administrative network, UHINet II. UHINet II Testing Environments The UHINet II testing environments and process are the result of requests directly from the UHIN community. UHINet II Environments Production Testing User Testing for Production Environment UHIN Prestaging UHIN Staff Testing (new updates) Development Community QA Testing (new updates) Production Production Environment Mirrored Environments Software from our strategic partner RelayHealth is first loaded in the UHIN Prestaging test environment where Beta testing is performed by UHIN. All software updates first goes here for both major and interim releases. After the software passes testing in UHIN Prestaging it moves to the Development environment where community members as needed can also test the most recently released software. Once UHIN is satisfied that the software has passed all testing and is ready for production it is moved simultaneously to the Production Testing test environment and to Production which is the production environment. Production Testing is a test environment that is an exact mirror of production. Production Testing is available for UHIN members to test their own software and connections against an environment that is exactly like production but without affecting production. The test environments UHIN and Production Testing are virtual environments residing on the same server. Development and Production each have their own separate physical servers. 11

12 Document Revision History Ver /21/2009 Initial version. 12

13 Appendix B Change Management and System Change Schedule System Architecture Changes (DirectPointe) Emergency right away High Risk As per Medium Risk Low Risk Currently 2 nd and 4 th Tuesday - change to 1 st and 3 rd Tuesday of the Month beginning UHINet Router programming changes (RelayHealth) April and October 2 nd Tuesday UHINT Application Changes (RelayHealth) April and October 2 nd Tuesday UHINSpeedi - Application Changes (All Health) May and November 2 nd Tuesday Elysium Changes (Axolotl) Monthly Releases when needed Change times/dates will be determined by utilization patters (off times) e-lite Changes (Axolotl) Monthly Releases when needed Wednesday mornings (2:00 5:00am) Programming Error Fixes 2 nd and 4 th Tuesday of Month caveat on 4 th only if needed and not the end of the month date. 13