1. Introduction to Disaster Management Interoperability Services (DMIS)
Welcome to “DMIS Basic School.” At the end of this course, you will understand the foundation elements of DMIS and be prepared to move into more advanced courses to become a DMIS Trainer, Installation Planner, Administrator, or Operator.
This course is a prerequisite for all other DMIS courses.
If you are seriously engaged with DMIS training, please read the “DMIS Training Curriculum Overview” if you have not yet done so. It is important to have an overview of the courses available and how they may be organized into tracks for DMIS planners, trainers, administrators, and operators.
We recommend you print out this course material as “Notes Pages.” That way, you can read along while you view the slides in Slide Show mode. Slide Show mode will allow you to see the animation on some of the slides. The animation is designed to aid understanding of the more complex points. You could also 3-hole punch the Notes Pages, place them in a binder, and keep it as a handy DMIS desk reference.
When you see in bold font on a Notes Page, just left click your mouse to trigger the next animated action or change slides.
“DMIS Basic School”
DMIS Web Services Release 2.3

2. DMIS Basic School Course Outline
Brief History
Description
Principles
Architecture
Development Approach
Current Capabilities
The DMIS Collaborative Operations Group (COG)
COG Functions
How Do I Establish a DMIS COG?
How Do I Download DMIS Tools?
“DMIS Basic School” will follow this course outline. It is helpful to know the origins of DMIS, its basic development principles, and how it is built. It is essential to know what DMIS is, how it serves responder needs, how its fundamental building blocks – COGs – work, what it does, and how you can get it.

3. Brief History Timeline
March 2000 – March 2001: CMIS Project Begins
Requirements analysis and technical prototyping
Requirements elicitation and architectural trade studies
April 2001 – September 2001
Requirements analysis and design/development
Fast Track – development, test, Beta test, fielded Sep 30, 2002
August 2002 – June 2003
CMIS transitioned from USMC to FEMA; CMIS to DMIS name change with DM e-Gov
Web Services Release
July 2003 – February 2004
Broader installations / training
Service Pack 1 Release
With Congressional “set aside” funding, a small CMIS team began work under program management by the U.S. Marine Corps Systems Command. The team was tasked to “build a national interoperability backbone for responder information sharing” and “basic automated tools” for communities without the means to acquire responder software tools.
Initially, the team traveled throughout the country observing and interviewing responders to understand their functional requirements. Careful analysis of the requirements led to an architectural concept and identification of various candidate software tools.
Responder needs shaped the CMIS / DMIS architecture. Many responders insisted that “the screen can’t go blank when we lose communications.” Given that emergency incidents often cause intermittent loss of communications, the CMIS team realized that the software tools could not be web browser-based. While tools were of interest, the original main focus was on the interoperability backbone.
The events of 9/11/01 marked a turning point in CMIS priorities. On that afternoon, the CMIS Program Manager asked the team to “get a basic set of tools out to responders as soon possible.” The FAST TRACK tool suite was distributed to responders in September of 2002.
In August of that year, as beta testing indicated that FAST TRACK would be successful, the Marine Corps and FEMA agreed that a technology transfer from DoD to a civilian agency would be appropriate. As CMIS was brought into the Disaster Management electronic government initiative, “Consequence” was replaced with “Disaster” in its name.
Four software tools releases have been made since the transition from DoD. DMIS has published a series of interoperability interface specifications. DMIS is now compliant with the Common Alerting Protocol 1.1 international standard and commercial software vendors have engaged in developing interfaces to the DMIS interoperability infrastructure now name Open Platform for Emergency Networks (OPEN).
March 2004 – July 2005
Broader installations / training
CAP 1.0-compliant Release 2.2
August 2005 – March 2006
Transition to DHS Science & Technology
CAP 1.1-compliant Release 2.3

