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. 

Sean Barker
0117 302 8184

> 
-----Original Message-----
> From: Barker, Sean (UK)
> Sent: 08 
January 2007 11:58
> To: 
> 
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

 

Purpose of this 
Note

 

            
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:

  
Characterize the content of the HAVE for OASIS-fp6 
  project;

  
Describe its relation to the work in OASIS-fp6, particularly the 
  Tactical Situation Object (TSO) and the Common Operating Picture 
  (COP);

  
Provide feedback to OASIS-Open EM TC from the OASIS-fp6 
  perspective.

 

Brief Description of 
HAVE

 

HAVE 
Purpose

 

(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"

 

Design 
Philosophy

 

"The 
principles that guided the design of the HAVE 
include:

  
Interoperability - The HAVE message should provide an interoperable 
  mechanism to exchange healthcare organization information among different 
  domains and among multiple systems 

  
Multi-Use Format – The HAVE message must be designed such that it can 
  be used in everyday events, during mass disasters, and for incident 
  preparedness. 

  
Flexibility – The design structure must be flexible such that it could 
  be used by a broad range of applications and systems to report status and 
  availability information "

 

Requirements for 
Design

 

"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."

 

DOCUMENT OBJECT 
MODEL

 

 

 

Brief 
Description

            
HAVE consists of information to identify the hospital being described, 
and five status records:

·        
Bed 
Capacity - Beds by type and number available;

  
Emergency Department - its capacity and the turnaround times for 
  ambulances;

·        
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.

 

Relation to 
OASIS-fp6

 

Relation to Situation 
Awareness

 

            
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:

  
Base load - the 
  extent to which the hospital predicts utilisation of its capacity 
  in normal circumstances;

  
Local crises - identify any emergencies or crises which are or will 
  impact the hospital status, for example, being in a flood 
  zone;

  
Operations in progress - identify any major emergencies in progress and 
  the level of involvement/commitment made to these 
  operations.

 

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.

 

Relation to 
TSO

 

            
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:

 

 

  
  

    
      
HAVE 
      classes

    
      
 

    
      
TSO 
      classes

  

    
      
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

    
      
Killed

 

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.

 

General 
Comments

            
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.

 

Detailed Review 
Notes

General

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.

Hospital

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? 

Organization Information

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.

OrganizationLocation

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.

EMSCensus, 
EMSCapacity

See 
comments on matching OASIS-EU TSO casualty list to the TriageCount 
field.

EMSAirTransportStatus, 
EMSAmbulanceStatus

The 
text of the two descriptions is identical - it would be better if the 
EMSAirTransportStatus referred to an "air ambulance" or similar 
term.

Offload

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

  
bed=AdultICU [no subcategoryBed element]

  
bed=AdultICU, subcategoryBed=surgery

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.

ServiceCoverageStatus

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.

HosptialFacilityStatus

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.

 

HospitalResourcesStatus

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.

Assessment

 

            
This is an initial draft for public review. The current draft has a 
number of recurrent minor editorial problems:

  
The Object Model 
  sometimes differs from the XML element definition in the 
  cardinalities;

  
A number of 
  definitions are weak, and assume that the terms are self-evident where they 
  should be made explicit;

  
There are a number of 
  implicit citations of other sources - all such citations should be made 
  explicit. This will be important in the long term maintenance of the 
  specification and in later discussions over the meaning of 
  terms.

These detract from the integrity 
of the specification, and distract from the more significant technical 
problems:

  
Many elements provide 
  a binary status (available/unavailable) however these are optional, and leave 
  undefined what is meant if the element is absent. It would be better if they 
  were made mandatory.

  
The Organization 
  Information allows for only a single language, which would not be appropriate 
  in a European context.

  
The controlled 
  vocabularies are embedded within the specification. An external vocabulary 
  would provide the needed control, but also flexibility. The ontology/reference 
  data approach used in the PLCS TC should be 
  considered.

  
The object structure 
  - and consequently the XML structure - does not always reflect the underlying 
  problem structure, which will make the message more difficult to interpret and 
  harder to maintain.

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.

********************************************************************