[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.
Sean Barker
0117 302 8184
>
-----Original Message-----
> From: Barker, Sean (UK)
> Sent: 08
January 2007 11:58
> To: emergency-comment@lists.oasis-open.org
>
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:
|
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.
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.
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
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.
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]