4. Brief History Disaster Management e-Gov Program
Began in February 2002; cooperative effort among federal agencies
DHS/S&T IT is managing partner
In top 3 of 22 E-Government initiatives defined by President’s Management Agenda
Disaster Management
SAFECOM
E-Authentication
Other E-Gov Initiatives
(Priority Established by PMC)
The Disaster Management Electronic Government (DM e-Gov) Program began at roughly the same time Department of Defense began looking for a civilian technology transfer recipient. The overall e-Gov program is governed by the President’s Management Council and managed by the Office of Management and Budget (OMB). FEMA was originally the lead among the Disaster Management e-Gov Federal partners and thus became the technology transfer recipient. Disaster Management was placed in the top three priorities among all the e-Gov initiatives.
Given the success and viability of DMIS, OMB mandated its use, in conjunction with the Common Alerting Protocol, by Federal agencies in the spring of 2005.
The DMIS program transferred from DHS/FEMA to DHS Science & Technology, Office for Interoperability and Compatibility in July It remains under the aegis of DM e-Gov as of this writing (March 2006).

5. Brief History Responders’ Needs
“The systems we have can’t talk to each other”
“Most of us don’t have budgets for software”
Per executive-level course at NFA
Common operating picture at ICP and EOC
Incident documentation
Media relations
DMIS is of, by, and for responders. In the late 1990s responder data needs “bubbled up” through such forums as the InterAgency Board for Equipment Standardization and the “Gilmore Commission.” Those needs led to the creation of the DMIS effort in the Spring of The DMIS development team spent much of the first year talking with responders to understand their needs.
By far, the most common data processing complaints heard from responders were “un-interoperability” among existing systems and the inability to afford automated systems.
The National Emergency Training Center in Emmetsburg, Maryland, consists of the Emergency Management Institute (EMI) and National Fire Academy (NFA). This “responder rich” environment gave DMIS developers access to responders and their needs. The executive level NFA course starts out with a self assessment of students’ readiness and issues in their home organization. Invariably, the top three problem areas for each class come out to be those listed in the slide above. You will see that DMIS offers a great deal to ease those problems.

6. Brief History Responders’ Information Problems
City “A”
City “B”
Emergency
Operations Center
Organization to organization interoperability tends to be inefficient
Emergency
Manager
Emergency
Manager
Emergency
Operations Center
Civil Support Team “A”
“Pass the rumor telephone chaos.”
FAX hassles
Responders report enclaves or “islands” of good information sharing within certain organizations but generally very little capability to share digital information among mutual aid partnerships or between civilian and military support organizations.
In many organizations, individuals must be brought into the same room in order to effectively collaborate. Also, complex responses are often managed only by voice communications, causing distortion of information passed from point to point and poor incident documentation. Some organizations try to pass information by facsimile machine, but find that method too slow and troublesome. Many metropolitan areas still use “un-sharable” acetate boards in operations centers to track status of the incident and resources.
In short, responders often feel left behind by the digital information revolution.
“Grease pencil and acetate”
“Same room syndrome”

7. Brief History Responder’s Vision
Leverage technology to gain efficiency
Develop a national emergency information interoperability service enabling horizontal and vertical data sharing
Nation
Region
While it may seem like a cliché, the vision of DMIS actually did begin on a bar napkin. In 1999, a small group of responders drew up the idea of a secure, nationally-scaled interoperability infrastructure enabling horizontal and vertical information sharing. That idea led to a Congressionally-funded effort to begin to build what was then called Consequence Management Interoperability Services (CMIS).
State
EOC
EOC
Local
ICP

8. Description
Open Platform for Emergency Networks (OPEN) – an interoperability backbone that lets systems “talk to each other”
Nationally scalable and secure
Gives responders freedom to choose software that best suits their needs
Provides access to common services supporting basic automated tools
DMIS Tools - basic automated tools
CAP Alert Messages
Tactical information exchange
Mapping
Private Messaging
From the beginning, DMIS has been two things – an interoperability platform and a set of basic tools.
By far, the interoperability backbone, now called OPEN, is the more important aspect of DMIS. It is the interoperability infrastructure that is enabling responders to acquire software that best suits their needs without having to worry about their neighbors buying the same software. OPEN enables information sharing among all systems that develop an automated program interface to it.
The basic tools only provide responders with the capability to exchange CAP-standard alerts, to describe an incident, and request specific needs. There are many functions that DMIS tools do not support. For example, response resource inventory and status are not accommodated by DMIS tools. There are already many commercial software packages that do those functions and DMIS would, in effect, be in competition with them if such capabilities were offered in DMIS. Since the Government is prohibited by law from competing with industry, DMIS intentionally keeps its tools very basic for “have not” response organizations without becoming a competitive threat to industry.

