a regional health information exchange …€¦ · design methodology is described in many...

Copyright ©2008 Tokai Medinet Forum -NPO

A REGIONAL HEALTH

INFORMATION EXCHANGE

SYSTEM

FOR STROKE CARE

(NAGOYA-RHIE)

Masaharu OBAYASHI Kanrikogaku, Ltd

Masayuki KAGAWA FUJITSU LIMITED

Masaaki MIZUNO Nagoya University Graduate School of Medicine

(Director of Tokai Medinet Forum -NPO)

Jun YOSHIDA National Hospital Organization Higashi-nagoya Hospital

(Head Director of Tokai Medinet Forum -NPO)

9th International HL7 Interoperability conference 2008

IHIC 2008 Oct. 8-11, 2008

Crete, Greece


The Nagoya-RHIE project is an initiative to develop regional

health information exchange (RHIE) system based on the global

standard, in Japan.

The NPO, named Tokai Medinet Forum, is an organization for

promoting the project sponsored by METI (Ministry of Economy,

Trade and Industry) to implement a RHIE system for stroke care in

the Nagoya area using global standards including HL7and IHE ,

and to evaluate their efficacy through trial experiment.

Nagoya-RHIE

•Progress StatusIn August, 2006, the project was initiated, and the system was

developed through out 2006 and 2007.

Trial use began from 4Q of 2007.

Now in 2008, the evaluation works is in progress.


•national/regional contextNational context supported by following organizations, but

current phase is regional trial in Nagoya.

- METI (Ministry of Economy, Trade and Industry),

-Japan Stroke Society,

-Japan Society of Neurosurgery,

-Japan Association of Rehabilitation Hospital and Institution,

-Japanese Association of Emergency Medicine,

-Medical Information System Development Center (MEDIS-DC),

- Japanese Association of Healthcare Information Systems

Industry (JAHIS)

.etc.

Introduction – Business Case


Collaborative Pathway with XDS/CDA Standards

Collaborative clinical pathway

Clinical Document for clinical pathway (HL7CDA)

Framework for sharing clinical document (IHE XDS/PIX/PDQ)

Sharing Information

Register clinical documents with appropriate classification of stage of clinical pathway

Whenever necessary in the care of clinical pathway, the documents could be found and

retrieved

Support of patient identification in regional collaboration

Security and Privacy

Provide adequate security facilities such as VPN, HPKI, node authentication, user

authentication, encryption and audit trail.

Access control to protect patient’s privacy

Support of collaborations

Notification facilities by SMTP and Web Services

Exchange clinical data between HIS database and CDA document through Excel, CSV and

flat simple XML format

Possibility and Extension

Secondary use of clinical information, e.g. for variants analysis, clinical study and trial

Applicable to other clinical pathways, e.g. repeated clinical pathway such as diabetes care

Registry Federation among RHIEs

Interoperability of different vender client systems for various clinical paths


•health information exchange networkXDS was implemented to exchange 6 type CDA documents on

the RHIE system for collaborative stroke care

-first notification (referral) for pre-discharge

-discharge summary for transfer from acute hospital

-evaluation report after 3 months rehabilitation

-discharge summary for transfer from rehabilitation hospital

-report of post-discharge in home care

-current medication and allergy for emergency medicine

This system has been developed based on IHE IT

Infrastructure Technical Framework and OASIS ebXML

registry repository standards


• interoperability problemStandards are needed for interoperability

-common collaborative pathway for stroke care

-common clinical documents for the pathway

-common framework for sharing documents

-transformation between legacy HIS data and common

clinical documents


•Challenge interoperability problem

The joint venture organized under the NPO has been developing the

system.

In this project, some of IHE profile has been enhanced.

For example,

XUA (Cross-Enterprise User Authentication),

NAV (Notification of Document Availability) profiles have been extended

by coupling them with access control mechanism based on

XACML (eXtensible Access Control Markup Language)

The project participant companies in JAHIS have made an effort to

develop the Japan realm profile and implementation guide for HL7 standard

and IHE profile for such as

CDA R2, HL7 V2.5,

XDS (Cross-Enterprise Document Sharing) with

PIX (Patient Identifier Cross-Referencing),

PDQ (Patient Demographics Query) and

ATNA (Audit Trail and Node Authentication)


Facility A Facility B

PIXManager

Document Source

Document Consumer

HIS,PACS,RIS

