REGISTRATION IS OPEN for #OHIE19 4-8 Nov, 2019 in Addis Ababa, Ethiopia - CLICK HERE
Skip to end of metadata
Go to start of metadata

Release Management and Workflow Processes


The purpose of this page is to describe the OpenHIE processes for Release Management and the development of OpenHIE Workflows.  The diagram below depicts the OpenHIE Workflow process (in green) and how it relates to the OpenHIE Release process (in blue).  

 Release Process Triggers  

  • A new release cycle or the necessity for a point release will trigger the release process.  


Release ActivityDescription

1. Plan Release

1.1 Determine the scope of the release including:
  • Noting that before a workflow can be included in a release, it must have a sponsor.
  • Define specifications necessary to support the workflow. (e.g., Create new; 2. Use existing without modification; 3. Modify existing.)
  • Identify exemplar software combinations to be tested.
  • Create supporting documents and other artifacts to be included in the release

1.2 Determine the timing of key release milestones including:

  • The date for OpenHIE Exemplar software to be finalized. (completion of "workflow activity 5" on the diagram above.)
  • The date for communicating the release.

2. Create Integration Test Scripts

and Test Data

2.1 Develop Integration Test Plan and Scope

  • A test plan stating the scope and goals of Integration testing needs to be created.
  • The scope of the test plan will outline the exemplar architecture components to be tested.
  • The test plan will also outline the test cases to be executed.
  • The Architecture Community shall review the test plan to ensure consensus on the scope of testing.
  • The test plan and scope shall be documented and shared with the OpenHIE community and implementors.

2.2 Develop Integration Test Scripts and Data

  • Test scripts and data required to meet the goals and test cases defined by the test plan will be created.
  • The scripts and any data required to execute the scripts will be available to the OpenHIE Community members and implementers.

3.  Establish Test Environment

Exemplar architecture components required for the release must be obtained, installed, and configured to support the workflows.

Test harness must be identified and deployed to support testing

4.  OpenHIE integration test

workflow and exemplar software

Testing will be executed and the results and testing artifacts will be documented and available for community consumption. Any deviations from the test plan will be noted.

  • Component testing
  • Integration testing
  • Functional testing
  • Performance testing

5. Develop Release Documentation

Release documentation including the following will be documented and available to implementors and OpenHIE community members:

  • The version of software components that were tested with the release.
  • Configurations used in testing the release.
  • Links to workflows that were in scope for the release.

6. Communicate the Release

The Leads team and the Architecture Community will determine distribution list for the OpenHIE release. Messaging will be created and released upon completion of the release.

7. Create Distribution?

To be discussed more

To be discussed

Colored text in the description = New text.  Black text = text that was previously agreed upon.  

Workflow Process Triggers  

  • Communities, countries, and/or other stakeholders will identify new real-world Health Information Exchange workflows that need to be supported within OpenHIE. (The impetus for new workflows will likely be organically initiated by country stakeholders either independently, or in conjunction with members of the OpenHIE community who have relationships with those stakeholders — not necessarily individuals on the architecture group.)

  • Requests to modify existing workflows may result not only from new country workflow requests, but also from within technical communities, among others. Existing workflows may need to be modified for various reasons (e.g., to address defects, to accommodate evolving requirements, to mitigate known technical limitations, etc.)    

Workflow ActivityDescription

1. Identify New / Changed workflow

1.1 ARB Evaluation  

The identified workflow will need to be evaluated by the Architectural Review Board (ARB) to assess the feasibility of incorporating into the OHIE framework; including determining whether the proposed workflow can be incorporated into an existing workflow with or without modification.  

1.2  Establish Sponsor(s)

The identified workflow sponsor is responsible for overseeing the design, development, and testing for new workflow processes, and coordinating with the appropriate OpenHIE communities.

2. Develop / Update Workflow

2.1 Call for participation

Seek subject matter experts to engage in the workflow development process.  

2.2. Identify Workflow Requirements 

The requirements for the new particular workflow will be enumerated and validated. (Requirements may include both technical and non-technical dimensions — e.g., policy, process.)

2.3. Design and Document Workflow

Given workflow requirements, identify appropriate existing transaction standards. If no existing standards are identified, develop a strategy for supporting workflow needs and assess the need for creating new consensus based specifications.  

3. Develop Exemplar Software Solutions

3.1 Create / Modify Exemplar Software and Documentation  