9. Architecture “What do you mean “interoperability services?”
As special stereo components can interoperate through a shared component providing common services . . .
Incident
Management
System A
System B
Mapping System
Weather System
. . . automated systems can interoperate through a shared component providing common services.
Let’s consider a simple analogy to assist with understanding OPEN. Back in the 1950s and early 1960s, there were record players and reel-to-reel tape recorders. Record players provided “services” such as amplification, volume control, tone control, and speaker output. Tape recorders provided the same services meaning that audiophiles paid for the same services twice. “Interoperability” consisted of placing the tape recorder’s microphones in front of the record player’s speakers to “move the record data” onto magnetic tape! Audiophile customers were not happy. In response, the industry developed an INTERFACE STANDARD that allowed:
1) the common services to be placed on one box – the amplifier / receiver – in the middle of a system of components, and
2) the different components to truly move their data from one component to another.
Each component could use the common services provided by the amplifier / receiver, and the customer only paid once for those services. The point is, that the INTERFACE STANDARD enabled affordable interoperability and freedom to choose components that best suited their needs. By the way, you have probably touched the physical manifestation of that interface standard – the simple RCA phono jack (on the back of the amplifier) and plug (on the ends of the component wires).
Modern software technologies are now available that allow software engineers to do a similar thing with differing systems. As a rough analogy, you can think of the DMIS interoperability backbone as that “thing in the middle” that enables shared use of common services (to manage data transactions) and the sharing of data among systems.
DMIS OPEN is “the thing
in the middle” enabling data
sharing

10. Key DMIS Principles All disasters are local
Maps are a central exhibit to most emergency response exchanges
“Use the data where it lies”
Creator of information controls where it goes and what can be done with it; no “big brother”
Nationally-scalable, private, interoperability infrastructure is the main thing
Interface available to all
Evolving interoperability maturity
There are some key principles that characterize DMIS. DMIS is built “from the bottom up” in recognition of the fact that all disasters – no matter how consequential or large-scaled – are first encountered by local responders. DMIS is designed to capture the local situation and share it with those with the need to know. And the map is the central means of depicting that situation.
DMIS seeks to “use the data where it lies.” For example, it is easy to use a national data source for aerial photograph layers over maps (orthoimages). But those orthoimages are generally older than those available at state and local level. DMIS has adopted an open interface standard that will make it relatively easy for responders to use more “local” data to locate items on a map.
In early requirements interviews, responders insisted that they be in control of information they create with no opportunity for higher government levels to “look down” into lower levels. The DMIS Post function ensures that requirement is satisfied.
It’s easy to get caught up in the DMIS Tools that you can see, “touch,” and use. But it’s OPEN - the interoperability backbone - that will allow you to share critical information with organizations who can help you, even if they’re using a different system. And any crisis information management system is free to develop an interface to DMIS and share information with others. At this time, the level of interoperability is very basic, but evolving.

11. Evolving Maturity Interoperability Standards Development
OASIS Emergency Management Technical Committee
Industry and government membership
Building XML data standards under the formal standards development “umbrella”
Resolving data semantic mismatches is key to higher interoperability maturity
Common Alerting Protocol (CAP)
Emergency Data Exchange Language (EDXL)
Interoperability demonstrations and trials
The Emergency Management Technical Committee (EM TC) within the OASIS standards development organization is a key to achieving higher levels of interoperability. The EM TC consists of government and commercial members working together to formally develop standards facilitating interoperability. DMIS implements the standards quickly and includes them in the published DMIS backbone interface specification. This provides software companies with a “hard engineering target” for developing their side of the DMIS backbone interface.
A key to reaching higher levels of interoperability maturity will be resolution of subtle differences in data definitions among various systems. In order for one system to correctly PROCESS data from another system, data elements must be exactly the same. Standards for resolving data mismatches are emerging and hold promise for advanced interoperability maturity.
The first standard adopted by the Emergency Management Technical Committee was the Common Alerting Protocol (CAP). CAP establishes a common framework in which alert messages may be created and distributed. The current DMIS 2.3 release is fully CAP 1.1 compliant in both the DMIS Tools and DMIS Interoperability Backbone. There are now roughly 25 commercial products that are both CAP-compliant and DMIS-enabled, therefore able to share CAP-standard alerting information.
EDXL refers to an emerging series of standards that will facilitate emergency information distribution, resource management, hospital bed availability tracking, and other response functions. The DMIS program will implement these EDXL standards as they emerge in both DMIS Tools and as common services in OPEN. As with CAP, OPEN will publish associated EDXL interface specifications for other systems to employ.
Members of the EM TC, vendors, and DMIS regularly conduct interoperability demonstrations. One such demonstration was held in the Rayburn Building in March 2004 for members of Congress and their staff. Several CAP-compliant/DMIS-ready initiatives supported DMIS in successful formal trials in the DoD Coalition Warrior Interoperability Demonstrations in June 2005.

