For your review: Draft of a high-level process for incorporating new workflows into OpenHIE

All,

As we further refine the architecture group process and membership, I wanted to stimulate discussion by sharing with you a high-level 6-step process (“life-cycle”?) anticipating how new health information exchange workflows may be incorporated into OpenHIE.

By articulating these types of processes, the emerging roles of the architecture group, workflow sponsors, interoperability specifications, etc., can be drawn into clearer focus. Note that this initial process description largely describes “what” will be done, not “by whom” or “how” these steps may be accomplished.

Needless to say, this is an early draft and we hope to get your feedback both via the discussion group and on an upcoming architecture group call. I look forward to hearing your thoughts!

Best,

Shaun

1. Propose New workflows.

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.)

2. Establish Workflow Sponsor.

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

3. 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.)

4. Design 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.

5. Develop Workflow Functionality.

Given requirements and design, augment or create new functionality within OpenHIE components to support new workflow.

6. Test and validate Workflow.

The newly designed and developed workflow shall be validated in a test environment, e.g. the OpenHIE sandbox. 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.

Hi Shaun,

This is looking good. I agree with the steps. Just one comment: for number 1, when new workflows are proposed how should we decide if they are accepted or appropriate for OpenHIE. Should they be brought to the ARB for discussion before we decide that they will be supported as OpenHIE workflows?

Cheers,

Ryan

···

On Mon, Apr 7, 2014 at 4:58 PM, Shaun Grannis sgrannis@gmail.com wrote:

All,

As we further refine the architecture group process and membership, I wanted to stimulate discussion by sharing with you a high-level 6-step process (“life-cycle”?) anticipating how new health information exchange workflows may be incorporated into OpenHIE.

By articulating these types of processes, the emerging roles of the architecture group, workflow sponsors, interoperability specifications, etc., can be drawn into clearer focus. Note that this initial process description largely describes “what” will be done, not “by whom” or “how” these steps may be accomplished.

Needless to say, this is an early draft and we hope to get your feedback both via the discussion group and on an upcoming architecture group call. I look forward to hearing your thoughts!

Best,

Shaun

1. Propose New workflows.

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.)

2. Establish Workflow Sponsor.

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

3. 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.)

4. Design 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.

5. Develop Workflow Functionality.

Given requirements and design, augment or create new functionality within OpenHIE components to support new workflow.

6. Test and validate Workflow.

The newly designed and developed workflow shall be validated in a test environment, e.g. the OpenHIE sandbox. 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.

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org