[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-comment] Observations on HAVE
This is a resend but with the comments appended after the
original text, rather than as an attachment, as it seems at least some people
didn't get the attachment.
0117 302 8184
> -----Original Message-----
> From: Barker, Sean (UK)
> Sent: 08 January 2007 11:58
> To: email@example.com
> Subject: [emergency-comment] Observations on HAVE
> *** WARNING ***
> This mail has originated outside your organization, either
> from an external partner or the Global Internet.
> Keep this in mind if you answer this message.
> The attached note is a brief review of HAVE both as a message
> structure in itself and in relation to the European fp6
> project, also confusingly called OASIS (I use the suffixes
> -open and -fp6 to distinguish the contexts).
> The document refers to the Common Operating Picture (COP),
> which is part of the OASIS-fp6 project designed to provide a
> central situation awareness database for emergency
> responders, for which I am the COP architect. It also refers
> the Tactical Situation Object (TSO), which is a lightweight
> XML message designed to provide basic situation information
> to emergency responders. This was also developed in the
> OASIS-fp6 project, and is being used to create a CEN Workshop
> agreement, which is a European pre-standardization process. I
> am also vice-chair of this workshop. We have had initial
> discussions with Patrick Gannon (CEO
> OASIS-open) on co-operation between the two OASES.
> The note represents my own views, and it not an official
> comment by any of BAE SYSTEMS, OASIS-fp6 or the CEN workshop.
> In particular, it reflects my view that software developers
> rarely have the time to read standards thoroughly and think
> through the implications, so that if there is any ambiguity
> or inconsistency that leaves two ways to implement something,
> then there will be at least three incompatible
> interpretations. Consequently, if it seems nit-picking,
> that's because it is, but better now than when it is being
> used for real.
> Sean Barker
> BAE SYSTEMS - Advanced Technology Centre Bristol, UK
> +44 (0)117 302 8184
Review of EDXL-HAVE
This note is a brief review of the Hospital AVailability Exchange - public review draft 02, 2 Nov 2006, as published on the OASIS-Open organization Emergency Management (EM) Technical Committee (TC) site. The aims of the review are to briefly:
(Sections in quotation marks are copied from HAVE).
"HAVE is a draft XML specification that allows the communication of the status of a hospital, its services, and its resources. These include bed capacity and availability, emergency department status, available service coverage, and the status of a hospital’s facility and operations"
"The principles that guided the design of the HAVE include:
"The EDXL HAVE standard MUST:
1. Allow medical and healthcare organizations to communicate their status and availability information.
2. Be designed to allow its use by a wide variety of medical and healthcare organizations (including hospitals and nursing homes), along with other emergency response organizations (such as emergency management centers, public safety answering points, and dispatch centers).
3. Be able to be used as a payload or content element with the EDXL Distribution Element.
4. Allow the communication of status information of one or more organizations in a single exchange.
5. Allow the communication of the organization’s status and availability information with regard to its facilities, operations, services, and resources.
6. Be designed to allow its use in normal operations, day-to-day emergencies and mass disasters."
HAVE consists of information to identify the hospital being described, and five status records:
· Bed Capacity - Beds by type and number available;
· Hospital Facilities - status of facilities used in responding to an emergency;
· Service Coverage - types of injury/treatment available;
· Resources - whether these are available.
The information is essentially a summary of the current status of the hospital.
The HAVE provides a summary of the status of a hospital at some point in the near past. Situation awareness covers not only what has happened, but what is on-going and planned. In this respect, HAVE provides only part of the situation awareness information needed.
A full situation awareness report would need to extend HAVE to include:
Both the centralization of emergency facilities and the tendency of terrorist organizations to make multiple co-ordinated attacks make it more likely that a hospital will be asked to respond to multiple emergencies at the same time. Consequently, the additional information is needed to assess whether the hospital will be available to respond to an emergency. This implies that the hospital would need to deliberately maintain its operational status, rather than simply extract the HAVE information from the operational systems.
Relation to COP
The COP is the central situation model, intended to provide an integrated situation picture, to merge multiple - possibly conflicting - reports, and provide views of the situation from the viewpoints of the different responders and different levels of control.
The COP data model could be straightforwardly be extended to include the HAVE attributes. The hospital itself would be a facility sub-type of an Object-item. Most of the status fields would be applied as classifications, and the strings used be encoded as ontology entries. The capacity measurements and TriageCounts would be encoded as integer properties. Currently there is no separate address entity - this could either be encoded directly as descriptors to the Object_item to the Location, or an address entity added as a basic attribute, with a set of descriptors for each field. The use of the descriptor type would also overcome the HAVE limitation of only allowing for names in a single language. The overall status would be tied together with Reporting_data, which would give the data and source of the information.
The current HAVE message has implied the assumption that the latest date of message is the most authoritative. The COP could provide a method to merge multiple messages on the basis of the source and date of the message.
Translation to and from the COP would be straightforward. Messages to the COP would be read in directly, with each hospital being an Object_item, and the various elements being added as classifications or properties. Procedures for dealing with hospitals which report from multiple sites would be needed. The COP could also directly prepare HAVE messages, although there is no obvious requirement for it to do so. Note, that since the HAVE message is essentially a summary of the status, it would be possible to reuse the structure to generate summary reports for, say, a city or region.
The TSO is focussed on the needs of a responder, to enable the assessment of the situation at the site of the emergency. There is relatively little overlap between the TSO and the HAVE message.
There is, however, one particular conflict. The EmergencyDepartmentStatus element is used to identify the capacity to accept further casualties and the number already accepted by triage class. The TSO reports the number of casualties and predictions of further casualties. The current classes for HAVE and the TSO are shown below:
TriageRed - victims with immediate needs
Highly Injured - an individual whose illness or injury is of such severity that life is imminently endangered
TriageYellow - victims with delayed needs
Seriously Injured - requires hospitalisation but there is no imminent danger to life
TriageGreen - victims with minor needs
Injured - requires hospitalisation
TriageBlack - deceased victims
Although there are the same number of classes, it is not clear that the classes have the same definitions. The TSO class names are not clear - for example, in normal British usage, "seriously injured" is always the most serious category of injury, and "highly injured" would not be recognised, although these terms may reflect the usage of other European countries. It would be better if the TSO adopted the more neutral terms of HAVE, and ensured that the categories are similarly defined.
The restriction of most elements to controlled terms makes the HAVE means that HAVE is not incompatible with the work done in OASIS-fp6. However, the way these are embedded in the text means that the values sets are difficult to extend. The COP/TSO approach of using ontologies is more flexible, and should be retained. The HAVE use of terms is context dependent - e.g. available/not-available, as opposed to an ontology convention, which would distinguish Surgery-bed-available/surgery-bed-not-available from Burn-bed-available/Burn-bed-not-available. Since in the HAVE approach, these terms are defined independently in each element, these approaches are equivalent, however there is always a temptation to reuse terms, and assume the definition in one context is the same as that in another.
HAVE uses EDXL-DE for distribution of information.
Many elements are replicated from GJXDM.
Many of the elements are strings requiring the use of a controlled vocabulary. This makes for easier translation into other languages.
Moving the allowed values to an ontology would provide a more flexible approach to vocabulary management.
There is an implied operational concept that the message is a complete snapshot of the status of the hospital. That is, there is an up-to-date, real-time system covering the entire hospital, and that therefore a later message always supersedes an earlier. This may not always be the case, e.g. in the case where the hospital IT systems are affected by a disaster, or where they are not of the standard assumed, or where the internal procedures do not provide a reliable real-time picture (e.g. at what point is the patient transferred from "emergency" to "surgery", and who is responsible for inputting this into the system).
a) There is no indication of the source of the hospital information - e.g. is it the hospital, some regional clearing system, or a direct input from a responder.
b) There is no indication of the (control) status of the information - e.g. authorized provider v. secondary information source, current validated v. last estimate.
c) There is no ability to distinguish the (control) status of the individual elements.
d) Is the association of a hospital to a single location always valid - e.g. the organizational unit which provides the IT infrastructure may provide a central service over multiple sites. The note on OrganizationName says it may include the site location. The comment that either the Id or Name must be present is not clear whether this is an exclusive OR. What happens if it is treated as inclusive, and the message contains multiple hospitals with the same OrganizationId but different OrganizationName, as the message seems to allow?
OrganizationId has an associated OrganizationIdProviderName. While this allows for different systems of Id's it has the following implications:
a) there must be a separate agreed list of OrganizationIdProviderNames.
b) the association between aliases is outside of the scope of the HAVE model. (Compare this with the PLCS approach, which starts with a global data integration model, and creates messages based on subsets of this model. Consequently, it has relationships to identify alternative identifiers in its data model, and therefore also a means to distribute the dictionary of aliases. There is no indication of how such a dictionary could be distributed for HAVE).
c) OrganizationTypeText - this seems to be a free text field - it would be better if the source was some form of controlled vocabulary, such as an ontology.
The organization location model allows only a single text field for each of the elements of the location. This is likely to be a problem in multi-lingual regions (such as Wales, Belgium, etc) where the spelling of a town can change depending on the linguistic community referencing it. The OperationalLocation model should change the cardinality of the association from 0..1 to 0..n.
From an operational point of view, it may be useful to include a contact element (e.g. telephone number) in the OrganizationLocation element, rather than leave the responder to have to find the link back.
The location definition is taken from the OASIS GML specification.
Emergency Department Status
EMSTraffic is listed as required in the field description, but shown as having cardinality 0..1 in the object model. The field description is probably correct.
Even if EMSTraffic is mandatory, neither of its component fields are. The description should be changed to make at least EMSTrafficStatus mandatory.
In the UK there are an increasing number of day time health "drop-in" centres and minor injuries units, which would be capable of accepting minor injuries victims. The capacity to treat could be modelled by identifying only TriageGreen capacity, but there is no direct way to represent the restricted operating hours.
See comments on matching OASIS-EU TSO casualty list to the TriageCount field.
The text of the two descriptions is identical - it would be better if the EMSAirTransportStatus referred to an "air ambulance" or similar term.
The offload time of an ambulance - the use of this field needs clarifying. One potential interpretation is that if the status is normal, then the time is the "normal default" which is not necessarily the current actual time. However, if the status is "delayed" then the hospital is asserting it currently has a problem, it knows it has a problem, and this is an estimate based on the current (known) problem. One issue here is that this is a historical fact being implicitly extrapolated to a future state - that is, the turn round times are most relevant when scheduling ambulances for the current emergency - what the scheduler will want to know is that, once the ambulances start to arrive, how long will it take to unload them?
Hospital Bed Capacity Status
The structure of the object model for this element does not correspond to the actual problem as described in the text. This may be due to a wish to simplify the overall structure, however, it does create some ambiguity in the message.
a) The object model gives a structure consisting of a list of discrete bed types, however the element definitions show that what is being used is a two tier structure, consisting of a top tier of discrete bed types, together with an optional second tier which breaks down each discrete type into subcategories.
b) The upper tier bed type is specified by the Bed element alone, whereas the second tier bed type is specified by the Bed and SubcategoryBed elements.
c) The current specification seems to state that where an upper tier category is subdivided by second tier categories: 1) the complete list of sub-category capacities must be present, and 2) the capacity values of the sub-categories must sum to exactly the capacity value of the parent category.
d) This implies that for each sub-category, the parent capacity record must be present. For example, if a hospital has only AdultICU surgery beds, this is represented by two records
e) If the hospital does not have a particular category of bed, does omitting the category assert this, or should it be asserted by a BedCapacity element with a CapacityStatus of NotAvailable?
f) The object model seems to show that in a BedCapacity Object, there may be multiple Bed elements and multiple capacity elements - in this case, there is no clear associativity between the Capacity Object and the type of Bed - for example, it would be legitimate to have a BedCapability with three Bed elements, with two Capacity Elements. It would be clearer if each BedCapacity element could contain only a single Bed element. It also requires that the meaning of multiple capacity statements in needed - are these supposed to be individual records that must be added together to get the overall picture, and if so, what is the function of providing multiple records?
g) The element BaselineCount is specified as "The maximum (baseline) number of beds in this category" - this is confusing, and the meaning of baseline should be spelled out, particularly since the AdditionalCapacityCount72Hr refers to "surge beds" - are these part of the baseline or not?
h) A reference to where the bed types are defined would be useful.
The model here is of a list of service types together with a status of available/not available. In the case of surgery, obstetrics and psychiatric services, separate subcategories can be listed. This could be done more simply using a controlled vocabulary and status, and this would enable the list of categories to be extended without having to re-issue the standard.
While this list appears at first comprehensive, there may be other categories or categorizations required. For example, in the heat wave in France in 2003 killed nearly 15,000 people (source wikipedia), most of who were elderly, however the list does not allow for geriatric services.
The meaning of the elements could be clearer - it is not clear when something is listed as not available whether this means that the hospital never offers this service, or is currently unable to offer this service (e.g. because all the surgery beds are full). This is further confused by elements themselves being optional. For example, is there a difference between a hospital not reporting any status for burns and one report that any burns service is unavailable? This should be clarified.
The definitions of the various elements assume that the terms are well known, well defined and universally agreed. Either the definitions should be refined, or the source of the terms cited.
The main content is a set of summary fields containing only a status code. In some cases the same codes are given, while several have codes specific to the particular field.
The object model gives a cardinality for the record of 0..1 whereas the documentation makes the HospitalFacilityStatus mandatory.
The concept of Emergency Operating Centre (EOC) is distinguished from normal accident and emergency services, but some better supporting definition is needed. There is also an Emergency Operating Plan. One might expect the emergency operating plan to call for the activation of an Emergency Operating Centre. The range of values for EOC needs reconsidering, perhaps to include "activating" and "not applicable". The element is optional, but there is no indication of what the absence of the element might mean.
ClinicalStatus has values for Level-1 and Level-2 surge conditions, but no reference as to where these are defined.
FacilityStatus definition is unhelpful - presumably it means the general status of the hospital.
The content is a list of name/value pairs, taken from the same controlled vocabulary. The definitions are a little weak - for example, would a staff shortage in the physiotherapy department mean that the overall HospitalResourceStatus.staffing has status insufficient? Some clear decision criteria are needed here.
The object model gives a cardinality for the record of 0..1 whereas the documentation makes the HospitalResourcesStatus mandatory.
This is an initial draft for public review. The current draft has a number of recurrent minor editorial problems:
These detract from the integrity of the specification, and distract from the more significant technical problems:
There are also some minor problems identified in the detailed notes.
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]