12. Development Approach “Of, by, and for responders . . .”
Test
Develop
Design
Elicit
Needs
Preliminary
Design Review
Categorize
Needs
Engaged
Responders
Use Case
Analysis
Id Function
Groups
Analysis
Review
It is no accident that responders’ initial response to DMIS is generally, “This is on track for what I need.” Responders are involved at multiple points in the process to develop a unit of software functionality. DMIS uses an international standard software development process and keeps responders engaged to make sure the products provide value.
Establish
Function Group
Priorities
Use Case
Discovery
Develop Concept
Descriptions
Requirements
Review

13. Where is DMIS used? DMIS serves in the RIZ and the FIZ / RIZ overlap.
ICP must share OPERATING PICTURE throughout the Rear Information Zone (RIZ), to aid strategic decision support and resource management.
Internet
Federal
In the Forward Information Zone (FIZ), different data capture devices need to use wireless communications to send data to the ICP for visualization by humans.
Supporting
EOCs
Local ICP
Local EOC
Where is DMIS used? Currently, the DMIS Backbone and DMIS Tools are used most commonly in Emergency Operations Centers at local, mutual aid partner, state, regional, and national levels. There are a few jurisdictions experimenting with the use of DMIS at the Incident Command Post. Those jurisdictions have the resources to 56 KBPS (or faster) wireless data connections “to the street.”
From the national viewpoint, DMIS is used in over 1600 operating groups in all 50 states and Canada. At the current rate of DMIS registrations, we expect over 2000 operating groups by fall 2006.
DMIS serves in the RIZ and the FIZ / RIZ overlap.
At the ICP, data must be received, transformed into information for human consumption and tactical decision support, and presented visually via (ideally) one interoperability platform.

14. Current Capabilities - Tools
Tactical Information Exchange
Mapping
Specific Needs Request
DMIS Messenger
CAP Alerts
National Summary Map
Weather Forecasts & Observations
COG Location Map
These are the current basic DMIS tools. They provide the ability to describe an incident and make specific needs requests in enough detail for shared situation awareness with other organizations that may be called upon to help. Within the Tactical Information Exchange (TIE) portion of DMIS, there are information forms that are named and look like the acetate-covered information boards in traditional Emergency Operations Centers. Locatable incident information (such as the incident site, hospitals, shelters, etc.) entered into the TIE forms may be automatically plotted on the incident map. The map is central to providing and sharing the “common operating picture” of the incident or situation.
Specific Needs Request (SNR) enables listing of needs by local responders. Other organizations can respond to the requests by articulating what assets they could provide.
The DMIS Messenger is a private online “chat” capability responders can use to communicate with other DMIS members real time. All DMIS Operators who have DMIS Messenger running are available to be invited to join a chat session.
DMIS Alerts provide the ability to quickly broadcast critical information to DMIS Operators in CAP standard format. Alerts are available as a stand-alone tool in DMIS or from within the TIE subsystem.
The National Summary Map is used to display incidents with the notification level of “National.” This is a valuable tool for those at higher levels of Government to see an overview of incidents in progress around the country.
The Weather Forecast tool may be accessed within the TIE subsystem or via the Disaster Management Tools menu. DMIS currently enables users to enter a ZIP code and obtain AccuWeather forecast data, in one-hour increments, for the next 48 hours. The user may choose to convert the data for the current hour into a weather observation for a working incident record in TIE. Weather observations may also be entered in the TIE Weather Observations form directly.
COG View Map, nicknamed “Who’s My Neighbor?” by the DMIS Team, allows you to see the all DMIS Collaborative Operating Groups (COGs). This will make it handy for you to find out what COGs are in your area and available for collaboration during incident response.

