OHIE Guidebook Outline and Framework Recommendations

Hello everyone,

I wanted to share some analysis that has been drafted into a
high level outline in an attempt to synthesize the OpenHIE (“OHIE”) framework,
as an OHIE Guidebook. Within the list below you will see a
suggested list of categories and concepts for the OHIE Guidebook, which we are
proposing for discussion within the OHIE Community.

Can I ask for suggestions from the OHIE Community to firm up
this list? I think we can start the conversation here and then open it up to
the other OHIE Community lists (e.g. Architecture, Shared Health Record,
Terminology Services, etc.). I have been participating in many of the Architecture
calls and Security and Privacy discussions, and have been working on redrafting
a requirements framework for the Shared Health Record. I would personally be
interested in discussing further these elements, but any and all categories of
OpenHIE is of interest.

I look forward to further discussions.

Thanks,

Brian

Regards

Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

OHIE Guidebook Table of Contents (proposed)

  • Introduction

  • What is OpenHIE?

  • The Architecture

  • Design Principles

  • Client Registry (CR)

  • Facilities Registry (FR)

  • Health Worker / Provider Registry (HWR / PR)

  • Shared Health Record (SHR)

  • Terminology Service (TS)

  • Interoperability Layer

  •   Standards (existing standards and future
    

    standards in OHIE)

  • The Tools (e.g. MIRTH Connect, OpenHIM, etc.)

  • The Community

  • General

  • Regional Forums

  • National Forums

  • Client Registry Community

  • Facilities Registry Community

  •    Health Management Information Systems
    

    Community

  • Health Worker Registry Community

  • Interoperability Layer Community

  • PEPFAR Data Exchange Community

  • Shared Health Record Community

  • Terminology Services Community

  • What it’s NOT

  • Not an EHR

  • Not a Laboratory Information System

  • Not a Pharmacy Information System

  • Not a…* more
    ideas?*

  • Getting Engaged

  • Why OpenHIE?

  • The Business Problem

  • The Data Problem

  • The Technology Problem

  • The Interop Problem

  • Designing based on OpenHIE

  • A fit for purpose architecture

  •   Implementation / architecture pattern (something
    

    like this)

  • How to Implement OpenHIE

  • Minimum requirements

  • Mine existing Implementation Guides

  • Implementation patterns

  •    Rapid HIE Solution - “I need to implement HIE
    

    end-to-end but I only have 40 hours, what can I accomplish?”

  • HIE-in-a-Box / Turnkey / Sandbox Solutions

  •     Virtual machines representing the core
    

    components of HIE pre-configured to be accessible out of the box. Using
    open source systems (e.g. OpenMRS, OpenHIM, OpenLIMS, OpenLMIS, MIRTH
    Connect, DHIS2, etc.)

  •     Use environments: Dev / Test / Training /
    

    Conferences

  • Enterprise Solutions

  • Microsoft Windows based platforms

  • Not-necessarily-open-source

  • MSSQL and Oracle-based SQL servers

  • Commercial HL7 / FHIR tools

  • Commercial EHRs

  •   HIE Capability Model (reduced or expanded based
    

    upon requirements)

  • Core Functional Capabilities

  • Clinical Enabling Capabilities

  • Technical Enabling Capabilities

  • Minimum Enabling Capabilities

  • OpenHIE and Health Systems Mapping

  •    Potentially a foundation model of OpenHIE
    

    systems / components and which open source systems implement the OpenHIE
    architecture (i.e. Facilities Registry can be located in DHIS2).

  •    Designs of OpenHIE and mapping of systems for
    

    each particular country.

  • Interface development

  • Messaging framework (e.g. HL7, FHIR, etc.)

  • Governance

  • Privacy

  • Security

  • Owners / Sponsors

  • eHealth Framework

  • Regulatory Framework

  • Systems Framework

  • Data Standards

  • Maintenance and Lifecycle Management

  • Software Updates

  • Hardware Upgrades and Maintenance

  • Deprecation

  • Licensing (in the case of Enterprise Solutions)

  • Networks & Connectivity

  • Satellite

  • WiFi

  • Cellular Data (e.g. 3G, LTE, etc.)

  • Shared Networks

  • Partner Networks

  • Community Networks

  • ‘Sneaker-Net’

  • Resources

  • Consulting Services

  • Logistics Management Services

  • Program Development Services

  • Software and Program Development Services

  • References

  • OpenMRS

  • OpenHIM

  • DATIM

  • Support

  • IT Support

  • Contact Centre and Help Desk

  •  Document Management (e.g. Architecture and PMO
    

    Repositories, CMDB)

  •  Knowledge Management (e.g. Case Studies,
    

    Clinical guidelines, Use Cases, Workflows, etc.)

  • Training

  •   Certifications / Qualifications (i.e. lists and
    

    purpose)

  • Curriculum development

  • Offline / Online Training

  • Workshops

  • Train-the-Trainer

  • Case Studies (Existing Implementations)

  • Implementer Documented Implementations

  • RHIE

  • Etc

  • Glossary of terms

Hi Brian,

Thanks for initiating this. My suggestions:

Put the ‘Why OpenHIE’ at the first part to set the context. This could contain real work problems faced by the reader. This also levels off the audience on what problems ohie tries to solve.

Put a practical part at the end that tries to show how OpenHIE’is able to solve one of the problems mentioned in Why OpenHIE. Off the bat, one such problem might be integrating data from diverse EMRs into the SHR. Another might be transforming the SHR into an SDG regional report.

The group might want to answer a philosophical question at the outset as this will influence the flavor of the document:

Are we presenting this to car drivers or to the mechanics? Deciding on one helps us focus on the content. We can then do the next one for the other type and maybe another for car owners…

My two cents. I would like to contribute to the part on SHR to SDG…

Alvin

Hello everyone,

I wanted to share some analysis that has been drafted into a
high level outline in an attempt to synthesize the OpenHIE (“OHIE”) framework,
as an OHIE Guidebook. Within the list below you will see a
suggested list of categories and concepts for the OHIE Guidebook, which we are
proposing for discussion within the OHIE Community.

Can I ask for suggestions from the OHIE Community to firm up
this list? I think we can start the conversation here and then open it up to
the other OHIE Community lists (e.g. Architecture, Shared Health Record,
Terminology Services, etc.). I have been participating in many of the Architecture
calls and Security and Privacy discussions, and have been working on redrafting
a requirements framework for the Shared Health Record. I would personally be
interested in discussing further these elements, but any and all categories of
OpenHIE is of interest.

I look forward to further discussions.

Thanks,

Brian

Regards

Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

OHIE Guidebook Table of Contents (proposed)

  • Introduction

  • What is OpenHIE?

  • The Architecture

  • Design Principles

  • Client Registry (CR)

  • Facilities Registry (FR)

  • Health Worker / Provider Registry (HWR / PR)

  • Shared Health Record (SHR)

  • Terminology Service (TS)

  • Interoperability Layer

  •   Standards (existing standards and future
    

    standards in OHIE)

  • The Tools (e.g. MIRTH Connect, OpenHIM, etc.)

  • The Community

  • General

  • Regional Forums

  • National Forums

  • Client Registry Community

  • Facilities Registry Community

  •    Health Management Information Systems
    

    Community

  • Health Worker Registry Community

  • Interoperability Layer Community

  • PEPFAR Data Exchange Community

  • Shared Health Record Community

  • Terminology Services Community

  • What it’s NOT

  • Not an EHR

  • Not a Laboratory Information System

  • Not a Pharmacy Information System

  • Not a…* more
    ideas?*

  • Getting Engaged

  • Why OpenHIE?

  • The Business Problem

  • The Data Problem

  • The Technology Problem

  • The Interop Problem

  • Designing based on OpenHIE

  • A fit for purpose architecture

  •   Implementation / architecture pattern (something
    

    like this)

  • How to Implement OpenHIE

  • Minimum requirements

  • Mine existing Implementation Guides

  • Implementation patterns

  •    Rapid HIE Solution - “I need to implement HIE
    

    end-to-end but I only have 40 hours, what can I accomplish?”

  • HIE-in-a-Box / Turnkey / Sandbox Solutions

  •     Virtual machines representing the core
    

    components of HIE pre-configured to be accessible out of the box. Using
    open source systems (e.g. OpenMRS, OpenHIM, OpenLIMS, OpenLMIS, MIRTH
    Connect, DHIS2, etc.)

  •     Use environments: Dev / Test / Training /
    

    Conferences

  • Enterprise Solutions

  • Microsoft Windows based platforms

  • Not-necessarily-open-source

  • MSSQL and Oracle-based SQL servers

  • Commercial HL7 / FHIR tools

  • Commercial EHRs

  •   HIE Capability Model (reduced or expanded based
    

    upon requirements)

  • Core Functional Capabilities

  • Clinical Enabling Capabilities

  • Technical Enabling Capabilities

  • Minimum Enabling Capabilities

  • OpenHIE and Health Systems Mapping

  •    Potentially a foundation model of OpenHIE
    

    systems / components and which open source systems implement the OpenHIE
    architecture (i.e. Facilities Registry can be located in DHIS2).

  •    Designs of OpenHIE and mapping of systems for
    

    each particular country.

  • Interface development

  • Messaging framework (e.g. HL7, FHIR, etc.)

  • Governance

  • Privacy

  • Security

  • Owners / Sponsors

  • eHealth Framework

  • Regulatory Framework

  • Systems Framework

  • Data Standards

  • Maintenance and Lifecycle Management

  • Software Updates

  • Hardware Upgrades and Maintenance

  • Deprecation

  • Licensing (in the case of Enterprise Solutions)

  • Networks & Connectivity

  • Satellite

  • WiFi

  • Cellular Data (e.g. 3G, LTE, etc.)

  • Shared Networks

  • Partner Networks

  • Community Networks

  • ‘Sneaker-Net’

  • Resources

  • Consulting Services

  • Logistics Management Services

  • Program Development Services

  • Software and Program Development Services

  • References

  • OpenMRS

  • OpenHIM

  • DATIM

  • Support

  • IT Support

  • Contact Centre and Help Desk

  •  Document Management (e.g. Architecture and PMO
    

    Repositories, CMDB)

  •  Knowledge Management (e.g. Case Studies,
    

    Clinical guidelines, Use Cases, Workflows, etc.)

  • Training

  •   Certifications / Qualifications (i.e. lists and
    

    purpose)

  • Curriculum development

  • Offline / Online Training

  • Workshops

  • Train-the-Trainer

  • Case Studies (Existing Implementations)

  • Implementer Documented Implementations

  • RHIE

  • Etc

  • Glossary of terms

Brian this is great. Do you see this as a space on the wiki that we can point people to. Also I think much of the content could come from http://store.elsevier.com/Health-Information-Exchange/isbn-9780128031353 /,
which we have access to.

**Jamie Thomas **|****Health Information Project Manager/Communications

Center for Biomedical Informatics

F447BFA7-64CF-416E-9382-5383D9F359EA[15].png

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org | Skype: jamie.thomas5670 | Twitter: @RegenstriefGHI

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention,
disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

···

From: ohie-implementers@googlegroups.com on behalf of “alvin.marcelo@gmail.comalvin.marcelo@gmail.com

Reply-To: “admarcelo1@up.edu.ph” admarcelo1@up.edu.ph

Date: Friday, June 24, 2016 at 1:09 PM

To: “brian.armstrong@jembi.orgbrian.armstrong@jembi.org

Cc: “OpenHIE Implementers Network (OHIN)” ohie-implementers@googlegroups.com

Subject: Re: [ohie-implementers] OHIE Guidebook Outline and Framework Recommendations

Hi Brian,

Thanks for initiating this. My suggestions:

Put the ‘Why OpenHIE’ at the first part to set the context. This could contain real work problems faced by the reader. This also levels off the audience on what problems ohie tries to solve.

Put a practical part at the end that tries to show how OpenHIE’is able to solve one of the problems mentioned in Why OpenHIE. Off the bat, one such problem might be integrating data from diverse EMRs into the SHR. Another might be transforming
the SHR into an SDG regional report.

The group might want to answer a philosophical question at the outset as this will influence the flavor of the document:

Are we presenting this to car drivers or to the mechanics? Deciding on one helps us focus on the content. We can then do the next one for the other type and maybe another for car owners…

My two cents. I would like to contribute to the part on SHR to SDG…

Alvin

