If the need for all extensions mapped to sub-categories -
which I don't think they do...
I was toying with the idea of adding one Parameter
element by extending it so it has an attribute named "category" and
give it a 0 to many cardinality:
(1) Any system-specific
datum, in the form:
<parameter>
<category>category</category>
<valueName>valueName</valueName>
<value>value</value>
</parameter>
where the content of
“valueName” is a
user-assigned string
designating the
domain of the code, the
category maps to
a specific HAVE category or
subcategory
and the content of “value”
is a string
(which may represent a number)
denoting
the value itself (e.g., valueName
="SAME"
and value="CIV".)
(2) Values of
“valueName” that are
acronyms SHOULD be represented
in all
capital letters without periods
(e.g., SAME,
FIPS, ZIP).
Those who cannot hear an angry shout may strain to hear a
whisper - Leonard Nimoy
-----Original Message-----
From: McGarry, Donald P. [mailto:]
Sent: Tuesday, July 13, 2010 8:31 PM
To: ''; ''
Subject: Re: [emergency-have] Groups - Draft - HAVE Issues List
(EDXL_HAVE_IssuesList_v1.0.xls) uploaded
Yeah...I agree. My thought was that we could add
the "extension" fields within the subcategories so at least they
would be tied to something tangible...
Don McGarry
The MITRE Corp.
(315) 838-2669 Office
(703) 595-9375 Cell
Sent via Blackberry
----- Original Message -----
From: Lee Tincher <>
To: McGarry, Donald P.;
<>
Sent: Tue Jul 13 20:29:02 2010
Subject: RE: [emergency-have] Groups - Draft - HAVE
Issues List (EDXL_HAVE_IssuesList_v1.0.xls) uploaded
It seems to be a common theme in all the areas where a
"list" is included in
the standard. I suggested we place a
<Parameter> value (as defined in CAP)
in key areas to allow for some ad-hoc additions with the
thought that we
could expand each list with known attributes, but each
disaster/incident is
sure to turn up some special needs we haven't calculated.
There was some major concern that the stakeholders who
worked so hard to
come to a consensus on these lists may not like this at
all. If you couple
that with the thought that "loosening" up the
standard that much may cause
confusion and may not even represent a concise standard -
well it all means
we need to think long and hard about this and reach out
as far as we can to
get some SME's to help us vet the ideas....
Please look at the Draft Meeting notes from today....
Thanks,
Lee
Those who cannot hear an angry shout may strain to hear a
whisper - Leonard
Nimoy
-----Original Message-----
From: McGarry, Donald P. [mailto:]
Sent: Tuesday, July 13, 2010 8:08 PM
To: '';
''
Subject: Re: [emergency-have] Groups - Draft - HAVE
Issues List
(EDXL_HAVE_IssuesList_v1.0.xls) uploaded
Haha...well at least we are on the same page! I
found this to be the case
with facilitystatus as well (no clear way to represent an
internal
disaster). One other thing is representing services
that are not a capacity
type...I.e. this facility has CT, Trauma Services, STEMI,
Stroke team. This
wouldn't give the status of that service, nor would it
give a capacity for
that service, just communicate the fact that the facility
"supports" or is
"certified" for it...
Don McGarry
The MITRE Corp.
(315) 838-2669 Office
(703) 595-9375 Cell
Sent via Blackberry
----- Original Message -----
From: Lee Tincher <>
To: McGarry, Donald P.;
<>
Sent: Tue Jul 13 19:37:41 2010
Subject: RE: [emergency-have] Groups - Draft - HAVE
Issues List
(EDXL_HAVE_IssuesList_v1.0.xls) uploaded
This is hilarious! We spent nearly the whole
meeting discussing this and
decided to table it until you could chime in....there are
some very
interesting issues around this and I look forward to
getting this problem
resolved...
All - I did not speak to Don about this at all before he
sent the email...
Thanks,
Lee
Those who cannot hear an angry shout may strain to hear a
whisper - Leonard
Nimoy
-----Original Message-----
From: McGarry, Donald P. [mailto:]
Sent: Tuesday, July 13, 2010 5:55 PM
To: '';
''
Subject: Re: [emergency-have] Groups - Draft - HAVE
Issues List
(EDXL_HAVE_IssuesList_v1.0.xls) uploaded
All-
Sorry I was unable to join today. In fact I am
working on a field
deployment for HAVE as we speak. In addition to the
structure of the
bedcapacity status being broken as already brought up I
have found that
there really needs to be extensibility added to the
servicecoveragestatus
section. I think this jives with Lee's findings but
as I started to examine
some really key services (CT, STEMI Team, Stroke Team,
etc.) It is really a
shoehorn to stick these into just a single boolean for a
more generic
service like cardio or neuro. I think to make this
work for now I'm going
to have to add a list of string bool pairs into the
standard to make this
work. Any other thoughts?
Don McGarry
The MITRE Corp.
(315) 838-2669 Office
(703) 595-9375 Cell
Sent via Blackberry
----- Original Message -----
From:
<>
To:
<>
Sent: Tue Jul 13 16:50:15 2010
Subject: [emergency-have] Groups - Draft - HAVE Issues
List
(EDXL_HAVE_IssuesList_v1.0.xls) uploaded
The document revision named Draft - HAVE Issues List
(EDXL_HAVE_IssuesList_v1.0.xls) has been submitted by Lee
Tincher to the EM
HAVE SC document repository. This document is
revision #3 of
EDXL_HAVE_IssuesList_v1.0.xls.
Document Description:
List of issues to be considered from HAVE 1.0
View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=38630
Download Document:
http://www.oasis-open.org/committees/download.php/38630/EDXL_HAVE_IssuesList
_v1.0.xls
Revision:
This document is revision #3 of
EDXL_HAVE_IssuesList_v1.0.xls. The
document details page referenced above will show the
complete revision
history.
PLEASE NOTE: If the above links do not work for
you, your email application
may be breaking the link into two pieces. You may
be able to copy and paste
the entire link address into the address field of your
web browser.
-OASIS Open Administration
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the
OASIS TC that
generates this mail. Follow this link to all your
TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the
OASIS TC that
generates this mail. Follow this link to all your
TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
