1 of 137

Welcome

to

Academy Live!

Foundations Of Health Information Exchange

2 of 137

Special “Thank You” to:

Global Connect
IntraHealth
Jembi
Kuunika
Mekelle University
PATH
Regenstrief

The OHIE Academy Community

and

The Whole OpenHIE Community

3 of 137

HIE Learning Ladder

HIE Foundation Certificate - Create a foundation for discussing data exchange / data exchange projects and support further engagement in the OpenHIE Community
Get started with an information exchange project with additional learning and documentation
(As needed) Enhance learning with specialized courses as applicable to use case, experience and expertise

3

Academy Workshop - To be Determined

Getting Started Guide

Architecture Specification

HIE Foundation Courses

Introduction to HIE
Architecture Overview
Intro to Data Standards
Interoperability

OpenHIE Academy Specialized Courses

OHIE + Other Relevant Content

FHIR and CQL
Terminology
Advanced OHIE courses

Courses about specific tooling like Instant OHIE or OpenHIM/ OpenIMIS
Testing courses

Foundation Certification

4 of 137

HIE Learning Ladder

HIE Foundation Certificate - Create a foundation for discussing data exchange / data exchange projects and support further engagement in the OpenHIE Community
Get started with an information exchange project with additional learning and documentation
(As needed) Enhance learning with specialized courses as applicable to use case, experience and expertise

4

Academy Workshop - To be Determined

Getting Started Guide

Architecture Specification

HIE Foundation Courses

Introduction to HIE
Architecture Overview
Intro to Data Standards
Interoperability

OpenHIE Academy Specialized Courses

OHIE + Other Relevant Content

FHIR and CQL
Terminology
Advanced OHIE courses

Courses about specific tooling like Instant OHIE or OpenHIM/ OpenIMIS
Testing courses

Foundation Certification

https://academy.ohie.org

5 of 137

Course Learning Objectives

Participants will be introduced to the basic concepts of health information exchange

Students will be able to articulate the basic component of the OpenHIE architecture
Students will be able to determine which architecture components are needed to solve basic health information sharing challenges
Students will understand the role of standard terminologies and message formats in health information exchange
Students will begin to understand how to apply standards-based data exchange design to solve a particular health system challenge

5

Opportunity for HIE Foundations Certification

6 of 137

Course Format

6

Present Key concepts

Small Group Sessions

Work through a scenario
Ask questions
Prepare to share

Large Group Discussion

Discuss small group findings
Ask questions
Capture key learning points

Large Group Sessions

7 of 137

Session Culture

Mute yourself when not speaking

Video not necessary

(it makes bandwidth challenging for some people)

All voices and questions are welcome. (Post questions in chat, raise your hand or speak up)

7

You know where the tea and facilities are

8 of 137

Live Course - Sept 2021

8

Time Slot	Content	Lead Facilitator(s)
Intro (30 min) 7:00AM EST	(10 min) Welcome and Introduction to course / facilitators (15 min Breakout) Introductions of group - one information sharing challenge you are facing or interested in	Jennifer Shivers
Section1 (30 min) 7:30 EST	(10 min) 1 to 2 group sharing discussion (20 min) Introduction to HIE	Jennifer Shivers
Section 2 (60 min) 8:00 EST	(40 min) Standards-based Architecture (20 min Breakout) Architecture components needed to support a Use Case	Rajab Billy
Section 3 (45 Min) 9:00	(15 min) Group work report out / Discussion (30 min) Introduction to interoperability	Daniel Futerman
Section 4 (30 min) 9:45	(5 min) Introduction to Standards (10 min) Terminology Standards (10 min) Workflows Message Standards	Joe Amlung / Jon Payne
Section 5 (75 min) 10:30	(10 min) Introduction to group exercise (same case study, but add in data exchanges and workflows) Add data exchanges with standards (if possible) to the components identified (40 min) Group exercise (25 min) Group sharing / discussion with large group	Sovello Mgani
Section 6 (15 min) 11:45	(15 min) Wrap up and Questions Feedback Certification directions	Jennifer Shivers / Kasey Cummins

Large Group Session

Large Group Discussion

Small Group Sessions

9 of 137

Key Links and Resources

Slides
Exercise Scenario
White Board Links
Facilitator Names

https://wiki.ohie.org/display/resources/Academy+Live

9

10 of 137

Welcome - Poll 1

11 of 137

Facilitators and Groups

11

Group Board	Facilitators
Group 1 - White Board	Carl Fourie, PATH / Digital Square Shaun Grannis, Regenstrief Institute
Group 2 - White Board	James Kariuki, CDC Steven Wanyee, IntelliSOFT
Group 3 - White Board	Carl Leitner, PATH / Digital Square Paul Biondich, Regenstrief Institute
Group 4 - White Board	Rajab Billy, Kuunika Daniel Futerman, Jembi Haftamu Kebede, Mekelle University
Group 5 - White Board	Richard Stanley, IntraHealth International Sovello Mgani, PATH / Digital Square Samson Yohannes, Mekelle University
Group 6 - White Board	Vladimer Shioshvili, ICF Jenny Thompson, PATH / Digital Square Joe Amlung, Regenstrief Institute
Group 7 - White Board	Jon Payne, Global Connect Ally Shaban, IntraHealth International Tesfit Gebremeskel, Mekelle University

12 of 137

Creating a Figma Whiteboard Account

Go to the link for your group’s board

Click on the best fit for you -

Then fill out the prompt -

12

13 of 137

Activity 1 - Small Group

Materials:

Collaborative Workspace (see wiki)

13

Introduce yourself (name, organization, role) Before time is up, list 3 or more health challenges that require data exchange (be prepared to share in the larger group).

14 of 137

Activity 1 - Large Group

Materials:

Collaborative Workspace (see wiki)

14

What stood out from your conversation about data exchange health challenges?

15 of 137

Section 1 - Introduction to HIE

What is Architected Health Information Exchange?
What opportunities does HIE present?
Key phrases and terms used by the community

Jennifer Shivers

16 of 137

16

17 of 137

17

18 of 137

18

19 of 137

19

20 of 137

Vignette -

Individual Patient Care

20

Pregnant Woman

Clinic

Care

A pregnant woman may receive clinic care for ANC1, community care for ANC2 and 3, and then may need to deliver at a hospital due to complications.

This leaves her health data spread across three different care facilities and her treatment providers may be challenged to see a complete picture of care.

Community

Care

Hospital

Care

21 of 137

Vignette -

Individual Patient Care

21

Pregnant Woman

Clinic

Care

Community

Care

Hospital

Care

A pregnant woman may receive clinic care for ANC1, community care for ANC2 and 3, and then may need to deliver at a hospital due to complications.

With a Health Data Exchange, her records from all three sites can be linked and that link can be used to show a shared view of her health records.

