Big Data as an e-Health services

Big Data as an e-Health Service Dr. W. Liu

Dr. E.K. Park

School of Science and Technology Georgia Gwinnett College

VP for Research and Dean of Graduate Studies California State University - Chico and their states, as well as other health-related information being carried among associates parties of insurance, government reporting and so on. Additional external data are in the e-Health communication and support infrastructure sources including the National Health Information Network (NHIN), Health Information Exchanges (HIE), Health Information Organizations (HIO) and Regional Health Information Organizations (RHIO).

Abstract— Big Data is transforming healthcare, business, and ultimately society itself, as e-Health becomes one of key driving factors during the innovation process. We investigate BDeHS (Big Data e-Health Service) to fulfill the Big Data applications in the e-Health service domain. In this paper we explain why the existing Big Data technologies such as Hadoop, MapReduce, STORM and the like cannot be simply applied to e-Health services directly. We then describe the additional capabilities as required in order to make Big Data services for e-Health become practical. Next we report our design of the BDeHS architecture that supplies data operation management capabilities, regulatory compliance, and e-Health meaningful usages.

As sources and volume of information increase, so will expectations in utilizing those large volume of e-Health data to reduce costs, boost outcomes and improve treatment. We investigate BDeHS to fulfill the Big Data applications in the e-Health service domain.

Keywords- Big Data Technologies; e-Health Solutions; Big Data as a Service; Service Support Infrastructure; e-Health Data Operation Management; Regulatory Compliance.

This paper is organized as follows. In section II, we describe the foundations and the additional BDeHS functionality. To further extend the Big Data service approach into a national and global framework for e-Health, in Section III we describe our design of the BDeHS architecture that supplies operational management capabilities, regulatory compliance, and promising e-Health meaningful usages. The final section concludes with a summary of our contributions.

I. INTRODUCTION Digital healthcare solutions have promised to transform the whole healthcare process to become more efficient, less expensive and higher quality[1~8]. In the context of eHealth, numerous flows have generated slightly less than 1,000 peta bytes of data now (and may reach about 12 ZBs by 2020 in our own estimates) from various sources such as electronic medical records (EMR) systems, mobilized health records (MHR), personal health records (PHR), mobile health care monitors, genetic sequencing and predictive analytics as well as a large array of biomedical sensors and smart devices.

II.

BIG DATA FOUNDATIONS FOR E-HEALTH

Figure 1 below depicts an environment that supports eHealth applications from individual outlets and test facilities as well as insurance providers and government agencies [9~12]. All generate tremendous data points interconnected with the national health information networks.