HIS,PACS,RIS

Document Repository

Patient Identification Source Patient

Identification Source

Center

Document Registry

Notification

Audit Trail

Authentication

Register Global PID

XDS registry

XDS Repository

Register document

Query document

Retrieve document

Find PID

PID registry

Health Information Exchange Network

Register metadata

User

ATNA

XUA PWPPIX/PDQ

NAV

XDS


Audit Trail

DB

Patient

Visit Repository

ADT

Patient Demographics and Visit Query

XDS

adapter

Document

Source

XDS

adaptor

[ITI-15]

[ITI-16]

[ITI-17]

[ITI-22]

[ITI-21]

[ITI-14]

PDQPatient

Demographics

Query

[ITI-17]

XDS

adaptor

Repository

[ITI-14]

PID

Source

Medical Center for Nagoya-RHIE

ATNA

Management

Tools

XDS

PIX

PDQ

Registry

Document

Consumer

PID

Source[ITI-15]

PDQII

ebXML

(omar)

[ITI-8] [ITI-9]

[ITI-16]

[ITI-8] [ITI-9]

[ITI-9]

ADT

Source

Facility Gateway1 Facility Gateway2

[ITI-18]

[ITI-14] Register Document Set,

[ITI-15] Provide and Register Document Set,

[ITI-16] Query Registry,

[ITI-17] Retrieve Document,

[ITI-18] Registry Stored Query,

[ITI-9] PIX Query,

[ITI-8] Patient Identity Feed,

[ITI-21] Patient Demographics Query,

[ITI-22] Patient Demographics and Visit Query.

Overview of Nagoya-RHIE system


Example: Process Model of First Notification (Referral) for Pre-discharge

[ITI-9]

[ITI-16]

[ITI-14]

[ITI-17][ITI-8]

[ITI-15]

[ITI-9]


Folder based Access Control

Patient Family

Repository

Owner

Home doctor

SpecialistStroke Care

Emergency

Acute Hospital

Rehabilitation Hospital

Clinic / Care at home

Registry

Nurse, co-medical

Paramedic

CDA documents Subscriber


• reasons for adopting CDADeveloping standard is generally very expensive and needs

to make much effort

-CDA is a global standard for clinical document based on

XML technology

-particular realm profile such as Implementation guide is

needed, however, it is easier to be defined using CDA R2

standard

-implementation is made easier with general XML tools


•describe usersThere are two kinds of users:

Clinical providers including doctors and nurses are primary

users of RHIE systems.

However, it is not necessary for them to know about CDA.

They could work through rendered form of CDA on the window.

The second type, implementers of a system are direct users to

create and read clinical documents written by CDA.

However, it is not so difficult for them to import/export legacy

data from/to CDA document if adopting our approach.


Implementation, Methodology and Tools

•design methodology/paper documentsDesign methodology is described in many documents of

JAHIS and NPO in Japanese.

•use of implementation guidesJapanese implementation guide for stroke care documents

has been developed


Attachments

Clinical-Path-Document（CDA R2）

-Document for Emergency Medicine (CDA R2)

Folder0 Path Folder1 Own Folder

Referral

Document Type

specified by

ClassCode and

typeCodeAcute care

Term

Specified by classCode and typeCode

Folder Specified by

CodeList

Long

Term

Lab.Result Image.Report

Rehabilitation

Term

Path Folder2

-ADT（HL7V2.5）

Path-Stage

Folders for

a Patient …..

Path-stage

indicated by

EventCode

Common Series１ Series2 Others

1) First notification (referral) for pre-discharge

2) Discharge summary for transfer from acute hospital

3) Evaluation report after 3 months rehabilitation

4) Discharge summary for transfer from rehabilitation hospital

5) Report of post-discharge care at home

6) Current medication and allergy for emergency medicine

• implementation of document types


•correspondence with paper documents/formsThere are some Excel forms, correspondence with Discharge

summary, Evaluation report and Report of post-discharge care at

home

•use of terminology and terminology

infrastructureJ-MIX; Japanese Vocabulary Set for medical data items (instead

of LOINC or SNOMED-CT)

•management of identifiersOID is defined in header-codetable and body-codetable

J-MIX is used and extended J-MIX code is defined in body-

template

Patient identifier is managed with IHE PIX function


• information reuseheader-instance can be defined by selecting elements of

header-template

body-instance can be defined by selecting elements of body-

template

