Dionseq Uatummy Odolorem Vel

(1)

Aciduisismodo Dolore Eolore

Dionseq Uatummy Odolorem Vel

Hitachi Clinical Repository

October 2011

Meet the Unique Challenges of DICOM/HL7 Data Access,

Data Consolidation, Data Mining and Data Distribution

(2)

Executive Summary and Introduction

(4)

Leverage Hitachi Clinical Repository

HCR is not a replacement for a PACS database or short-term cache. Providers can choose to leverage the block storage with or without Hitachi Virtual Storage Platform fronting.

HCR allows your administrators to get around the validation objection as its uses in-dustry standard communication protocols (DICOM and HL7) to interface with the PACS and IS systems. This eliminates the need for independent software vendors (ISVs) to validate the Hitachi storage layer.

The Hitachi Clinical Repository Solution

Today's modern healthcare facility is faced with an explosion of image and information related data from multiple departments and domains across the enterprise. Data is generated in a variety of formats and interoperability is lacking when outside the originating department. For the healthcare organization, trying to manage data access, distribution and storage from these disparate data silos often turns into a compatibility nightmare. And the significant ongoing expense of maintaining each department's viewer, archive and storage islands must be considered.

Hitachi Clinical Repository is an interoperability framework and storage solution, purpose built for managing the business and health data, fixed content, images and their associated metadata. HCR enables a healthcare organization to establish a facility-wide central repository that allows multiple business and clinical systems to utilize a central archive to deliver data storage in a vendor-neutral format. HCR achieves this by abstracting the data from the source applications. This allows HCR to deliver this data to consuming applications based on the metadata abstraction, regardless of the source or format of the data.