22 of 137

Architected Health Information Exchange

A community approach to

22

Supporting Health Information Needs	Individual Patient Care (Clinical) Reproductive, maternal, newborn and child health Immunization Health HIV disease management Non communicable disease management	Population and Public Health Infectious disease surveillance, reporting and management Cohort identification, management and tracking	Healthcare Administration Facilities Health workers Health medicine and supplies Health coverage and enrollment
Through Support of Data Sharing Capabilities
Designed with Architected Standards-based Solutions

23 of 137

What is OpenHIE?

OpenHIE is a Global Mission-Driven Community of Practice that is dedicated to improve the health of the underserved through open and collaborative development and support of country driven, large scale standards-based health information sharing architectures.

It is an international community working in low resource settings to:

Enable large scale health information interoperability
Support community needs through peer technical assistance communities

23

24 of 137

Core/Central Communities / Groups:

Leadership
Architecture
Implementers Network (OHIN)

Practice Areas / Community of Practice

Patient Identity Management
Facility Management
Health Worker Management
Terminology
Interoperability Layer
Shared Health Record
Health Management Information
Health Supply Chain
Health Financing towards UHC
Lab Information

24

Communities of Practice

OpenHIE Communities of Practice

Source: https://wiki.ohie.org/display/SUB

25 of 137

INTEROPERABILITY?

25

STANDARDIZATION?

HARMONIZATION?

ARCHITECTURE?

OHIE?

FHIR?

IHE?

CR?

26 of 137

What is an HIE?

Health information exchange (HIE) is the exchange of healthcare/clinical information electronically across organizations within a facility/hospital system, region or country.

A Health Information Exchange (HIE) makes the sharing of health data across information systems possible.
Like a universal translator, an HIE normalizes data and secures the transmission of health information throughout databases, between facilities, and across regions or countries.

26

27 of 137

Interoperability

27

The ability of computer systems or software to exchange and make use of information.

28 of 137

Standardization

28

How are you today?

Comment allez-vous aujourd'hui?

Hujambo leo?

29 of 137

Standardization

29

30 of 137

Point-to-Point Connections

30

31 of 137

Architecture

31

This configuration looks much different. Instead of linking each house directly to another, there is a planned grid that lays out how the people can move from one house to another.

As we think about the images of the intersection, and the underlying systems and rules that are applied (cross walks, stop signals etc) the Architecture is the underlying blueprint or model of what systems are needed and how they connect. It includes the components, rules (standards) and governance and Rajab will talk to us about this

Blueprint (model) that creates a framework for how the HIS subsystems interact
Is the planning function between strategy formulation and delivery
Depicts the system’s organization or structure and provides an explanation of how it behaves
Analogous to a city master plan
Delineates information systems, data sources, integration & governance and fits to the national enterprise architecture

32 of 137

Section 2 - Standards-Based Architecture

Architecture Principles
Architecture Components

Registry Services
Business Domain Services
Interoperability Layer

Rajab Billy

33 of 137

Why Apply Health Architecture?

33

Adherence to the eHealth Architecture,

an agreed upon technical and conceptual blueprint for HIS systems and data, enables the MOH to share knowledge, collaborate on care, and understand the reports and population health data available for use throughout the health system.

34 of 137

34

OpenHIE Architecture Principles

Standards-based
Adaptable / implementable
Interchangeability / "swappable"

More about the Architecture Principles is in the Specification

35 of 137

35

Service Oriented Architecture (SOA)

Designed to overcome the problems resulting from monolithic applications
Emerged as an evolution of distributed computing
Introduce the concept of a ‘service’ that interacts over the wire using a protocol such as REST or SOAP
SOA – a software application is designed as a combination of services
Services are loosely coupled, meaning the service interface is independent of the underlying implementation

36 of 137

36

OpenHIE Architecture - Patterns

This is the OpenHIE architecture pattern. In the next sections, we will work through these components in detail. At a high level, the gray box represents the health information exchange. Inside that box, is an interoperability layer that is like the gateway or doorway to the health exchange. The point of service applications, noted in black are the places in the field where the data are collected. These can include EMRs, community health mobile apps, lab systems and pharmacy systems.

The keys to supporting information exchange include having an eHealth Architecture or a plan that establishes the key components needed to support health information exchange and having the standards both messaging standards and terminology standards that allow data to flow between systems in a way that maintains integrity and meaning of the data.

37 of 137

37

Registry Services

Registry services are designed to support interoperability and data normalization by providing authoritative sources for data and metadata that are used throughout the eHealth system.

Starting with the bottom blue row in the OpenHIE Architecture Diagram, there are what we call registries. These registries help identify the nouns in the health data; patients are uniquely tracked in a client registry, health care providers (health workers) are tracked in a health worker registry, facilities are tracked in a facility registry, medications and medical supplies can be tracked in a product registry and medical terms can be tracked in a terminology registry. One of the key features of registries is that they provide unique identifiers for each of these nouns that allow for linking and using data across systems. For example, a facility ID can be established and linked to data being generated by an EMR system or point-of-care system at a specific facility.

Each registry provides ways to uniquely identify patients, health workers, facilities, health medications or products and medical terms.

The rest of this section will focus on looking at each of these registry systems and providing some examples.

38 of 137

Registry Services

(Shared Services)

Water image: Michael Tewelde/USAID Lowland WASH ActivityMichael Tewelde/USAID Lowland WASH Activity

38

39 of 137

39

Client Identity Management

Hosp. B Client ID

Hiwott Patient ID 99999

Hiwott

Hiwott Patient ID 123456

Clinic A Client ID

40 of 137

Client Registry

Client Registry (Enterprise Master Patient Index):

a master patient index (MPI), or Client Registry manages the unique identities of citizens receiving health services with the country

40

Hosp. B Client ID

Hiwott Patient ID 99999

Client Registry

Hiwott Patient CR ID 5555555555
Clinic ID 123456 + demographics
Hospital ID 99999 + demographics

Hiwott

Hiwott Patient ID 123456

Clinic A Client ID

Foundational to the ability to combine patient records from multiple systems that are using their own IDs
Links a patient’s ID in one system with their ID in another system
Provides a unique enterprise identity for that patient

The OpenHIE Architecture allows HIwott’s demographic data from both point-of-care systems to be be sent to the health information exchange client registry (CR) which can also be called an enterprise master patient index (EMPI). Inside the CR there is matching logic to help link the patient demographics and patient IDs from one point-of-care system with another. While the CR doesn’t physically , link medical data from the two system, it does create a way to be able to link the patient’s data from one system with the same patient’s data from another system.

The capability to uniquely identify a patient across multiple systems lays the foundation for more accurate metrics calculations and population health. It also provides a foundation for creating a comprehensive health record for a patient.

