063-100 《Contemporary-Health-Informatics》第三章

• Overview
• Classifying Health Information Exchanges
  • Scope of HIEs
  • Status of HIEs
  • Architecture of HIEs
  • Function of HIEs
• Case Study: the Indiana Health information Exchange (IHIE)
• Case Study: CONNECT
• Case Study: Federated Architecture: Direct
  • Direct Technical Concepts
  • The Fax replacement Use Case
  • Workflow issues
  • Beyond Fax Machine
• Case Study: CurrentCare
• Related post

图书信息：豆瓣

抄书作总结的方式做笔记，真是花时间啊，看样子10天看完是不太可能的了。

本章内容是健康信息交流（HIE）系统的介绍，包括HIE的用途，分类，应用范围，架构，和使用技术一些案例分析等等。

Part II: Key technologies Chapter 3: Health Information Exchange

Overview

HIE’s main focus is data sharing and advantages:

• managing patient at population level
• managing provides as group
• engaging patients through PHR and EMR
• replacing point-to-point data exchange

US need more HIEs to improve health information sharing and reduce medical errors. Interoperability is the main issue that HIEs need to resolve.

Locate patient: Master Patient Index (MPI) are designed to use birthday, gender, race, ethnicity and address to identify patients. Enterprise MPI (EMPI) and cross-enterprise MPI (XMPI) are the two forms of MPI.

Locate Clinical data: Two solutions: 1) central data warehouse; 2) document locator or registry service which provide indexes of the location of data. Data normalization or standardization might be needed to aggregated data from different sources but there are ways to use third party software to analyze and parse data without the need for normalization (e.g. IBM’s Watson system).

HIEs should also consider patient daily activity data generated by wearable health devices and apps.

Classifying Health Information Exchanges

HIEs can be classified by their *IScope, **Status,Architecture, and functionality.

Scope of HIEs

• Enterprise HIE(EHIE): Serve hospitals/professionals within on health system.
• Service-area HIE: geographic area or area which health provides/hospitals get their patients from.

economic sustainability is harder with increased scope, because: patients are providers client so they generally do not want to share with other. Most patient don’t have the need to see providers far away (except patient with cancer or rare diseases).

EHIE: is good for coordinating care for patients and managing quality of providers. It can also provide population health management tools to improve outcome.

Beyond an Enterprise: do not have huge need.Use case includes cancer or rare disease patients, medical emergency while travel or nationwide research.

Status of HIEs

Seven-stage classification proposed by eHealth Initiatives (eHI)

1. getting just started.
2. getting organized with goals and objectives
3. planning business
4. piloting approaches
5. In operation
6. made the transition to a sustainable business model
7. beyond sustainability and are innovating.

“Private HIE”, funded by local private sector. Carolina eHealth Alliance is a private HIE focused on emergency department.

Challenges that HIEs face: 1) sustainability; 2) Privacy, security and trust of health data and 3) funding.

Architecture of HIEs

Three major architectures:

Function of HIEs

• Direct exchange: like the federated model, provide means to send and receive information between providers.
• Query based exchange: find and request information from providers.
• customer-mediated exchange: put patients’ data under their control.

Case Study: the Indiana Health information Exchange (IHIE)

Major services include:

• Docs4Docs®: deliver lab results, reports to physicians. Supports Fax, Web portal or HL7 message delivery.
• Indiana Network for Patient Care(INCP)™: a patient-centric community health record. It functions as a virtual EHR and provides data from providers, payers, public health and pharmaceutical vendors.
• Quality Health First®: Population health management system.
• ** ImageZone**SM: cloud-based medical image sharing service. not a permanent storage.
• AOC Services: tracking where care has been delivered,; managing transitions of care; following up to ensure care has been delivered as needed.

Case Study: CONNECT

CONNECT is the federal government’s open source solution for centralized HIE.

It has three key functional elements:

1. Core Services Gateway: implements general centralized HIE function.
2. Enterprise Service Components: provides modules for user to customize
3. Universal Client Framework: allows CONNECT sites to create edge systems; supports test and demonstration; supports application development.

CONNECT is free of charge but difficult to install, IT professionals’ help is needed if one want to use it.

Case Study: Federated Architecture: Direct

Direct Technical Concepts

Direct assures security and trust using Internet technologies such as SMTP and MIME. Each provider registers with one health ISP (HISP) and obtain a Direct email address. Sender send secure email (using SMPT/S or HTTPS) to HISP. HISP then find the recipient’s public key using DNS or LDAP, encrypted the email with the public key and then transmit the email to recipient’s HISP. recipient’s HISP will decrypt the email and then the email is ready for recipient to retrieve using secure POP, IMAP or HTTPS. Delivery confirmation might also be provided.

The Fax replacement Use Case

Users (providers, other health practitioner and even patients) must have internet access and registered with HISP to use Direct. HISP will verify the identity of users to ensure trust.

Public Key and Private Key. A user will have a public key and private key. Anyone can take his/her public key and encrypt a message, but only the one with the corresponding private key can decrypt the message. So the public key can be stored anywhere but the private key can only be stored at the user’s HISP.

With Direct, sending medical records is as simple as sending out an e-mail. You prepare your message with records as attachment, hit the send button of your email client or web mail, and it’s done.

Workflow issues

To make things even more easier, vendors are building applications which allows users to send direct messages within EMR systems so users don’t need to get records out of EMR and then prepare for an e-mail. A “share” button or stand-alone mail applications which can facilitate the Direct messaging process are available.

Beyond Fax Machine

Trust among HISPs: DirectTrust provides a community agreement so HISPs who join DirectTrust don’t need to negotiate with one another. DirectTrust introduced health identity provider as registration authority (RA, to verify identity of users) and certificate authority (CA, to assignment public and private keys).

Patient Involvement: Ideally, providers can send medical reports to patient’s PHR and patient can send their health information to providers without office visit. This requires patient registering with one HISP. There is discussion about what level of assurance should have. (Providers have LOA 3).

Pull ( or triggered push):Push is initiated from the sender’s end. Pull is initiated by recipient. Pull is more useful for ED to get the information needed or for user to update there PHR with providers EMR. But direct pull might not be very practical because it needs go through providers EMR to identify records that are needed, it’s time and resource consuming. Triggered push: the EMR prepare the need records ready for push, the user’s PHR updates everytime it starts.

Message delivery notification: is only partially implemented at the HISP end, but full MDN is needed but not simple.

Edge Protocols: some XD* protocol for document sharing.

• cross-Enterprise Document Sharing (XDS)
• cross-Enterprise Document Media Interchange(XDM)
• cross-Enterprise Document Reliable Interchange(XDR)

Case Study: CurrentCare

CurrentCare is the state of Rhode Island’s HIE. It mostly uses Direct technology. It’s unique because it utilizes an opt-in approach to patient consent.

Related post

Intro to Health Informatics 第三周笔记

2015-09-01 初稿