The electronic medical record (EMR) initiative has resulted data streams from all types of patients at the hospital, insurance companies and doctor’s office. A single patient stay generates thousands of data elements, including diagnoses, procedures, medications, medical supplies, digital image, lab results and billing. These need to be validated, processed and integrated into a large data pools to enable meaningful analysis. Multiplying this by all the patientstays across the health processing systems and combining it with the large number of points where data is generated and stored and the scope of the big data challenge begins to emerge. Outside the care provider facilities, external health data are patient generated (including social media, selfquantification including use of smartphones/wearable sensor information on patients' heart rate, brain activity, sleep patterns, temperature, muscle motion, and numerous other clinically useful data points), high-throughput and systemwide measurement systems of many biological body parts

Figure 1. e-Health Big Data Service Environments

A. Data Sources and Types Data types include structured data, semi-structured ones

1

982

and other unstructured information. •

HL 7 (Health Level 7) messaging standards [13] supply well defined structured data to carry e-Health information. Examples include transaction sections such as Admission Discharge Transfer, Summary of Care and so on. Various IDs could be involved [14,15]. International Disease Codes supply standard diagnostic coding schemes for clinical visits.

•

NCPDP (National Council for Prescription Drug Program) prescription insurance claims and NCPDP SCRIPT for electronic prescription messaging [16] are standard structured data that handle prescription orders with NCPDP validation of drug-to-drug interaction, allergy and dose checks, pharmacy database access, decision modules, inventory tagging and reading, as well as record keepings.

•

DICOM (Digital Imaging and Communications in Medicine) provides semi-structured data for radiology image exchanges over IP networks [17]. While the metadata could be structured, some internal image stores may not be fully standardized.

•

HIPAA transactions for insurance claims and other processes are based on American Standard Institute accredited committees X12 messaging standards [18]. Those data are well structured.

•

ISO/IEEE suite of protocols and messaging standards for digital health monitoring and diagnostics devices [19] provide well-structured data. However, they do not preclude vendor devices from introducing additional optional files or other data set extensions.

•

Internal logging and security audit records (such as Java Messaging Service format from application-domain monitoring nodes) could be similar in Health IT systems, but there have been no standards. They have to be treated as semi-structured data as far as end-to-end system flows are concerned.

•

A patient-support system can gather, store and deliver medical information (e.g., electronic patient and medical records) to patients and doctors remotely, including medical history, allergies, vaccinations, appointments, and invoices as well as inquiry supports. Inside the vendor systems, there are no guarantees that all data sets are standard compliant.

•

•

A research-portal system can gather, store and analyze patient medical information used by researchers and for government Centers for Disease Control reporting. The research systems also support new scientific discoveries, in seeking better disease management regimes and monitoring public health. The information will be fed into future e-Healthcare application developments.

•

A national health information network [20] generates communicational data about the underlying communication (session) functions. Some of the interfaces are standardized by NHIN and data flows could be well recognized.

•

An operational environment to implement policy and security functions as well as usage accounting/charging functions [21] is essential to handle the performance data in order to meet the overall operational management functional requirements, including QoS benchmarks, security audit trails and tracking logs.

B. Big Data Solutions and Products Big Data research requires knowledge about standards, filters, meta-data, techniques for storing, finding, analyzing, visualizing and securing data, and sector-specific editing of data. The predominant current technologies include MapReduce, Hadoop, STORM and alike with combinations or extensions. 1) STORM Storm is a free and open source distributed realtime computation system [23]. Storm makes it easy to reliably process unbounded streams of data. Storm can be used with any programming language (usually Java, but also Python and others as well). Storm integrates with the message queuing and database technologies. A Storm topology consumes streams of data and processes those streams in arbitrarily complex ways, repartitioning the streams between each stage of the computation however needed. Storm may achieve processing of over a million tuples processed per second per node as necessary for e-Health global flows. To do realtime computation on Storm, a “topology” is created, which is a graph of computation. Each node in a topology contains processing logic, and links between nodes indicate how data should be passed around between nodes.

A clinical-support system can gather, store and retrieve patient medical information for internal use by physicians and healthcare workers delivering services at the point of care. The admin and supervisory personnel can have access to backend processing of resources, insurance claims and billings. A number of exchanged networks have been under development to ensure userlevel standards. But the system level data have not been standardized.

Figure 2. Illustration of STORM Architecture

Storm can integrate with any source of message queuing and database connections. It can also generate its 2

983

own stream or read from somewhere like e-Health streaming data. The source of data stream is called a “spout” in the Storm architecture (see Figure 2 above).

Hadoop is used by many companies as a highperformance, scalable and relatively low-cost option. Vendors such as EMC, IBM and Oracle have commercialized Hadoop, and aligned and integrated it with the rest of their database and analytic offerings. The batch processing nature allows e-Health informatics be processed off-line to generate reports and research discovery. But it cannot be directly used in real time to correlate the e-Health data within the 15 seconds interval as shown in some of Big Data research and development [25].

The logic of processing the input and output steams (such as functions, filters, streaming joins, streaming aggregations, talking to databases, and so on) are stored into “bolts”. A Storm topology forms a network of spouts and bolts, with each edge in the network generating output streams. A topology is an arbitrarily complex multi-stage stream computation. Topologies run indefinitely when deployed.

3) MapReduce Hadoop was derived from Google's MapReduce and Google File System (GFS) papers [26] and thus it is important to understand the foundations to avoid reinventing the wheel in this regard.

Storm is scalable, fault-tolerant, guarantees your data will be processed, and is easy to set up and operate. However, partitioning of e-Health data is not a native support which is a serious limitation for direct e-Health data services as not all service providers and associate are allowed to process every parts of the data set due to eHealth regulatory requirements [3,8]. The logic in processing stages does not support the e-Health routing flows as described in [9]. Other than guaranteed processing, there are no Quality of Service or QoS mechanisms explicitly spelled out for e-Health service.

MapReduce is a computational paradigm where the application is divided into mappers and reducers which may be executed or re-executed on any node in the cluster. In addition, it provides a distributed file system that stores data on the computing nodes, providing very high aggregate bandwidth across the cluster. It enables applications to work with thousands of computation-independent computers and petabytes of data.