41 of 137

41

Health Worker Registry

Health Worker(s)

Qualifications / Certifications

Health Worker Registry (eHIRIS) :

a health worker registry uniquely identifies each individual who works within the healthcare system and may track information about their qualifications.

The patients or people served by the health system one of the key aspects of a health information system.

Another key aspect in the health system is the health worker or the practitioner providing some type of care. The provider may not be the key subject of point of case systems, but those systems often track the provider that administered the service, performed the lab test or dispensed the medication. It is important to track who has has served the patient. The HWR allows the common ID for a provider to be established and used across the health system.

In health emergencies or crises like Ebola and COVID, it has been important to understand the types of health workers available and the understanding the geographic distribution of those workers can help with planning for capacities in times of crisis and for supporting the population health.

42 of 137

42

Nigeria

43 of 137

43

Nigeria

44 of 137

44

Facility Registry

Facilities

Geographic hierarchy
Data about the facilities

Master Facility Registry (MFR) :

a MFR manages the unique id and attributes of the locations where health services are administered or supported.

Usually supports hierarchy data used for analysis and reporting
Allows for analysis of facility or regional data from multiple systems

45 of 137

45

Kenya - http://kmhfl.health.go.ke

46 of 137

46

Kenya - http://kmhfl.health.go.ke

47 of 137

47

Tanzania

48 of 137

48

Registry Services

Registry services are designed to support interoperability and data normalization by providing authoritative sources for data and metadata that are used throughout the eHealth system.

49 of 137

49

Product Catalogue

A Product Catalogue serves as the source of truth about what a Product is within an HIE.

Allows organizations to publish and manage one or more product catalogs including product information and master data management
Should support common product identifiers such as GS1 and mappings between different product catalogs/ identifiers
Provides interoperability
Provides data governance workflows

Like the other registries, we need a distinct way to identify products used across the health system. Products can be a little tricky because the health supply chain may be focused on detailed levels of packaging and manufacturer of a health product and a health provider may be focused on prescribing at an active ingredient level.

This means that how a product like a medication or gloves is understood and discussed depends upon upon the context of use of the product. OpenHIE is working through technical ways to describe products that work in the supply chain, provider and insurance or payer contexts. To provide care, products need to be represented in a way that allows all levels of the health system to interact in ways that enable having medications, vaccines and supplies needed in the right place at the right time to care for patients.

50 of 137

50

Terminology Service

Uniquely defines and identifies both the clinical and M&E concepts throughout the country
Used to align patient-level or indicator-level data across point of service or enterprise-level applications

The last registry I’ll describe is the terminology service registry. This one is a bit more challenging because terminology may not be as obvious to see as some of the other registry components we have discussed so far. However, terminology is one of the keys to interoperability.

For example, the word trolly in US English generally refers to a form of transportation that several people can ride at one time and the British word trolly can refer to a cart or bin with wheels that one uses when shopping or at the airport. As humans, we can use the context to discern the differences in these meanings. However, when computer systems are sharing data, it is important that the meaning of the term is successfully shared. To do this, we use terminology. There is a course that will focus on standards. That course will explain more about the standard health terminologies like ICD-10 that are used in health care settings.

51 of 137

51

Registry Services

Registry services are designed to support interoperability and data normalization by providing authoritative sources for data and metadata that are used throughout the eHealth system.

52 of 137

52

Business Domain Services

Services that support a particular domain and may be used by other HIS systems.

This section is focused on the business domain services located at the top row of the OpenHIE Architecture Diagram. These components service specific domains of the health care system. Many of you are familiar with these types of systems and this section will not be covering each of them in detail.

I will start by briefly describing HMIS (Health Management Information Systems) - Many of you are probably aware of systems like DHIS2 that collect and store health system metrics that are used to understand and manage the broader health system. These systems have three main features:

Store routinely-collected aggregate health care data
Typically uses additional aggregation and visualizations to support data use.
Facilitate analysis with the goal of improving the quality of health services.

LMIS (Logistics Management System) typically bridges the health and supply chain operations

Enabling commodity visibility
Enabling re-supply workflows for clinical locations

Finance and insurance Services

May track information about the different options or payer selections for individuals.

The shared health record may be a bit more challenging to understand. I’ll walk you through a more detailed explanation of that component.

53 of 137

53

Distributed Health Record

Clinic A Client ID

Hosp. B Client ID

Hiwott

Hiwott Patient Records

ANC1 visit data

Hiwott Patient Records

ANC 4 visit data
Delivery data

Health Post

Client ID

Hiwott Patient Records

ANC2 visit data
ANC3 visit data

A pregnant woman may receive clinic care for ANC1, community care for ANC2 and 3, and then may need to deliver at a hospital due to complications.

This leaves her health data spread across three different systems and her treatment providers are challenged to see a complete picture of care.

54 of 137

54

Shared Health Record

Shared Health Record:

collection of fully normalized person-level data records.

Provides a holistic view of a patient’s medical record
Allows providers working at different facilities to see a patient’s longitudinal record

Hiwot Patient

ANC1 visit data
ANC2 visit data
ANC3 visit data
ANC4 visit data
Delivery data

Clinic A Client ID

Hosp. B Client ID

Hiwott

Hiwott Patient

ANC1 visit data

Hiwott Patient

ANC 4 visit data
Delivery data

Health Post

Client ID

Hiwott Patient

ANC2 visit data
ANC3 visit data

55 of 137

55

The OpenHIE Architecture supports the shared health record through use of several OpenHIE components.

The first is the point-of-care or point-of service systems (shown in the black icons.) These systems collect the data about the patient’s demographic data and the patient’s health care visits.
The point of care data can be shared through the interoperability layer, which will be discussed more in the next section of this training course.
The client registry can link the IDs from the various point-of-care systems.
Finally the shared health record is a collection of the health records for a particular patient.

To fully implement this type of data exchange, other OpenHIE Architecture Components are required. In addition, there are data (semantic) and message standards that are required to share data.

56 of 137

56

Business Domain Services

Services that support a particular domain and may be used by other HIS systems.

57 of 137

57

58 of 137

58

Interoperability Service

The interoperability layer provides:

a single point of entry for data and requests of the architecture
centralize the logging/auditing of messages
authentication (verifying the machine or process that is sending or receiving data)
authorization (verifying that the machine or process has access to the requested resources)
routing of messages to the correct service provider
mediation functions for transactions in an attempt to simplify the business logic required by service consumer systems

The interoperability layer which is sometimes abbreviated as the IOL is comprised of three main functions; a gateway, a log and a conductor.

