Preceding the Health Sector Reference Group a number of Australasian WebEOC users are going to meet on Monday 24 August to discuss issues around interoperability, best practice, training and WebEOC development.
Whilst the current economic climate has made travel difficult for agencies I really hope that some of the Australian agencies will be able to make it, but we should still have confirmed attendance from Maritime NZ, Auckland City Council and Ministry of Health.
One of the key discussion points will be on interoperability and sharing common operating picture. There are a range of ways to achieve this and over the last 3 months Health have added log ons at various levels to nearly 100 agencies in order to better share data around the pandemic response however there are also smarter ways to work with database to database links. With that in mind we'd welcome attendance from other agencies who have an EMIS capability or are looking at acquiring one in order to ensure interoperability between agencies in the future.
Tuesday, July 28, 2009
EMIS Reference Group meetings
A number of meetings postponed because of the Pandemic response at the end of May have been rescheduled for the end of August in Wellington.
The most important of these meetings is on Tuesday 25 August which will see the Health Sector EMIS Reference group meeting to discuss the effectiveness of WebEOC during the current pandemic and what other operational changes need to be made going forward. The reference group has representatives from District Health Boards, Public Health Units, Ambulance Providers and Comms Centre and a number of other specialist providers.
An email went out to the wider health emergency management community with a copy of the agenda and their local representatives but if anyone has not received this please feel free to email me webeoc@moh.govt.nz
The most important of these meetings is on Tuesday 25 August which will see the Health Sector EMIS Reference group meeting to discuss the effectiveness of WebEOC during the current pandemic and what other operational changes need to be made going forward. The reference group has representatives from District Health Boards, Public Health Units, Ambulance Providers and Comms Centre and a number of other specialist providers.
An email went out to the wider health emergency management community with a copy of the agenda and their local representatives but if anyone has not received this please feel free to email me webeoc@moh.govt.nz
Monday, July 20, 2009
Intensive Care Unit direct dashboard reporting via WebEOC
Over the last week ICU clinical directors and their staff from around the country have been getting used to providing direct local figures for their facility into the DHB Dashboard.
In this case it is Auckland DHB which has a Paediatric ICU (Starship) as well as Cardio Vascular and Department of Critical Care Medicine ICUs. These three ICUs all provide summed figures to the main DHB board.
It has also been an opportunity to start using some of the built-in reporter functionality of the system, and for the non WebEOC Admins out there this basically allows the admins to build a database query and store it on the control panel as a weblink. Clicking the link will open another window and return the pre-canned report which can then been exported to excel and sliced and diced as required. This is a whole level of functionality we have not really utilised so far but allows historical reports and trends over time to be easily viewed.
For example: Want to see how the incident details board has changed over time? - simply run a report and it will show what time and what user changed any of the specified fields. Of course there are a few limitations, because it is returning raw data fields you need to know what the data fields you are interested in were called and sometimes what was clearly labelled to the developer might not be clear to someone looking at the report later.
The data fields were developed by an ICU Advisory group representing intensivists and ICU nursing staff from around the country as well as the Ministry. Colin McArthur, Clinical Director from Auckland Department of Critical Care Medicine and the Operations Team in the National Health Coordination Centre were instrumental in supporting the development of this board and persuading users that we could do better than trying to manage 25 excel spreadsheets returned daily.
The ICU dashboard was built as an additional table within the existing DHB Dashboard. This allows a DHB to add as many ICU facilities as they have and then edit and update the records for those ICUs. The previous ICU data that the DHB Emergency Operations Centre had been entering around patients with confirmed H1N1 is now automatically populated via a related list function from the ICU data.
For a DHB with more that one ICU the numbers for each respective category are automatically summed and provided as a return for the DHB. As you can see below the ICU details appear as a nested table within the DHB detail display.
In this case it is Auckland DHB which has a Paediatric ICU (Starship) as well as Cardio Vascular and Department of Critical Care Medicine ICUs. These three ICUs all provide summed figures to the main DHB board.
There is also a display view linked off the main the DHB Dashboard that provides a consolidated view of all of the ICU units. This type of functionality is incredibly useful and the print to PDF button allows a snapshot view to be rapidly disseminated and shared.
It has also been an opportunity to start using some of the built-in reporter functionality of the system, and for the non WebEOC Admins out there this basically allows the admins to build a database query and store it on the control panel as a weblink. Clicking the link will open another window and return the pre-canned report which can then been exported to excel and sliced and diced as required. This is a whole level of functionality we have not really utilised so far but allows historical reports and trends over time to be easily viewed.For example: Want to see how the incident details board has changed over time? - simply run a report and it will show what time and what user changed any of the specified fields. Of course there are a few limitations, because it is returning raw data fields you need to know what the data fields you are interested in were called and sometimes what was clearly labelled to the developer might not be clear to someone looking at the report later.
Lates updates and changes
The ongoing development of board 47, the DHB Dasboard, including the development of the Intensive Care Unit as well as more consistent reporting via EpiSurv means that board 10 Case Summary has been removed from suers control panels.
We are currently working on an API that will provide a view only display of high level summary data direct from EpiSurv that can displayed on a WebEOC board.
We are currently working on an API that will provide a view only display of high level summary data direct from EpiSurv that can displayed on a WebEOC board.
Wednesday, July 15, 2009
Auckland CDEM Group ready to support Health Sector with WebEOC
Fred Wilson, who works with Auckland City Council to support their instance of WebEOC has let me have this update on some of the excellent joint planning around response activities that is taking place in the Region. It's really encouraging to see some good operational examples of data exchange and interoperability taking place.
The Auckland CDEM Group, which comprises the Auckland Regional Council and Rodney, North Shore, Waitakere, Auckland City, Manukau, Papakura and Franklin Councils, has completed preparations to provide welfare support in the region should this become necessary.
Using the Auckland City instance of WebEOC, council personnel have been trained to use the system, and supported by the Auckland Region Welfare Advisory Group members (which comprises agencies such as Work & Income, Child Youth and Family, Red Cross, Salvation Army, SPCA, St John, etc.) procedures have been set up to action welfare requests, if this is requested. The current process is that the Northern Region Health Co-ordination Centre (NRHCC) is managing welfare requests associated with consequences of the pandemic in the region, but if the volume becomes unmanageable they may ask for CDEM support.
Preparations include the establishment of a dedicated call centre to take requests for welfare assistance from people referred there from the MoH Healthline. Details will be entered directly into WebEOC, assessed by the Group EOC, and assigned to the various council EOCs as appropriate for action. Where specialist assistance is required, the council will request support from one or more of the welfare agencies. As each request is progressed and action taken, updates entered into WebEOC will be monitored by the Group EOC to detect any areas of over-commitment or delays in responding to requests.
Two short exercises were conducted in early July to test the system and the Auckland CDEM Group region is now ready to provide support if needed.
Using a feature known as Dual Commit, the MoH and Auckland City WebEOC instances can exchange data at the server level. Through this component, the Auckland CDEM personnel can directly access selected non-medical MoH boards such as the National Significant Events and School Closures, and thus easily keep up to date with developments.
The Auckland CDEM Group, which comprises the Auckland Regional Council and Rodney, North Shore, Waitakere, Auckland City, Manukau, Papakura and Franklin Councils, has completed preparations to provide welfare support in the region should this become necessary.
Using the Auckland City instance of WebEOC, council personnel have been trained to use the system, and supported by the Auckland Region Welfare Advisory Group members (which comprises agencies such as Work & Income, Child Youth and Family, Red Cross, Salvation Army, SPCA, St John, etc.) procedures have been set up to action welfare requests, if this is requested. The current process is that the Northern Region Health Co-ordination Centre (NRHCC) is managing welfare requests associated with consequences of the pandemic in the region, but if the volume becomes unmanageable they may ask for CDEM support.
Preparations include the establishment of a dedicated call centre to take requests for welfare assistance from people referred there from the MoH Healthline. Details will be entered directly into WebEOC, assessed by the Group EOC, and assigned to the various council EOCs as appropriate for action. Where specialist assistance is required, the council will request support from one or more of the welfare agencies. As each request is progressed and action taken, updates entered into WebEOC will be monitored by the Group EOC to detect any areas of over-commitment or delays in responding to requests.
Two short exercises were conducted in early July to test the system and the Auckland CDEM Group region is now ready to provide support if needed.
Using a feature known as Dual Commit, the MoH and Auckland City WebEOC instances can exchange data at the server level. Through this component, the Auckland CDEM personnel can directly access selected non-medical MoH boards such as the National Significant Events and School Closures, and thus easily keep up to date with developments.
Monday, June 29, 2009
Facility and Status dashboards
Every Emergency Manager familiar with the capability of EMIS or CIMS systems talks about the need to have 'Dashboards' - display views showing critical information that are often shaded or coloured to highlight particular values based on priority, time due, alert level etc.
Unfortunately as much as everyone thinks they are a good thing (and the answer to all their briefing problems), no-one can really agree on what should actually be in a dashboard. Over the last year or so I've learnt that whilst most database EMIS systems can be built to record and display whatever their administrator or project manager can think of, the real challenge is in identifying data of worth that needs to be displayed.
Some of the NZ Health Emergency Managers may remember a WebEOC board that was used during the WebEOC trial in Ex Cruickshank May 2007. That board was based on the second page of the national health sitrep and allowed a District Health Board to report on bed availability, staff shortages, infrastructure damage, system status and utility failure.
Whilst this was turned into a great looking WebEOC board (a consolidated series of screenshots for 'Shortland St' Hospital is shown below) it underlined the fundamental difficulty in designing effective dashboards - that is how do you usefully record dashboard information such as fire, water damage, power outages or staff shortages for multi-sited, mulit-building, multi-department sites like a modern healthcare facility?
For example the paper based form had the ability to record as 'Functioning' 'Partially Functioning' and 'Not Functioning' for utility and service status that was subdivided into Electricity, Gas, Potable Water, Steam, Sewerage etc. Whilst these three values are easily added to a WebEOC form as a drop down field, and can be shaded in the display view green, orange and red the trouble is it does not really tell you what you need to know.
If Power is 'Partially Functioning' what does that actually mean on a multi-building hospital site, how does the partial power outage impact on the ability to receive casualties? What if it is in the Emergency Department - then there may still be options around field triage or generators but if it is in other departments, such as imaging or ICU the effects may be much greater.
Bed availability is another area that on first glance looks easy but is notoriously difficult to record within a dashboard. Intensive Care Unit capacity is not just the physical bed but also require trained staff, equipment such as ventilators and support systems. Furthermore clinical staff are excellent at actually freeing up capacity when it is required but all of this is dependent on capacity of other departments and wards and is not something that can easily be entered.
Some of the most successful dashboards in this area have been developed in jurisdictions that are linked to business as usual systems, especially Patient Management Systems. For example EM Systems provide a PMS that is used in about a third of US hospitals and is constantly updated on patient location, bed availability and staffing.
In the event of a hospital activating their Emergency Plan this data is immediately available to WebEOC via a special Application Program Interface. The advantages of this are obvious, clinical and clerical staff can get on with responding to the influx of casualties whilst the Emergency Operations Centre will have access to real time data right from the start of the incident.
The design of the NZ Health EMIS is such that it is intended to also support local incidents and not simply to be used in regional or national events. Over the last couple of weeks we've developed a number of APIs for this instance of WebEOC and going forward there is no reason why any NZ Health agency cannot develop APIs between their own business as usual systems and WebEOC.
With the Influenza response ongoing for the forseeable future I'm currently working on some options to host the next EMIS Reference Group meeting and another 'Board Building Boot Camp' to train some additional adminsitrators.
In the event of a hospital activating their Emergency Plan this data is immediately available to WebEOC via a special Application Program Interface. The advantages of this are obvious, clinical and clerical staff can get on with responding to the influx of casualties whilst the Emergency Operations Centre will have access to real time data right from the start of the incident.
The design of the NZ Health EMIS is such that it is intended to also support local incidents and not simply to be used in regional or national events. Over the last couple of weeks we've developed a number of APIs for this instance of WebEOC and going forward there is no reason why any NZ Health agency cannot develop APIs between their own business as usual systems and WebEOC.
With the Influenza response ongoing for the forseeable future I'm currently working on some options to host the next EMIS Reference Group meeting and another 'Board Building Boot Camp' to train some additional adminsitrators.
Dashboard displays and WebEOC adaptability
The ongoing response to Novel Influenza A (H1N1) is continuing to generate a lot of new data reporting and collecting requirements at both local and national level EOCs. The big advantage of WebEOC is that these boards to capture and allow local users to directly enter this data (hence reducing errors from transposing results from fax, email, phonecall) can quickly and easily be developed over a couple of hours and then continually be refined. This ongoing board development can even be done, with a bit of care*, on the production database mid incident.
Last week for example Planning and Intelligence in the NHCC identified the need to start to track several disparate pieces of information around hospital admissions and DHB staff sickness for Influenza Like Illness (ILI) and confirmed cases of H1N1. This information was initially gathered as DHB responses to a Task - Request for Information, and then as regular reporting items within their daily sitrep but it made much more sense to collate it into a table, ideally something that would show the status of all 21 DHBs 'at a glance' and perhaps be expandable to track other key indicators as they are identified. In short, for all the WebEOC administrators out there the elusive lesser spotted WebEOC Dashboard.
The actual board was a pretty basic form, that followed the standard CSS formatting of other display pages within our WebEOC board. The initial build was a little clunky:
The 'Current' and 'Cumulative' data fields were recorded above and below each other, however these data fields were sufficient to get the board 'live' and in use at the end of last week.
Following feedback from the sector the categories were extended to capture cases of ILI as well as confirmed H1N1 and two new views were created, one showing current and the other cumulative data with a 'Viewlink' between them in order to streamline the page.
The page also has filter views that allow users to view DHBs data within each of the respective Health Regions. As further categories are identified for this 'Dashboard' additional display views will be created, each accessed by a viewlink button of the main display.
There is some further work to still be done; this board currently requires the DHB to manually indicate whether they have Community Based Assessment Centres open. Now ideally that would be a 'Datalink' from the CBAC status board, but unfortunately that is a 'list' and this is a 'form' display. What that means is there is no easy way of getting rolled up data, such as the number of CBACs open, from the CBAC board to this board. To solve this Jeremy has already mentioned his favourite word, Database Trigger, but in the interim I'm afraid users will need to reconfirm this data in two places. If any WebEOC administrator out there has an idea on a solution to this please PM me.
-------------------------------------------------------------------------------------------------
*I'm talking about adding new fields, adding explanatory text, re-labelling fields or re-arranging display views. I'm not talking about adding complicated java script, building SQL database triggers or anything else you wouldn't find in the plain old vanilla WebEOC Admin manual. Even then I still copy and create a back up of the current view or input that I'm about to mess with!
Last week for example Planning and Intelligence in the NHCC identified the need to start to track several disparate pieces of information around hospital admissions and DHB staff sickness for Influenza Like Illness (ILI) and confirmed cases of H1N1. This information was initially gathered as DHB responses to a Task - Request for Information, and then as regular reporting items within their daily sitrep but it made much more sense to collate it into a table, ideally something that would show the status of all 21 DHBs 'at a glance' and perhaps be expandable to track other key indicators as they are identified. In short, for all the WebEOC administrators out there the elusive lesser spotted WebEOC Dashboard.
The actual board was a pretty basic form, that followed the standard CSS formatting of other display pages within our WebEOC board. The initial build was a little clunky:
The 'Current' and 'Cumulative' data fields were recorded above and below each other, however these data fields were sufficient to get the board 'live' and in use at the end of last week.
Following feedback from the sector the categories were extended to capture cases of ILI as well as confirmed H1N1 and two new views were created, one showing current and the other cumulative data with a 'Viewlink' between them in order to streamline the page.
The page also has filter views that allow users to view DHBs data within each of the respective Health Regions. As further categories are identified for this 'Dashboard' additional display views will be created, each accessed by a viewlink button of the main display.There is some further work to still be done; this board currently requires the DHB to manually indicate whether they have Community Based Assessment Centres open. Now ideally that would be a 'Datalink' from the CBAC status board, but unfortunately that is a 'list' and this is a 'form' display. What that means is there is no easy way of getting rolled up data, such as the number of CBACs open, from the CBAC board to this board. To solve this Jeremy has already mentioned his favourite word, Database Trigger, but in the interim I'm afraid users will need to reconfirm this data in two places. If any WebEOC administrator out there has an idea on a solution to this please PM me.
-------------------------------------------------------------------------------------------------
*I'm talking about adding new fields, adding explanatory text, re-labelling fields or re-arranging display views. I'm not talking about adding complicated java script, building SQL database triggers or anything else you wouldn't find in the plain old vanilla WebEOC Admin manual. Even then I still copy and create a back up of the current view or input that I'm about to mess with!
Subscribe to:
Posts (Atom)
Posts