2) Hadoop for Batch Processing Hadoop is another framework [24] for dealing with big data (see Figure 3 below). It provides a set of general primitives for doing batch processing. It supports the running of applications on large clusters of commodity hardware. The Hadoop framework transparently provides both reliability and data motion to applications.

However, for non-splitable (compressed) files such as e-Health DICOM image files, they may have to flow into a single mapper thus reducing the effectiveness of Bid Data processing capability. Additional tools have to be incorporated into the ecosystems. Those tools in turn have to be trained for e-Health files rules causing another layer of complexity. Besides the technology limitations in each of specific Big Data foundation technologies or tool sets, the Big Data applications in health have focused too much on offline informatics. In order to generate on-flight e-Health big-data services, QoS and service level agreements have to become a native support capability in the underlying e-Health service infrastructure. 4) Programing Tools Besides the general Big Data solution paradigms, it is worth mentioning the e-Health specific big data programming tools known as MUMPS [27], which stands for Massachusetts General Hospital Utility MultiProgramming System. MUMPS (or simply M) is a multiuser, strongly imperative language designed to manipulate and control massive databases. It is used in the high availability, high reliability niche of the computer market— which includes banking and hospitals. It provides simple data abstractions, in which all data values are strings of characters, and all data can be structured as multiple dimensional arrays. M data structures are sparse, using strings of characters as subscripts. M is itself a language combined with a database engine. The application field of M is very specific to high demand and high performance databases that require support for sparse data.

Figure 3. Hapoop Processing Systems

Hadoop scales across a small cluster to large clusters. A small Hadoop cluster will include a single master and multiple worker nodes. The master node consists of a JobTracker, TaskTracker, NameNode and DataNode. A slave or worker node acts as both a DataNode and TaskTracker. A name node contains the processing logics, and a JobTracker server can manage job scheduling. In clusters of the Hadoop where the MapReduce engine is deployed against an alternate file system, the NameNode, secondary NameNode and DataNode architecture of the HDFS in Hadoop are replaced by the file-system-specific equivalent. 3

984

operational support architecture to constantly automatic and improve the quality of services.

The initiative of deploying EHRs in all US hospitals now brings M programming into the mainstream. This becomes a major enabler for mapping and flows of big data services. Further programming constructs are required to develop key analytics algorithms to power many of the big data applications (collaborative filtering, trend prediction, and anomaly detection). Algorithms include Dimension reduction, curse of dimension, nearest neighbor search (similarity search), SVD (singular value decomposition), LSI (Latent semantics indexing), Random walk, recursive linear regression, and so on.

Big data solution architectures have to be flexible enough to cope with not only the additional sources but also the evolution of schemas and structures used for transporting and storing data. To ensure analytics are meaningful, accurate and suitable, metadata and semantic layers are needed that accurately define the data and provide business context and guidance, including appropriate and inappropriate uses of the data. This evolution of standards will eventually improve interoperability and data quality. Data timeliness is a challenge in various healthcare settings, such as clinical decision support, whether for making decisions or providing information that guides decisions. Big data can make decision support simpler, faster and ultimately more accurate because decisions are based on higher volumes of data that are more current and relevant. As the data points and decision points are going beyond the humanly availability during a very limited window for clinical decision support, response time has to be capped to run a report or analytic query. Careful attention to data and query structure, scope and execution is needed to ensure that the constraints of the processing windows are observed while still obtaining the best possible answer.

C. Additional e-Health (Big Data) Capabilities The BDeHS provides the services to access, organize, and glean discoveries from huge volumes of e-Health digital data. In order to augment the Big Data foundations to the ecosystems of e-Health, we identify additional key capabilities necessary for BDeHS services. 1) Data Federation and Aggregation The various types have been described in the previous section, and those sources reflect the fragmentation of eHealth data among the various stakeholders, including payers, providers, labs, ancillary vendors, data vendors, standards organizations, insurance institutions and regulatory agencies. Solutions for big data will break the traditional model, in which all data is loaded into a warehouse. Data federation will emerge as a solution in which the big data architecture is based on a collection of nodes within and outside the enterprise and accessed through a layer that integrates the data and analytics.

In the Big Data ecosystems, streams of e-Health data containing complex and varied events without an overarching structure need to be addressed. In this case, those events have to be turned into meaningful measures in real time that are, in turn, suitable for rapid analysis. Security of data is inherently built-in when e-Health regulations were designed for promoting e-Health roll outs. As the operational infrastructure becomes extremely complex, operational management has become an integral part of the BDeHS when we design the solutions.

