Skip to end of metadata
Go to start of metadata

Specification Management and Workflow Processes

Purpose 

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

 Specification Process Triggers  

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


Release ActivityDescription
  1.  Establish Specification Publication Timeline
Determine the milestones for:  
  • Diagram Changes
  • Component Specifications Updates and Changes
  • Workflow Updates and Changes

  2. Propose Diagram Changes

Diagram changes can come from sub community work, the Architecture Community or other inputs.  

  3.  Determine and Make Diagram Changes 

The ARB will need to come to consensus on diagram changes.  

 4.  Create / Update Component Specification

The OpenHIE sub communities will review the specifications for the component(s) supported by their sub community and update them as appropriate.  
  5.  Review Component SpecificationsThe ARB will need to review and approve the component specifications.  
  6.  Propose Workflow Additions and ChangesAs sub communities and implementers work through health information exchange processes (workflows), these will need to be shared with the Architecture Community. 
  7.  Determine and Make Workflow ChangesWorkflow specifications additions and changes will be approved by the ARB.
  8.  Publish SpecificationThe specification will be made available from the OHIE web site.  Appropriate communications such as blog posts and discourse messages will be created to share the specification.  


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 (if needed) Register for IHE or other conformance testing 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.


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.  


  • No labels

2 Comments

  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