OHIE Guidebook Outline and Framework Recommendations

[brian.a...@jembi.org]

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

 

[Alvin Marcelo]

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

...

[Thomas, Jamie]

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.

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

[Alvin Marcelo]

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!

[Brian Armstrong]

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 

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

[Brian Armstrong]

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

[Brian Armstrong]

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

[Carl Fourie]

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.

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

[Elaine Baker]

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

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

[Derek Ritz]

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

[Elaine Baker]

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...@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.b...@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

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

--

Elaine Baker
+255715568512

[Derek Ritz]

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.b...@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...@ecgroupinc.com> wrote:

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