Additional central data collection points are emerging as HIE, RHIO and NHIN work to facilitate the exchange of healthcare data. 2) Security and Regulatory Concerns This is the most fundamental requirements that distinguish the Big Data services for e-Health. They deal with additional challenges, such as privacy, security and legal concerns, as well as questions about authenticity, accuracy and consistency.

III.

SOLUTIONS OF BIG DATA SERVICE FOR E-HEALTH

Our Big Data for e-Health Service solutions are evolved from our research of interoperable (data) flows as defined in [3,8,9] into streams as illustrated in the Figure 4 below.

The entire healthcare system can realize benefits from democratizing big data access and the cloud [2] makes exposing and sharing big data easy and relatively inexpensive. However, significant security and privacy concerns exist, including the Health Insurance Portability and Accountability Act (HIPAA). A credentialing process could facilitate and automate this access, but there are complexities and challenges. Since providers, patients and other interested parties such as researchers need various secure accesses, data security policies have to control by group, role and function. Finally, the security of the data once it leaves the cloud also needs to be assured. 3) Data Operational Management The operational management capabilities [8,9,11] include data interoperability management at a global scale, information timeliness to meet service level agreement, and

Figure 4. BDeHS Solution Diagram

4

985

Another benefit is in its flexibility to deal with Regionalization and/or Globalization of flows. External data will come from different medical systems in various regions and countries. Effectively working across these disparate data repositories can help identify local knowledge and best practices and leverage them regionally and globally.

A. Big Data Flows in e-Health Streams Our new solution provides data streaming federation and decision points in supplement to the original flows of eHealth adaptation and message routing [3,8,9]. The center of the concept is around application flow set-up procedures that detail the processing stages including data fork points, stream joints, as well as event and message logging. All of which are specified in a policy format that controls the in-flight processing of data. A protocol command (e.g., transform/send/store data) may be triggered by a protocol type and the policy ID established during the flow setup processing.

The BDeHS e-Health-flows deal with increasing mobile Health application traffic as well. Demand for ubiquitous access to information mandates mobility and other technologies that provide access on demand. As data becomes more current, it can be forked out of the flows into the mobility adaptation gateway into the hands of people with an immediate need for it, such as for clinical decision support. Quality of care and improved outcomes will be the ultimate benefits.

A data flow in this e-Health environment is mapped into a stream with additional processing stages. First data formats are adapted via adaptation gateways into a common format as required by the e-Health metadata model, while security policies are tagged along with the flows.

B. Security and Regulatory Compliance Secure BDeHS service payloads and information flows have to be part of an e-Health solution. Possible messages with security concerns include summary of patient record exchange, terminology mediation, message handling (includes transformation, routing, logging and content based filtering), secure data delivery, and confirmation of meaningful usages.

Data Federation is extended into our own e-Health adaptation gateways [3,11], which admit data flows into the processing nodes with e-Health data processing logics (filtering, logging, aggregation, exploratory and iterative analysis, regulatory checkpoints, and so on). Inside the BDeHS infrastructure, processing nodes can further feed into another adaptation gateway for further flow analysis so that information may be further correlated with other flows.

Security framework in e-Health was already established in [8]. Once a secure e-Healthcare association is established, both end points may invite others to participate in a MPMD (Multiple Participations and Multiple Drop-offs) eHealthcare flow. The e-Healthcare Service Associates Identifier(s) are correlated together so that each entity has the visibility to the relevant portion(s) of the communication payload, while linking the total messages intended for different recipients. When the data streams are routed into any Big Data analytic engines, patient-indefinable information are removed according to BDeHS security policies following the intent and security level of the steam sink points.

Data sinking gateways provide the exit points of the eHealth data flows when anomalies (e.g., adverse treatment or drug effects) are detected on flight or when e-Health data security events have to be reported. Data logs from relevant flows can be directed into certain exit gateways so that aggregation can formulate dynamic solutions that require immediate decisions (e.g., responses to the spread patterns of an epidemic). In addition, aggregated data reports can be generated at any stages of the e-Health data streams. In between the data entries and exits, a number of middle storage and processing stages supply data replications and parallel processing logics for additional data segmentation, summarization, (security and health regulation) policy enforcement, filtering, data transformation, header and trailer expansion, message split or union, state synchronization, and coordination with other distributed processing nodes.