First, we can think of the IOL as the door or gateway to the health information exchange. The IOL ensures that only known senders and receivers can participate in sending data to information exchange or retrieving data from the information exchange. This is called authentication. The IOL can also determine which senders and receivers are authorized to send or share information. So the IOL is like a gateway with a gatekeeper that decides what systems can send or receive information and the types of transactions they can perform.
The interoperability layer also logs transactions that go in and out of the HIE
The interoperability layer can also function like a conductor ensuring that messages are routed to registries to translate IDs and terminology.

59 of 137

Workflows - Patterns

(Information Exchanges)

59

60 of 137

Shared Services Example

Abraham is a child that has been seen by both a community health worker and a hospitalist during the first 4 months of life. While he received immunizations in both service locations, bringing those data together imply being able to uniquely identify similar immunizations from each location (ie, Polio vaccine) as well as distinguishing the service location.

Shared services allow data emitted from both an EMR and a mobile app to be normalized consistently. The Shared Health record allows this normalized data to be made available to the larger enterprise.

60

Shared Services

Master Facility Registry

Health Data Dictionary

Facility Registry

Client Registry (EMPI)

Shared Health Record

EMR

Mobile App

Interoperability Service

Data travels from the point of care system, through the interoperability layer.

The interoperability layer authenticates the sender and mediates the rest of the process steps.

Any terminology that is not compliant with the standards is translated.
Patient IDs are translated from the local id to the health system ID
Data is recorded in the shared health record

1.

2.

3.

4.

61 of 137

Activity 2

Materials:

61

Given the future state scenario, determine which architecture components in addition to the EMR and the CHMA mobile app, are needed to support the information exchanges?

62 of 137

Future State Scenario

62

Background	Fireiwot is a health extension worker who supports a catchment area for the Amigo Health Center. Fireiwot has reliable 3G wireless internet in most of her catchment area. She is able to work offline when she does not have a connection. They have recently implemented a community health mobile app (CHMA) which allows Fireiwot to collect patient-level information electronically while sh e is out and about in the community. Fireiwot regularly phones community leaders in her catchment area who meet with the mothers-to-be regularly.
Mobile App (CHMA)	Fireiwot learns from a community leader that Hiwot, a mother within her catchment, has become pregnant. Fireiwot completes the mobile CHMA registration and the mother’s demographic record (identity) is electronically captured in the mobile system. Hiwot has not been registered in the system previously. Fireiwot continues to complete the CHMA pregnancy form in the mobile app. At the end of the day, Fireiwot will need to upload the data from her mobile CHMA to the central health information exchange.
Clinic - EMR	The Amigo Health Center has recently been fitted with fiber optic intranet services, and also maintains an EMR registration and basic MNCH EMR function within the setting. Kebede, who leads the ANC unit at the Amigo Health Center is able to use the EMR to get the list of pregnant patients in his catchment area (This includes data collected from the CHMA and the EMR). Because of data uploaded from the CHMA, he sees that Hiwot should be coming to the health center for her ANC visit. Kebede begins the process to receive Hiwot for her first ANC visit. When Hiwot arrives at the ANC Unit at the Health Center, she is given a thorough evaluation and screening and overall, she appears to be in excellent health. Kebede documents all of these findings in the EMR and that data is then synced with the Health Information Exchange. Hiwot then returns home, with an expectation, that until the end of her pregnancy, she’ll be supported within her local community and by Firewot.
Mobile App (CHMA)	Using the mobile app, Firewot can see the expected due date and other key health data recorded at the Amigo Health Center during the ANC1 visit. Over the course of the next few months, Hiwot participated in a number of peer support events in her community, and also completed her second and third antenatal visits with Firewot. As a part of the job the Health Extension worker (HEW), Firewot, talks about the nutrition status of the family. The HEW measures Hiwot’s arm, after noting that Hiwot has always been a light eater. Over the course of the past few months, she has not gained as much weight as she should. She gave the mother some advice, and they decided to manage this conservatively. All of this information is dutifully gathered and this data are recorded in the mobile CHMA and subsequently synced with the HIE.
Clinic - EMR	Now eight months into the pregnancy, Firewot reminds Hiwot to go back to the Amigo ANC Unit for her 4th antenatal visit. During that visit, Kebede notes that the nutrition interventions have been working. Hiwot ends up delivering a healthy baby at the Amigo Clinic a few weeks later. She names her boy Dawit. Kebede registers Dawit as a new delivery, and ensures that the Amiigo clinic is prepared to receive him as soon as possible for immunizations and his first well child visit.

63 of 137

Activity 2 - Large Group

Materials:

Collaborative Workspace

63

Which architecture components are needed to support the health information exchange for the scenario? Share a new insight or learning from the discussion.

64 of 137

Section 3 - Interoperability

Why interoperability matters
Architectural Solutions - Interoperability layer
Interoperability Layer in Action

Daniel Futerman

65 of 137

The Interoperability Challenge

Clinicians need accurate, timely and complete information for decision-making

BUT

Healthcare information solutions are often siloed, making it difficult to share information across different systems, different facilities and different locations, in combination with other factors such as resource constraints and lack of skilled individuals.

65

66 of 137

The Solution

Interoperability seeks to solve this challenge through support for:

different information systems, devices and applications (systems) to access, exchange, integrate and cooperatively use data in a coordinated manner, within and across organizational, regional and national boundaries, to provide timely and seamless portability of information and optimize the health of individuals and populations globally.

66

67 of 137

The Case for Interoperability

Contextual challenges

Fragmented Systems

Tailored to local and specific needs

Different data representation and level of detail
Different architecture and underlying technologies

Cost

HW, SW and labour costs
Loss of productivity in initial phase
Recurrent Costs such as yearly subscription fee

Privacy

Data privacy concerns

67

68 of 137

Interoperability Challenges

Resources

Low resource setting constraints

Unreliable infrastructure
Power interruptions
Systems network problems

Limited availability of skilled individuals

Other

Refusing to share data with other competitors
Pragmatic reasons to continue using existing systems

Replacement of legacy systems is not feasible

The future

68

69 of 137

Multiple Layers of Interoperability

Foundational Interoperability

Basic level that requires a receiving system/application/device to be able to receive messages, but does not require interpretation of messages. E.g. HTTP/S, REST transport protocols.

Syntactic Interoperability

Defines message structures, content and service definitions of data that is exchanged between two or more systems/applications/devices. E.g. Health Level Seven(HL7) , DICOM data exchange standards.

Semantic Interoperability

Provides capabilities of systems to both exchange and use the information that has been transmitted, where the meaning of the data is transmitted with the data itself, so that a receiving system/application/device can interpret messages. E.g. ICD, LOINC terminology standards.

69

70 of 137

WHO Classification of Digital Health Interventions

70

Health System Challenges

Digital Health Interventions

System Categories

71 of 137

71

