By Rex Brooks and Russell Ruggiero
The Open Public Electronic and Necessary (OPEN) Government Data Act (OGDA) was officially signed into law on January 14, 2019. The OPEN Government Data Act builds on President Obama’s May 2013 Open Data Policy (M13-13) and is included as Title II in Speaker Paul Ryan’s Foundations for Evidence-Based Policymaking (FEBP) Act (H.R. 4174)[i] (aka the “Evidence Act.”).
The primary focus of this new initiative is for Federal Agencies to publish all of their information as open data (using standardized, non-proprietary formats). The main objective of this short piece is to provide an overview of Emergency Data Exchange Language (EDXL) and explain its various benefits relating to the Open Government Data Act. If properly implemented the combination of OGDA and EDXL could promote greater transparency, improved efficiency of day-to-day operations, along with a more cohesive response to manmade (e.g., terrorist attacks, oil spills, etc.) and natural (e.g., hurricanes, fires, earthquakes, etc.) catastrophic events. The sheer number and magnitude of recent catastrophic events substantiates using standardized non-proprietary formats as a priority in the implementation of the Open Government Data Act. One may ask then, how will relevant open-standards such as EDXL be incorporated into the mix?
As noted in the conclusion of the section of this report that focuses on the devil in the details, in the case of EDXL, at least, existing SAFECOM Grant Guidance for Emergency Communications specifies EDXL as a recommended open and non-proprietary standard.
EDXL has been continuously developed since 2002 in the Organization for the Advancement of Structured Information Standards (OASIS). It is a suite of free, internationally available, open and non-proprietary standards and specifications. These standards and specifications are designed to enable information exchange throughout all phases of the emergency lifecycle: preparedness, response, recovery and mitigation. EDXL makes it possible to share accurate, relevant and useful information among emergency response and management service providers.
OASIS is an international not-for-profit consortium that drives the development, conversion and adoption of open standards. OASIS work is organized into technical committees. The Emergency Management Technical Committee is (EMTC) is dedicated to the development and ongoing maintenance of the entire EDXL suite of standards and specifications.
OGDA Challenges: Implementation Guidance
How will each agency implement OGDA? The Act itself requires an agency by agency implementation through mandated non-political Chief Data Officers (CDOs), though there are implementation resources available from previous open data efforts in Project Open Data.[ii] The Evidence Act requires the Office of Management and Budget (OMB), the Office of Government Information Services (OGIS) and the General Services Administration (GSA) to develop and maintain an online repository of tools, best practices and schema standards to facilitate the adoption of open data practices across the Federal ecosystem. When the new OGDA repository is launched, it will then replace and retire the Open Data Project.
OGDA Challenges: How Will the Data be made Available?
The Devil in the Details
The OPEN Government Data Act sets an official presumption that “Government data assets made available by an agency shall be published as machine-readable data…in an open format, and…under open licenses.”
The OPEN Government Data Act also requires agencies to maintain, and publish, a comprehensive data inventory of all data assets. The data inventory will help agencies and open data advocates identify key government information resources and transform them from documents and siloed databases into open data.
There are a number of existing programs that make their work products available as data, such as the National Weather Service (NWS) of the National Oceanic and Atmospheric Agency (NOAA). Among the work products offered are Common Alerting Protocol (CAP) Alerts for familiar meteorological events, such as hurricanes, tornadoes and flooding as well as relatively raw data from the Geostationary Operational Environmental Satellites – R Series (GOES-R) Program. In addition NOAA has been working steadily since 2014 with major infrastructure-as-a-service (IAAS) providers like Amazon Web Services, IBM and Microsoft to increase the no-cost availability of NOAA’s data resources through its Big Data Project[iii] This includes the Filtered Alert Hub[iv], which aggregates CAP alert messages
Ted Kaouk, CDO at the Department of Agriculture, explains, “The original impetus was really about open data, and the value to the public, sharing across agencies. I think that’s proven to be very important … but I think the shift now is, from our Secretary’s perspective, creating a data-driven organization.”
In the Air Force, CDO Eileen Vidrine has begun implementing the VAULT model, standing for visible, accessible, understanding, linking and trustworthy data.
Kaouk and Vidrine both affirmed to government IT blog MERItalk that the critical part of this project will be engaging undersecretaries and leading a cultural change toward a “data driven mindset.”[v]
It is still very early in the process of putting open government data into practical applications., However, it is crucial to the healthy development of agency policy to implement this strategically significant legislation, and that we, the public, stay connected and focused on this effort moving forward. It is also incumbent upon us to see that we take measures to ensure that our personal, individual data, including our private medical historical records data, legal records data and individual online behavioral records data and all other incidental personal data come under our conscious, legal control.
To see this concern in current practice, one need look no further than the recent enactment of the European data privacy law, the General Data Protection Regulation (EU) 2016/679 (“GDPR”), a regulation in European Union (EU) law on dataprotection and privacy for all individuals within the EU and the European Economic Area (EEA), which also addresses the export of personal data outside the EU and EEA areas.
It is important in this discussion that we also recognize and look closer at NIEM, which is an information (data) sharing effort specific to the United States.
NIEM—the National Information Exchange Model—is a community-driven, government-wide, standards-based approach to exchanging information. NIEM may sound complex, but the premise of it is simple: NIEM connects communities of people who share a common need to exchange information in order to advance their mission.[vi]
NIEM is an XML-based information exchange framework from the United States. NIEM represents a collaborative partnership of agencies and organizations across all levels of government (federal, state, tribal, and local) and with private industry. The primary objective of this partnership is to effectively and efficiently share critical information at key decision points throughout the whole of the justice, public safety, emergency and disaster,management, intelligence, and homeland security enterprise. NIEM is designed to develop, disseminate, and support enterprise-wide information exchange standards and processes that will enable jurisdictions to automate information sharing.[vii]
The convergence of GDPR, the OPEN Government Data Act and NIEM suits EDXL in many ways. As with the HIPAA legislation that preceded these developments, the need to protect the individual privacy of personal information (data) cannot be postponed any further. There are several ways that adopting the EDXL suite of standards and specifications can enable and support this effort. However, for the purpose of exploring how EDXL specifically supports the OPEN Government Data Act, one can assume that OGDA, EDXL, GDPR, HIPAA and NIEM will come into play in the effort to protect individual data privacy, especially within the context of freely available government data.
Specifically, EDXL provides a set of standards and specifications for exchanging emergency information. The extent to which this set of data models is already acknowledged in the Emergency Management domain is evident in the fact that EDXL is specified in The Department of Homeland Security Office of Emergency Communications Fiscal Year 2018 SAFECOM Guidance on Emergency Communications Grants.[viii] So, to a large extent, EDXL is pre-qualified for use with the OPEN Government Data Act.
The EDXL suite of standards is designed to work together so that individual specifications, in the form of controlled vocabularies or terminologies defining domain-specific data models complement each other with each focusing on a specific area of need. Through a practitioner-driven process, the current EDXL standards include
- The Common Alerting Protocol v1.2 specification (EDXL-CAP), with various dedicated profiles
- The Distribution Element specification v2.0 (EDXL-DE)
- The Hospital AVailability Exchange specification v1.0 (EDXL-HAVE)
- The Tracking of Emergency Patients specification v1.1 (EDXL-TEP)
- The Resource Messaging specification v1.0 (EDXL-RM)
- The Situation Reporting specification v1.0 (EDXL-SitRep)
- The Tracking of Emergency Clients v1.0 (EDXL-TEC)
All of the documentation for these standards can be found at http://docs.oasis-open.org/emergency/
EDXL-CAP: The Beginning
The events of 9/11/2001 were not the sole reason the work of the OASIS Emergency Management Technical Committee ( EM TC) was started, but it did serve as a catalyst in bringing attention to the topic of improving Emergency Response.
What the events of 9/11 showed was the vital need to improve communication between responders to share information that fulfills the need for interoperability.
Interoperability is the term used to indicate that information held in common between agencies or entities can be operated on or used within each system’s particular software. This interoperability of information, or data, needs to extend across diverse emergency management systems and across organizational and jurisdictional boundaries.
The work that evolved into EDXL began when the Partnership for Public Warning (PPW) brought their work on a Common Alerting Protocol (CAP) into OASIS. CAP allows consistent alert and warning messages to be sent out simultaneously over many different systems. This greatly increases warning effectiveness while also simplifying the task of notification. CAP addresses the challenges posed by the diversity of communication channels and independently developed warning systems. It serves as a universal adapter for alert messages, defining one message format with features that are essential for the broad range of alert systems and sensor technologies. Although the term “EDXL” is not included specifically in the title, CAP is a member of the EDXL suite of standards. In OASIS, CAP was cast into an XML Schema-based IT international Standard in version 1.0 in March 2004, and versioned to 1.1 a little more than a year and a half later in October 2005 and adopted as International Telecom Union (ITU) Recommendation X.1303, later versioned to ITU Recommendation X.1303 bis.
CAP remained at this stage of development until version 1.2 was approved by OASIS a little less than 5 years later in July 2010. The international recognition of CAP is evident in Canada and Australia having produced their own national profiles of CAP, which is also profiled in the Integrated Public Alert and Warning System (IPAWS) in the Department of Homeland Security – Federal Emergency Management Agency (FEMA) of the United States.
EDXL-DE: The Distribution Element and the EDXL Process
Following the work on CAP, the next standard undertaken in the EDXL suite was the Distribution Element or EDXL-DE. Version 1.0 was approved as an OASIS Standard in June 2006. Version 2.0 was released as a Committee Specification in September 2013. Both versions are supported, though Version 1.0 has wider adoption. Further work on EDXL-DE Version 2.0 is in progress
EDXL-DE facilitates the packaging of content and provides a standard set of elements in a header to describe that content in order to facilitate message delivery. This standard assumes and relies upon a message distribution framework for data sharing among emergency information systems. The DE may be thought of as a container for structured or unstructured data, like an envelope used for postal messages. It carries formatted messages such as alerts or resource messages and helps facilitate delivery using routing information. The DE is designed to package and deliver messages based on the other standards and specifications in the EDXL suite or other data payload messages. The EDXL-DE data model provides a standard format for identifying senders and targeted recipients of the message, along with other metadata pertaining to whom and under what circumstances the enveloped data is to be sent and received..
Unlike CAP, which was brought into the OASIS Technical Committee Process, EDXL-DE was the first standard taken on through the developing EDXL Process, a practitioner-driven process sponsored by DHS Science & Technology. The process produces requirements identified by practitioners to solve a particular problem with data exchanges. Stakeholder working groups identify real-world scenarios to analyze and draft these requirements. These are then vetted through the vendor community including the Emergency Interoperability Consortium or EIC. After review, a draft specification based on the requirements is submitted to the Emergency Management Technical Committee where work is undertaken to develop and publish a standard taking into account international needs.
The OASIS process is open and comments are accepted from any source during public review, subject to the OASIS Feedback License[ix] regardless of membership in the organization. Once complete, these standards are internationally recognized and available at no cost for implementation. However, the process does not end here. Through ongoing outreach and feedback from implementers, standards can be revised through a formal technical committee process to better support the stakeholder community. Please Note: The relevant technical material contained in this document has been reviewed by members of the OASIS Emergency Management Technical Committee.
EDXL-RM and EDXL-HAVE: EDXL Process Matures
Next in our in our series of emergency communications standards came EDXL Resource Messaging (EDXL-RM), one of the more challenging specifications tackled by the EM TC. And, as it happened, this work was completed at the same time as EDXL –HAVE, the Hospital Availability Exchange specification. Versions 1.0 of both these specifications were approved in Nov. 2008.
EDXL-RM organizes emergency logistics information in a standard XML vocabulary and contains sixteen separate pre-defined messages covering the spectrum of logistics-related resource messaging- in the request-response-report pattern. It also allows user-defined resource messages using a standard set of terms and datatypes.
EDXL-HAVE allows the communication of the status of a hospital, its services, and its resources.This includes bed capacity per department and availability of staff and resources to support that capacity, emergency department status, available services and the status of a hospital’s facility and operations. HAVE allows emergency dispatchers and managers to make logistics decisions on where to route victims to ensure the receiving hospital is prepared to admit them. EDXL-HAVE was used by several companies and organizations in the response to the 2010 Haiti earthquake where much was learned.
On January 19, 2019, EDXL-HAVE Version 2.0 was published as a Committee Specification taking into account lessons learned. It has become the first Joint Release of OASIS Open and Health Level Seven International (HL7).
The convergence and overlap of the work on these two separate specifications prompted the EM TC and its industry partners to refine the EDXL Process, evolving into the mature process represented in the Figure 1.
Figure 1: The EDXL Process
EDXL-TEP and the Bi-Directional Transform to HL7 ADT
Although EDXL Tracking Emergency Patients (EDXL-TEP) was developed later in the chronology of the EDXL suite, it is important to include it here, following EDXL-HAVE in order to keep the EDXL Emergency Healthcare standards and specifications together because they are closely associated. It is in this context that we can highlight how the OASIS EMTC began working closely with its sister Standards Development Organization (SDO), HL7,leading up to two collaborative efforts between the two SDOs.
Where EDXL-HAVE provides a snapshot report of the capabilities of hospital facilities in a given area, EDXL-TEP provides a standard vocabulary for collecting emergency patient information (data) in the field and transmitting it to emergency managers for tracking and to receiving hospitals. This standard is designed for exchanging emergency patient or tracking information during the patient encounter from admission to release. EDXL-TEP supports emergency patient tracking across the emergency medical service, EMS, and emergency care continuum, as well as hospital evacuations and day-to-day patient transfers. EDXL-TEP provides real-time information to emergency responders, emergency management, coordinating organizations, and care facilities in the chain of care and transport.
TEP 1.0 was released in January 2014 and led directly to TEP 1.1 which was released as a Committee Specification in 2016. TEP 1.1 includes Bi-directional Transformation of OASIS EDXL-TEP (Tracking of Emergency Patients) v1.1 and HL7 v2.7.1 ADT (Admit – Discharge – Transfer) Specification Version 1.0 – Committee Note 01 – 31 May 2016. It was also published as an HL7 Implementation Guide.
As noted in the previous section EDXL-HAVE – Version 2.0 was jointly released in January 2019 by OASIS Open and HL7 International.
EDXL-TEC: Tracking Emergency Clients
EDXL-TEC is a sister specification to EDXL-TEP that incorporates Google’s People Finder Interchange Format (PFIF) into EDXL-TEC Registry. Tracking of Emergency Clients (TEC) Client Registry Exchange 1.0 was released as a Committee Specification in 2014.
EDXL-SitRep: EM Decision Support
From Field Report to Management Summary –
Returning to chronological order, after the first versions of EDXL-RM and EDXL-HAVE were approved by OASIS in 2008, they were then followed by version 1.2 of CAP in 2010, when the EM TC subsequently launched EDXL-Situation Reporting (EDXL-SitRep). The first Committee Specification for version 1.0 was approved by the EM TC in Nov. 2012. The latest release of SitRep 1.0 as a Committee Specification came out in 2016. See http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/cs02/edxl-sitrep-v1.0-cs02.zip
The ability to gather accurate information in time-critical circumstances is the chief requirement met by EDXL SitRep. This specification supports reporting on incidents in a consistent format so that data can be collected and provided to other systems or decision makers. The end goal is to enable the exchange of clear well-defined information to facilitate decision-making. The standard includes a set of pre-configured reports. It incorporates the standard Incident Command System () forms.
While SitRep was under development, the EM TC undertook the development of language components common to many of our standards, specifications and profiles. This, in turn, led to the development of three supporting specifications for terms used consistently throughout the EDXL suite of standards and specifications.
EDXL-RIM: The EDXL Reference Information Model
The EDXL Reference Information Model provides a high level, abstract information model that supports the entire family of EDXL standards. It includes common components as well as governance for usage and change.
- EDXL Common Types collects elements common to all EDXL specifications
- EDXL CIQ (Contact Information) collects person/contact, organizational and geopolitical address information
- EDXL GSF (Profile GML Simple Features) profiles a brief collection of geospatial reference information for specifying location information
- UML Model of the EDXL Suite of Standards shows the overall inter-related structure of the EDXL suite.
Irma and Maria in 2017 and the California Fires of 2017 (then worst ever) and
2018 (new worst ever) are excellent case studies on how we respond to natural
events. They also helped to expose serious deficiencies. Questions on how do we
reduce redundancies and improve communication should be explored, along with
various technology efforts to improve information understanding such as recurrent
neural networks. Some improvements are
currently available (open-standards) and some like AI are years away. No
matter, leveraging what is currently available, while building towards the
future seems to be both logical and prudent from an effort and cost
perspective. We live in an ever changing world and must adapt to both natural
and manmade events, so our responses need to be more effective and efficient. Therefore
we should view EDXL as an impactful open-standard that could help to reduce
loss of life, while minimizing injury and property damage.