The major benefit of ID-removal ensures access to some de-identified data can simultaneously improve levels of selfreporting as well as data sharing. For example, Patient ID credentials (instead of the detail ID#, Name, Address information) are no longer presented from clinical offices to the lab facilities. Sending only the essential (minimum credential) data that are pre-agreed upon among the eHealthcare processing parties also enhances performance of rapid forking of the streams into Big Data processing clusters.

One key benefits of our solution approach is in e-Health Data Consistency. Data adaptation and mappings promote consistency in self-reported data across the healthcare system to eliminate local discrepancies and increase the usefulness of data. As e-Health becomes global solutions, we plan to come up with new ways to further the adaptation layer to facilitate global scale usages. Aggregating data regionally and globally also provides healthcare researchers with larger populations for clinical studies, trending and disease monitoring for epidemics, as well as early detection and the potential for improved results.

When we allow security associations with multiple entities, an issue has to be addressed as different parties may want to view a different subset of the records on-the-fly in order to collaborate in the care process. For example, some portions of the patient records may not be relevant to another e-Healthcare party (e.g., such as the lab with a processing entity that only needs a patient identity without the details of patient records). 5

986

end-to-end test setup, and so on. The services describe the specific interfaces to be used among interconnection participants to locate and exchange health information. All are governed by QoS parameters which in turn support service level guarantees.

The issue of sending only a portion of relevant data set can now be achieved. As multiple parties in secure eHealthcare association(s) and with their different roles and different access privileges being supported, the end-to-end streams set-up in BDeHS manages the potential growth of many combinations among these join/sink points. The solution allows both individuals and the parties with which they are doing business to have higher-assurance transactions without needing to exchange the details of information as the security policy managers will take over those disparate works.

3) Data Interoperability Management Our solution architecture is flexible enough to cope with not only the additional sources but also the evolution of schemas and structures used for transporting and storing data. To ensure analytics are meaningful, accurate and suitable, metadata and semantic layers are supported that accurately define the data and provide business context and guidance, including appropriate and inappropriate uses of the data. This evolution of standards will eventually improve data quality.

When the BDeHS processing nodes recognized the communication message contains HIPPA conformance required fields, additional logging actions are invoked before a node can process or send the payload forward. As such, regulatory compliance specific actions are carried out during the flow. An example of e-Health network policy action is to do packet inspection inside a data stream to check the principal parties and the so called busines associates (as defined in HIPPA and HIGHTEC Acts), and then to be conformant with HIPAA security rule of ensuring the appropriete log entries will have a whole message instead of a partial MDMP stream.

IV.

SUMMARY

We have presented a new BDeHS (Big Data for Health Service) approach to bring healthcare flows and data/message management intelligence into the ecosystems for better stream processing, operational management and regulatory compliance. By asserting security control into the service layer with native e-Health features our solutions ensure regulatory compliance.

C. Data Operational Management and Data Timeliness Because not all e-Health Big Data flows are batch process, we need to develop realtime flows that meets QoS (such as time constraints and throughput requirements) in order to provide on-flight e-Health event detection and aggregation analysis.

Additional key benefits of our BDeHS operational features include:

The current BDeHS capabilities include policy actions further combined with QoS actions as future traffic patterns are identified with routing of e-Health contents being further improved. In other words, any routing policies may further reference application-oriended policies that have to be satisfied before the routing can be applied.

•

Big Data Stream setup and provision to support application flow associations, data federation and aggregation along the streaming paths, partitioning of eHealth messages along the processing.

•

Security to meet stringent e-Health environments and regulations is an integral part of the infrastructure. Multiple flows can be managed by a common MPMD model. End-to-end regulatory oversights can be guaranteed.

Quality of Service guarantees includes realtime processing, reconfiguration and enhancement of processing cluster and network capacity, data interoperability management, as well as reporting capabilities. The BDeHS service solution as reported in this paper has supplied the much needed detailed guidelines for overall Big Data services to achieve the meaningful usages of eHealth global solutions.

1) Centralized QoS Monitoring Monitoring the BDeHS performance is the essential step in provisioning additional storage clusters and networking resources to guarantee QoS of e-Health Big Data applications. QoS Service Managers are devised to control and coordination of the end-to-end overall Big Data stream service views. The QoS manager handles end-point performance parameter requests. During a BDeHS flow, the QoS manager also monitors and assists in enforcement of end-to-end transmission performance, via accessing to logs and reports of functional performance feedback.

•

REFERENCES [1] W. Liu and E.K. Park, “e-Health AON (Application Oriented

2) BDeHS Service Profile Management The best way to manage a wide variety of e-Health application flows is to maintain a number of BDeHS service profiles that can easily be converted into the required action policies to provision and setup the big data streams.

