Draft Disaster XML Spec Review
Review per CAN request of Draft Disaster XML Specification's proposed data elements and types. This review is from the perspective of its overlap/compatibility with HUD HMIS XML data elements, in its present and future form. I hope this helps further the development of the Disaster XML Schema!
The following bullet points, divided into sections, constitute a review of the Draft Disaster XML Specification.
Inaccuracies in the CAN Client Data Disaster XML/HUD HMIS XML 2.7 Comparison Chart
Inaccuracies in the CAN Client Data Disaster XML/HUD HMIS XML 2.7 Comparison Chart
- The comparison chart column for HUD HMIS XML understates its overlap with Draft Disaster XML. HMIS XSD 2.7 does contain an equivalent to "RecordCreationTime", since it has an ISO dateTime for this in its ExportDate section. As an aside, version 2.8 adds timestamps to all elements, not just element groups, and has full update/create timestamps.
- The comparison chart indicates that HMIS XSD 2.7 does not have DataSourceID, DataSourceName, and DataSourceDate, which HMIS XSD 2.7 does in fact possess, but named 'DatabaseID', 'DatabaseName', and 'ExportDate'.
- The comparison chart indicates that 'Services Provided' is not contained in HMIS XSD 2.7, however, it does in fact it have an entire 'ServiceEvent' section which more accurately describes services using the AIRS Taxonomy, as opposed to a single free text field in the Draft Disaster XML specification.
- ClientID, Program Participation, and Entry/Exits in HMIS XML are similar in use to CaseID.
- Non-overlapping data elements (for version 2.7 of HUD HMIS XSD) then, are: Preferred Language, address fields, FEMA Number, IncidentDRONumber, phone contact info, and some elements' record edit dates (to be fixed in HUD HMIS XSD 2.8), which are a very small number of fields.
- Need to make sure the resulting Schema is extensible, to add more fields, but still keep the core requirements. This is also a feature of the pending release of HUD HMIS XML Schema v.2.8.
- Make both a CSV and XML version of the Disaster XML spec.
- A dual release of Disaster XML as an importable type, and as a standalone schema would allow Disaster XML to be "tacked onto" existing standards by means of extension. This would avoid the need to choose one standard over another.
- Not an inaccuracy in the chart, but "Special Needs" will be analogous to "Needs" to be tentatively included into HUD HMIS XML v. 2.8.
- In the Draft Disaster XML Specification, the Pre/PostDisasterAddress and related address fields could be eliminated in favor of a generic set of address fields with date effective attributes. Then, the pre/post disaster aspects of the address can be reported upon by calculating if the address was effective before or after the disaster date. This will both caught down on duplicate fields and remove errors. For example, one agency may consider the disaster to have happened on a different date than another, causing anomalies in the data.
- The copyright symbol is still present in the reviewed document. An Open Source license and using one of the Creative Commons copyrights, or the like would be a good idea.
- AIRS taxonomy codes should be used in the Disaster XML, instead of a free text field, since this taxonomy is a robust and standardized way to indicate services provided. With a free text field, the number of ways of indicating the same exact service are unlimited, making effective reporting nearly impossible. It's also not a compact way to describe a service, in addition to not being concise.
- 'Services Needed', if added, could be also be an AIRS Taxonomy code. A need fulfilled/met flag would also be helpful if this is added. then unmet needs reports could be run.
- Head of Household, if collected, should have an accompanying household ID to group families together.
- The process by which Disaster XML draft elements were determined, had it been more open to the social services community, could have avoided many of the existing deficiencies. A draft could then proceed after a collaborative process. A public email listserv for Disaster XML development would be a great addition.