Hello everyone,

I wanted to share some analysis that has been drafted into a high level outline in an attempt to synthesize the OpenHIE (“OHIE”) framework, as an OHIE Guidebook. Within the list below you will see a suggested list of categories and concepts
for the OHIE Guidebook, which we are proposing for discussion within the OHIE Community.

Can I ask for suggestions from the OHIE Community to firm up this list? I think we can start the conversation here and then open it up to the other OHIE Community lists (e.g. Architecture, Shared Health Record, Terminology Services, etc.).
I have been participating in many of the Architecture calls and Security and Privacy discussions, and have been working on redrafting a requirements framework for the Shared Health Record. I would personally be interested in discussing further these elements,
but any and all categories of OpenHIE is of interest.

I look forward to further discussions.

Thanks,

Brian

Regards

Brian Armstrong*
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701
0939 | Skype: briankarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

OHIE Guidebook Table of Contents (proposed)

  • Introduction

  • What is OpenHIE?

    • The Architecture
      • Design Principles
      • Client Registry (CR)
      • Facilities Registry (FR)
      • Health Worker / Provider Registry (HWR / PR)
      • Shared Health Record (SHR)
      • Terminology Service (TS)
      • Interoperability Layer
    • Standards (existing standards and future standards in OHIE)
    • The Tools (e.g. MIRTH Connect, OpenHIM, etc.)
    • The Community
      • General
      • Regional Forums
      • National Forums
      • Client Registry Community
      • Facilities Registry Community
      • Health Management Information Systems Community
      • Health Worker Registry Community
      • Interoperability Layer Community
      • PEPFAR Data Exchange Community
      • Shared Health Record Community
      • Terminology Services Community
  • What it’s NOT

    • Not an EHR
    • Not a Laboratory Information System
    • Not a Pharmacy Information System
    • Not a…more ideas?
  • Getting Engaged

  • Why OpenHIE?

    • The Business Problem
    • The Data Problem
    • The Technology Problem
    • The Interop Problem
  • Designing based on OpenHIE

    • A fit for purpose architecture
    • Implementation / architecture pattern (something like this)
  • How to Implement OpenHIE

    • Minimum requirements
    • Mine existing Implementation Guides
    • Implementation patterns
      • Rapid HIE Solution - “I need to implement HIE end-to-end but I only have 40 hours, what can I accomplish?”
      • HIE-in-a-Box / Turnkey / Sandbox Solutions
  • Virtual machines representing the core components of HIE pre-configured to be accessible out of the box. Using open source systems (e.g. OpenMRS, OpenHIM, OpenLIMS, OpenLMIS, MIRTH Connect, DHIS2, etc.)

  • Use environments: Dev / Test / Training / Conferences

  • Enterprise Solutions

    • Microsoft Windows based platforms
    • Not-necessarily-open-source
    • MSSQL and Oracle-based SQL servers
    • Commercial HL7 / FHIR tools
    • Commercial EHRs
  • HIE Capability Model (reduced or expanded based upon requirements)

    • Core Functional Capabilities
    • Clinical Enabling Capabilities
    • Technical Enabling Capabilities
    • Minimum Enabling Capabilities
  • OpenHIE and Health Systems Mapping

    • Potentially a foundation model of OpenHIE systems / components and which open source systems implement the OpenHIE architecture (i.e. Facilities Registry can be located in DHIS2).
    • Designs of OpenHIE and mapping of systems for each particular country.
  • Interface development

  • Messaging framework (e.g. HL7, FHIR, etc.)

  • Governance

    • Privacy
    • Security
    • Owners / Sponsors
    • eHealth Framework
    • Regulatory Framework
    • Systems Framework
    • Data Standards
  • Maintenance and Lifecycle Management

    • Software Updates
    • Hardware Upgrades and Maintenance
    • Deprecation
    • Licensing (in the case of Enterprise Solutions)
  • Networks & Connectivity

    • Satellite
    • WiFi
    • Cellular Data (e.g. 3G, LTE, etc.)
    • Shared Networks
    • Partner Networks
    • Community Networks
    • ‘Sneaker-Net’
  • Resources

    • Consulting Services
    • Logistics Management Services
    • Program Development Services
    • Software and Program Development Services
  • References

    • OpenMRS
    • OpenHIM
    • DATIM
  • Support

    • IT Support
    • Contact Centre and Help Desk
  • Document Management (e.g. Architecture and PMO Repositories, CMDB)

  • Knowledge Management (e.g. Case Studies, Clinical guidelines, Use Cases, Workflows, etc.)

  • Training

    • Certifications / Qualifications (i.e. lists and purpose)
    • Curriculum development
    • Offline / Online Training
    • Workshops
    • Train-the-Trainer
  • Case Studies (Existing Implementations)

    • Implementer Documented Implementations
    • RHIE
    • Etc
  • Glossary of terms

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to
ohie-implementers@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-implementers/CAEHg8%2BJg%2BJRo5KK4fhFNSWmNc8pn4SJ5Sv3%3DVRLv_iyS6PpXkA%40mail.gmail.com
.

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

Just to be clear, I was using analogies.

Mechanics are those who need to understand the underlying engine of the ohie and how it works so they can fix it when broken or optimize it.

The drivers need to know just enough to navigate the ohie and use it for business benefit.

The car owners are the executives who buy/gas up the car and pay the drivers and mechanics. They sit at the back and look good all the time!

···

On Jun 25, 2016 1:09 AM, “Alvin Marcelo” alvin.marcelo@gmail.com wrote:

Hi Brian,

Thanks for initiating this. My suggestions:

Put the ‘Why OpenHIE’ at the first part to set the context. This could contain real work problems faced by the reader. This also levels off the audience on what problems ohie tries to solve.

Put a practical part at the end that tries to show how OpenHIE’is able to solve one of the problems mentioned in Why OpenHIE. Off the bat, one such problem might be integrating data from diverse EMRs into the SHR. Another might be transforming the SHR into an SDG regional report.

The group might want to answer a philosophical question at the outset as this will influence the flavor of the document:

Are we presenting this to car drivers or to the mechanics? Deciding on one helps us focus on the content. We can then do the next one for the other type and maybe another for car owners…

My two cents. I would like to contribute to the part on SHR to SDG…

Alvin

Hello everyone,

I wanted to share some analysis that has been drafted into a
high level outline in an attempt to synthesize the OpenHIE (“OHIE”) framework,
as an OHIE Guidebook. Within the list below you will see a
suggested list of categories and concepts for the OHIE Guidebook, which we are
proposing for discussion within the OHIE Community.

Can I ask for suggestions from the OHIE Community to firm up
this list? I think we can start the conversation here and then open it up to
the other OHIE Community lists (e.g. Architecture, Shared Health Record,
Terminology Services, etc.). I have been participating in many of the Architecture
calls and Security and Privacy discussions, and have been working on redrafting
a requirements framework for the Shared Health Record. I would personally be
interested in discussing further these elements, but any and all categories of
OpenHIE is of interest.

I look forward to further discussions.

Thanks,

Brian

Regards

Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

OHIE Guidebook Table of Contents (proposed)

  • Introduction
  • What is OpenHIE?
  • The Architecture
  • Design Principles
  • Client Registry (CR)
  • Facilities Registry (FR)
  • Health Worker / Provider Registry (HWR / PR)
  • Shared Health Record (SHR)
  • Terminology Service (TS)
  • Interoperability Layer
  •   Standards (existing standards and future
    
    standards in OHIE)
  • The Tools (e.g. MIRTH Connect, OpenHIM, etc.)
  • The Community
  • General
  • Regional Forums
  • National Forums
  • Client Registry Community
  • Facilities Registry Community
  •    Health Management Information Systems
    
    Community
  • Health Worker Registry Community
  • Interoperability Layer Community
  • PEPFAR Data Exchange Community
  • Shared Health Record Community
  • Terminology Services Community
  • What it’s NOT
  • Not an EHR
  • Not a Laboratory Information System
  • Not a Pharmacy Information System
  • Not a…* more
    ideas?*
  • Getting Engaged
  • Why OpenHIE?
  • The Business Problem
  • The Data Problem
  • The Technology Problem
  • The Interop Problem
  • Designing based on OpenHIE
  • A fit for purpose architecture
  •   Implementation / architecture pattern (something
    
    like this)
  • How to Implement OpenHIE
  • Minimum requirements
  • Mine existing Implementation Guides
  • Implementation patterns
  •    Rapid HIE Solution - “I need to implement HIE
    
    end-to-end but I only have 40 hours, what can I accomplish?”
  • HIE-in-a-Box / Turnkey / Sandbox Solutions
  •     Virtual machines representing the core
    
    components of HIE pre-configured to be accessible out of the box. Using
    open source systems (e.g. OpenMRS, OpenHIM, OpenLIMS, OpenLMIS, MIRTH
    Connect, DHIS2, etc.)
  •     Use environments: Dev / Test / Training /
    
    Conferences
  • Enterprise Solutions
  • Microsoft Windows based platforms
  • Not-necessarily-open-source
  • MSSQL and Oracle-based SQL servers
  • Commercial HL7 / FHIR tools
  • Commercial EHRs
  •   HIE Capability Model (reduced or expanded based
    
    upon requirements)
  • Core Functional Capabilities
  • Clinical Enabling Capabilities
  • Technical Enabling Capabilities
  • Minimum Enabling Capabilities
  • OpenHIE and Health Systems Mapping
  •    Potentially a foundation model of OpenHIE
    
    systems / components and which open source systems implement the OpenHIE
    architecture (i.e. Facilities Registry can be located in DHIS2).
  •    Designs of OpenHIE and mapping of systems for
    
    each particular country.
  • Interface development
  • Messaging framework (e.g. HL7, FHIR, etc.)
  • Governance
  • Privacy
  • Security
  • Owners / Sponsors
  • eHealth Framework
  • Regulatory Framework
  • Systems Framework
  • Data Standards
  • Maintenance and Lifecycle Management
  • Software Updates
  • Hardware Upgrades and Maintenance
  • Deprecation
  • Licensing (in the case of Enterprise Solutions)
  • Networks & Connectivity
  • Satellite
  • WiFi
  • Cellular Data (e.g. 3G, LTE, etc.)
  • Shared Networks
  • Partner Networks
  • Community Networks
  • ‘Sneaker-Net’
  • Resources
  • Consulting Services
  • Logistics Management Services
  • Program Development Services
  • Software and Program Development Services
  • References
  • OpenMRS
  • OpenHIM
  • DATIM
  • Support
  • IT Support
  • Contact Centre and Help Desk
  •  Document Management (e.g. Architecture and PMO
    
    Repositories, CMDB)
  •  Knowledge Management (e.g. Case Studies,
    
    Clinical guidelines, Use Cases, Workflows, etc.)
  • Training
  •   Certifications / Qualifications (i.e. lists and
    
    purpose)
  • Curriculum development
  • Offline / Online Training
  • Workshops
  • Train-the-Trainer
  • Case Studies (Existing Implementations)
  • Implementer Documented Implementations
  • RHIE
  • Etc
  • Glossary of terms

Hi Alvin,

Thanks for your comments. I agree, the framing of this is best to understand the audiences. I like your analogy (tip of the hat to your follow up email) of the mechanic versus the driver and the relationship of the OHIE in this context.