OpenHIE Architectural solution and specification of components Defines how HIE infrastructure and its various parts FIT TOGETHER Maintains list of reference tools and releases of specifications Component based design, enables multiple services to work together and brings flexibility Promotes health information sharing among variety of HISs in a country

72 of 137

72

OpenHIE Interoperability is facilitated through simple and inexpensive interfaces/reusable Implementable quickly with few disruptions to existing HISs

73 of 137

The Interoperability Layer

Acts as a single entry point for the HIE.
Manages the security of the HIE through authentication (identity verification), authorization (permission to interact with specified HIE components) and encryption and decryption of messages.
Routes messages to the appropriate architecture component or external point-of-service applications.
Provides a central logging mechanism for messages sent through the exchange by logging copies of the messages that travel through the IL for audit and reporting purposes.
Allows for the rerunning of failed transactions at a central level, alleviating the need for point-of-service applications to resend data.

73

74 of 137

Point-to-Point Solutions

74

N*N Links

75 of 137

Disadvantages of Point-to-Point

Tightly coupled, brittle, and inflexible to changes
Expensive to maintain
Changing one application can affect many others
Routing logic is hardcoded into the applications
No common security model; security is ad hoc
No common communications protocol
No common ground to enforce best practices
Unreliable
No health monitoring and deployment management of applications and integration components

75

76 of 137

Interoperability Layer Benefits

Acts as an interface into the Health Information Exchange architecture.
Allows other components to interoperate more easily

Handles common functions (security, auditing, logging)
Provides a single point of communication
Message transformation and orchestration via mediators

Certificates managed centrally, rather than in each component
Common and basic features are implemented centrally, rather than in each component

E.g. auditing, logging, and authentication

76

77 of 137

Interoperability Layer Benefits

Acts as an interface into the Health Information Exchange architecture.
Allows other components to interoperate more easily

Handles common functions (security, auditing, logging)
Provides a single point of communication
Message transformation and orchestration via mediators

Certificates managed centrally, rather than in each component
Common and basic features are implemented centrally, rather than in each component

E.g. auditing, logging, and authentication

77

78 of 137

Interoperability Layer Features

78

Middle Layer

Single point of access to OHIE
Access to all transactions
Routing Messages
Enforcements and regulating

Extensibility

Encryption / Decryption
Normalization / Denormalization
Orchestration

Security

Authentication and authorization

Single point of security concern

ATNA

Audit Trail
Node Authentication

Central user and system account management
Secured connections

Middle Layer:

Associated Functional Requirements:

IOLF-1, IOLF-2, IOLF-4, IOLF-6, IOLF-7, IOLF-9, IOLF-16

Innovational Capabilities:

Associated Functional Requirements:

IOLF-5, IOLF-8, IOLF-13, IOLF-15

Security:

Associated Functional Requirements:

IOLWF-1, IOLF-3, , IOLF-10, IOLF-11, IOLF-12, IOLF-14

The IOL simplifies the security for the HIE by providing a single point of access for all external systems that are attempting to communicate with the components of the HIE such as the CR, PR, FR or the SHR.

The IOL keeps a record of all the transactions that take place in the OpenHIE.

The IOL is responsible for the routing messages to the appropriate service provider within the infrastructure.

Transparent services

Authorise - Ensure that the service requester is authorized to perform the request

Decrypt - Be able to decrypt incoming messages to pass on to service providers

Route - Be able to route messages to the correct service provider system

Mediation services

Normalise - Transform messages into a well understood intermediate form (canonical form)

Orchestration - Execute a set of steps to perform a business function, this often can include requesting services from multiple service providers

De-normalise - Transform messages into a form that a specific service provider can understand

79 of 137

Interoperability Layer Features

79

Middle Layer

Single point of access to OHIE
Access to all transactions
Routing Messages
Enforcements and regulating

Extensibility

Encryption / Decryption
Normalization / Denormalization
Orchestration

Security

Authentication and authorization

Single point of security concern

ATNA

Audit Trail
Node Authentication

Central user and system account management
Secured connections

Middle Layer:

Associated Functional Requirements:

IOLF-1, IOLF-2, IOLF-4, IOLF-6, IOLF-7, IOLF-9, IOLF-16

Innovational Capabilities:

Associated Functional Requirements:

IOLF-5, IOLF-8, IOLF-13, IOLF-15

Security:

Associated Functional Requirements:

IOLWF-1, IOLF-3, , IOLF-10, IOLF-11, IOLF-12, IOLF-14

The IOL simplifies the security for the HIE by providing a single point of access for all external systems that are attempting to communicate with the components of the HIE such as the CR, PR, FR or the SHR.

The IOL keeps a record of all the transactions that take place in the OpenHIE.

The IOL is responsible for the routing messages to the appropriate service provider within the infrastructure.

Transparent services

Authorise - Ensure that the service requester is authorized to perform the request

Decrypt - Be able to decrypt incoming messages to pass on to service providers

Route - Be able to route messages to the correct service provider system

Mediation services

Normalise - Transform messages into a well understood intermediate form (canonical form)

Orchestration - Execute a set of steps to perform a business function, this often can include requesting services from multiple service providers

De-normalise - Transform messages into a form that a specific service provider can understand

80 of 137

Interoperability Layer Features

80

Middle Layer

Single point of access to OHIE
Access to all transactions
Routing Messages
Enforcements and regulating

Extensibility

Encryption / Decryption
Normalization / Denormalization
Orchestration

Security

Authentication and authorization

Single point of security concern

ATNA

Audit Trail
Node Authentication

Central user and system account management
Secured connections

Middle Layer:

Associated Functional Requirements:

IOLF-1, IOLF-2, IOLF-4, IOLF-6, IOLF-7, IOLF-9, IOLF-16

Innovational Capabilities:

Associated Functional Requirements:

IOLF-5, IOLF-8, IOLF-13, IOLF-15

Security:

Associated Functional Requirements:

IOLWF-1, IOLF-3, , IOLF-10, IOLF-11, IOLF-12, IOLF-14

The IOL simplifies the security for the HIE by providing a single point of access for all external systems that are attempting to communicate with the components of the HIE such as the CR, PR, FR or the SHR.

The IOL keeps a record of all the transactions that take place in the OpenHIE.

The IOL is responsible for the routing messages to the appropriate service provider within the infrastructure.

Transparent services

Authorise - Ensure that the service requester is authorized to perform the request

Decrypt - Be able to decrypt incoming messages to pass on to service providers

Route - Be able to route messages to the correct service provider system

Mediation services

Normalise - Transform messages into a well understood intermediate form (canonical form)

Orchestration - Execute a set of steps to perform a business function, this often can include requesting services from multiple service providers

De-normalise - Transform messages into a form that a specific service provider can understand

81 of 137

Interoperability Layer in Action

81

Save Client Encounter:

Submit clinical encounter
Resolve client identifier
Return person record
Extract ECID and enrich message with ECID if patient exists, else error
Fetch provider details and perform validation
Return cached details and validation results
Fetch facility details and perform validation
Return cached details and validation results
Read validation result and enrich document with EPID and ELID
Save clinical encounter
Parse and store certain sections of clinical document discreetly
Register a CCD on-demand document for this patient
Acknowledge encounter saved
Acknowledge encounter saved

82 of 137

Section 4 - Introduction to Standards

What are standards and why are they important?
Terminology standards
Data exchange standards

Joe Amlung and Jon Payne

83 of 137

Which of these standards would you use to construct a message to send from one computer system to another?

LOINC
Google Mail (Gmail)
Medical Subject Headings (MeSH)
Messaging standard, like HL7 FHIR

83

84 of 137

Which of these standards would you use to construct a message to send from one computer system to another?

LOINC
Google Mail (Gmail)
Medical Subject Headings (MeSH)
Messaging standard, like HL7 FHIR

84

85 of 137

Which of these standards would you use to code a cause of death?

ICD
HL7 FHIR
SNOMED
LOINC

85

86 of 137

Which of these standards would you use to code a cause of death?

ICD
HL7 FHIR
SNOMED
LOINC

86

87 of 137

Which of these is NOT a real ICD-10 code?

Injury due to accidental contact with duck.
Walked into lamppost, subsequent encounter.
Lip puncture due to inner tube accident.
Problems in relationship with in-laws.

87

88 of 137

Which of these is NOT a real ICD-10 code?

Injury due to accidental contact with duck. (W61.69)
Walked into lamppost, subsequent encounter. (W22.02)
Lip puncture due to inner tube accident.
Problems in relationship with in-laws. (Z63.1)

88

89 of 137

89

Comic available at xkcd.com/1179/ under the Creative Commons Attribution-NonCommercial 2.5 License.

90 of 137

There are many types of health informatics standards! �Each plays an important role in enabling interoperability

Types of Health Informatics Standards

Architecture, Frameworks and Models

OpenHIE, ISO TR 14639

Semantic content (aka Terminology)

ICD-10, SNOMED, LOINC

Systems and Device Interoperability (aka Messaging, Data Exchange)

HL7 FHIR

Security, Safety and Privacy

ISO 13606, Breach Notification, HIPAA

Pharmacy and Medicines Business

RxNorm

Traditional Medicine
Personalized digital health

Source: ISO TC 215 Health Informatics Standards Working Groups, https://www.iso.org/committee/54960.html

91 of 137

Value of Health Standards

Safe and Effective Clinical Care
Create Longitudinal Care Record
Data Quality
Interoperability between Systems
Report Aggregation and Evaluation
Analytics and Business Intelligence (DW)

91

Able to record data and information at the point of care Example: Recording Blood Pressure Data in EMR Systolic Diastolic Acceptable values

92 of 137

… Value of Health Standards

Safe and Effective Clinical Care
Create Longitudinal Care Record
Data Quality
Interoperability between Systems
Report Aggregation and Evaluation
Analytics and Business Intelligence (DW)

92

Able to share data and information across the systems used over the life of the patient Example: Recording Blood Pressure Data Systolic Diastolic Where data was obtained Acceptable values Graphing BP data

93 of 137

… Value of Health Standards

Safe and Effective Clinical Care
Create Longitudinal Care Record
Data Quality
Interoperability between Systems
Report Aggregation and Evaluation
Analytics and Business Intelligence (DW)

93

Compare apples to apples and not oranges Eliminate ’values’ that are nonsensical (E.g. systolic BP of 10) Track longitudinally Consistency Technical normalization

94 of 137

… Value of Health Standards

Safe and Effective Clinical Care
Create Longitudinal Care Record
Data Quality
Interoperability between Systems
Report Aggregation and Evaluation
Analytics and Business intelligence (DW)

94

Able to share granular data and reports Consistency in data sharing and longitudinal tracking Database can change: fields can be mapped to the ‘new standard’

95 of 137

… Value of Health Standards

Safe and Effective Clinical Care
Create Longitudinal Care Record
Data Quality
Interoperability between Systems
Report Aggregation and Evaluation
Analytics and Business intelligence (DW)

95

Blood pressure can be aggregated Know that all systolic BPs/ diastolic BPS mean the same thing Able to aggregate granular data and reports Able to evaluate quality of report results and aggregation Consistency in longitudinal tracking

96 of 137

… Value of Health Standards

Safe and Effective Clinical Care
Create Longitudinal Care Record
Data Quality
Interoperability between Systems
Report Aggregation and Evaluation
Analytics and Business Intelligence / Data Warehouse

96

Longitudinal value Universal and global standards Internal and external comparison of data with other organizations Support for Data Mining and Research

97 of 137

How do computers talk to each other?

Messaging/ Syntactical “sentence” standards: HL7 V2, FHIR, etc.
Semantic “word” standards: country or internationally established (ICD10, SNOMED, LOINC)

97

https://transparencee.org/analysis/data-standards-what-are-they-and-why-do-they-matter/

98 of 137

The need for terminology standards...

98

99 of 137

Semantic / Terminology Standards

Components in an architecture use different types of vocabularies, terminologies, code sets and classification systems to represent health concepts and communicate with each other.

99

Types of Terminology standards ICD10/11 LOINC SNOMED When thinking about standards, think about long term ownership. Some of them have fees or costs associated with using the terminology service.

100 of 137

International Classification of Disease (IDC10/11)

ICD is managed and curated with the World Health Organization.
ICD-11 was released on 18 June 2018, and officially endorsed by all WHO members during the 72nd World Health Assembly.
The ICD-11 has a more sophisticated structure than the ICD-10. With around 55,000 codes that can be used to classify diseases, disorders, injuries, and causes of death, the ICD-11 offers a fine level of detail in coding these illnesses.

100

101 of 137

ICD-10 Example 1

New ICD-10 codes for COVID-19

U07.1 COVID-19, virus identified
U07.2 COVID-19, virus not identified

Clinically-epidemiologically diagnosed COVID-19
Probable COVID-19
Suspected COVID-19

101

COVID-19

An emergency ICD-10 code of ‘U07.1 COVID-19, virus identified’ is assigned to a disease diagnosis of COVID-19 confirmed by laboratory testing. An emergency ICD-10 code of ‘U07.2 COVID-19, virus not identified’ is assigned to a clinical or epidemiological diagnosis of COVID-19 where laboratory confirmation is inconclusive or not available.

102 of 137

ICD-10 Example 2

S36.0: Injury of spleen
S36.1: Injury of liver or gallbladder
S36.2: Injury of pancreas
S36.3: Injury of stomach

102

S36: Injury of intra-abdominal organs