15. Current Capabilities - OPEN
Access control
Transaction management
Alert
Auto-generate DMIS incident record
Attach
Post
Remember our analogy about common services in a component stereo system? This slide is about the common services currently provided to external systems by DMIS OPEN - the Interoperability Backbone. DMIS allows external systems to use DMIS OPEN access control services to make sure that only legitimate responders are using the system of systems. There are several common services exposed through the interface that are necessary to manage information transactions among the participating external systems. The DMIS CAP 1.1 Alert function is also freely available, as an option, to external systems who build an interface to the DMIS OPEN. When external systems package an incident report and use the DMIS Post function within the interface, a DMIS incident record is automatically generated for dissemination via the DMIS backbone. The Attach function within the interface allows external systems to attach files to Alerts and Incident Records for sharing with others via the Post function.

16. Computer technology and DMI-Services make it possible.
The DMIS Collaborative Operations Group (COG) What is a COG?
A group of people working together, . . .
. . . on the same information, even if they are not in the same room.
Collaborative View
The Collaborative Operations Group (COG) is the fundamental building block of the “DMIS universe.” Understanding COGs is essential to understanding DMIS. At first, just think of a COG as a group of people working together. It’s a “community of interest”.
Then, imagine those people working on the same report, request, or map together, even if they are geographically distributed.
With DMIS, a personal computer, a modem, and a telephone line, your emergency responders can do just that. Inside a COG, members can see the data quickly, as soon as any member enters and saves it. This is called the Collaborative View because it allows COG members to “work together apart” to rapidly coordinate information.
Computer technology and DMI-Services make it possible.

17. What is a COG? A group of DMIS Operators who need to:
Coordinate actions
Communicate quickly
Exchange consequence management information in a collaborative environment – situational awareness
Enhance incident reporting
Local SOPs define your local COG configuration and policies
The local DMIS Administrator implements and maintains the COG(s)
A DMIS Collaborative Operations Group (COG) is a virtual consequence management organization consisting of a set of DMIS Operators who need to coordinate actions, communicate, and exchange information in a collaborative environment. Because so many organizations are responsible for preparing, responding, and recovering from hazards and emergency incidents (ranging from relatively routine incidents to major terrorist incidents), a COG can consist of any number of operators from multiple organizations who need to work together to respond to an incident.
Examples of organizations that may constitute a COG include an entire state or county Emergency Management (EM) Office, divisions of an EM Organization, local fire departments, federal agencies, military units, a public or private consulting organization that participates in Consequence Management, a single individual, or any combination of these (or similar entities) as necessary to maintain the desired level of collaboration. DMIS functionality, exercised through COGs, supports and supplements existing emergency management organizations, relationships, policies, and procedures.
We recommend you look closely at your SOPs to decide how DMIS can best work for you, and establish your COG based on the results. The COG Cookbook course helps you with that planning process. An organization’s size, complexity, and processes will influence the kind of COG structure that is best for your environment.
Key duties of your DMI-Services Administrator will be to define COG structure and assign Operators to COGs.

18. Like your current people in their organizations, except . . .
How do COGs Work?
Like your current people in their organizations, except . . .
deal with paper and FAX hassles,
They don’t have to wait for everybody to get to the same room,
You will get to define how your COG is structured and how it works. The idea is to make it match your current organizational structure and processes. In the DMIS environment, you will find that you can collaborate with your counterparts without necessarily being in the same physical space. You can work at a pace faster than FAX machines, and you don’t have the problems associated with voice communications.
or depend on “telephone chaos.”

19. Collaborate internally
How do COGs Work?
Share
externally
Members of another COG
External COG Information Sharing
Directed to selected COGs
Recipients can view information and comment using on-line chat
Recipients can forward information if originator grants permissions
You
Collaborate internally
Members of your COG
Internal COG Collaboration
Create, update information collaboratively
Members with appropriate privileges:
Have updates as information is saved
Can edit the information
To review, please note these key points on “How COGs work.”
Inside your own COG, operators with the create, update, and view privileges to an application can see each others’ entries in “near real time.” When an operator enters data and “refreshes” the view via the Save function, other operators can see and respond to the entry right away.
To share that information with someone in another COG, however, the Post function must be used. When a set of information is posted, the operator with release authority from the sending COG defines what COGs may see the information, and to some extent, what they can do with it.
When you receive information from another COG, you can look at it and comment on it using a chat function, but you can’t change what the sender posted. Additionally, you can’t forward information received from a COG to yet another COG. DMIS functionality ensures the “owner” of information is in full control of its distribution and re-use.