•complementary standardsIHE IT Infrastructure Technical Framework profile

OASIS ebXML registry repository standards


•security and confidentiality issuesThe system has been enhanced by the following functions and

tools including open source programs.

-Master data of User, Facility, Group, and Node (ebXML)

-Access Control and Notification using Folder (ebXML)

-Single Sign On (using openSSO)

-Life Cycle Management for XDS metadata

-Digital Signature (HPKI)

-Import/Export HIS data into/from CDA document

•software tools Excel, XML editor and XSLT engine

•conformance testingNot yet available


Project type:

•exploratory, pilot, large scale deploymentadvanced pilot project

CDA workflow:

•sites where CDA is in useinvolve about 30-40 hospitals and clinics in Nagoya area

•number of userscurrently about 200 medical staffs are involved

CDA in Use (Content Management)


•Map/template specificationSpecification can be provided using Excel sheets as follows:

1) header-codetable: define code system and value set

2) header-template: define element type of header

3) header-instance: define element value and mapping

4) body-codetable: define code system and value set

5) body-template: define element type of body

6) body-instance: define element value and mapping

•Instance ValuesInstance values can be provided as simple XML format from HIS

DB or Path Editor.

•Automatic generation of CDA documentXSLT Transformation from Map/Template specification and

Instance values into CDA document can be performed.


•volume of documents exchangedThe table shows the volume of the specification for

collaborative stroke care document.

sheet name sheets number of elements

1 header-codetable 1 10

2 header-template 1 11

3 header-instance 6 11,11,16,16,16,16

4 body-codetable 1 96

5 body-template 1 331

6 body-instance 6 4,28,239,34,331,241

• training and education for users, implementersEnd user can use the system without knowing XDS/CDA

Implementer of client applications should only understand the

flat XML formats to exchange medical information.


•CDA import/export in the electronic health record


header-instance

header-template

header-codetable

Figure 5. Example of Automatic Generation of CDA Document

body-codetable

body-instance

body-template

XML

format

For stroke care, 6 types of CDA documents can be generated

based on Map/Template specification and Instance Value set


Technical view point is to resolve the interoperability problem as

follows;

-common collaborative pathway for stroke care

-common clinical documents for the pathway

-common framework for sharing documents

-transformation between legacy HIS data and common clinical

documents

Clinical view point is to improve the pathway process comparing

the case of without IT system.

-improve the score of care outcome according to evaluation

criteria

-establish the pathway process including human network and

communication

-able to obtain demographical data on collaborative stroke care

Evaluation/Assessment


• method of evaluationdeploy the system to participant facilities and apply patient

care in the real filed

• resultsTechnical view point is to resolve the interoperability

problem as follows;

-common collaborative pathway for stroke care: success

-common clinical documents for the pathway: success

-common framework for sharing documents: success

-transformation between legacy HIS data and common

clinical document: success


Clinical view point is to improve the pathway process

comparing the case of without IT system.

-improve the score of care outcome according to evaluation

criteria: under evaluation

-establish the pathway process including human network and

communication: under evaluation

-able to obtain demographical data about collaborative stroke

care: under evaluation

• feedback to next CDA release 3analysis of result and consideration will be needed


•changes/extensions to CDA designextend our approach to the other CDA document

•planned changes/extensions to overall exchange

architectureIn the current implementation, pathway editor needs high cost

to maintain program according to change of specification.

More flexible tool is expected as a pathway editor.

Development of architecture and tool for specification driven

pathway editor will be planned.

Future Plans


•next stepsarchetypes of openEHR (CEN13606) is similar to the

specification

then to be able to handle the archetype and template of

openEHR within our approach

As a next step, the Nagoya-RHIE project will begin to apply the

system to other collaborative pathways such as orthopedic

surgery, especially femoral [femur] neck fracture.


•conclusionsThe new approach and tool for creating CDA document from

specification and instance value set is useful to reduce the cost

of developing RHIE system

•lessons learnedFor now, our aimed collaborative care system could be

achieved by XDS and CDA.

Specifying the standard for Japan realm could be done

smoothly in JAHIS (effort and cost reduced).

•summary of primary business drivers,

challenges aheadXDS with HL7CDA may be a good framework for EHR.

design and realize PHR-EHR system based on XDS and CDA

Conclusions and Lessons Learned


Thank You!

Question?

a regional health information exchange …€¦ · design methodology is described in many...

Documents