0 without open wound into cavity 1 with open wound into cavity Are character positions where it is not possible to use multiple coding or not desired to use multiple coding

103 of 137

ICD-11 Example 1

6C51.0: Gaming disorder, predominantly online
6C51.1: Gaming disorder, predominantly offline
6C51.2: Gaming disorder, unspecified

103

6C51: Gaming Disorder

Parent: Disorders due to addictive behaviours Description: Gaming disorder is characterized by a pattern of persistent or recurrent gaming behaviour (‘digital gaming’ or ‘video-gaming’), which may be online (i.e., over the internet) or offline

104 of 137

ICD-10 Browser https://icd.who.int/browse10/2016/en#/S36.1

104

105 of 137

LOINC (Lab Terminology Standard)

https://loinc.org/get-started/loinc-term-basics/

LOINC is a common language (set of identifiers, names, and codes) for identifying health measurements, observations, and documents.
LOINC's goal is to create different codes for each test, measurement, or observation that has a clinically different meaning. To do that LOINC codes distinguish a given observation (test ordered/reported, survey question, clinical document) across six dimensions.

105

106 of 137

E.g: Manual count of white blood cells in cerebral spinal fluid specimen, which is represented by LOINC code 806-0

106

Component: The substance or entity being measured or observed. Property: The characteristic or attribute of the component. Time: The interval of time over which an observation was made. System: The specimen or thing upon which the observation was made. Scale: How the observation value is quantified or expressed: quantitative, ordinal, nominal. Method: A high-level classification of how the observation was made.

107 of 137

Example LOINC Search

107

https://loinc.org/search/?t=1&s=a1c

108 of 137

SNOMED CT

Concept-oriented, comprehensive, multilingual clinical healthcare terminology in the world
A resource with comprehensive, scientifically-validated clinical content
It enables consistent representation of clinical content in electronic health records
It is mapped to other international standards
It is in use in more than eighty countries

108

109 of 137

SNOMED CT Core Components

The core component types in SNOMED CT are:

Concepts
Descriptions
Relationships

109

110 of 137

SNOMED GPS

The GPS (Global patient Set) is a managed list of existing SNOMED CT concepts which includes the:

Unique identifier (id), Fully specified name (FSN), The preferred usage term (PT) in International English, and Status flag (active or inactive).

Though GPS does not include SNOMED CT relationships, attributes and hierarchies, it support the sharing of patient health information coded with SNOMED CT® without the need for a SNOMED CT Affiliate license.

110

Scope of the GPS General dentistry diagnoses International Patient Summary Family/General practice health issues and reasons for encounter Renal disorders Nursing activities Nursing health issues DICOM IHE Clinical Profiles

https://www.snomed.org/snomed-international/learn-more/global-patient-set

111 of 137

Using reference terminologies directly at the point of service is challenging...why?

Using reference terminologies is complicated -- ie. when do you use SNOMED vs ICD vs LOINC?
Data often needs to be translated into multiple terminologies (eg clinical documentation vs billing codes vs aggregate reporting) -- requires maintaining mappings between codes
Reference terminologies change -- keeping locally deployed terminology up-to-date is costly
Using post-coordinated terms is tricky for point of service tools, which prefer a single concept or ID for a data field/value
Point of service tools need translations and synonyms

111

112 of 137

Interface Terminology

An Interface Terminology is designed to be used at the point of service, i.e. at the interface between a provider and a patient

CIEL: Columbia International eHealth Laboratory Interface Terminology

Used in 50+ countries
Contains >50,000 concepts
Mappings to ICD-10, LOINC, SNOMED, and IMO
Default dictionary for OpenMRS

Malaria example:

Multiple translations and synonyms
Mappings to other terminologies ...that someone else maintains!
May combine multiple codes into a single post-coordinated concept

112

https://app.openconceptlab.org/#/orgs/CIEL/sources/CIEL/concepts/116128/

113 of 137

Types of Standards

Semantic (Terminology)
Syntactic (Message Structure)

113

Outline the structure of the messages used in exchange EXAMPLES: HL7 (v2, v3, FHIR) IHE (ADX, mCSD)

114 of 137

Computer-talk

MSH|^~\&|SOURCE|383018129|PRIORITY HEALTH|382715520|2007100914484648||ORU^R01|0129938170710091448|P|2.3|

PID|1|1034157|012993817||BIONDICH^PAUL||19520101|M|||1234 MAIN^^DEARBORN HEIGHT^MI^48127||||||||

PID|1||94000000000^^^Priority Health||LASTNAME^FIRSTNAME||19400101|F|

PD1|1|||1234567890^DOCLAST^DOCFIRST^M^^^^^NPI|

OBR|1|||80061^LIPID PROFILE^CPT-4||20070911||||||||||

OBX|1|NM|13457-7^LDL (CALCULATED)^LN|49.000|MG/DL| 0.000 - 100.000|N|||F|

OBX|2|NM|2093-3^CHOLESTEROL^LN|138.000|MG/DL|100.000 - 200.000|N|||F|

OBX|3|NM|2086-7^HDL^LN|24.000|MG/DL|45.000 - 150.000|L|||F|

OBX|4|NM|2571-8^TRIGLYCERIDES^LN|324.000|MG/DL| 0.000 - 150.000|H|||F|

OBR|1|||74546^URINALYSIS^CPT-4||20070911||||||||||

OBX|1|CWE|5778-6^COLOR OF URINE)^LN||371244009^YELLOW^SN||N|||F|

114

115 of 137

Syntactic (Messaging)

Data Exchange Standards

Messaging standards define the structure and content of data that can be exchanged between systems, as well as the policies and procedures that guide the exchange
Technical aspect of sending a message between sender and receiver for communication and common understanding
Terminology Standards can not stand alone but need a messaging format or standard to accommodate extra syntactic information

115

116 of 137

FHIR http://www.hl7.org/documentcenter/public/training/IntroToHL7/player.html

FHIR is a data standard that helps the exchange of electronic health care information. It is Resource based exchange of content. A single resource of FHIR might be classified into six different categories.

1. Clinical: clinical care content

2. Administrative: Administrative content

3. Workflow: business process depiction content

4. Financial: fiscal element of healthcare

5. Conformance: creation and designing of FHIR resource

6. Infrastructure: needed infrastructure for FHIR implementation

116

117 of 137

FHIR Resources

117

118 of 137

Resource Example

118

119 of 137

FHIR Implementation Guides

119

http://www.fhir.org/guides/registry/

120 of 137

Syntactic Standards

120

HL7 FHIR, v2, V3

IHE Profiles

OpenHIE Architecture Specification

121 of 137

Developes

Community

Patterns

Applied in

Informs

Unique

Contexts

122 of 137

122

OpenHIE Architecture Overview

https://ohie.org/architecture-specification/