20. How Do I Establish a DMIS COG?
Register for a COG at
Select “Enter Website, then “Register,” then “Registration Form.” Complete and submit the form.
Use “Remarks” field to state if you want a CD, download, or both
Be patient for 2 weeks while DMIS:
Verifies that you are a member of the responder community
Creates your COG in the DMIS database
Creates your initial COG Administrator id/password
Tests the COG and id/password
Sends you an Installation Kit, sends id/password to download client software, or both per your request
If you think you would like to try DMIS Tools, or you already use CAP-compliant/DMIS-ready tools and want to be included in the DMIS information sharing “universe,” you need to register to create a DMIS COG. If you are a “have not” with no tools, it doesn’t cost anything but time to try out the DMIS Tools. If you are a “have” with CAP-compliant/DMIS-ready tools on hand, you still need a COG in order to share information with other organizations using other tools. For example, Frederick County (Maryland) Emergency Management uses Blue 292 while the Maryland Emergency Management Agency uses WebEOC. They can exchange CAP messages via the DMIS Interoperability Backbone because they each have DMIS COGs (but never use the DMIS Tools!).
If you want to obtain and install the DMIS Tools, please use the Remarks field on the Registration Form to state whether you want:
An installation kit with CD,
To download the DMIS Tools, or
Both
When you apply for a DMIS COG, it takes a bit of processing before you are “good to go.” First, we must verify that you are who you claim to be in your COG Registration. Then we must create the COG and its initial COG Administrator userid/password pair and test them. Then we send you an Installation Kit or download instructions, your choice. And, yes, both can be a choice.
The DMIS registration form on our website is intended to register a collaborative operations group (COG) just one time – not individuals within that group. Each COG should have one individual (and a back-up) act as its administrator. We give the local DMIS group administrator the necessary permissions within DMIS to add individual Operators locally as he/she deems appropriate. Information on how to add new operators is covered in the DMIS Operators Guide. DMIS is government provided software and has no licensing restrictions, so it may be loaded onto as many workstations in as many locations as necessary.

21. How Do I Download DMIS Tools?
When you receive your download userid and password, go to and enter the site
On the Home Page select Click Here to Download
Remember to follow the installation instructions and to Run the Configuration Tool after installation.
IMPORTANT: If you request the DMIS Tools Installation Kit when you register, you will receive a CD in the kit that has the Installation Guide and Operator’s Guide on board the CD. If you download DMIS Web Services Release v2.3, be aware that you ALSO NEED TO DOWNLOAD the Installation Guide, Quick Reference Guide, Operator’s Guide, and Addendum to the Operator’s Guide.  We highly recommend that you print out and follow the Installation Guide, as you must know how to use the DMIS Configuration Tool to set up your DMIS Desktop to log into your specific COG. 
Next, to download the DMIS v2.3 Desktop and V-One SmartPass, click on Install Now or CLICK HERE TO INSTALL NOW (Website). When prompted, enter the following username and password sent to you by the DMIS COG Manager. You may have to enter it several times.  We suggest that you copy and paste the userid and password into the login screen to prevent making any typographical errors, as the logins are case sensitive and contain special characters:
Click on:  Download (56.9M)
Save this file to a temp directory.
After the file has downloaded, please go to that temp directory, launch install.exe and follow the installation instructions.
If you have any questions or encounter any local problems, please contact our Help Desk at or phone:
Problems? or phone:

22. Course Conclusion DMIS is: Of, by, and for responders
An interoperability backbone and basic tools
An evolving work in progress
Being used nation-wide
Organized by Collaborative Operating Groups (COGs)
Congratulations on completing “DMIS Basic School”
We have covered these key points and hope we have made them in an understandable manner. Please proceed to the more advanced DMIS courses appropriate for your role as a DMIS Trainer, Planner, Administrator, or Operator.