Review background information related to your information exchange, assess resource impact, understand business context, and identify information exchange business scenarios.
Develop a high level scope and goal of the intended exchange. Decide what information needs to be a part of it. Interview stakeholders to gain an understanding of the information exchange environment. Stakeholders can include the organizations with whom you are exchanging information, community stakeholders in the same mission space, and practitioners from your organization.
Review existing documentation and ask exchange stakeholders questions such as the following:
Beyond the basic questions, consider complicating factors that may need to be addressed:
Determine if NIEM is right for this particular exchange.
Reasons to use NIEM include:
Reasons why NIEM might not be right for the exchange:
Business requirements are the drivers for an information exchange that are primarily operational or functional requirements.
The verification service shall respond only to search requests issued by the client application, the Verification Information System (VIS).
Developing business requirements
Follow a formal process to define and validate business requirements and accurately document an information exchange:
Not all requirements for an exchange are applicable to an IEPD. Some requirements are related to implementation and fall out of the scope of NIEM and IEPDs.
A large, urban city identified the need to create a series of exchanges that would allow parents, city-wide, to apply online for their children’s school meals program and automate the processing of the request between the Human Services Agency and the school.
This will be implemented via a web-based service that, upon submission, will automatically check the city’s Human Services agency database to ensure the applicant is from a low-income family and qualifies for the school meals program. If qualified, the web-based service will then notify the respective school to add the child to the meal program.
Currently, the only means the city has to process school meal program applications is through paper-based applications at the city Human Services Agency office. Once approved, the Human Services Agency faxes approved applications to the particular school where the child attends. Overall, it is a manual process that inhibits timely delivery of citizen services.
Examples of good business requirements from the business case above include:
Candidate Message Exchange Packages
- Request from Parent to Human Services Agency for meal program
- Eligibility request from Human Services Agency web-based service to eligibility system
- Eligibility reply from Human Services Agency to parent
- Notification to add child to meal program from Human Services Agency to school
- Request from school to Human Services Agency for monthly report
- Monthly report reply from Human Services Agency to school
- The web-based service will notify parents via email whether or not their child qualifies for the school meals program ten minutes after receiving their application.
- A school will receive notification within 24 hours of a new qualified child within their school.
- Each school in the city shall be able to receive a monthly report of every child in their school who is currently enrolled in the school meals program.
Note: Data Quality Requirements should be taken into consideration once above requirements are discussed.
Differences in exchange complexity will have an effect on the resources required to develop the IEPD and will assist in determining which IEPD artifacts should be developed as part of the exchange.
IEPD development efforts tend to be lower in the following situations:
The following situations can lead to a higher level of effort required to develop or update and exchange:
All stakeholders associated with this exchange should be involved in determining the complexity so that all factors are understood and taken into account when planning the exchange.
An effective scenario is informative, strategic, and comprehensive. A model is a graphical representation of information exchange requirements and is essential to depict the scenario that will ultimately drive the building of the information exchange. Use diagrams to create business scenarios as an effective first step to accomplish this.
Recommended diagram types include the following:
A use case diagram graphically represents the functionality of a particular information exchange as perceived by an external observer.
A use case diagram has the following components:
|Actor||Depicts system interactions; a role that a human, device, or system “plays” within the diagram.|
|Use Case||Depicts system functionality such as main or sub functionality, a user goal, or an activity system.|
|Relationship||Depicts the relationships actors have with use cases and each other.|
|System||Contains all functionality and limits scope of the diagram.|
Several of these simple diagrams can form a more complex diagram.
A business process diagram shows the graphical and sequential activities involved in an exchange. It is similar to a workflow diagram.
A business process diagram has the following components:
|Stakeholder||Any person, organization, or system directly or indirectly involved in the information exchange.|
|Activity||Correlates the data being exchanged with any activity that drives it.|
|Gateway-Event Based||Activities that force a decision upon a stakeholder.|
|Flow||Connects business processes and events to show the direction of activities in the diagram.|
|Start Event/Stop Event||Acts as an activity trigger or represents the result or completion of an activity.|
Steps to develop a business process diagram:
A sequence diagram shows how applications or systems operate with one another. It displays the sequential order of operational processes or messages between applications as horizontal arrows between the parallel, vertical lines that are used for applications. This allows the specification of simple runtime scenarios in a graphical manner.
A typical sequence diagram should include the following elements:
|Applications||Any application involved in sending messages within the information exchange.|
|Messages||Any message being sent between applications within the information exchange.|
At the end of this phase, high-level information about the IEPD can begin to be documented and captured. While this is not required and the information can continue to be updated and refined during the rest of the IEPD development process, it can be useful to start recording thoughts and decisions now.
An IEPD Catalog is one of the required artifacts of an IEPD. This will be filled in during the Assemble and Document phase of the IEPD lifecycle (Phase 5), but some basic data that will be needed can begin to be collected now.
|IEPD name||A name or title for the IEPD|
|IEPD version||Identifier for a specific release of an IEPD. “1.0” is typical for new exchanges.|
|NIEM release||Determine which NIEM release should be used. Typical to use the current NIEM release unless an older release is already in use within the organization or by the exchange partners. This will determine
(1) which release will be used for the NIEM subset in the IEPD
(2) which version of the Naming and Design Rules (NDR) should be used for conformance testing
(3) whether the IEPD should follow the 3.0 or 5.0 version of the MPD / IEPD specification
|Related IEPDs||Capture information about any related IEPDs that may be extended, reused, or otherwise leveraged|
|Message names||One IEPD can be built that defines multiple kinds of related messages. One example is a request / response pair of messages. Document the names and descriptions of each kind of message if more than one will be built.|
|Authoritative source||What organization will serve as the authoritative source for the IEPD? Will need a name and point of contact information.|
|Keywords||Common aliases, terms, or phrases that would help other users discover this IEPD|
|Subject matter domain||The community in which this IEPD is applicable or used. This does not need to correspond to a domain that already exists in NIEM or will be used in the IEPD.|
|Purpose||A description of the intended usage and reason for the IEPD|
|Exchange pattern||A description of the transaction or design pattern by which information will be shared|
|Exchange partners||Names or kinds of the organizations that will use this IEPD to share data.|
A Readme is another required artifact in an IEPD. This will serve as the introductory human-readable documentation and should include the following:
Any of the diagrams or documents created to analyze and document the exchange scenario should also be included in the final IEPD package. Keep these together and update as needed during the IEPD development process.