OpenHIE Architecture Community and Sub Communities

Architecture Diagram

Component Requirements

Workflows / Data Exchanges

OpenHIE Architecture Specification

123 of 137

Syntactic Standards

123

HL7 FHIR, v2, V3

IHE Profiles

OpenHIE Architecture Specification

124 of 137

124

125 of 137

OHIE Architecture Data Exchange Standards

125

Profile	Data Exchange Description	Aligned OHIE Components
ADX / mADX	Enables interoperable public health reporting of aggregate health data. Emerging FHIR standard for aggregated data exchange	HMIS
APS	A medical summary and inherits all header constraints from Medical Summaries.
CSD/ mCSD	Supports queries across related directories containing data about: organizations, facilities, services and providers.	CSD is not currently supported by Resource Map or DHIS2. mCSD is being considered for support.
PDQ / PDQm	Patient demographic query
PIX	Patient identifier cross referencing
SVCM	Shared value sets, Codes and Maps
MHD / XDS.b	Mobile access to Health documents / cross enterprise document sharing
mACM	Mobile alert communication management

Full list is published in the OpenHIE Architecture Specification

126 of 137

Syntactic Standards

126

HL7 FHIR, v2, V3

FHIR PDQm Implementation Guide

IHE Profiles

Patient Demographics Query IHE ITI PDQm

OpenHIE Architecture Specification

Query Patient Demographic Records By Identifier Workflow

127 of 137

Getting Started - Syntactic Standards

127

OpenHIE Architecture Specification

128 of 137

Section 5 - Group Exercise

Sovello Mgani

129 of 137

Activity 3

Materials:

129

Given the scenario, determine the key data exchanges that would need to be in place to support the scenario. If you have time, note the OpenHIE “workflows” or data exchanges that would be used.

130 of 137

Future State Scenario

130

Background	Fireiwot is a health extension worker who supports a catchment area for the Amigo Health Center. Fireiwot has reliable 3G wireless internet in most of her catchment area. She is able to work offline when she does not have a connection. They have recently implemented a community health mobile app (CHMA) which allows Fireiwot to collect patient-level information electronically while sh e is out and about in the community. Fireiwot regularly phones community leaders in her catchment area who meet with the mothers-to-be regularly.
Mobile App (CHMA)	Fireiwot learns from a community leader that Hiwot, a mother within her catchment, has become pregnant. Fireiwot completes the mobile CHMA registration and the mother’s demographic record (identity) is electronically captured in the mobile system. Hiwot has not been registered in the system previously. Fireiwot continues to complete the CHMA pregnancy form in the mobile app. At the end of the day, Fireiwot will need to upload the data from her mobile CHMA to the central health information exchange.
Clinic - EMR	The Amigo Health Center has recently been fitted with fiber optic intranet services, and also maintains an EMR registration and basic MNCH EMR function within the setting. Kebede, who leads the ANC unit at the Amigo Health Center is able to use the EMR to get the list of pregnant patients in his catchment area (This includes data collected from the CHMA and the EMR). Because of data uploaded from the CHMA, he sees that Hiwot should be coming to the health center for her ANC visit. Kebede begins the process to receive Hiwot for her first ANC visit. When Hiwot arrives at the ANC Unit at the Health Center, she is given a thorough evaluation and screening and overall, she appears to be in excellent health. Kebede documents all of these findings in the EMR and that data is then synced with the Health Information Exchange. Hiwot then returns home, with an expectation, that until the end of her pregnancy, she’ll be supported within her local community and by Firewot.
Mobile App (CHMA)	Using the mobile app, Firewot can see the expected due date and other key health data recorded at the Amigo Health Center during the ANC1 visit. Over the course of the next few months, Hiwot participated in a number of peer support events in her community, and also completed her second and third antenatal visits with Firewot. As a part of the job the Health Extension worker (HEW), Firewot, talks about the nutrition status of the family. The HEW measures Hiwot’s arm, after noting that Hiwot has always been a light eater. Over the course of the past few months, she has not gained as much weight as she should. She gave the mother some advice, and they decided to manage this conservatively. All of this information is dutifully gathered and this data are recorded in the mobile CHMA and subsequently synced with the HIE.
Clinic - EMR	Now eight months into the pregnancy, Firewot reminds Hiwot to go back to the Amigo ANC Unit for her 4th antenatal visit. During that visit, Kebede notes that the nutrition interventions have been working. Hiwot ends up delivering a healthy baby at the Amigo Clinic a few weeks later. She names her boy Dawit. Kebede registers Dawit as a new delivery, and ensures that the Amiigo clinic is prepared to receive him as soon as possible for immunizations and his first well child visit.

131 of 137

Activity 3 - Large Group

Materials:

Collaborative Workspace

131

Share diagrams of your solutions. Share a new insight or learning from the discussion.

132 of 137

Section 6 - Closing and Wrap-up

Final Questions
Feedback / Wrap-up
Certification Opportunity

Jennifer Shivers and Kasey Upchurch

133 of 137

THANK YOU!

133

Any final questions from the group?

134 of 137

HIE Learning Ladder

HIE Foundation Certificate - Create a foundation for discussing data exchange / data exchange projects and support further engagement in the OpenHIE Community
Get started with an information exchange project with additional learning and documentation
(As needed) Enhance learning with specialized courses as applicable to use case, experience and expertise

134

Academy Workshop - To be Determined

Getting Started Guide

Architecture Specification

HIE Foundation Courses

Introduction to HIE
Architecture Overview
Intro to Data Standards
Interoperability

OpenHIE Academy Specialized Courses

OHIE + Other Relevant Content

FHIR and CQL
Terminology
Advanced OHIE courses

Courses about specific tooling like Instant OHIE or OpenHIM/ OpenIMIS
Testing courses

https://academy.ohie.org

Foundation Certification

135 of 137

Certification

$39 US “Foundations in Health Information Exchange”

Designates that the certificate holder:

Understands the basic concepts of interoperability
Understands the basic function of health information exchange and the OpenHIE Architecture components
Can designate which HIE architecture components are needed to solve a health data exchange challenge.
Has a basic understanding of the importance of semantic and syntactic standards

135

We will send out a follow up communication about this opportunity.

136 of 137

Feedback

Share your feedback now on MentiMeter:

https://www.menti.com/j9t7dxzxip

Share your feedback anytime on the community forum: https://discourse.ohie.org/c/openhie-feedback/3

136

137 of 137

#WeAreOHIE

Use the architecture - https://guides.ohie.org/arch-spec
Attend topical conversations monthly (Schedule)
Start and join discussions on the community forum (introduce yourself, ask questions, share experiences)
Follow us on Twitter @OpenHIE
Join our annual community meeting, October 5-8!

There’s still time to register! https://ohie.org/ohie21/