I concur that the first questions should be centred around why someone would choose and HIE and what is in it for them as a stakeholder. There was some thoughts expressed through the OHIN Wiki (https://wiki.ohie.org/display/SUB/OHIN+Wiki+content+suggestions) on potential views as being: 1) Country Implementers, 2) Domain Experts, 3) Developers. Could these be modified to ensure that all views are represented?

I also like your thoughts on integration of the SHR and EMRs though there is a diversity element that is played out differently in each country where Governments and Partners have combinations that are not necessarily homogeneous.

Perhaps this can also be a parallel discussion in order to map out a master list of SHR requirements, which I have been consolidating from many initiatives and the OHIE community. There is much work to be done here, but I’m also mindful of the need to ensure that what is compiled and designed works for low resource settings.

I would love to have feedback on this at some point, for now it is being vetted internally at Jembi.

Thanks and looking forward to more of this type of discussion.

Cheers,

Brian

···

On Fri, Jun 24, 2016 at 10:09 AM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Hi Brian,

Thanks for initiating this. My suggestions:

Put the ‘Why OpenHIE’ at the first part to set the context. This could contain real work problems faced by the reader. This also levels off the audience on what problems ohie tries to solve.

Put a practical part at the end that tries to show how OpenHIE’is able to solve one of the problems mentioned in Why OpenHIE. Off the bat, one such problem might be integrating data from diverse EMRs into the SHR. Another might be transforming the SHR into an SDG regional report.

The group might want to answer a philosophical question at the outset as this will influence the flavor of the document:

Are we presenting this to car drivers or to the mechanics? Deciding on one helps us focus on the content. We can then do the next one for the other type and maybe another for car owners…

My two cents. I would like to contribute to the part on SHR to SDG…

Alvin

Hello everyone,

I wanted to share some analysis that has been drafted into a
high level outline in an attempt to synthesize the OpenHIE (“OHIE”) framework,
as an OHIE Guidebook. Within the list below you will see a
suggested list of categories and concepts for the OHIE Guidebook, which we are
proposing for discussion within the OHIE Community.

Can I ask for suggestions from the OHIE Community to firm up
this list? I think we can start the conversation here and then open it up to
the other OHIE Community lists (e.g. Architecture, Shared Health Record,
Terminology Services, etc.). I have been participating in many of the Architecture
calls and Security and Privacy discussions, and have been working on redrafting
a requirements framework for the Shared Health Record. I would personally be
interested in discussing further these elements, but any and all categories of
OpenHIE is of interest.

I look forward to further discussions.

Thanks,

Brian

Regards

Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

OHIE Guidebook Table of Contents (proposed)

  • Introduction
  • What is OpenHIE?
  • The Architecture
  • Design Principles
  • Client Registry (CR)
  • Facilities Registry (FR)
  • Health Worker / Provider Registry (HWR / PR)
  • Shared Health Record (SHR)
  • Terminology Service (TS)
  • Interoperability Layer
  •   Standards (existing standards and future
    
    standards in OHIE)
  • The Tools (e.g. MIRTH Connect, OpenHIM, etc.)
  • The Community
  • General
  • Regional Forums
  • National Forums
  • Client Registry Community
  • Facilities Registry Community
  •    Health Management Information Systems
    
    Community
  • Health Worker Registry Community
  • Interoperability Layer Community
  • PEPFAR Data Exchange Community
  • Shared Health Record Community
  • Terminology Services Community
  • What it’s NOT
  • Not an EHR
  • Not a Laboratory Information System
  • Not a Pharmacy Information System
  • Not a…* more
    ideas?*
  • Getting Engaged
  • Why OpenHIE?
  • The Business Problem
  • The Data Problem
  • The Technology Problem
  • The Interop Problem
  • Designing based on OpenHIE
  • A fit for purpose architecture
  •   Implementation / architecture pattern (something
    
    like this)
  • How to Implement OpenHIE
  • Minimum requirements
  • Mine existing Implementation Guides
  • Implementation patterns
  •    Rapid HIE Solution - “I need to implement HIE
    
    end-to-end but I only have 40 hours, what can I accomplish?”
  • HIE-in-a-Box / Turnkey / Sandbox Solutions
  •     Virtual machines representing the core
    
    components of HIE pre-configured to be accessible out of the box. Using
    open source systems (e.g. OpenMRS, OpenHIM, OpenLIMS, OpenLMIS, MIRTH
    Connect, DHIS2, etc.)
  •     Use environments: Dev / Test / Training /
    
    Conferences
  • Enterprise Solutions
  • Microsoft Windows based platforms
  • Not-necessarily-open-source
  • MSSQL and Oracle-based SQL servers
  • Commercial HL7 / FHIR tools
  • Commercial EHRs
  •   HIE Capability Model (reduced or expanded based
    
    upon requirements)
  • Core Functional Capabilities
  • Clinical Enabling Capabilities
  • Technical Enabling Capabilities
  • Minimum Enabling Capabilities
  • OpenHIE and Health Systems Mapping
  •    Potentially a foundation model of OpenHIE
    
    systems / components and which open source systems implement the OpenHIE
    architecture (i.e. Facilities Registry can be located in DHIS2).
  •    Designs of OpenHIE and mapping of systems for
    
    each particular country.
  • Interface development
  • Messaging framework (e.g. HL7, FHIR, etc.)
  • Governance
  • Privacy
  • Security
  • Owners / Sponsors
  • eHealth Framework
  • Regulatory Framework
  • Systems Framework
  • Data Standards
  • Maintenance and Lifecycle Management
  • Software Updates
  • Hardware Upgrades and Maintenance
  • Deprecation
  • Licensing (in the case of Enterprise Solutions)
  • Networks & Connectivity
  • Satellite
  • WiFi
  • Cellular Data (e.g. 3G, LTE, etc.)
  • Shared Networks
  • Partner Networks
  • Community Networks
  • ‘Sneaker-Net’
  • Resources
  • Consulting Services
  • Logistics Management Services
  • Program Development Services
  • Software and Program Development Services
  • References
  • OpenMRS
  • OpenHIM
  • DATIM
  • Support
  • IT Support
  • Contact Centre and Help Desk
  •  Document Management (e.g. Architecture and PMO
    
    Repositories, CMDB)
  •  Knowledge Management (e.g. Case Studies,
    
    Clinical guidelines, Use Cases, Workflows, etc.)
  • Training
  •   Certifications / Qualifications (i.e. lists and
    
    purpose)
  • Curriculum development
  • Offline / Online Training
  • Workshops
  • Train-the-Trainer
  • Case Studies (Existing Implementations)
  • Implementer Documented Implementations
  • RHIE
  • Etc
  • Glossary of terms

Regards
Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

Hi Jamie,

I am going to put the OHIE Guidebook Table of Contents up on the Wiki. I will send a link shortly.

I don’t have access to the content at the link you shared. How do I get a copy of that resource document?

F447BFA7-64CF-416E-9382-5383D9F359EA[15].png

···

On Fri, Jun 24, 2016 at 10:15 AM, Thomas, Jamie jt48@regenstrief.org wrote:

Brian this is great. Do you see this as a space on the wiki that we can point people to. Also I think much of the content could come from http://store.elsevier.com/Health-Information-Exchange/isbn-9780128031353 /,
which we have access to.

**Jamie Thomas **|****Health Information Project Manager/Communications

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org | Skype: jamie.thomas5670 | Twitter: @RegenstriefGHI

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention,
disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

From: ohie-implementers@googlegroups.com on behalf of “alvin.marcelo@gmail.comalvin.marcelo@gmail.com

Reply-To: “admarcelo1@up.edu.ph” admarcelo1@up.edu.ph

Date: Friday, June 24, 2016 at 1:09 PM

To: “brian.armstrong@jembi.orgbrian.armstrong@jembi.org

Cc: “OpenHIE Implementers Network (OHIN)” ohie-implementers@googlegroups.com

Subject: Re: [ohie-implementers] OHIE Guidebook Outline and Framework Recommendations

Hi Brian,

Thanks for initiating this. My suggestions:

Put the ‘Why OpenHIE’ at the first part to set the context. This could contain real work problems faced by the reader. This also levels off the audience on what problems ohie tries to solve.

Put a practical part at the end that tries to show how OpenHIE’is able to solve one of the problems mentioned in Why OpenHIE. Off the bat, one such problem might be integrating data from diverse EMRs into the SHR. Another might be transforming
the SHR into an SDG regional report.

The group might want to answer a philosophical question at the outset as this will influence the flavor of the document:

Are we presenting this to car drivers or to the mechanics? Deciding on one helps us focus on the content. We can then do the next one for the other type and maybe another for car owners…

My two cents. I would like to contribute to the part on SHR to SDG…

Alvin

Hello everyone,

I wanted to share some analysis that has been drafted into a high level outline in an attempt to synthesize the OpenHIE (“OHIE”) framework, as an OHIE Guidebook. Within the list below you will see a suggested list of categories and concepts
for the OHIE Guidebook, which we are proposing for discussion within the OHIE Community.

Can I ask for suggestions from the OHIE Community to firm up this list? I think we can start the conversation here and then open it up to the other OHIE Community lists (e.g. Architecture, Shared Health Record, Terminology Services, etc.).
I have been participating in many of the Architecture calls and Security and Privacy discussions, and have been working on redrafting a requirements framework for the Shared Health Record. I would personally be interested in discussing further these elements,
but any and all categories of OpenHIE is of interest.

I look forward to further discussions.

Thanks,

Brian

Regards

Brian Armstrong*
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701
0939 | Skype: briankarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

OHIE Guidebook Table of Contents (proposed)

  • Introduction
  • What is OpenHIE?
    • The Architecture
      • Design Principles
      • Client Registry (CR)
      • Facilities Registry (FR)
      • Health Worker / Provider Registry (HWR / PR)
      • Shared Health Record (SHR)
      • Terminology Service (TS)
      • Interoperability Layer
    • Standards (existing standards and future standards in OHIE)
    • The Tools (e.g. MIRTH Connect, OpenHIM, etc.)
    • The Community
      • General
      • Regional Forums
      • National Forums
      • Client Registry Community
      • Facilities Registry Community
      • Health Management Information Systems Community
      • Health Worker Registry Community
      • Interoperability Layer Community
      • PEPFAR Data Exchange Community
      • Shared Health Record Community
      • Terminology Services Community
  • What it’s NOT
    • Not an EHR
    • Not a Laboratory Information System
    • Not a Pharmacy Information System
    • Not a…more ideas?
  • Getting Engaged
  • Why OpenHIE?
    • The Business Problem
    • The Data Problem
    • The Technology Problem
    • The Interop Problem
  • Designing based on OpenHIE
    • A fit for purpose architecture
    • Implementation / architecture pattern (something like this)
  • How to Implement OpenHIE
    • Minimum requirements
    • Mine existing Implementation Guides
    • Implementation patterns
      • Rapid HIE Solution - “I need to implement HIE end-to-end but I only have 40 hours, what can I accomplish?”
      • HIE-in-a-Box / Turnkey / Sandbox Solutions
  • Virtual machines representing the core components of HIE pre-configured to be accessible out of the box. Using open source systems (e.g. OpenMRS, OpenHIM, OpenLIMS, OpenLMIS, MIRTH Connect, DHIS2, etc.)
  • Use environments: Dev / Test / Training / Conferences
  • Enterprise Solutions
    • Microsoft Windows based platforms
    • Not-necessarily-open-source
    • MSSQL and Oracle-based SQL servers
    • Commercial HL7 / FHIR tools
    • Commercial EHRs
  • HIE Capability Model (reduced or expanded based upon requirements)
    • Core Functional Capabilities
    • Clinical Enabling Capabilities
    • Technical Enabling Capabilities
    • Minimum Enabling Capabilities
  • OpenHIE and Health Systems Mapping
    • Potentially a foundation model of OpenHIE systems / components and which open source systems implement the OpenHIE architecture (i.e. Facilities Registry can be located in DHIS2).
    • Designs of OpenHIE and mapping of systems for each particular country.
  • Interface development
  • Messaging framework (e.g. HL7, FHIR, etc.)
  • Governance
    • Privacy
    • Security
    • Owners / Sponsors
    • eHealth Framework
    • Regulatory Framework
    • Systems Framework
    • Data Standards
  • Maintenance and Lifecycle Management
    • Software Updates
    • Hardware Upgrades and Maintenance
    • Deprecation
    • Licensing (in the case of Enterprise Solutions)
  • Networks & Connectivity
    • Satellite
    • WiFi
    • Cellular Data (e.g. 3G, LTE, etc.)
    • Shared Networks
    • Partner Networks
    • Community Networks
    • ‘Sneaker-Net’
  • Resources
    • Consulting Services
    • Logistics Management Services
    • Program Development Services
    • Software and Program Development Services
  • References
    • OpenMRS
    • OpenHIM
    • DATIM
  • Support
    • IT Support
    • Contact Centre and Help Desk
  • Document Management (e.g. Architecture and PMO Repositories, CMDB)
  • Knowledge Management (e.g. Case Studies, Clinical guidelines, Use Cases, Workflows, etc.)
  • Training
    • Certifications / Qualifications (i.e. lists and purpose)
    • Curriculum development
    • Offline / Online Training
    • Workshops
    • Train-the-Trainer
  • Case Studies (Existing Implementations)
    • Implementer Documented Implementations
    • RHIE
    • Etc
  • Glossary of terms

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to
ohie-implementers@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-implementers/CAEHg8%2BJg%2BJRo5KK4fhFNSWmNc8pn4SJ5Sv3%3DVRLv_iyS6PpXkA%40mail.gmail.com
.

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

Regards
Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

Hi,

I have created a Wiki page with the OHIE Guidebook Table of Contents that was proposed at the start of this thread. Can we get the community to update this and suggest further modifications, and then we can start linking in the existing content, and produce new content to help solidify the use cases and requirements.

Thanks,

Brian

F447BFA7-64CF-416E-9382-5383D9F359EA[15].png

···

On Fri, Jun 24, 2016 at 2:16 PM, Brian Armstrong brian.armstrong@jembi.org wrote:

Hi Jamie,

I am going to put the OHIE Guidebook Table of Contents up on the Wiki. I will send a link shortly.

I don’t have access to the content at the link you shared. How do I get a copy of that resource document?

Regards
Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

Regards
Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

On Fri, Jun 24, 2016 at 10:15 AM, Thomas, Jamie jt48@regenstrief.org wrote:

Brian this is great. Do you see this as a space on the wiki that we can point people to. Also I think much of the content could come from http://store.elsevier.com/Health-Information-Exchange/isbn-9780128031353 /,
which we have access to.

**Jamie Thomas **|****Health Information Project Manager/Communications

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org | Skype: jamie.thomas5670 | Twitter: @RegenstriefGHI

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention,
disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

From: ohie-implementers@googlegroups.com on behalf of “alvin.marcelo@gmail.comalvin.marcelo@gmail.com

Reply-To: “admarcelo1@up.edu.ph” admarcelo1@up.edu.ph

Date: Friday, June 24, 2016 at 1:09 PM

To: “brian.armstrong@jembi.orgbrian.armstrong@jembi.org

Cc: “OpenHIE Implementers Network (OHIN)” ohie-implementers@googlegroups.com

Subject: Re: [ohie-implementers] OHIE Guidebook Outline and Framework Recommendations

Hi Brian,

Thanks for initiating this. My suggestions:

Put the ‘Why OpenHIE’ at the first part to set the context. This could contain real work problems faced by the reader. This also levels off the audience on what problems ohie tries to solve.

Put a practical part at the end that tries to show how OpenHIE’is able to solve one of the problems mentioned in Why OpenHIE. Off the bat, one such problem might be integrating data from diverse EMRs into the SHR. Another might be transforming
the SHR into an SDG regional report.

The group might want to answer a philosophical question at the outset as this will influence the flavor of the document:

Are we presenting this to car drivers or to the mechanics? Deciding on one helps us focus on the content. We can then do the next one for the other type and maybe another for car owners…

My two cents. I would like to contribute to the part on SHR to SDG…

Alvin

Hello everyone,

I wanted to share some analysis that has been drafted into a high level outline in an attempt to synthesize the OpenHIE (“OHIE”) framework, as an OHIE Guidebook. Within the list below you will see a suggested list of categories and concepts
for the OHIE Guidebook, which we are proposing for discussion within the OHIE Community.

Can I ask for suggestions from the OHIE Community to firm up this list? I think we can start the conversation here and then open it up to the other OHIE Community lists (e.g. Architecture, Shared Health Record, Terminology Services, etc.).
I have been participating in many of the Architecture calls and Security and Privacy discussions, and have been working on redrafting a requirements framework for the Shared Health Record. I would personally be interested in discussing further these elements,
but any and all categories of OpenHIE is of interest.

I look forward to further discussions.

Thanks,

Brian

Regards

Brian Armstrong*
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701
0939 | Skype: briankarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

OHIE Guidebook Table of Contents (proposed)

  • Introduction
  • What is OpenHIE?
    • The Architecture
      • Design Principles
      • Client Registry (CR)
      • Facilities Registry (FR)
      • Health Worker / Provider Registry (HWR / PR)
      • Shared Health Record (SHR)
      • Terminology Service (TS)
      • Interoperability Layer
    • Standards (existing standards and future standards in OHIE)
    • The Tools (e.g. MIRTH Connect, OpenHIM, etc.)
    • The Community
      • General
      • Regional Forums
      • National Forums
      • Client Registry Community
      • Facilities Registry Community
      • Health Management Information Systems Community
      • Health Worker Registry Community
      • Interoperability Layer Community
      • PEPFAR Data Exchange Community
      • Shared Health Record Community
      • Terminology Services Community
  • What it’s NOT
    • Not an EHR
    • Not a Laboratory Information System
    • Not a Pharmacy Information System
    • Not a…more ideas?
  • Getting Engaged
  • Why OpenHIE?
    • The Business Problem
    • The Data Problem
    • The Technology Problem
    • The Interop Problem
  • Designing based on OpenHIE
    • A fit for purpose architecture
    • Implementation / architecture pattern (something like this)
  • How to Implement OpenHIE
    • Minimum requirements
    • Mine existing Implementation Guides
    • Implementation patterns
      • Rapid HIE Solution - “I need to implement HIE end-to-end but I only have 40 hours, what can I accomplish?”
      • HIE-in-a-Box / Turnkey / Sandbox Solutions
  • Virtual machines representing the core components of HIE pre-configured to be accessible out of the box. Using open source systems (e.g. OpenMRS, OpenHIM, OpenLIMS, OpenLMIS, MIRTH Connect, DHIS2, etc.)
  • Use environments: Dev / Test / Training / Conferences
  • Enterprise Solutions
    • Microsoft Windows based platforms
    • Not-necessarily-open-source
    • MSSQL and Oracle-based SQL servers
    • Commercial HL7 / FHIR tools
    • Commercial EHRs
  • HIE Capability Model (reduced or expanded based upon requirements)
    • Core Functional Capabilities
    • Clinical Enabling Capabilities
    • Technical Enabling Capabilities
    • Minimum Enabling Capabilities
  • OpenHIE and Health Systems Mapping
    • Potentially a foundation model of OpenHIE systems / components and which open source systems implement the OpenHIE architecture (i.e. Facilities Registry can be located in DHIS2).
    • Designs of OpenHIE and mapping of systems for each particular country.
  • Interface development
  • Messaging framework (e.g. HL7, FHIR, etc.)
  • Governance
    • Privacy
    • Security
    • Owners / Sponsors
    • eHealth Framework
    • Regulatory Framework
    • Systems Framework
    • Data Standards
  • Maintenance and Lifecycle Management
    • Software Updates
    • Hardware Upgrades and Maintenance
    • Deprecation
    • Licensing (in the case of Enterprise Solutions)
  • Networks & Connectivity
    • Satellite
    • WiFi
    • Cellular Data (e.g. 3G, LTE, etc.)
    • Shared Networks
    • Partner Networks
    • Community Networks
    • ‘Sneaker-Net’
  • Resources
    • Consulting Services
    • Logistics Management Services
    • Program Development Services
    • Software and Program Development Services
  • References
    • OpenMRS
    • OpenHIM
    • DATIM
  • Support
    • IT Support
    • Contact Centre and Help Desk
  • Document Management (e.g. Architecture and PMO Repositories, CMDB)
  • Knowledge Management (e.g. Case Studies, Clinical guidelines, Use Cases, Workflows, etc.)
  • Training
    • Certifications / Qualifications (i.e. lists and purpose)
    • Curriculum development
    • Offline / Online Training
    • Workshops
    • Train-the-Trainer
  • Case Studies (Existing Implementations)
    • Implementer Documented Implementations
    • RHIE
    • Etc
  • Glossary of terms

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to
ohie-implementers@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-implementers/CAEHg8%2BJg%2BJRo5KK4fhFNSWmNc8pn4SJ5Sv3%3DVRLv_iyS6PpXkA%40mail.gmail.com
.

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

Thanks for posting this Brian

I think it is a good way to bring in some of the questions that are floating out there and where the “what would you like to see of the OHIN wiki?” question’s answers could feed into. Alvin I agree that the framing of the audiance is important and in some internal discussions we had thought of creating “entry points” for the 3 types of users that teh OHIN is looking to support (Brian laid these out earlier). It would be great to start getting some of that content into the pages and this may actually be a good place to propose a call? to discuss this moving forward?

Thoughts from the Network?

F447BFA7-64CF-416E-9382-5383D9F359EA[15].png

···

On Mon, Jun 27, 2016 at 8:56 AM, Brian Armstrong brian.armstrong@jembi.org wrote:

Hi,

I have created a Wiki page with the OHIE Guidebook Table of Contents that was proposed at the start of this thread. Can we get the community to update this and suggest further modifications, and then we can start linking in the existing content, and produce new content to help solidify the use cases and requirements.

Thanks,

Brian

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAKRUSZWZKqr_Xtp8N7cp1viWLJa2H4iTAy1RWSWoDgcy-zOwRw%40mail.gmail.com.

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

Regards
Carl Fourie

Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl.fourie@jembi.org

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

Regards
Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

On Fri, Jun 24, 2016 at 2:16 PM, Brian Armstrong brian.armstrong@jembi.org wrote:

Hi Jamie,

I am going to put the OHIE Guidebook Table of Contents up on the Wiki. I will send a link shortly.

I don’t have access to the content at the link you shared. How do I get a copy of that resource document?

Regards
Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

On Fri, Jun 24, 2016 at 10:15 AM, Thomas, Jamie jt48@regenstrief.org wrote:

Brian this is great. Do you see this as a space on the wiki that we can point people to. Also I think much of the content could come from http://store.elsevier.com/Health-Information-Exchange/isbn-9780128031353 /,
which we have access to.

**Jamie Thomas **|****Health Information Project Manager/Communications

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org | Skype: jamie.thomas5670 | Twitter: @RegenstriefGHI

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention,
disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

From: ohie-implementers@googlegroups.com on behalf of “alvin.marcelo@gmail.comalvin.marcelo@gmail.com

Reply-To: “admarcelo1@up.edu.ph” admarcelo1@up.edu.ph

Date: Friday, June 24, 2016 at 1:09 PM

To: “brian.armstrong@jembi.orgbrian.armstrong@jembi.org

Cc: “OpenHIE Implementers Network (OHIN)” ohie-implementers@googlegroups.com

Subject: Re: [ohie-implementers] OHIE Guidebook Outline and Framework Recommendations

Hi Brian,

Thanks for initiating this. My suggestions:

Put the ‘Why OpenHIE’ at the first part to set the context. This could contain real work problems faced by the reader. This also levels off the audience on what problems ohie tries to solve.

Put a practical part at the end that tries to show how OpenHIE’is able to solve one of the problems mentioned in Why OpenHIE. Off the bat, one such problem might be integrating data from diverse EMRs into the SHR. Another might be transforming
the SHR into an SDG regional report.

The group might want to answer a philosophical question at the outset as this will influence the flavor of the document:

Are we presenting this to car drivers or to the mechanics? Deciding on one helps us focus on the content. We can then do the next one for the other type and maybe another for car owners…

My two cents. I would like to contribute to the part on SHR to SDG…

Alvin

Hello everyone,

I wanted to share some analysis that has been drafted into a high level outline in an attempt to synthesize the OpenHIE (“OHIE”) framework, as an OHIE Guidebook. Within the list below you will see a suggested list of categories and concepts
for the OHIE Guidebook, which we are proposing for discussion within the OHIE Community.

Can I ask for suggestions from the OHIE Community to firm up this list? I think we can start the conversation here and then open it up to the other OHIE Community lists (e.g. Architecture, Shared Health Record, Terminology Services, etc.).
I have been participating in many of the Architecture calls and Security and Privacy discussions, and have been working on redrafting a requirements framework for the Shared Health Record. I would personally be interested in discussing further these elements,
but any and all categories of OpenHIE is of interest.

I look forward to further discussions.

Thanks,

Brian

Regards

Brian Armstrong*
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701
0939 | Skype: briankarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

OHIE Guidebook Table of Contents (proposed)

  • Introduction
  • What is OpenHIE?
    • The Architecture
      • Design Principles
      • Client Registry (CR)
      • Facilities Registry (FR)
      • Health Worker / Provider Registry (HWR / PR)
      • Shared Health Record (SHR)
      • Terminology Service (TS)
      • Interoperability Layer
    • Standards (existing standards and future standards in OHIE)
    • The Tools (e.g. MIRTH Connect, OpenHIM, etc.)
    • The Community
      • General
      • Regional Forums
      • National Forums
      • Client Registry Community
      • Facilities Registry Community
      • Health Management Information Systems Community
      • Health Worker Registry Community
      • Interoperability Layer Community
      • PEPFAR Data Exchange Community
      • Shared Health Record Community
      • Terminology Services Community
  • What it’s NOT
    • Not an EHR
    • Not a Laboratory Information System
    • Not a Pharmacy Information System
    • Not a…more ideas?
  • Getting Engaged
  • Why OpenHIE?
    • The Business Problem
    • The Data Problem
    • The Technology Problem
    • The Interop Problem
  • Designing based on OpenHIE
    • A fit for purpose architecture
    • Implementation / architecture pattern (something like this)
  • How to Implement OpenHIE
    • Minimum requirements
    • Mine existing Implementation Guides
    • Implementation patterns
      • Rapid HIE Solution - “I need to implement HIE end-to-end but I only have 40 hours, what can I accomplish?”
      • HIE-in-a-Box / Turnkey / Sandbox Solutions
  • Virtual machines representing the core components of HIE pre-configured to be accessible out of the box. Using open source systems (e.g. OpenMRS, OpenHIM, OpenLIMS, OpenLMIS, MIRTH Connect, DHIS2, etc.)
  • Use environments: Dev / Test / Training / Conferences
  • Enterprise Solutions
    • Microsoft Windows based platforms
    • Not-necessarily-open-source
    • MSSQL and Oracle-based SQL servers
    • Commercial HL7 / FHIR tools
    • Commercial EHRs
  • HIE Capability Model (reduced or expanded based upon requirements)
    • Core Functional Capabilities
    • Clinical Enabling Capabilities
    • Technical Enabling Capabilities
    • Minimum Enabling Capabilities
  • OpenHIE and Health Systems Mapping
    • Potentially a foundation model of OpenHIE systems / components and which open source systems implement the OpenHIE architecture (i.e. Facilities Registry can be located in DHIS2).
    • Designs of OpenHIE and mapping of systems for each particular country.
  • Interface development
  • Messaging framework (e.g. HL7, FHIR, etc.)
  • Governance
    • Privacy
    • Security
    • Owners / Sponsors
    • eHealth Framework
    • Regulatory Framework
    • Systems Framework
    • Data Standards
  • Maintenance and Lifecycle Management
    • Software Updates
    • Hardware Upgrades and Maintenance
    • Deprecation
    • Licensing (in the case of Enterprise Solutions)
  • Networks & Connectivity
    • Satellite
    • WiFi
    • Cellular Data (e.g. 3G, LTE, etc.)
    • Shared Networks
    • Partner Networks
    • Community Networks
    • ‘Sneaker-Net’
  • Resources
    • Consulting Services
    • Logistics Management Services
    • Program Development Services
    • Software and Program Development Services
  • References
    • OpenMRS
    • OpenHIM
    • DATIM
  • Support
    • IT Support
    • Contact Centre and Help Desk
  • Document Management (e.g. Architecture and PMO Repositories, CMDB)
  • Knowledge Management (e.g. Case Studies, Clinical guidelines, Use Cases, Workflows, etc.)
  • Training
    • Certifications / Qualifications (i.e. lists and purpose)
    • Curriculum development
    • Offline / Online Training
    • Workshops
    • Train-the-Trainer
  • Case Studies (Existing Implementations)
    • Implementer Documented Implementations
    • RHIE
    • Etc
  • Glossary of terms

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to
ohie-implementers@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-implementers/CAEHg8%2BJg%2BJRo5KK4fhFNSWmNc8pn4SJ5Sv3%3DVRLv_iyS6PpXkA%40mail.gmail.com
.

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

Thanks for sharing this outline.

The first section on architecture I think should be quite detailed.

  • Design Principles

  • Client Registry (CR)

  • Facilities Registry (FR)

  • Health Worker / Provider Registry (HWR / PR)

  • Shared Health Record (SHR)

  • Terminology Service (TS)

  • Interoperability Layer
    I thought that for each component we could have content like this:

  • what is the component for?

  • how does the component facilitate interoperability ? (give concrete examples)

  • if the component stores data - what sort of data does it store? (give concrete, easy to read examples)

  • what are the “services” the component provides? How can external applications benefit from using those “services” when exchanging data with each other ? (give concrete examples from a variety of different interoperability use cases eg EMR talking to insurance system, supply chain system talking to facility admin system etc).

A big thing I am trying to understand is permissions: permissions-to-humans vs permissions-to-systems. I am not sure how that fits in in the table of contents.

Once again, I think framing a lot of content in terms of user stories or interoperability use cases would be very helpful.

Best wishes

Elaine

F447BFA7-64CF-416E-9382-5383D9F359EA[15].png

···

On 27 June 2016 at 11:06, Carl Fourie carl@jembi.org wrote:

Thanks for posting this Brian

I think it is a good way to bring in some of the questions that are floating out there and where the “what would you like to see of the OHIN wiki?” question’s answers could feed into. Alvin I agree that the framing of the audiance is important and in some internal discussions we had thought of creating “entry points” for the 3 types of users that teh OHIN is looking to support (Brian laid these out earlier). It would be great to start getting some of that content into the pages and this may actually be a good place to propose a call? to discuss this moving forward?

Thoughts from the Network?

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWiF2a%3DzB1BiaFHGp7hXY5nubpSoeTuQEZuni_g4YCOxwQ%40mail.gmail.com.

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

Regards
Carl Fourie

Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl.fourie@jembi.org

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

On Mon, Jun 27, 2016 at 8:56 AM, Brian Armstrong brian.armstrong@jembi.org wrote:

Hi,

I have created a Wiki page with the OHIE Guidebook Table of Contents that was proposed at the start of this thread. Can we get the community to update this and suggest further modifications, and then we can start linking in the existing content, and produce new content to help solidify the use cases and requirements.

Thanks,

Brian

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAKRUSZWZKqr_Xtp8N7cp1viWLJa2H4iTAy1RWSWoDgcy-zOwRw%40mail.gmail.com.

Regards
Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

On Fri, Jun 24, 2016 at 2:16 PM, Brian Armstrong brian.armstrong@jembi.org wrote:

Hi Jamie,

I am going to put the OHIE Guidebook Table of Contents up on the Wiki. I will send a link shortly.

I don’t have access to the content at the link you shared. How do I get a copy of that resource document?

Regards
Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

On Fri, Jun 24, 2016 at 10:15 AM, Thomas, Jamie jt48@regenstrief.org wrote:

Brian this is great. Do you see this as a space on the wiki that we can point people to. Also I think much of the content could come from http://store.elsevier.com/Health-Information-Exchange/isbn-9780128031353 /,
which we have access to.

**Jamie Thomas **|****Health Information Project Manager/Communications

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org | Skype: jamie.thomas5670 | Twitter: @RegenstriefGHI

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention,
disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

From: ohie-implementers@googlegroups.com on behalf of “alvin.marcelo@gmail.comalvin.marcelo@gmail.com

Reply-To: “admarcelo1@up.edu.ph” admarcelo1@up.edu.ph

Date: Friday, June 24, 2016 at 1:09 PM

To: “brian.armstrong@jembi.orgbrian.armstrong@jembi.org

Cc: “OpenHIE Implementers Network (OHIN)” ohie-implementers@googlegroups.com

Subject: Re: [ohie-implementers] OHIE Guidebook Outline and Framework Recommendations

Hi Brian,

Thanks for initiating this. My suggestions:

Put the ‘Why OpenHIE’ at the first part to set the context. This could contain real work problems faced by the reader. This also levels off the audience on what problems ohie tries to solve.

Put a practical part at the end that tries to show how OpenHIE’is able to solve one of the problems mentioned in Why OpenHIE. Off the bat, one such problem might be integrating data from diverse EMRs into the SHR. Another might be transforming
the SHR into an SDG regional report.

The group might want to answer a philosophical question at the outset as this will influence the flavor of the document:

Are we presenting this to car drivers or to the mechanics? Deciding on one helps us focus on the content. We can then do the next one for the other type and maybe another for car owners…

My two cents. I would like to contribute to the part on SHR to SDG…

Alvin

Hello everyone,

I wanted to share some analysis that has been drafted into a high level outline in an attempt to synthesize the OpenHIE (“OHIE”) framework, as an OHIE Guidebook. Within the list below you will see a suggested list of categories and concepts
for the OHIE Guidebook, which we are proposing for discussion within the OHIE Community.

Can I ask for suggestions from the OHIE Community to firm up this list? I think we can start the conversation here and then open it up to the other OHIE Community lists (e.g. Architecture, Shared Health Record, Terminology Services, etc.).
I have been participating in many of the Architecture calls and Security and Privacy discussions, and have been working on redrafting a requirements framework for the Shared Health Record. I would personally be interested in discussing further these elements,
but any and all categories of OpenHIE is of interest.

I look forward to further discussions.

Thanks,

Brian

Regards

Brian Armstrong*
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701
0939 | Skype: briankarmstrong

E-mail: brian.armstrong@jembi.org

Web: www.jembi.org

OHIE Guidebook Table of Contents (proposed)

  • Introduction
  • What is OpenHIE?
    • The Architecture
      • Design Principles
      • Client Registry (CR)
      • Facilities Registry (FR)
      • Health Worker / Provider Registry (HWR / PR)
      • Shared Health Record (SHR)
      • Terminology Service (TS)
      • Interoperability Layer
    • Standards (existing standards and future standards in OHIE)
    • The Tools (e.g. MIRTH Connect, OpenHIM, etc.)
    • The Community
      • General
      • Regional Forums
      • National Forums
      • Client Registry Community
      • Facilities Registry Community
      • Health Management Information Systems Community
      • Health Worker Registry Community
      • Interoperability Layer Community
      • PEPFAR Data Exchange Community
      • Shared Health Record Community
      • Terminology Services Community
  • What it’s NOT
    • Not an EHR
    • Not a Laboratory Information System
    • Not a Pharmacy Information System
    • Not a…more ideas?
  • Getting Engaged
  • Why OpenHIE?
    • The Business Problem
    • The Data Problem
    • The Technology Problem
    • The Interop Problem
  • Designing based on OpenHIE
    • A fit for purpose architecture
    • Implementation / architecture pattern (something like this)
  • How to Implement OpenHIE
    • Minimum requirements
    • Mine existing Implementation Guides
    • Implementation patterns
      • Rapid HIE Solution - “I need to implement HIE end-to-end but I only have 40 hours, what can I accomplish?”
      • HIE-in-a-Box / Turnkey / Sandbox Solutions
  • Virtual machines representing the core components of HIE pre-configured to be accessible out of the box. Using open source systems (e.g. OpenMRS, OpenHIM, OpenLIMS, OpenLMIS, MIRTH Connect, DHIS2, etc.)
  • Use environments: Dev / Test / Training / Conferences
  • Enterprise Solutions
    • Microsoft Windows based platforms
    • Not-necessarily-open-source
    • MSSQL and Oracle-based SQL servers
    • Commercial HL7 / FHIR tools
    • Commercial EHRs
  • HIE Capability Model (reduced or expanded based upon requirements)
    • Core Functional Capabilities
    • Clinical Enabling Capabilities
    • Technical Enabling Capabilities
    • Minimum Enabling Capabilities
  • OpenHIE and Health Systems Mapping
    • Potentially a foundation model of OpenHIE systems / components and which open source systems implement the OpenHIE architecture (i.e. Facilities Registry can be located in DHIS2).
    • Designs of OpenHIE and mapping of systems for each particular country.
  • Interface development
  • Messaging framework (e.g. HL7, FHIR, etc.)
  • Governance
    • Privacy
    • Security
    • Owners / Sponsors
    • eHealth Framework
    • Regulatory Framework
    • Systems Framework
    • Data Standards
  • Maintenance and Lifecycle Management
    • Software Updates
    • Hardware Upgrades and Maintenance
    • Deprecation
    • Licensing (in the case of Enterprise Solutions)
  • Networks & Connectivity
    • Satellite
    • WiFi
    • Cellular Data (e.g. 3G, LTE, etc.)
    • Shared Networks
    • Partner Networks
    • Community Networks
    • ‘Sneaker-Net’
  • Resources
    • Consulting Services
    • Logistics Management Services
    • Program Development Services
    • Software and Program Development Services
  • References
    • OpenMRS
    • OpenHIM
    • DATIM
  • Support
    • IT Support
    • Contact Centre and Help Desk
  • Document Management (e.g. Architecture and PMO Repositories, CMDB)
  • Knowledge Management (e.g. Case Studies, Clinical guidelines, Use Cases, Workflows, etc.)
  • Training
    • Certifications / Qualifications (i.e. lists and purpose)
    • Curriculum development
    • Offline / Online Training
    • Workshops
    • Train-the-Trainer
  • Case Studies (Existing Implementations)
    • Implementer Documented Implementations
    • RHIE
    • Etc
  • Glossary of terms

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to
ohie-implementers@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-implementers/CAEHg8%2BJg%2BJRo5KK4fhFNSWmNc8pn4SJ5Sv3%3DVRLv_iyS6PpXkA%40mail.gmail.com
.

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

Elaine Baker
+255715568512

Hi Elaine.

There is a slide deck on the OpenHIE wiki that gives a 30,000 ft overview of the architectural components and what they do. It is generally in lay terms and clearly does not go into nearly enough depth… but it is a start, and it might be a way to frame a deeper dive.

The deck is here: https://wiki.ohie.org/download/attachments/13926693/15-08-24%20OpenHIE's%20Architecture%20and%20its%20ComponentsDR.pptx?api=v2.

-DJ

···

On Monday, 27 June 2016 11:17:44 UTC-4, Elaine Baker wrote:

Thanks for sharing this outline.

The first section on architecture I think should be quite detailed.

  • Design Principles
  • Client Registry (CR)
  • Facilities Registry (FR)
  • Health Worker / Provider Registry (HWR / PR)
  • Shared Health Record (SHR)
  • Terminology Service (TS)
  • Interoperability Layer
    I thought that for each component we could have content like this:
  • what is the component for?
  • how does the component facilitate interoperability ? (give concrete examples)
  • if the component stores data - what sort of data does it store? (give concrete, easy to read examples)
  • what are the “services” the component provides? How can external applications benefit from using those “services” when exchanging data with each other ? (give concrete examples from a variety of different interoperability use cases eg EMR talking to insurance system, supply chain system talking to facility admin system etc).

A big thing I am trying to understand is permissions: permissions-to-humans vs permissions-to-systems. I am not sure how that fits in in the table of contents.

Once again, I think framing a lot of content in terms of user stories or interoperability use cases would be very helpful.

Best wishes

Elaine

On 27 June 2016 at 11:06, Carl Fourie ca...@jembi.org wrote:

Thanks for posting this Brian

I think it is a good way to bring in some of the questions that are floating out there and where the “what would you like to see of the OHIN wiki?” question’s answers could feed into. Alvin I agree that the framing of the audiance is important and in some internal discussions we had thought of creating “entry points” for the 3 types of users that teh OHIN is looking to support (Brian laid these out earlier). It would be great to start getting some of that content into the pages and this may actually be a good place to propose a call? to discuss this moving forward?

Thoughts from the Network?

Regards
Carl Fourie

Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl....@jembi.org

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

On Mon, Jun 27, 2016 at 8:56 AM, Brian Armstrong brian.a...@jembi.org wrote:

Hi,

I have created a Wiki page with the OHIE Guidebook Table of Contents that was proposed at the start of this thread. Can we get the community to update this and suggest further modifications, and then we can start linking in the existing content, and produce new content to help solidify the use cases and requirements.

Thanks,

Brian

Regards
Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.a...@jembi.org

Web: www.jembi.org

On Fri, Jun 24, 2016 at 2:16 PM, Brian Armstrong brian.a...@jembi.org wrote:

Hi Jamie,

I am going to put the OHIE Guidebook Table of Contents up on the Wiki. I will send a link shortly.

I don’t have access to the content at the link you shared. How do I get a copy of that resource document?

Regards
Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.a...@jembi.org

Web: www.jembi.org

On Fri, Jun 24, 2016 at 10:15 AM, Thomas, Jamie jt...@regenstrief.org wrote:

Brian this is great. Do you see this as a space on the wiki that we can point people to. Also I think much of the content could come from http://store.elsevier.com/Health-Information-Exchange/isbn-9780128031353 /,
which we have access to.

**Jamie Thomas **|****Health Information Project Manager/Communications

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt...@regenstrief.org | Skype: jamie.thomas5670 | Twitter: @RegenstriefGHI

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention,
disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

From: ohie-imp...@googlegroups.com on behalf of “alvin....@gmail.comalvin....@gmail.com

Reply-To: “admar…@up.edu.phadmar...@up.edu.ph

Date: Friday, June 24, 2016 at 1:09 PM

To: “brian.a...@jembi.orgbrian.a...@jembi.org

Cc: “OpenHIE Implementers Network (OHIN)” ohie-imp...@googlegroups.com

Subject: Re: [ohie-implementers] OHIE Guidebook Outline and Framework Recommendations

Hi Brian,

Thanks for initiating this. My suggestions:

Put the ‘Why OpenHIE’ at the first part to set the context. This could contain real work problems faced by the reader. This also levels off the audience on what problems ohie tries to solve.

Put a practical part at the end that tries to show how OpenHIE’is able to solve one of the problems mentioned in Why OpenHIE. Off the bat, one such problem might be integrating data from diverse EMRs into the SHR. Another might be transforming
the SHR into an SDG regional report.

The group might want to answer a philosophical question at the outset as this will influence the flavor of the document:

Are we presenting this to car drivers or to the mechanics? Deciding on one helps us focus on the content. We can then do the next one for the other type and maybe another for car owners…

My two cents. I would like to contribute to the part on SHR to SDG…

Alvin

Hello everyone,

I wanted to share some analysis that has been drafted into a high level outline in an attempt to synthesize the OpenHIE (“OHIE”) framework, as an OHIE Guidebook. Within the list below you will see a suggested list of categories and concepts
for the OHIE Guidebook, which we are proposing for discussion within the OHIE Community.

Can I ask for suggestions from the OHIE Community to firm up this list? I think we can start the conversation here and then open it up to the other OHIE Community lists (e.g. Architecture, Shared Health Record, Terminology Services, etc.).
I have been participating in many of the Architecture calls and Security and Privacy discussions, and have been working on redrafting a requirements framework for the Shared Health Record. I would personally be interested in discussing further these elements,
but any and all categories of OpenHIE is of interest.

I look forward to further discussions.

Thanks,

Brian

Regards

Brian Armstrong*
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701
0939 | Skype: briankarmstrong

E-mail: brian.a...@jembi.org

Web: www.jembi.org

OHIE Guidebook Table of Contents (proposed)

  • Introduction
  • What is OpenHIE?
    • The Architecture
      • Design Principles
      • Client Registry (CR)
      • Facilities Registry (FR)
      • Health Worker / Provider Registry (HWR / PR)
      • Shared Health Record (SHR)
      • Terminology Service (TS)
      • Interoperability Layer
    • Standards (existing standards and future standards in OHIE)
    • The Tools (e.g. MIRTH Connect, OpenHIM, etc.)
    • The Community
      • General
      • Regional Forums
      • National Forums
      • Client Registry Community
      • Facilities Registry Community
      • Health Management Information Systems Community
      • Health Worker Registry Community
      • Interoperability Layer Community
      • PEPFAR Data Exchange Community
      • Shared Health Record Community
      • Terminology Services Community
  • What it’s NOT
    • Not an EHR
    • Not a Laboratory Information System
    • Not a Pharmacy Information System
    • Not a…more ideas?
  • Getting Engaged
  • Why OpenHIE?
    • The Business Problem
    • The Data Problem
    • The Technology Problem
    • The Interop Problem
  • Designing based on OpenHIE
    • A fit for purpose architecture
    • Implementation / architecture pattern (something like this)
  • How to Implement OpenHIE
    • Minimum requirements
    • Mine existing Implementation Guides
    • Implementation patterns
      • Rapid HIE Solution - “I need to implement HIE end-to-end but I only have 40 hours, what can I accomplish?”
      • HIE-in-a-Box / Turnkey / Sandbox Solutions
  • Virtual machines representing the core components of HIE pre-configured to be accessible out of the box. Using open source systems (e.g. OpenMRS, OpenHIM, OpenLIMS, OpenLMIS, MIRTH Connect, DHIS2, etc.)
  • Use environments: Dev / Test / Training / Conferences
  • Enterprise Solutions
    • Microsoft Windows based platforms
    • Not-necessarily-open-source
    • MSSQL and Oracle-based SQL servers
    • Commercial HL7 / FHIR tools
    • Commercial EHRs
  • HIE Capability Model (reduced or expanded based upon requirements)
    • Core Functional Capabilities
    • Clinical Enabling Capabilities
    • Technical Enabling Capabilities
    • Minimum Enabling Capabilities
  • OpenHIE and Health Systems Mapping
    • Potentially a foundation model of OpenHIE systems / components and which open source systems implement the OpenHIE architecture (i.e. Facilities Registry can be located in DHIS2).
    • Designs of OpenHIE and mapping of systems for each particular country.
  • Interface development
  • Messaging framework (e.g. HL7, FHIR, etc.)
  • Governance
    • Privacy
    • Security
    • Owners / Sponsors
    • eHealth Framework
    • Regulatory Framework
    • Systems Framework
    • Data Standards
  • Maintenance and Lifecycle Management
    • Software Updates
    • Hardware Upgrades and Maintenance
    • Deprecation
    • Licensing (in the case of Enterprise Solutions)
  • Networks & Connectivity
    • Satellite
    • WiFi
    • Cellular Data (e.g. 3G, LTE, etc.)
    • Shared Networks
    • Partner Networks
    • Community Networks
    • ‘Sneaker-Net’
  • Resources
    • Consulting Services
    • Logistics Management Services
    • Program Development Services
    • Software and Program Development Services
  • References
    • OpenMRS
    • OpenHIM
    • DATIM
  • Support
    • IT Support
    • Contact Centre and Help Desk
  • Document Management (e.g. Architecture and PMO Repositories, CMDB)
  • Knowledge Management (e.g. Case Studies, Clinical guidelines, Use Cases, Workflows, etc.)
  • Training
    • Certifications / Qualifications (i.e. lists and purpose)
    • Curriculum development
    • Offline / Online Training
    • Workshops
    • Train-the-Trainer
  • Case Studies (Existing Implementations)
    • Implementer Documented Implementations
    • RHIE
    • Etc
  • Glossary of terms

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to
ohie-imp...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-implementers/CAEHg8%2BJg%2BJRo5KK4fhFNSWmNc8pn4SJ5Sv3%3DVRLv_iyS6PpXkA%40mail.gmail.com
.

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

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-imp...@googlegroups.com.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAKRUSZWZKqr_Xtp8N7cp1viWLJa2H4iTAy1RWSWoDgcy-zOwRw%40mail.gmail.com.

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-imp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWiF2a%3DzB1BiaFHGp7hXY5nubpSoeTuQEZuni_g4YCOxwQ%40mail.gmail.com.

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


Elaine Baker
+255715568512

Hi Elaine.

There are two notes which I think relate to your comments. First – one of the benefits of using standards-based IHE profiles (or one of the perceived/anticipated benefits, at least) is that these profiles are all very heavily documented and we (the OpenHIE community) felt that we could inherit this body of documentation and not need to replicate it. So… the behaviours of the puzzle pieces (e.g. client registry, CSD infomanager, etc.) is well-documented, including the APIs and the pre and post conditions and so on. Mercifully, the IHE profiles also include significant documentation regarding the use cases – so the “business” descriptions are also there (in Volume 1 of each profile). I think it would be useful for us to review this documentation and identify where we think there may be gaps. In your view, is the content for our 20 slides already present in these IHE documents?

Regarding the order of implementation – I would actually like us to consider the benefits of a full-install distro (an uber SETUP.EXE that lights up an entire HIE) versus the idea of standing up one piece or another piece. The premise that I’m advocating for is that OpenHIE becomes the “product”… and that even if only some bits are being used, all of the puzzle pieces are there. We are making really useful progress on being able to better do this. To be honest, if we can install an entire HIE in a half day or less… why would we bother with trying to come up with documentation around all the possible permutations and combinations of installing individual pieces in whatever order they might be lit up. Elaine (and others) – what do you think of this approach?

Warmest regards,

Derek.

···

On Tue, Aug 30, 2016 at 1:50 AM, Elaine Baker elaine.baker.work@gmail.com wrote:

Thank you Derek - that is a very nice overview of OpenHIE which mentions each component briefly and how it all works together.
I guess what I am asking for is the next step on from this - something which goes into more detail on each component. So for example about 20 slides on the client registry, 20 slides on the provider registry etc, suitable for a country considering focusing on implementing one of the components to start with. Something which talks about the services provided by the component, how data is written to and read from the component, de-dupication and matching, the sorts of data stored, and how that component could facilitate interoperability (even if the other components did not exist).

Also is there a recommended order for establishing the OpenHIE components ?

Best wishes

Elaine

On 27 August 2016 at 00:50, Derek Ritz derek.ritz@ecgroupinc.com wrote:

Hi Elaine.

There is a slide deck on the OpenHIE wiki that gives a 30,000 ft overview of the architectural components and what they do. It is generally in lay terms and clearly does not go into nearly enough depth… but it is a start, and it might be a way to frame a deeper dive.

The deck is here: https://wiki.ohie.org/download/attachments/13926693/15-08-24%20OpenHIE%27s%20Architecture%20and%20its%20ComponentsDR.pptx?api=v2.

-DJ

On Monday, 27 June 2016 11:17:44 UTC-4, Elaine Baker wrote:

Thanks for sharing this outline.

The first section on architecture I think should be quite detailed.

  • Design Principles
  • Client Registry (CR)
  • Facilities Registry (FR)
  • Health Worker / Provider Registry (HWR / PR)
  • Shared Health Record (SHR)
  • Terminology Service (TS)
  • Interoperability Layer
    I thought that for each component we could have content like this:
  • what is the component for?
  • how does the component facilitate interoperability ? (give concrete examples)
  • if the component stores data - what sort of data does it store? (give concrete, easy to read examples)
  • what are the “services” the component provides? How can external applications benefit from using those “services” when exchanging data with each other ? (give concrete examples from a variety of different interoperability use cases eg EMR talking to insurance system, supply chain system talking to facility admin system etc).

A big thing I am trying to understand is permissions: permissions-to-humans vs permissions-to-systems. I am not sure how that fits in in the table of contents.

Once again, I think framing a lot of content in terms of user stories or interoperability use cases would be very helpful.

Best wishes

Elaine

On 27 June 2016 at 11:06, Carl Fourie ca...@jembi.org wrote:

Thanks for posting this Brian

I think it is a good way to bring in some of the questions that are floating out there and where the “what would you like to see of the OHIN wiki?” question’s answers could feed into. Alvin I agree that the framing of the audiance is important and in some internal discussions we had thought of creating “entry points” for the 3 types of users that teh OHIN is looking to support (Brian laid these out earlier). It would be great to start getting some of that content into the pages and this may actually be a good place to propose a call? to discuss this moving forward?

Thoughts from the Network?

Regards
Carl Fourie

Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl....@jembi.org

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

On Mon, Jun 27, 2016 at 8:56 AM, Brian Armstrong brian.a...@jembi.org wrote:

Hi,

I have created a Wiki page with the OHIE Guidebook Table of Contents that was proposed at the start of this thread. Can we get the community to update this and suggest further modifications, and then we can start linking in the existing content, and produce new content to help solidify the use cases and requirements.

Thanks,

Brian

Regards
Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.a...@jembi.org

Web: www.jembi.org

On Fri, Jun 24, 2016 at 2:16 PM, Brian Armstrong brian.a...@jembi.org wrote:

Hi Jamie,

I am going to put the OHIE Guidebook Table of Contents up on the Wiki. I will send a link shortly.

I don’t have access to the content at the link you shared. How do I get a copy of that resource document?

Regards
Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.a...@jembi.org

Web: www.jembi.org

On Fri, Jun 24, 2016 at 10:15 AM, Thomas, Jamie jt...@regenstrief.org wrote:

Brian this is great. Do you see this as a space on the wiki that we can point people to. Also I think much of the content could come from http://store.elsevier.com/Health-Information-Exchange/isbn-9780128031353 /,
which we have access to.

**Jamie Thomas **|****Health Information Project Manager/Communications

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt...@regenstrief.org | Skype: jamie.thomas5670 | Twitter: @RegenstriefGHI

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention,
disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

From: ohie-imp...@googlegroups.com on behalf of “alvin....@gmail.comalvin....@gmail.com

Reply-To: “admar…@up.edu.phadmar...@up.edu.ph

Date: Friday, June 24, 2016 at 1:09 PM

To: “brian.a...@jembi.orgbrian.a...@jembi.org

Cc: “OpenHIE Implementers Network (OHIN)” ohie-imp...@googlegroups.com

Subject: Re: [ohie-implementers] OHIE Guidebook Outline and Framework Recommendations

Hi Brian,

Thanks for initiating this. My suggestions:

Put the ‘Why OpenHIE’ at the first part to set the context. This could contain real work problems faced by the reader. This also levels off the audience on what problems ohie tries to solve.

Put a practical part at the end that tries to show how OpenHIE’is able to solve one of the problems mentioned in Why OpenHIE. Off the bat, one such problem might be integrating data from diverse EMRs into the SHR. Another might be transforming
the SHR into an SDG regional report.

The group might want to answer a philosophical question at the outset as this will influence the flavor of the document:

Are we presenting this to car drivers or to the mechanics? Deciding on one helps us focus on the content. We can then do the next one for the other type and maybe another for car owners…

My two cents. I would like to contribute to the part on SHR to SDG…

Alvin

Hello everyone,

I wanted to share some analysis that has been drafted into a high level outline in an attempt to synthesize the OpenHIE (“OHIE”) framework, as an OHIE Guidebook. Within the list below you will see a suggested list of categories and concepts
for the OHIE Guidebook, which we are proposing for discussion within the OHIE Community.

Can I ask for suggestions from the OHIE Community to firm up this list? I think we can start the conversation here and then open it up to the other OHIE Community lists (e.g. Architecture, Shared Health Record, Terminology Services, etc.).
I have been participating in many of the Architecture calls and Security and Privacy discussions, and have been working on redrafting a requirements framework for the Shared Health Record. I would personally be interested in discussing further these elements,
but any and all categories of OpenHIE is of interest.

I look forward to further discussions.

Thanks,

Brian

Regards

Brian Armstrong*
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701
0939 | Skype: briankarmstrong

E-mail: brian.a...@jembi.org

Web: www.jembi.org

OHIE Guidebook Table of Contents (proposed)

  • Introduction
  • What is OpenHIE?
    • The Architecture
      • Design Principles
      • Client Registry (CR)
      • Facilities Registry (FR)
      • Health Worker / Provider Registry (HWR / PR)
      • Shared Health Record (SHR)
      • Terminology Service (TS)
      • Interoperability Layer
    • Standards (existing standards and future standards in OHIE)
    • The Tools (e.g. MIRTH Connect, OpenHIM, etc.)
    • The Community
      • General
      • Regional Forums
      • National Forums
      • Client Registry Community
      • Facilities Registry Community
      • Health Management Information Systems Community
      • Health Worker Registry Community
      • Interoperability Layer Community
      • PEPFAR Data Exchange Community
      • Shared Health Record Community
      • Terminology Services Community
  • What it’s NOT
    • Not an EHR
    • Not a Laboratory Information System
    • Not a Pharmacy Information System
    • Not a…more ideas?
  • Getting Engaged
  • Why OpenHIE?
    • The Business Problem
    • The Data Problem
    • The Technology Problem
    • The Interop Problem
  • Designing based on OpenHIE
    • A fit for purpose architecture
    • Implementation / architecture pattern (something like this)
  • How to Implement OpenHIE
    • Minimum requirements
    • Mine existing Implementation Guides
    • Implementation patterns
      • Rapid HIE Solution - “I need to implement HIE end-to-end but I only have 40 hours, what can I accomplish?”
      • HIE-in-a-Box / Turnkey / Sandbox Solutions
  • Virtual machines representing the core components of HIE pre-configured to be accessible out of the box. Using open source systems (e.g. OpenMRS, OpenHIM, OpenLIMS, OpenLMIS, MIRTH Connect, DHIS2, etc.)
  • Use environments: Dev / Test / Training / Conferences
  • Enterprise Solutions
    • Microsoft Windows based platforms
    • Not-necessarily-open-source
    • MSSQL and Oracle-based SQL servers
    • Commercial HL7 / FHIR tools
    • Commercial EHRs
  • HIE Capability Model (reduced or expanded based upon requirements)
    • Core Functional Capabilities
    • Clinical Enabling Capabilities
    • Technical Enabling Capabilities
    • Minimum Enabling Capabilities
  • OpenHIE and Health Systems Mapping
    • Potentially a foundation model of OpenHIE systems / components and which open source systems implement the OpenHIE architecture (i.e. Facilities Registry can be located in DHIS2).
    • Designs of OpenHIE and mapping of systems for each particular country.
  • Interface development
  • Messaging framework (e.g. HL7, FHIR, etc.)
  • Governance
    • Privacy
    • Security
    • Owners / Sponsors
    • eHealth Framework
    • Regulatory Framework
    • Systems Framework
    • Data Standards
  • Maintenance and Lifecycle Management
    • Software Updates
    • Hardware Upgrades and Maintenance
    • Deprecation
    • Licensing (in the case of Enterprise Solutions)
  • Networks & Connectivity
    • Satellite
    • WiFi
    • Cellular Data (e.g. 3G, LTE, etc.)
    • Shared Networks
    • Partner Networks
    • Community Networks
    • ‘Sneaker-Net’
  • Resources
    • Consulting Services
    • Logistics Management Services
    • Program Development Services
    • Software and Program Development Services
  • References
    • OpenMRS
    • OpenHIM
    • DATIM
  • Support
    • IT Support
    • Contact Centre and Help Desk
  • Document Management (e.g. Architecture and PMO Repositories, CMDB)
  • Knowledge Management (e.g. Case Studies, Clinical guidelines, Use Cases, Workflows, etc.)
  • Training
    • Certifications / Qualifications (i.e. lists and purpose)
    • Curriculum development
    • Offline / Online Training
    • Workshops
    • Train-the-Trainer
  • Case Studies (Existing Implementations)
    • Implementer Documented Implementations
    • RHIE
    • Etc
  • Glossary of terms

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to
ohie-imp...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-implementers/CAEHg8%2BJg%2BJRo5KK4fhFNSWmNc8pn4SJ5Sv3%3DVRLv_iyS6PpXkA%40mail.gmail.com
.

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

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-imp...@googlegroups.com.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAKRUSZWZKqr_Xtp8N7cp1viWLJa2H4iTAy1RWSWoDgcy-zOwRw%40mail.gmail.com.

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-imp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWiF2a%3DzB1BiaFHGp7hXY5nubpSoeTuQEZuni_g4YCOxwQ%40mail.gmail.com.

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

Elaine Baker
+255715568512

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/f18b6555-fc3d-44a7-a4cd-cc2e05c8891f%40googlegroups.com.

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

Elaine Baker
+255715568512

Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
www.ecgroupinc.com

Thanks for the useful discussion Derek

On existing documents, are you referring to the Grannis document on health information exchange? That is indeed a very useful document I think, and could form the basis of some slides. Or if you are referring to other documents could you point me to them?

On just installing OpenHIE out of a box - I think implementing OpenHIE or any of its components is a lot more than just running a setup. A lot of thought and consensus building has to go into firstly establishing what data should be exchanged between which systems, and then for each component establishing what people or systems have read and write access, deciding what the institutional mechanisms for updating the data in the different components are (and even establishing the “seed” data to start it off), deciding on fields to be included, deciding on matching algorithms, integrating existing systems with the components etc. So while it might be nice to do it all at once, I don’t think it is realistic - it is more realistic to go step by step. For example here in Tanzania we have a facility registry but we don’t yet have the other components. I would be interested in hearing whether it makes sense to do a provider registry next, then a client registry, then terminology services, then an interoperability layer, or do an interoperability layer before the other parts etc

Best wishes

Elaine

···

On 30 August 2016 at 16:21, Derek Ritz derek.ritz@ecgroupinc.com wrote:

Hi Elaine.

There are two notes which I think relate to your comments. First – one of the benefits of using standards-based IHE profiles (or one of the perceived/anticipated benefits, at least) is that these profiles are all very heavily documented and we (the OpenHIE community) felt that we could inherit this body of documentation and not need to replicate it. So… the behaviours of the puzzle pieces (e.g. client registry, CSD infomanager, etc.) is well-documented, including the APIs and the pre and post conditions and so on. Mercifully, the IHE profiles also include significant documentation regarding the use cases – so the “business” descriptions are also there (in Volume 1 of each profile). I think it would be useful for us to review this documentation and identify where we think there may be gaps. In your view, is the content for our 20 slides already present in these IHE documents?

Regarding the order of implementation – I would actually like us to consider the benefits of a full-install distro (an uber SETUP.EXE that lights up an entire HIE) versus the idea of standing up one piece or another piece. The premise that I’m advocating for is that OpenHIE becomes the “product”… and that even if only some bits are being used, all of the puzzle pieces are there. We are making really useful progress on being able to better do this. To be honest, if we can install an entire HIE in a half day or less… why would we bother with trying to come up with documentation around all the possible permutations and combinations of installing individual pieces in whatever order they might be lit up. Elaine (and others) – what do you think of this approach?

Warmest regards,

Derek.

On Tue, Aug 30, 2016 at 1:50 AM, Elaine Baker elaine.baker.work@gmail.com wrote:

Thank you Derek - that is a very nice overview of OpenHIE which mentions each component briefly and how it all works together.
I guess what I am asking for is the next step on from this - something which goes into more detail on each component. So for example about 20 slides on the client registry, 20 slides on the provider registry etc, suitable for a country considering focusing on implementing one of the components to start with. Something which talks about the services provided by the component, how data is written to and read from the component, de-dupication and matching, the sorts of data stored, and how that component could facilitate interoperability (even if the other components did not exist).

Also is there a recommended order for establishing the OpenHIE components ?

Best wishes

Elaine

Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
www.ecgroupinc.com

On 27 August 2016 at 00:50, Derek Ritz derek.ritz@ecgroupinc.com wrote:

Hi Elaine.

There is a slide deck on the OpenHIE wiki that gives a 30,000 ft overview of the architectural components and what they do. It is generally in lay terms and clearly does not go into nearly enough depth… but it is a start, and it might be a way to frame a deeper dive.

The deck is here: https://wiki.ohie.org/download/attachments/13926693/15-08-24%20OpenHIE%27s%20Architecture%20and%20its%20ComponentsDR.pptx?api=v2.

-DJ

On Monday, 27 June 2016 11:17:44 UTC-4, Elaine Baker wrote:

Thanks for sharing this outline.

The first section on architecture I think should be quite detailed.

  • Design Principles
  • Client Registry (CR)
  • Facilities Registry (FR)
  • Health Worker / Provider Registry (HWR / PR)
  • Shared Health Record (SHR)
  • Terminology Service (TS)
  • Interoperability Layer
    I thought that for each component we could have content like this:
  • what is the component for?
  • how does the component facilitate interoperability ? (give concrete examples)
  • if the component stores data - what sort of data does it store? (give concrete, easy to read examples)
  • what are the “services” the component provides? How can external applications benefit from using those “services” when exchanging data with each other ? (give concrete examples from a variety of different interoperability use cases eg EMR talking to insurance system, supply chain system talking to facility admin system etc).

A big thing I am trying to understand is permissions: permissions-to-humans vs permissions-to-systems. I am not sure how that fits in in the table of contents.

Once again, I think framing a lot of content in terms of user stories or interoperability use cases would be very helpful.

Best wishes

Elaine

On 27 June 2016 at 11:06, Carl Fourie ca...@jembi.org wrote:

Thanks for posting this Brian

I think it is a good way to bring in some of the questions that are floating out there and where the “what would you like to see of the OHIN wiki?” question’s answers could feed into. Alvin I agree that the framing of the audiance is important and in some internal discussions we had thought of creating “entry points” for the 3 types of users that teh OHIN is looking to support (Brian laid these out earlier). It would be great to start getting some of that content into the pages and this may actually be a good place to propose a call? to discuss this moving forward?

Thoughts from the Network?

Regards
Carl Fourie

Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl....@jembi.org

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

On Mon, Jun 27, 2016 at 8:56 AM, Brian Armstrong brian.a...@jembi.org wrote:

Hi,

I have created a Wiki page with the OHIE Guidebook Table of Contents that was proposed at the start of this thread. Can we get the community to update this and suggest further modifications, and then we can start linking in the existing content, and produce new content to help solidify the use cases and requirements.

Thanks,

Brian

Regards
Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.a...@jembi.org

Web: www.jembi.org

On Fri, Jun 24, 2016 at 2:16 PM, Brian Armstrong brian.a...@jembi.org wrote:

Hi Jamie,

I am going to put the OHIE Guidebook Table of Contents up on the Wiki. I will send a link shortly.

I don’t have access to the content at the link you shared. How do I get a copy of that resource document?

Regards
Brian Armstrong
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701 0939 | Skype: briankarmstrong

E-mail: brian.a...@jembi.org

Web: www.jembi.org

On Fri, Jun 24, 2016 at 10:15 AM, Thomas, Jamie jt...@regenstrief.org wrote:

Brian this is great. Do you see this as a space on the wiki that we can point people to. Also I think much of the content could come from http://store.elsevier.com/Health-Information-Exchange/isbn-9780128031353 /,
which we have access to.

**Jamie Thomas **|****Health Information Project Manager/Communications

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt...@regenstrief.org | Skype: jamie.thomas5670 | Twitter: @RegenstriefGHI

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention,
disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

From: ohie-imp...@googlegroups.com on behalf of “alvin....@gmail.comalvin....@gmail.com

Reply-To: “admar…@up.edu.phadmar...@up.edu.ph

Date: Friday, June 24, 2016 at 1:09 PM

To: “brian.a...@jembi.orgbrian.a...@jembi.org

Cc: “OpenHIE Implementers Network (OHIN)” ohie-imp...@googlegroups.com

Subject: Re: [ohie-implementers] OHIE Guidebook Outline and Framework Recommendations

Hi Brian,

Thanks for initiating this. My suggestions:

Put the ‘Why OpenHIE’ at the first part to set the context. This could contain real work problems faced by the reader. This also levels off the audience on what problems ohie tries to solve.

Put a practical part at the end that tries to show how OpenHIE’is able to solve one of the problems mentioned in Why OpenHIE. Off the bat, one such problem might be integrating data from diverse EMRs into the SHR. Another might be transforming
the SHR into an SDG regional report.

The group might want to answer a philosophical question at the outset as this will influence the flavor of the document:

Are we presenting this to car drivers or to the mechanics? Deciding on one helps us focus on the content. We can then do the next one for the other type and maybe another for car owners…

My two cents. I would like to contribute to the part on SHR to SDG…

Alvin

Hello everyone,

I wanted to share some analysis that has been drafted into a high level outline in an attempt to synthesize the OpenHIE (“OHIE”) framework, as an OHIE Guidebook. Within the list below you will see a suggested list of categories and concepts
for the OHIE Guidebook, which we are proposing for discussion within the OHIE Community.

Can I ask for suggestions from the OHIE Community to firm up this list? I think we can start the conversation here and then open it up to the other OHIE Community lists (e.g. Architecture, Shared Health Record, Terminology Services, etc.).
I have been participating in many of the Architecture calls and Security and Privacy discussions, and have been working on redrafting a requirements framework for the Shared Health Record. I would personally be interested in discussing further these elements,
but any and all categories of OpenHIE is of interest.

I look forward to further discussions.

Thanks,

Brian

Regards

Brian Armstrong*
Digital Health Systems Architect

Jembi Health Systems | SOUTH AFRICA
Mobile: +1-778-984-4009 | Office: +27 21 701
0939 | Skype: briankarmstrong

E-mail: brian.a...@jembi.org

Web: www.jembi.org

OHIE Guidebook Table of Contents (proposed)

  • Introduction
  • What is OpenHIE?
    • The Architecture
      • Design Principles
      • Client Registry (CR)
      • Facilities Registry (FR)
      • Health Worker / Provider Registry (HWR / PR)
      • Shared Health Record (SHR)
      • Terminology Service (TS)
      • Interoperability Layer
    • Standards (existing standards and future standards in OHIE)
    • The Tools (e.g. MIRTH Connect, OpenHIM, etc.)
    • The Community
      • General
      • Regional Forums
      • National Forums
      • Client Registry Community
      • Facilities Registry Community
      • Health Management Information Systems Community
      • Health Worker Registry Community
      • Interoperability Layer Community
      • PEPFAR Data Exchange Community
      • Shared Health Record Community
      • Terminology Services Community
  • What it’s NOT
    • Not an EHR
    • Not a Laboratory Information System
    • Not a Pharmacy Information System
    • Not a…more ideas?
  • Getting Engaged
  • Why OpenHIE?
    • The Business Problem
    • The Data Problem
    • The Technology Problem
    • The Interop Problem
  • Designing based on OpenHIE
    • A fit for purpose architecture
    • Implementation / architecture pattern (something like this)
  • How to Implement OpenHIE
    • Minimum requirements
    • Mine existing Implementation Guides
    • Implementation patterns
      • Rapid HIE Solution - “I need to implement HIE end-to-end but I only have 40 hours, what can I accomplish?”
      • HIE-in-a-Box / Turnkey / Sandbox Solutions
  • Virtual machines representing the core components of HIE pre-configured to be accessible out of the box. Using open source systems (e.g. OpenMRS, OpenHIM, OpenLIMS, OpenLMIS, MIRTH Connect, DHIS2, etc.)
  • Use environments: Dev / Test / Training / Conferences
  • Enterprise Solutions
    • Microsoft Windows based platforms
    • Not-necessarily-open-source
    • MSSQL and Oracle-based SQL servers
    • Commercial HL7 / FHIR tools
    • Commercial EHRs
  • HIE Capability Model (reduced or expanded based upon requirements)
    • Core Functional Capabilities
    • Clinical Enabling Capabilities
    • Technical Enabling Capabilities
    • Minimum Enabling Capabilities
  • OpenHIE and Health Systems Mapping
    • Potentially a foundation model of OpenHIE systems / components and which open source systems implement the OpenHIE architecture (i.e. Facilities Registry can be located in DHIS2).
    • Designs of OpenHIE and mapping of systems for each particular country.
  • Interface development
  • Messaging framework (e.g. HL7, FHIR, etc.)
  • Governance
    • Privacy
    • Security
    • Owners / Sponsors
    • eHealth Framework
    • Regulatory Framework
    • Systems Framework
    • Data Standards
  • Maintenance and Lifecycle Management
    • Software Updates
    • Hardware Upgrades and Maintenance
    • Deprecation
    • Licensing (in the case of Enterprise Solutions)
  • Networks & Connectivity
    • Satellite
    • WiFi
    • Cellular Data (e.g. 3G, LTE, etc.)
    • Shared Networks
    • Partner Networks
    • Community Networks
    • ‘Sneaker-Net’
  • Resources
    • Consulting Services
    • Logistics Management Services
    • Program Development Services
    • Software and Program Development Services
  • References
    • OpenMRS
    • OpenHIM
    • DATIM
  • Support
    • IT Support
    • Contact Centre and Help Desk
  • Document Management (e.g. Architecture and PMO Repositories, CMDB)
  • Knowledge Management (e.g. Case Studies, Clinical guidelines, Use Cases, Workflows, etc.)
  • Training
    • Certifications / Qualifications (i.e. lists and purpose)
    • Curriculum development
    • Offline / Online Training
    • Workshops
    • Train-the-Trainer
  • Case Studies (Existing Implementations)
    • Implementer Documented Implementations
    • RHIE
    • Etc
  • Glossary of terms

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to
ohie-imp...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-implementers/CAEHg8%2BJg%2BJRo5KK4fhFNSWmNc8pn4SJ5Sv3%3DVRLv_iyS6PpXkA%40mail.gmail.com
.

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

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-imp...@googlegroups.com.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAKRUSZWZKqr_Xtp8N7cp1viWLJa2H4iTAy1RWSWoDgcy-zOwRw%40mail.gmail.com.

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-imp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWiF2a%3DzB1BiaFHGp7hXY5nubpSoeTuQEZuni_g4YCOxwQ%40mail.gmail.com.

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

Elaine Baker
+255715568512

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/f18b6555-fc3d-44a7-a4cd-cc2e05c8891f%40googlegroups.com.

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

Elaine Baker
+255715568512

Elaine Baker
+255715568512