The workflow sponsor will work with exemplar software development teams will modify or build software to support the workflow.   

3.2 Unit Test and Validate Workflow 

The newly designed and developed workflow shall be unit tested / validated in a test environment, e.g. the OpenHIE sandbox using exemplar software. Testing may identify challenges with code, interoperability specifications, etc., requiring iteration over steps 4-6. Workflow testing/validation will be performed until desired outcomes (defined in #3) are achieved. Scripts and test cases will shared with the architecture community. Testing may also include IHE testing for the application. 

4.  IHE test software adherence to msg. standards in workflow

4.1 Register for IHE test and plan for required resources

If applicable, the sponsor should ensure that the appropriate software is registered for IHE conformance testing and that there are appropriate resources to perform the pre-IHE testing and execute the formal IHE tests.  

4.3 Execute IHE tests
The appropriate exemplar software shall be IHE tested.  

4.4 Write Conformance Statement
To complete conformance testing, conformance statements will be written and made available to potential consumers.  

5. Finalize Tested Software Version

5.1 Finalize Tested Software Version

After completion of software testing, the software will be versioned and ready for integration testing.

Colored text in the description = New text.  Black text = text that was previously agreed upon.  

IHE Key Milestones 

The following are some key milestones that are important to the OpenHIE release and workflow processes.  

Key IHE MilestonesDescription

1. Intake process for new IHE work items (profiles, white papers)

OpenHIE Need: No existing profile can be used to meet the workflow needs
The intake process for new IHE work items (profiles, white papers) starts in mid-September with a 2 page top-level description. Full presentations are made to the planning committee in October. The committee votes to accept or not accept the work item into the current year’s workstream. Accepted work items are handed off to the technical committee to schedule the work and manage the development of documents.
2. Profile is released for trial implementation

OpenHIE Need: A new profile is being developed that will be used for a workflow

Volume 1 of an accepted profile is to be completed by the February F2F meeting. This week-long meeting is hosted by a different IHE country partner each year; it is the only international meeting.

Volume 2 or 3 (depending on whether the work item is transaction-based (2) or content-based (3)) is completed at the spring F2F meeting, held in Chicago at the RSNA offices. This is a week-long meeting; it is usually held in late April. The output of this meeting is a profile draft for public comment.

The public comment process is usually 6 weeks long or so. The resolution of comments meeting is a week-long F2F meeting in Chicago. It is held in mid-July. At this meeting, all public comments are resolved and final edits are made to the profile. The edited profile is released for trial implementation (this publication happens in late August and early September).

3.  Connectathon

OpenHIE Need: An exemplar software implementation needs to test conformance to an IHE profile

HIE profiles that are in final text or in trial implementation may be tested at Connectathon. The sign-up for Connectathon (CAT) is in September/October. Organizations indicate the systems they will test and the profiles they will test against. The North American CAT is at the end of January; it is held in Cleveland. The European CAT is hosted by a different IHE Europe country each year; it is usually held in mid-April (with a sign-up time of ~December). There have been, in recent years, Asian CATs that have been hosted alongside the HIMSS Asia conference; these have been hosted by different countries and the timing is usually ~November.

OpenHIE Need:  OpenHIE Needs to request a change to an existing profile

Change Proposals, or "CPs", may be brought to an IHE technical committee at any time. According to this process, they are assigned to a committee member to draft new language for the Trial Implementation(TI) profile to give effect to the CP. This is committee balloted. If it passes, it is submitted to full-member ballot.  CPs for "final text" have more governance surrounding them. This is because "final text" profiles have typically been in production in multiple products for multiple years. 

OpenHIE can interact with HIE by engaging in the CP process while simultaneously engaging in the workflow and release processes.  


Proposed changes to Workflow Template for next release

To support the process above, the following changes are proposed for the workflow templates.  

  1. Add "Test Cases"  - This should include a high-level list of the positive and Negative Cases that need to be tested 
  2. Add "Example Messages"  add a link to example messages to assist implementers in understanding the use case 
  3. Remove "Last modified" - the modified date is automatically handled by the Wiki.  
  • No labels


  1. Jennifer E Shivers can we clean this up and pull it onto the Workflow Documentation page?

  2. Jennifer E Shivers note from OHIE 101 session 

    • organize workflow page by approved workflows, progress workflows and project specific workflows
    • document process on how workflows are reached