Network)”, IEEE International Conference on Computer Communication Networks, BMAN Workshop, Nausa, Bahamas, July 2013. [2] E.K. Park and W. Liu, “e-Healthcare Cloud Computing Application Solutions”, IEEE ICNC2013, International Conference on Computing, Networking and Communications, San Diego, CA, January 2013. [3] W. Liu, E.K. Park and Udo R. Krieger, “e-Health Interconnection Infrastructure Challenges and Solutions Overview”, IEEE HealthCom-2012, the 14th IEEE International Conference on e-

Service profiles describe how to provision services for a specific domain or functionality such as e-Health participation levels, priorities, acceptable usage parameters, 6

987

[4]

[5]

[6]

[7]

[8] [9]

[10] [11]

[12] [13]

[14] National Provider Identification (NPI), https://nppes.cms.hhs.gov. [15] Health Industry Number System (HIN), http://www.hibcc.org/

Health Networking, Application & Services, Beijing, China, October 2012. C.G. Chute, “Obstacles and options for big-data applications in biomedicine: The role of standards and normalizations”, 2012 IEEE International Conference on Bioinformatics and Biomedicine (BIBM). D. Li, C. Tao, H. Liu and C. Chute, “Ontology-Based Temporal Relation Modeling with MapReduce Latent Dirichlet Allocations for Big EHR Data”, Second International Conference on Cloud and Green Computing (CGC) , 2012. X. Lu, H. Tang, W. Cheng and T. Zhang , “Heterogeneous Data Source Middleware for Android E-Health Application”, Eighth International Conference on Mobile Ad-hoc and Sensor Networks (MSN), 2012. M. Diaz, G. Juan, O. Lucas and A. Ryuga, “Big Data on the Internet of Things: An Example for the E-health, “Sixth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS), 2012. W. Liu and E.K. Park, “e-Healthcare Security Solution Framework”, IEEE International Conference on Computer Communication Networks, MobiPST-2012, Munich, Germany, August 2012. W. Liu and E.K. Park, “e-Health Service Characteristics and QoS Guarantee”, IEEE International Conference on Computer Communication Networks, Workshop on Context-aware QoS Provisioning and Management for Emerging Networks, Applications and Services, Maui, HI, August 2011. J. Yang, D. Tang and X. Zheng, “Research on the distributed electronic medical records storage model”, International Symposium on IT in Medicine and Education (ITME) , 2011. W. Liu and E.K. Park, “Emerging Platform for Healthcare IT Services”, IEEE International Conference on Computer Communication Networks 2010, WiMAN Workshop, Zurich, Switzerland, August 2010. W. Liu, “Digital Health Care (DHC) Information Technology Infrastructure Framework”, IEEE Consumer Communications Network Conference, Las Vegas, January 2010. Health Level Seven International, http://www.hl7.org/implement/ standards.

hinsystem.htm.

[16] NCPDP, National Council for Prescription Drug Program, http://www.ncpdp.org.

[17] Digital Imaging and Communications in Medicine (DICOM), http://medical.nema.org.

[18] US Congress, “Health Insurance Portability And Accountability Act”, 1996.

[19] ISO/IEEE11073, [20] [21] [22] [23] [24] [25] [26] [27] [28]

7

988

“Medical/Health Device Communication Standards”, 2004 (base standards) ~ 2012 (additional parts and revisions). U.S. Department of Health & Human Services, “National Health Information Network”, http://healthIT.hhs.gov. US Department of HHS, “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology”, January 2010. US Committees on Energy and Commerce,Ways and Means, and Science and Technology, “Title IV - Health Information Technology for Economic and Clinical Health Act”, January 16, 2009. http://storm-project.net/ http://hadoop.apache.org/ Technology Association of Georgia, “Big Data in Healthcare”, http://tagtvonline.com/tag-events/2013-big-data-in-healthcare, Atlanta, GA, June 2013. J. Dean and S. Ghemawat, “MapReduce: Simplified Data Processing on Large Clusters”, available in http://www.usenix.org/, published 2004. ANSI Standard, “MUMPS Database and Language”, implementation information available in http://mumps.sourceforge.net/ ANSI (American National Standard Institute), “OAM&P Information Model and Services for Interfaces between Operations Systems Across Jurisdictional Boundaries to Support Configuration Management Customer Account Record Exchange", W. Liu, et al., technical editors, revisions of 1998, published in 1999.