WL2K compatibility with WebEOC

[SkyeDog]

Several CA Counties use WebEOC, as do many others around the Nation, including at least one (SJC) in SJV uses it for their bi annual, MHOAC Approved Recurring Exercises.

This may be beyond the scope of an Open Source Winlink Client but if the parameters for using a current WebEOC API to enter records into WebEOC can be defined - perhaps we could cross that bridge and add populating WebEOC with data per each local Jurisdiction's specifications.

Developing this capability could extend the reach of WL2K and cross a frequently encountered barrier within the Medical ESF Nation wide.

Cheers,
dan sohn wl7coo

[w3qalor]

We are dealing with this in both WA and NC now, and have investigated it for other states as the questions get asked. Turns out, it’s a different project for every State, as their contract with Juvare will specify different support and local programming details/requirements. Every State wants something a bit different, too. I do not think this is a generalized feature we can bake into any released product, at least with what we’ve learned so far. It’s not really a technical issue, we can surely do it. But the actual specs will need to be nailed down, and I don’t think that’s possible. —Lor

…

On May 27, 2023, at 3:48 PM, SkyeDog ***@***.***> wrote: Several CA Counties use WebEOC, as do many others around the Nation, including at least one (SJC) in SJV uses it for their bi annual, MHOAC Approved Recurring Exercises. This may be beyond the scope of an Open Source Winlink Client but if the parameters for using a current WebEOC API to enter records into WebEOC can be defined - perhaps we could cross that bridge and add populating WebEOC with data per each local Jurisdiction's specifications. Developing this capability could extend the reach of WL2K and cross a frequently encountered barrier within the Medical ESF Nation wide. Cheers, dan sohn wl7coo — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[SkyeDog]

This is all above my pay grade, I stopped baking network data exchange interfaces decades ago (mid 1980s) - yet old habits are hard to suppress & hard fought battles are harder to forget. As I recollect, the Version 7 WebEOC API (circa 2010) I stumbled across in an archived FedGov Procurement Contract synopsis provided sufficient tools to implement any specific data record structure the License owning entity wanted if anyone on board was fluent with what was then nascent post C++ OO programming. I think a different Gov’t Tech Sales Corporation (Beltway bandit) used to own WebEOC so a contact with Juvare needs to be developed to determine (if you haven’t already) wether the current API is similarly accommodating to the extent that each AHJ using it could bake their own WebEOC records out of plain text WL2K Messaging… i.e. accept ASCII strings in a pre-specified sequence which only the end user Agency needs to know & understand. Barring State or national standards, each user node can vette each word or ASCII character or group of characters as the proposed record is accepted through their system's inbound record portal(s). Using APIs into other potentially secured systems dovetails very nicely with the whole “...examine what actually has to be transmitted” and complements the last half dozen years of outstanding Forms progress like making Forms Agency entity specific as well as providing Form instructions at 'form fill’ time. [’Select your Agency WebOES ID from this list'] Thank you for the rapid feedback and confirming there is interest re: interfacing w/WebEOC. Cheers, Daniel Sohn ***@***.*** ***@***.***> 209.628.2242

…

We are dealing with this in both WA and NC now, and have investigated it for other states as the questions get asked. Turns out, it’s a different project for every State, as their contract with Juvare will specify different support and local programming details/requirements. Every State wants something a bit different, too. I do not think this is a generalized feature we can bake into any released product, at least with what we’ve learned so far. It’s not really a technical issue, we can surely do it. But the actual specs will need to be nailed down, and I don’t think that’s possible. —Lor > On May 27, 2023, at 3:48 PM, SkyeDog ***@***.***> wrote: > > > Several CA Counties use WebEOC, as do many others around the Nation, including at least one (SJC) in SJV uses it for their bi annual, MHOAC Approved Recurring Exercises. > This may be beyond the scope of an Open Source Winlink Client but if the parameters for using a current WebEOC API to enter records into WebEOC can be defined - perhaps we could cross that bridge and add populating WebEOC with data per each local Jurisdiction's specifications. > Developing this capability could extend the reach of WL2K and cross a frequently encountered barrier within the Medical ESF Nation wide. > Cheers, > dan sohn wl7coo > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFRDMWT46BXCWSF2K2WB5LLXIJRSHANCNFSM6AAAAAAYRLRWDQ>. You are receiving this because you authored the thread.

[k0qed]

It's possible that something as diverse as interfacing with state WebEOC could be supported by using a plugin approach, where the actual implementation is handled by persons working within each state. This project would just provide the interface mechanism for a generic WebEOC plugin.

[SkyeDog]

To further the potential value of the ‘possible’ in your response below - is there sufficient interest to solicit (formally or informally) from Jurisdictions how many are using WebEOC vs other competing products? Specifying, writing and iterative testing of a generic API component, while possible with enough talent & time invested, is a goal which reaches significantly further than I would ever hope to dare. Does ARFSI have the reach to solicit ‘pushing the edge’ Computer Science University programs to identify talent or survey the literature of any public domain work already engaged in similar generic ‘plug in’ absorption capability funded by whomever funds large reward capabilities aka [Beltway Bandits Inc] or perhaps somebody involved in EMI’s https://training.fema.gov/hiedu/specialinterest/stisig.aspx Also note while you are there that EMI’s Independent Study courses are moving to a new system on July 10, 2023 after a brief outage EMI’s STI SIG ‘Brief Description’ even mentions WebEOC - bolding is mine - finding it was a pleasant surprise: "From software like WebEOC to the complex algorithms of machine learning, the demand for computer use in emergency management is increasing at an exponential rate. By focusing on integrating science and technology with existing emergency management praxis, the STI SIG can help educate emergency managers to use cutting edge computational techniques and teach them to others quickly and effectively.” Part of the challenge might become, that on its face, ARSFI’s WL2K and CISA SHARES might be construed by some as potential competitors in the small community of Beltway bandit EMA System providers rather than achieving the ‘Whole Community’ force multiplier dicta for all Gov’t Agencies ESF2 requirements that it is. Though this may be unique to CA - relying on States to impose uniformity on all EOC Operations has some interesting caveats for developing functional requirements. Cheers, Daniel Sohn 209.628.2242 ***@***.*** or wl7coo @ winlink.org

…

On May 28, 2023, at 5:35 AM, Lee ***@***.***> wrote: It's possible that something as diverse as interfacing with state WebEOC could be supported by using a plugin approach, where the actual implementation is handled by persons working within each state. This project would just provide the interface mechanism for a generic WebEOC plugin. — Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFRDMWUMOOB5PX6W56HGLETXINA7RANCNFSM6AAAAAAYRLRWDQ>. You are receiving this because you authored the thread.