HCR is composed of a Hitachi storage layer (Hitachi Content Platform and Hitachi Data Discovery Suite) integrated with an interoperability framework (that tightly integrates with a hospital's clinical IT systems) (see Figure 1). This combination delivers a solution that meets the unique challenges sur-rounding DICOM/HL7 data access, data consolidation, data mining and data distribution. Key benefits of Hitachi Clinical Repository include:

■

■ _{Full clinical repository for all departments} ■

■ _{Central image and data storage} ■

■ _{Standards-based architecture DICOM/HL7/IHE/CIFS/NFS/REST/HTTP} ■

■ _{Support for all image and data types} ■

■ _{Open API for electronic patient record (EPR) and electronic medical record (EMR) Integration} ■

■ _{Highly scalable storage systems} ■

■ _{Vendor-neutral long-term clinical archive} ■

(5)

Solution Architecture and Components

Figure 1. Hitachi Clinical Repository Architecture and Components

As mentioned above, HCR is made up of Hitachi Content Platform and Hitachi Data Discovery Suite integrated with a 3rd-party ISV product developed by Visbion. Delivered as a solution, HCR seam-lessly consolidates and presents all relevant health and business data in a single, longitudinal record. This gives healthcare providers access to the most comprehensive view of their patients, enabling them to be more efficient, cost-effective and innovative.

Hitachi Content Platform

(6)

A combination of software and hardware, HCP provides an archival storage environment ideal for storing all types of data, from simple text files to medical images to multigigabyte database images. HCP provides easy access to the archive for adding, retrieving and, when allowed, deleting the stored data. It uses write once, read many (WORM) storage technology and a variety of policies to ensure the integrity of archived data.

HCP stores objects in an archive. Each object permanently associates data HCP receives (for example, a file, an image or a database) with information about that data. HCP also allows client ac-cess to the archive through the leading industry-standard protocols: HTTP, WebDAV, CIFS and NFS. Using these protocols, actions such as adding objects to the archive, viewing and retrieving objects, changing object metadata and deleting objects can be performed. These protocols can be used interactively with a command-line tool or graphical user interface (GUI), or programmatically with ap-plications written against the archive.

Extending the capabilities of HCP is the addition of the Hitachi Adaptable Modular Storage (AMS) family of scalable storage systems designed to manage many of your extremely complex tasks and give you operational efficiencies and performance you won't find anywhere else in a midrange system. AMS includes enterprise storage capabilities that are typically found in high-end storage systems, including dynamic provisioning to improve overall utilization rates and help simplify storage management.

Nonclinical Information Workflow (CIFS, NFS, HTTP, etc.)

Figure 2 depicts the workflow for Hitachi Clinical Repository ingesting clinical information. HCR uses standard protocols available in Hitachi Content Platform from information systems (IS) to archive and index content into a single access point for consuming applications.

(7)

Hitachi Data Discovery Suite

Hitachi Data Discovery Suite provides indexing, search, file-tiering and proactive e-discovery ca-pabilities for Hitachi Clinical Repository. HDDS simplifies e-discovery and improves the efficiency of identifying, searching, retaining and managing unstructured data across online, nearline and archive media. Users can search across multiple data silos, including all clinical data within HCR, regardless of where that data originated. This all can be accomplished from a single interface according to user access privileges via Microsoft Active Directory and LDAP integration (see Figure 3).

Figure 3. Hitachi Data Discovery Suite

Hitachi Data Discovery Suite and HTTPS Protocol

HDDS supports the Web Services non-GUI interface to perform HDDS operations and to execute commands using the HTTPS protocol. Within this interface, method calls are made over the network using HTTPS POST requests to the HDDS server, and HDDS returns the results in XML format.

(8)

Hitachi Clinical Repository DICOM Connector

Integrated within Hitachi Clinical Repository is a DICOM library supplied by Visbion, a leading medical imaging software company. The HCR DICOM connector ingests a DICOM feed from the picture archiving and communication system (PACS) over the TCP/IP network and receives the DICOM images. It then parses the DICOM header into a custom XML file and stores the .dcm file, system metadata and custom XML to HCP using its REST interface. The ability to create metadata about the data object outside of the original application's database allows consuming applications (such as electronic health record or portals) to discover and consume all clinical data, regardless of the source of that data. It is this unique feature that sets HCR apart from other archiving solutions, such as vendor-neutral archives and image archives.

Medical Imaging (DICOM Systems) Workflow

Figure 4 represents the components involved in Hitachi Content Repository ingesting DICOM images from a PACS as its long-term archive.

Figure 4. Medical Imaging Workflow

Hitachi Clinical Repository HL7 Connector

(9)

HL7 messages that the information systems [i.e., radiology information system (RIS), computer information system (CIS), laboratory information system (LIS), hospital information system (HIS), etc.] are already creating and sending out as part of the normal clinical workflow. In most cases, this is accomplished by setting up a new destination on the hospitals' interface engine (i.e., Cloverleaf, BizTalk, etc.) with HCR receiving a copy of all HL7 messages that are routed through the interface engine. When HCR receives the HL7 message, it parses the content into a custom XML file and stores the original HL7 message plus the custom XML to HCP using its REST interface. As a result, HCR remains up to date with any patient and study updates as well as storing and indexing the reports for consumption downstream.

By capturing this HL7 message, HCR reduces the need to be integrated with the originating ap-plication. The originating application would consume the exact same HL7 message that HCR consumes. The difference is that HCR is not using the originating application's database to store the result; thus, the requirement to validate the ISV is removed.

Clinical Information Systems Workflow (HL7)

Figure 5 represents the component and workflow of Hitachi Clinical Repository when ingesting HL7 messages from information systems. HCR will parse the contents and aggregate the information into a single access point for consuming applications.

(10)

Conclusion

Hitachi Clinical Repository is an interoperability framework and storage solution for the health and life sciences market. It is purpose built for managing the business and health data, fixed content, images and their associated metadata. HCR enables a healthcare organization to establish a facility-wide central repository that allows multiple business and clinical systems to utilize a central archive that provides data storage in a vendor-neutral format. HCR assists our customers in addressing key business problems, such as:

■

■ _{Providing a consolidated view of clinical data, including custom metadata, so that it may be}

stored, accessed, distributed and utilized in an intelligent way

■

■ _{Delivering data ownership and ultimate control back to the facility, thereby facilitating a flexible IT}

strategy that meets their needs today and future-proofs existing investments

■

■ _{Delivering performance and availability while simplifying IT management and reducing the}

grow-ing expense for maintaingrow-ing disparate systems

■

■ _{Enabling the provision of one longitudinal clinical record to a clinical portal to improve data quality}

and informed decision making (competitive differentiation)

Example Electronic Health Record (EHR) Query in Hitachi Clinical Repository In this example, the consuming application is querying for all records where the patientName is Dave Wilson.

URL: https://hdds.hds.com:8443/hdds/api/cli METHOD: POST

Parameter: #c=SearchFiles&-u=admin&-p=password&-y=advanced&-x=&-m=10000& #u=xml:patient:patientInfo:patientName:string("Dave Wilson",

mode="phrase")

What the XML looks like:

(11)

States and other countries.

All other trademarks, service marks and company names in this document or website are properties of their respective owners.

Notice: This document is for informational purposes only, and does not set forth any warranty, expressed or implied, concerning any equipment or service offered or to be offered by Hitachi Data Systems Corporation.

Dionseq Uatummy Odolorem Vel

Aciduisismodo Dolore Eolore