[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-have] Groups - Draft - HAVE Issues List (EDXL_HAVE_IssuesList_v1.0.xls) uploaded
|
Here’s an idea for a basic
structure that should allow us good extendibility without having to use
<params> except in extreme cases. It breaks the HAVE report into
three areas, FacilityInfo, Services, and resources. Services and resources are
lists so they can be extended as needed. We can supply default enumerations for
these list to encourage common terminology. The elements defined are in no way
complete, enough has been entered to see the general pattern Rob 805-551-6232 From: McGarry, Donald P.
[mailto:dmcgarry@mitre.org] I agree that not all will, but most of them may...if we put the
extension in both places you give folks the ability to categorize, but then
again you add complexity! From: Lee Tincher <ltincher@evotecinc.com>
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: 1<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----- 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. dmcgarry@mitre.org (315) 838-2669 Office (703) 595-9375 Cell Sent via Blackberry ----- Original Message ----- From: Lee Tincher <ltincher@evotecinc.com> To: McGarry, Donald P.; emergency-have@lists.oasis-open.org
<emergency-have@lists.oasis-open.org> 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:dmcgarry@mitre.org] Sent: Tuesday, July 13, 2010 8:08 PM To: 'ltincher@evotecinc.com'; 'emergency-have@lists.oasis-open.org' 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. dmcgarry@mitre.org (315) 838-2669 Office (703) 595-9375 Cell Sent via Blackberry ----- Original Message ----- From: Lee Tincher <ltincher@evotecinc.com> To: McGarry, Donald P.;
emergency-have@lists.oasis-open.org <emergency-have@lists.oasis-open.org> 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:dmcgarry@mitre.org] Sent: Tuesday, July 13, 2010 5:55 PM To: 'ltincher@evotecinc.com';
'emergency-have@lists.oasis-open.org' 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. dmcgarry@mitre.org (315) 838-2669 Office (703) 595-9375 Cell Sent via Blackberry ----- Original Message ----- From: ltincher@evotecinc.com
<ltincher@evotecinc.com> To: emergency-have@lists.oasis-open.org <emergency-have@lists.oasis-open.org> 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
|
<hospital>
<facilityInfo>
<ParentFacility></ParentFacility> <!-- typically a large medical faciltiy is part of a group belonging to a parent org.
Also during diasasters they may spin up seperate, maybe temporary facilities -->
<name></name>
<type></type> <!-- i.e. hospital, aid station, urgent care,evacution center with medical services, etc. -->
<ID></ID>
<locationInfo></locationInfo>
<transportation></transportation>
<contactInfo></contactInfo> <!-- or put this under organization -->
<organization></organization>
<HoursOfOperations></HoursOfOperations> <!-- structured for a week -->
<EmergencyDeptHours></EmergencyDeptHours><!-- structured for a week - maybe this belongs under services,
or do we make the emergenct department a block by itself? -->
<LastUpdateTime></LastUpdateTime>
<Comment></Comment>
<status>
<OpenClosed></OpenClosed>
<HospitalEOCStatus></HospitalEOCStatus>
<HospitalEOCPlan></HospitalEOCPlan>
<security></security>
<evacuations></evacuations>
<Comment></Comment>
</status>
<Staffing></Staffing> <!-- this would be for general hospital staff not covered by department -->
</facilityInfo>
<services> <!-- Multiple - rename departments? -->
<Name></Name>
<status></status>
<HoursOfOperation></HoursOfOperation> <!-- structured for a week -->
<ContactInfo></ContactInfo>
<Comment></Comment>
<TimePeriod> <!-- Multiple - Default enumerations - current, 24hrs, 48,72, the rest can be extendable -->
<SupplyStatus></SupplyStatus>
<bedCapacity>
<baseline></baseline>
<current></current>
</bedCapacity>
<Staffing> <!-- enumerations? -->
<Surgeaons></Surgeaons>
<Nursing></Nursing>
<Adminstration></Adminstration>
</Staffing>
<Surgery>
<operatingRooms></operatingRooms>
</Surgery>
<ServiceSpecificInventory> <!-- not sure if a facility tracks inventory per dept, at the facility level, or both -->
<inventoryStructure></inventoryStructure> <!--refer to resources -->
</ServiceSpecificInventory>
<Comment></Comment>
</TimePeriod>
</services>
<resources> <!-- Multiple - I think this should be called inventory, resources to me reflects everything the hopspital has to offer -->
<!-- maybe do this by a time period as well -->
<!-- does it need to be a block by itself or should it all be under services ?? -->
<Name></Name>
<status></status>
<Type></Type>
<UnitsOfMeasure></UnitsOfMeasure>
<LotNumber></LotNumber>
<StorageRequirements></StorageRequirements>
<Expiration></Expiration>
<OnHand></OnHand>
<Needed></Needed>
<Requested> <!-- multiple -->
<Qty></Qty>
<RequestedFrom></RequestedFrom> <!-- ContactInfoBlock? -->
<DateRequested></DateRequested>
<PlannedDeliveryDate></PlannedDeliveryDate>
<Comment></Comment>
</Requested>
<Confirmed></Confirmed>
<Comment></Comment>
</resources>
</hospital>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]