This information will be changing in the 4.0 of the OpenHIE Architecture Specification
Specification Management and Workflow Processes
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.
Determine the milestones for:
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 Specifications||The ARB will need to review and approve the component specifications.|
|6. Propose Workflow Additions and Changes||As 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 Changes||Workflow specifications additions and changes will be approved by the ARB.|
|8. Publish Specification||The 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.)
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.
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 Milestones||Description|
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).
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.