Modernization Hub

Modernization and Improvement
From Trauma to Technology: The District of Columbia’s Journey to an Integrated Case Planning Process

From Trauma to Technology: The District of Columbia’s Journey to an Integrated Case Planning Process

>>Joyce Rose: Thank you and welcome to the
Child Welfare Information Technology Systems Managers and Staff webinar series brought
to you on behalf of the Health and Human Services Administration for Children and Families,
Children’s Bureau, and presented by ICF International. Today’s webinar is entitled Modernizing your
CWIS, Child Welfare Information Systems, Without Losing Your Sanity. I am Joyce Rose, your host and moderator for
today’s webinar. Next. For new attendees and assuming you many have
missed previous webinars, here is the list of the previously recorded webinars which
are posted to the link identified on the slide. And we are currently working on developing
future webinar topics. Next. Attendees are encouraged to participate in
our webinar with questions and comments. All of the participant lines are muted now
but we will open them for the Q&A session at the end of the presentation. However, please be aware that you can submit
questions at any time using the GoToWebinar chat feature and those will be addressed during
the Q&A session. Should we run out of time we will respond
to your questions via email and/or should you have additional questions you may submit
those to me at the email address listed on the slide. Also, if you have any topics that you would
like to recommend as potential webinars please do not hesitate to contact me at the email
listed above, [email protected] Next. The Division of State Systems within the Children’s
Bureau continues to provide a series of monthly webinars supporting information sharing and
discussion. Certainly understanding who is attending the
webinars helps to identify content that is applicable for everyone participating in an
agency CWIS effort. Please self-select one of the five categories
listed. And now my colleague Kristy will conduct the
poll. Kristy, how are we doing?>>Kristy Stankovich: We’re about 85% and
we’ll give one more minute, one more second.>>Joyce Rose: Perfect. Okay, we have an excellent split of attendees
between our project managers and our policy and technical staff, and of course we have
our ACF personnel, our contractor staff, and I’m very pleased to see that we also have
some of our tribal CWS program, policy or technical staff attending. So thank you so very much and let’s move on. And let’s start with the introduction of our
participants. We are very pleased to have a cast from the
District of Columbia do our presentations today. Brady Birdsong is the Chief Information Officer
for the District of Columbia’s Child and Family Services Agency and his passion is to deliver
the highest quality child welfare technology solutions that will improve outcomes for children
and families. Lori Peterson oversees the production of data
that measure the agency’s performance in relation to internal, as well as various federal reporting
requirements and plans. She most recently led the successful implementation
of the cloud based data dashboard solution which allows program staff to visualize and
then manipulate data to meet their needs. Spencer Wilder serves as a supervisor of the
D.C. Child and Family Services Applications Team and is responsible for coordinating,
testing and deploying all enhancements for the District’s Child Welfare Information System. As an IT Manager, Eldon Harmon oversees the
development, implementation and support of MFACES and the Foster D.C. Kids mobile application, as well as managing
various other innovative initiatives the agency is working on. So let’s invite our guests from the District
of Columbia to actually do our presentation. And I’m going to turn it over to Mr. Brady
Birdsong.>>Brady Birdsong: Thank you Joyce and good
afternoon everyone. I suppose if there’s anybody on the West Coast
it’s still good morning. So first, I’m really grateful that we were
asked to share what we’ve been doing in the district. So the objective of the webinar is to share
the District of Columbia’s journey to modernizing our mature SACWIS and give hope to other states
considering making changes to an existing system. The title, Doing this Without Losing Your
Sanity, was a little bit of an inside joke because I’m not sure that anybody on our staff
actually thought that we stayed sane throughout the whole process because there was a lot
going on. But it’s also meant to say, you know, I think
when you’re making modernization efforts you don’t have to go crazy and do massive amounts
of ripping and replacing. And at least for the District, we were in
a place where we didn’t have – we weren’t faced with the issue of having – to replace
a legacy system or a mature system or trying to replace a system. So actually this is the District’s journey,
which we were able to embark on and mostly complete really due to some unique and specific
circumstances that we were facing. And I’ll discuss the specifics later on. But we were also addressing existing business
problems with the modernization effort. So the obstacles, again that we were faced
with, was not that we needed to replace an aging system. So the agenda will be, again the introduction
of backgrounds, and then we’re going to present to you the new technologies. And we really are focusing a lot in this presentation
on the specific implementations that we did over the past 18 to 24 months and also providing,
hopefully, the background and the business case as to why we implemented these new technologies. And then of course we’ll do some Lessons Learned
and some Q&A. So first I always think it’s important from
the state perspective to give some demographics about the agency and the environment that
we’re doing our work in. So this is just some information for FY 2015. I believe it was through July because we used
this presentation earlier this year. But I do think one of the most important things
here to note is that 50% of our case management is done by private agencies. We have approximately 270 staff doing direct
service, and a total of 1000 FACES.NET users – FACES.NET is the name of our SACWIS system. So probably for a lot of states on the call
that may – actually may be the fewest number of users for a SACWIS system. But it does again give context for the District
of Columbia. I also want to give a little bit of background
on the D.C. CWIS which was originally implemented in 1999 and it was called FACES. It was a client server power builder system. In 2006 we really did our first major modernization. This was a very significant and a – basically
a re-engineering of the existing system – and we Web-enabled, Web-based the system in 2006
using .net. And as far as the – our SACWIS approval
goes, we are Children’s Bureau approved action plans in 2015, with three significant requirements
that are outstanding at this point. So this, for those that are interested, are
really from the technology background, this is the architecture and the infrastructure
of the FACES System. So if you – hopefully you can see this. If not I think you can blow up the PowerPoint
at some point and see – get a better representation of it. So I also think, you know, when we think about
modernization it’s also probably important I think just to say we didn’t starting out
taking our project saying we were going to modernize our system. This was not as, at the beginning, a modernization
“Title modernization” project. But when you think of what modernization is
it’s “A model of progressive transition from a pre-modern to traditional or traditional
to modern; to make modern in appearance, style or character update; to accept or adopt modern
ways, ideas or styles.” And all of us, most of us I’m sure who have
been involved in the SACWIS Child Welfare Information Systems world and have had systems
that have been around for a while, you realize that the technology that’s available now and
– to create these types of systems is a lot different even than it was in 2006, and
a completely different world than it was in 1999. And so there’s really – this is the time,
and it’s probably been this way for a few years, where there are really a lot of modernization
efforts that can be made using these new technologies, and without having to create a whole brand
new monolithic system. So in our experience, the drivers that we
had here in the District of Columbia was this really started in 2013, it was basically two
years ago almost to the dot today, and we had a visionary leader, Brenda Donald, who
is now the Deputy Mayor in the District for Health and Human Services, but she was really
changing the way our agency was operating and had a big vision for how we did our practice,
but also the support around the practice. And that was not just technology supports
but a lot of it she wanted to have new technologies that would support the work. But it was a complete encompassing idea of
how we really improve our system. We’ve also been under a federal lawsuit since
1989, and this is really – the lawsuit has really created a climate of compliance. And folks are really driven on these – meeting
these measures. And so we’ve looked at data a lot. We’ve been looking at data for years, and
a lot of that was really around the lawsuit. We also, our director created a strategic
framework which was to refocus and reframe the way that we were talking about our practice
away from the federal lawsuit, but into these more really strategic thinking, and having
some clear goals and objectives that we were aiming for. And just to go over them real quickly, they’re
called the Four Pillars. And the first pillar was to narrow the front
door, meaning we were going to remove children only when absolutely necessary. The next was that foster care would be a temporary
safe haven. So we didn’t want children to linger in foster
care, but we wanted to – if we needed to remove them for their safety, our main goal
was to get them back home or into a safe place as quickly as possible. Also focusing on the wellbeing and not just
the safety of the child, but their ongoing wellbeing, as far as education and mental
health and other things so that we would focus on that. And finally, the final pillar was exit to
positive permanency so that we – again, making sure that foster care was a temporary
safe haven, but that when we exited children it was to positive permanency, not aging out
or something like that. At the same time we were doing some significant
practice shifts, just really changed the way that we did our work as an agency. And the first was we were awarded a Trauma
Grant. And the grant was to implement a trauma informed
practice across the entire agency and so that when we are dealing with children and families,
we’re really addressing the trauma that they have experienced prior to coming into care. And the next thing was being granted the IV-E
Waiver. So we started being able to shift our practice
away from all of our dollars being involved with the foster care side and out of home,
but to also prevention, and using our IV-E dollars to prevent children from coming into
care. And that led to actually the bigger and bolder
challenge and this was in 2014 our budget for Fiscal Year 2014 had a surplus in it for
a number of reasons. One, we were successful in narrowing the front
door so we had fewer children in foster care but had budgeted for a larger number of kids
in foster care and those dollars were freed up. Under the IV-E Waiver we were able to negotiate
a new reimbursement rate with ACS that was actually going – it was retroactive for
two years. So we were able to claim backward for two
years and we ended up in a situation which rarely we’re faced with as state agencies,
but we actually had surplus funds that needed to be spent in Fiscal Year 2014. So the challenge was “How are we going to
spend those dollars to really further the work that the District is doing?” And finally, the driver was we did have a
mature CWIS. Our FACES.NET had been around and been in
use for several years, there was strong confidence in the functionality of the system, as well
as the data that came out of the system. It was Web-enabled so people could access
it anywhere they had an Internet connection. And in fact we – so much that it – you
know, folks were saying, “More things needed to go in FACES.” More things need to go in there instead of
like, “We need to get rid of that system and do something else.” So the challenge was “Brady, how are you and
your team going to spend this money? What’s your plan?” So we sat down in a room, we spent several
hours looking over what we knew to be existing business problems and how we wanted to build
on what we had and the strategic plan we came up with was; one, “Well let’s maximize our
existing IT investment.” We’ve spent money on FACES, it works, we’re
getting a lot of the data that we want out of it, so let’s just leave that and build
on what we already have. But with all these new practice changes there
also were coming, a number of requests to “We need this assessment in the system. We’re trying to assess for trauma and then
we want to be able to do other screenings and deeper assessments.” But you needed to do it quickly. So we needed a nimble approach to development. And with the focus on our lawsuit and compliance
we really weren’t getting the results that we wanted from the existing number of data
reports that we had out there. We were meeting some measures but there just
wasn’t a sense of ownership. And one of the things we really saw was the
way that we were reporting was so one-dimensional that it really wasn’t meeting the needs of
the agency. So we wanted to enable a greater sense of
data ownership and responsibility for the outcomes. And then finally, there were a lot of requests
for “We need mobile devices; we want tablets, we want smartphones.” And we understood that those devices were
only as good as the amount of work that you could do on them. And since our SACWIS and CWIS was not mobile
friendly, you just couldn’t load the entire application or the entire system on a smartphone
or a tablet that we wanted to really create some mobile applications. So we also knew that it was very important
that in all of these different initiatives we weren’t doing something that appeared to
be different, right? This was – we recognized and identified
the business needs, but we also recognized the need that this needed to be as seamless
as possible to our social workers, and that the number – the amount of work that they
had to do to use these new technologies really needed to be zero if possible, as minimal
as possible. So keeping with the idea this is all still
FACES right? It’s built upon the existing data that our
technology investment FACES, but we’re just using that system to drive other types of
activities and use it in other types of technologies. So we – that was our strategic plan and
we needed some solutions to do – to meet the strategic plan. And we came up with these were the solutions
that we invested in. First was the Avoka Forms Automation which
allowed us to have a more nimble approach, again to the types of practice requests that
were coming to us, rather than having to build a .net screen we could use the Forms Automation. We invested in the Birst Data Digitalization
Platform as a way to build a more interactive system for dealing with the data that we had
and we also built some mobile apps. And we’ll go more into detail with these in
a minute. But also at the same time, we still needed
to make changes to our – the SACWIS functionality or to the CWIS functionality, and we had a
major initiative going on with redesigning our case plan based on assessments that were
being used for our Trauma Grant as well as our IV-E Waiver and this was the CAFAS and
the PECFAS and the Caretaker Strengths and Barriers, and all of these replacing an existing
assessment so that we could have a new case plan based on these new practice changes. So it was a lot going on at one time, which
actually it probably was a little insane to do all of these things at one time, and in
a span of 18 to 24 months, but I guess I was saying that “Without Losing Your Sanity,”
because everybody seems pretty sane still. But the other thing we did to be able to do
multiple things at one time in the CWIS is we created the ability to do multiple development
streams at one time. And then finally sort of to me it’s like the
least sexy activity that we did that was probably the one that was the most important to really
get the buy-in and to be able to integrate these programs together, was the Secure Authentication
and the Single Sign On so that workers would not have to remember multiple usernames and
multiple passwords, which is one of the most frustrating things that we all experience,
right? So let’s at least eliminate that as a problem
when we’re introducing these new technologies. And so we did that and we also created a Single
Sign On portal which all of these – to access these different solutions and technologies,
you could go to one portal. So that actually leads – I’ve completed
my part with the introduction, and now we’re going to dive into the specific solutions
and we’re going to start with our data visualization solution. I’m going to turn this over now to Lori Peterson.>>Lori Peterson: Thank you Brady. Good afternoon, I’m Lori Peterson and I manage
the day-to-day activities of our Information Management Team. And just to give you a background on what
we do; currently we design and develop and maintain over 300 Crystal Reports in our system,
the data reports on key performance indicators for our consent order, our federal reporting
whether it’s NCANDS, AFCARS, or NYTD, and any ad hoc reporting we have. When we embarked upon this initiative to come
up with a data visualization we said, “What are we resolving here? What is the end goal for this? How can we advance our staff’s ability to
educate and the data driven decisions that they need to make on a day-to-day basis and
look at that data in a meaningful way?” We also wanted to reduce the burden on our
staff to create additional ad hoc reports because we receive a numerous amount of report
requests from all over asking us for data. So we – our current system is our Crystal
Reports System. Right now we have a lot of reports, as I mentioned,
we have over 300 reports in our system. Those reports are accurate. They present the data in a summary format. They are – they describe a particular activity
that we do in our system or a particular process that we do in our agency for our business
practice. But there are some limitations to those Crystal
Reports; there is limited data visualization capabilities; it requires end users to go
in and access multiple reports to gain the information that they’re looking for; there
was no ability to view trends across a period of time; and there was limited flexibility
to filter or breakdown the data as desired by the end user. This slide here is a representation of six
different management reports, Crystal Reports that we use for our visitation metrics. You actually would have to pull six different
reports, multiple pages, and to drill-down all the way to the details of these reports. Imagine all six of these reports sprawled
across your desk, pages and pages of summaries and details. This can be a daunting task at times; it’s
time consuming, it’s – you have to pull and print out multiple pages of reports, and
you can’t see the information all at once. The Birst Reporting System, which is our visualization
and our dashboard platform that we’ve created, it allows those users to take those six reports
and be able to see all of this in one single view. At a click of a button you can determine “What
– how am I performing on my visitation?” I can see all of the information, see my landscape,
drilled down to the user. It improved the efficiency for gathering,
analyzing and sharing information. It’s more real-time; it gets updated every
day. It reduces the amount of resource hours used
to fulfill any other ad hoc report request that I’ve mentioned before. The above goals enable us to have the right
information at our fingertips and the end user can be self-sufficient and own their
own data. So we took all six of those reports and we
put them in what we call a dashboard. That – those six reports with multiple pages,
many, many pages, can be visualized with all of these nice colors in one screen. So now I can see the performance metrics of
all six visitation metrics that we have and – at once, at a glance, as well as being
able to drill-down. As you can see at the top of the screen there’s
a Select feature that allows me to drill-down to a specific worker. And so I can take it and look at a unit level,
an administrative level, all the way down to an individual worker. The dashboards are interactive. If I select the name they will – the dashboard
below will respond accordingly. This is our Birst – BI, Business Intelligence
architecture. This is how we got to where we are. So this first layer is our data source. Normally your data is coming from – is useful
when you’re addressing the business questions and requirements. Currently our single data source is FACES
our CWIS, however there is an ability to expand to have multiple data sources. Layer two in this picture, it focuses on three
main processes; the extraction, transformation and loading. From the data source layered below, that data
is extracted, cleansed and transformed, after which it’s loaded in a targeted repository
which is our data warehouse. That’s still Layer 3. Our data warehouse is the Birst Cloud. Each night our data is extracted and uploaded
to the Birst Cloud where it is further processed in the data warehouse. So we had to take all of our data, our existing
tables within the FACES database, the CWIS database, and we had to cleanse them and cleanse
the data and format it so that we can have our data marked to have our attributes around
a single process. And you’ll see that in the next slide; how
it ended up. Excuse me. So our data warehouse then, after it transforms
and uploads that data, the data warehouse goes to the end user layer, which is how they
see the actual dashboards. So when we talk about a data warehouse, when
you actually do the data modeling, which we did for all of our different practices, whether
it was intake, case management, we had to actually reorganize our data. And this is just a pictorial of what happened. We had to actually have attributes around
all of those data to come up with a single process. This is a sample of our Data Dashboard. To-date we have approximately 40 key performance
indicators. Those are identified at the top left where
you can see the numbers in red and blue. The blue indicates that we’re in compliance
with the performance measure, red gives the percentages. We actually have hyperlinks on the key performance
indicators. You can click a hyperlink to drill-down to
the details. We have different visualizations, whether
it’s a funnel. Obviously when you’re on the green section
of the funnel you have time to complete an activity. As you get closer and closer to the due date
of an activity you get closer and closer to red – so you don’t want to get into red. And then you have all of the information on
the right hand side of the dashboard where you can actually click and see specific information
related to a particular worker. Other great features about this data visualization
tool is we’re able to export reports in different formats. So any of those visualizations that we’ve
developed or any of those dashboards that are available, they can be exported into any
of these softwares whether it’s a PDF, PowerPoint, Excel or Word. And so that’s pretty useful when you’re preparing
for a presentation or doing your supervision with your staff. You can actually export those charts and those
visualizations and have a discussion. You don’t have to recreate the wheel. Additionally, you can schedule reports. The report scheduling is pretty important
and has been a great feature that staff are excited about so each morning they don’t have
to go into the visualization system and pull the same data. Once they’ve scheduled that report they can
send it as often as they want and it’s sent via email. So during our Birst implementation, as I mentioned
we have over 40 key performance indicators. Unfortunately I don’t have the number of dashboards
that that’s the equivalent to but we took our practice from the front door all the way
up to our populations served. Those indicators are still – we’re still
adding to them. But some of the lessons learned as we were
developing our Birst System, we needed to have earlier involvement by our program staff. So we wanted to do this quickly. We got it done in about 16 months to-date. But we wanted – we needed a starting place. So because we were familiar, we developed
over 300 Crystal Reports. We knew the activities of the agency and the
reporting requirements. We started with our compliance reporting that
we needed for our court monitor as a guide, or as a way to start developing the dashboards. But as we moved away from compliance driven
agencies and more about serving our families and children we probably should have discussions
with our staff – our program staff on some of their needs and not necessarily be so compliance
driven. So we will want to have them involved earlier. Also, develop a communication strategy. This tool is so awesome, it’s so interactive,
all of the colors and the data that’s at your fingertips, people get so excited and are
awed by the information. But we should have communicated it a lot better
and just advertised it a lot more to get people on board in the beginning. Also, the technical staff training; it would
be ideal if that technical expertise developed in-house prior to rolling it out, or actually
even put in your plans, account for that learning curve. Because these technical skills that are required
for building this, we learned this while doing it and in-house, but that wasn’t factored
into the timeframe for releasing this system. The next step for our Birst system is to continue
to adopt user adoption strategies. Like “How do we plan to work with the program
staff?” With all of this great data at your fingertips,
how do we plan to strategize on how you should use the system? So we’re going to continue to work with staff
on that. We’re also going to expand our dashboards
to incorporate practice changes. We’re currently changing our safety and danger
assessment in which we’ll then create a dashboard to reflect that. We’re going to have ongoing assessment and
opportunities for future dashboard development. And so we’re excited about continuing to work
with that. And with that said, that’s the end of my presentation
with regard to our data visualization. And I’ll now turn it over to Eldon Harmon
so can talk about our mobile strategies.>>Eldon Harmon: Good afternoon everyone,
my name Eldon Harmon and I’m IT Manager with CFSA. And I just want to talk – I’m talk a little
about the mobile application. So I’m going to begin the presentation talking
about the business requirements for the mobile app. And it started with equipping employees with
mobile devices. The goal is to increase productivity, and
then also enable access to external applications such as Google Maps and also Google Translate. And once we deployed the mobile devices, we
now started to look at the needs of social workers. Social workers need access to case notes while
in the field. So the day in the life of a social worker;
they’re at a client site, they whip out their notepad, because they put – they maybe jot
down some notes earlier, or maybe they would go in and put some information and look in
the laptop – look in the laptop – for information that they need related to the
client. So they definitely needed to have access to
case notes while in the field. Also, social workers require a smaller, easily
accessible device. So you probably can imagine they’re talking,
they’re in front of their client, and this is not a situation where they want to whip
out their laptop, or even they might be in a situation where they are in an unsafe environment
and they don’t necessarily want to whip out their laptop and get unwanted attention. Another need is that they needed Wi-Fi or
Internet connectivity. The laptop would require Wi-Fi access or a
connection to the Internet, whereas in some situations maybe on the train or on their
way home at night, they may need to have access to Internet connectivity and they don’t have
that when they have the laptop. So we needed a solution that would enable
social workers to; one, capture notes while in the field; easily access case file information;
and also easily update/add contacts – these were some of the basic requirements that we
needed to – when we thought about creating our app. And this is some of the information that we
used to actually start the design of our mobile app. So now we’re at a point – or at least in
this presentation – I’m at a point where we decided that we’re going to deploy a mobile
app, but we don’t necessarily have the information to deploy the app. So what we did was we created a RFP, we reached
out to vendors, and we also worked with the Office of Chief Technology officer, we call
them OCTO. And we worked with OCTO and the vendor to
identify our needs to support or stand up a mobile application. And from that, working with the vendor and
OCTO, we identified that we needed security, encryption and the ability to remote wipe
data. So if the phone was lost or stolen the data
was encrypted, and if it was lost we can remotely wipe any data that was on the phone. We also wanted to deploy this application
internally to all our employees, so we needed an internal app catalog to deploy this application
to our employees. We also need a single sign on solution for
a login session. And I always thought Single Sign On was only
for Web applications, but it actually turns out that mobile applications require Single
Sign On because if you close out the application and you go to another one, well you still
want – you don’t want to have to always have to login with your username and password. And Single Sign On allows that, as well as
allows you to put in a username and password and secures the application. We also needed restful application programming
interfaces, API technology, so we can have that bidirectional communication with our
databases. And once we have APIs we have to have a way
to manage those APIs. And our API management system would allow
us to manage those APIs. So this slide, really I’m just trying to identify
the actual technologies that we used. We used AirWatch MDM, our Mobile Device Management,
to secure and manage devices, to do that remote wipe that I had mentioned earlier, to provide
security, and also to push out the application to all our users. We used SecureAuth to enable secure access
to the applications. This is where – what I was talking about
before, about the Single Sign On, we used SecureAuth for Single Sign On. This will allow the users to put in their
username and password, and also that multiple session access that I talked about with mobile
applications. We also used it for other apps within our
ecosystem, we use Single Sign On SecureAuth. And for our application we call it MFACES,
it’s powered by ten APIs that’s compatible with iOS and Android platforms. These ten APIs again, allow us that bidirectional
communication with our database. And then we also have to manage those APIs,
CA Layer 7 API Gateway. And this really allows us to protect or to
secure the APIs so that not everyone can access the APIs. We actually will provide them a key to access
those APIs through our CA Layer 11 – Layer 7 API Gateway. And one other thing that we do with the Gateway
is that we can have those APIs directed to different environments. So recently we had a situation where we needed
to have a user look, not in our production environment – or a test user, not to look
at our production environment, but to look at our pre-production environment. And we used Layer 7 API Gateways to do that. And the image to the right is really just
showing you the different technologies that we have. So now that we learned how to stand up a mobile
app, we have the different technology that we put up, the SecureAuth, we put in AirWatch,
but now we have all this infrastructure in place, we went ahead and started to build
the app based off of the information from focus groups and from our users, and making
sure that we take in the needs of our social workers, and we created this app. So now the MFACES app will allow social workers
to review caseloads and assignments, record visits, map directions, receive alerts, take
investigations, access critical phone numbers and update contacts notes. We also – and this slide doesn’t tell all
of the background information and the blood and sweat and tears that went into developing
the app, but we have different environments that we use to test the app; we have our UT
Environment, which is our Unit Testing Environment, we have our Pre-production Environment, and
we also have our Prod Environment, which we view iterative development of the app so that
we can ensure that the testing is done before they go into production. Okay, Lessons Learned. So the first lesson is – or at least the
first bullet that I put in here is that you need to know your users. And I started off this presentation talking
about the needs of the social worker, and that’s really how we came about developing
the app is trying to satisfy that need for the social worker to be able to go out in
the field, access – to work with their clients and to be effective at their jobs. The development process is iterative. We’re constantly learning. As mentioned in a slide earlier, that, we
had to learn what technologies were needed to stand up the mobile app. We are also learning different – better
processes to actually make the app more efficient. And we use those different environments to
do that. Managing different technologies. I put a bullet here for managing the management
of different technologies, and the reason I say this, it may not come across very clear
in the bullet, is that at least with Android, and I think when we go to iOS, when we’re
dealing with the multiple technologies, for example AirWatch, SecureAuth and Android,
their Android OS systems, they all have different updates. And one situation that happened to us is that
our AirWatch solution didn’t really play well with our Android updates. And as a result all of our users had to wipe
their phones. We had to wipe each of the users. We had to come in, we had to communicate – put
the communication out to all the users that they needed to come in and get their phones
fixed by us or they may end up wiping their phones. And it was something that we didn’t want to
go through but we had to go through. It was a hard lesson to learn, but we learned
it. And going forward we would definitely do it
differently. I also have a bullet here for researching
security methods early in the development process. A lot of the technologies that I mentioned
earlier it’s really around security and it’s really trying to, without putting that
– those technologies up front in the beginning, it would have made it very hard to do it in
the back end. So definitely research security methods early
and in the development process. Communication is definitely key for success. You’re developing a great product and no one
will know that it’s a great product if you don’t communicate that this is a great product
and that it’s coming out. Next steps; updates and testings will occur
in development environment. The reason why I put this bullet in here is
because of that same reason when I talked about iOS or Android OS system not playing
very well with the AirWatch is that that went straight into our production environment. That should have went into maybe our pre-production
environment or our UT Environment prior to going into production. So going forward, next step is to ensure that
all of those updates go into like a testing environment and that we will use those environments
prior to going into maybe our production. This is a hard lesson that we learned early. Work with focus groups for future enhancements. So the goal here is that we ensure that the
app is effectively used and is effective for the users so that we’ll continually, you know,
get from – get the information from the horse’s mouth and find out what the needs
are and what’s necessary to make the app more effective for the users. Develop a process for incorporating user feedback. So you would think these two bullets are the
same, but they’re different because this bullet I’m talking about incorporating user feedback
without even knowing that they’re giving feedback. So we recently started using Google Analytics
to capture information like “How many users are logging into certain pages,” or “How many
users are actually using the app?” So this is information that we’re capturing
that they don’t even know that we’re capturing. But this will help us be more effective. So for example, we noticed that they’re using
a certain page very often, we can probably focus on making enhancements to that page. Or if that page is no longer being used maybe
we no longer need to use that page. So we can make enhancements to the applications
by using Google Analytics and getting that feedback about our users. Security is always increasing, it’s always
changing, so we definitely want to keep an eye out for any new security updates and any
way that we can make the app more useable for the user. And last one I have here is advertise, advertise,
advertise. I think it’s very important that you advertise
and let everyone know, setup those groups and talk to everyone and let them – like
the different stakeholders, and let them know that this is something that’s coming out. And have them also advertise your product
because if you have this great tool that can make people’s lives easier, its better if
they have it in their hands. So that concludes my portion of the presentation. I will now hand it over to Spencer Wilder
who will talk about Avoka. Thank you.>>Spencer Wilder: Good afternoon. Again, my name is Spencer Wilder, and I’m
the Application Supervisor here with the District of Columbia. I know that Brady talked about it early on
in the presentation but I want to set a little bit more context in terms of what happened
with Avoka and why we were led to actually start a Forms Automation process. So with the shifting priorities, we’ve talked
about the IV-E Waiver, we’ve talked about trauma, but at the end of the day it really
changes the lens through which we were viewing families and assessing families, and ultimately
linking them to service. So that inherently meant that just on volume
alone we needed to be able to see things from conception to market. So at the same point we also knew that our
biggest challenge to actually getting a project from conception all the way to market really
rested in gathering requirements and the dev time. Spent a lot of time in a lot of closed doors
pulling at each other’s hair and fighting back and forth trying to make sure that our
concepts were clear, trying to make sure that we had accounted for every different nuance,
trying to make sure that we got it right the first time and that we didn’t have to go back
and do any rework. And so it really began to hempen how we were
able to conceptualize and how could we move things from thinking and actually putting
it into production. We also knew that the federal regulations
required SACWIS to be the system of record. So even if we were able to get workers to
enter in information, we knew that that information and that data had to come back into our system
and we had to be able to record it and report on it. We also knew that we had to match existing
supply to an increasing demand. I mean the photo to the right is not my office,
but my office almost did look like that at one point because in a lot of ways you were
getting information about requirements or enhancements or things that people want to
change in our SACWIS system in hallways, you’d get them in passing. And so there was an increasing demand to get
a lot of this information in and figure out a way to draw a straight line between our
practice and what our commitments were. What’s not on the slide is that we also recognized
that we had a changing workforce. We knew that folks were coming in the door
now and they were more computer and smartphone savvy. So they’re part of the app generation. So they wanted things now to be able to access
data and to make decisions on it. So all of this kind of set the scene for us
thinking out of the box and really trying to determine the best way for us to meet that
increasing demand. So we came up with Forms Automation. I know Mr. Birdsong, at the end of the day
would always say, “You know no matter what we’re doing new, it really is just a form.” And so a form. And we need to be able to standardize the
way that we collect data, the way that we store it, and then the way that we report
on it. So why not take a chance and figure out if
we can’t figure out some software or identify a software that could make that form an editable
document where we can track things and really meet some of our needs. So not to regurgitate a lot of what has already
been said, but really just to drive the point home that there are some common themes and
there are some common components on the IT side that we leveraged and we used in different
ways to meet multiple needs. So we’ve already talked about Single Sign
On which reduces the need for workers to reenter usernames and passwords. We’ve talked about developing APIs and using
those APIs to bring information from our database into what other technology we need to use
it. We’ve talked about incorporating cloud-based
technologies to store our data and to make sure that we can always extract it and bring
it back into our database. But the big one for us in terms of the Forms
Automation piece is really the idea of the rules engine. You know, with SACWIS, with our FACES system
being a mature system, a lot of the code that was used that governs the functionality is
written onto the screen. So if you have a data element, the code of
how the data element is supposed to function and whether or not it’s supposed to relate
to a different screen is written on the screen itself. But now with the rules engine you can develop
those screens independently of one another and the code actually sits on top of those
screens. The codes govern how those screens operate
and how those screens function. So we knew we wanted to take advantage of
that. After landing on Forms Automation, and we
use a software called Avoka, a couple of things; we knew we were able to meet or complete customizable
forms which operated just like FACES screens – there was no difference; we were able
to easily integrate it with FACES.NET, here again pulling the data that’s entered through
a Forms Automation software and pulling that back into our database so that our reports
don’t skip a beat. We still were able to honor the federal requirements
and support the case management processes. It gave us an opportunity to let the process
breath. A lot of this was really around making sure
that workers could do their job more effectively. And we had a lot of different themes and paradigms
that we weren’t even sure at that particular point, would work together and how they would
work together. But we knew at the end of the day that at
least Forms Automation gave us an ability to make changes on the fly. At the same time we were able to control security
and access; we were able to really frame the data storage, so we were able to pull from
the cloud back into FACES.NET; we could do approval processes so them being able to have
a worker complete a form and then send it to a supervisor for approval; automated workflow,
so that is from A to Z determining how that form is going to travel throughout your agency;
developing an alert system for completing tasks. I know on an earlier slide when you were showing
the mobile app we had a reminder there; workers like to be reminded and like to get information
about what’s coming up and what they need to do, and draw their attention to what’s
the most immediate need. Avoka allows us to do that. And last but not least, we can actually build
in calculations so that we know where information is going and we can determine our next move. All of our forms right now are supported by
both – on Android and iOS devices. And we know ultimately that it reduces the
development time, the project cost and the staff resources. So as an example, this isn’t a live demo of
our Forms Automation, but what this does is it highlights what it actually looks like,
and from a user’s perspective, what you would be able to do. So if you’re looking here, when I login to
the form, this is our Strengths and Difficulties Questionnaire. This is one of our core components and screening
assessments for our Trauma Grant. So this questionnaire actually drives, it
assesses emotional and behavioral issues on five different scales. And so based on how you answer these questions
it actually drives the referral for a deeper assessment. So if a kid is presenting certain issues,
you’re able to document that, we do the calculations in the background and those calculations actually
rollup into a threshold. And then we tell you whether or not that kid
is in need of further assessment. So from the API perspective when a logger
– when a worker logs in, they’re able to put in the Client ID, and that Client ID calls
to our database, it pulls up the client name, the child’s gender and the date of birth. And then from there the worker’s responsible
for filling out the screening assessment. We have standardized all of their options. It’s on a Likert Scale, so the values range
from Not True to Always True. They actually assess behavior across five
different areas, so you’re talking about conduct, hyperactivity, peer problems and pro-social. And at the end of the day we’re able to calculate
the total difficulty score and I know you can barely see it, but at a score of 20 we
actually build that threshold in so that you can have a note instructing the worker that
because their behavior is abnormal you really need to send a referral to DBH, which our
Department of Behavioral Health, for further assessment. So I know that’s a very simplistic kind of
view, but what it does is it allows us to capture the most relevant data and then move
it along without having to write lines and lines of code. So in terms of where we are today, we’ve implemented
Forms Automation through Avoka in 2014. It really reduced the reliance on both manual
and alternative databases. We’ve found out that there were a lot of staff
– not as it relates to client related data – but there were a lot of databases – whether
they were Access databases or folks were using Excel – you know, just to document and hold
on and be able to report out on their daily activities. So now – instead of having to do that – we
can turn that information into a form, send it you, allow you to access it and now you
have a standardized way of collecting all the data and rolling it up. The really big hit for us was that it reduced
the time to market from two to three months to two to three weeks. So, you know, my coworkers will laugh, but
I call myself Mr. SDLC because we’d had one way of actually doing our development. We did the development life cycle. And so with that, we’re gathering requirements. We’re getting levels of estimate. We’re moving it to a developer. We have a whole series of testing environments
that we’re working through. And that process can be quite lengthy. But given the same level of effort – the
same estimates, the same staffing resources – if you control for all of those things,
we can actually move from concept to development in about two to three weeks without there
being any impact on product quality. So we’re producing a high quality product
and – at the same time – we’re significantly cutting back on our development time. At the present day, we’ve developed 17 forms
across eight different programs and administrations, and it’s turned out to be a more effective
and efficient way to track those things that we weren’t able to do previously. So in terms of lessons learned – which is
like if I knew then what I knew now – the important thing to remember is that forms
automation, it may speed up your development process and your project process, but it doesn’t
replace it. You’re still going to have to go through those
same steps. You’re still going to have to do requirements,
and you’re still going to have to do a level testing. And it’s going to be very important that you
approach it and think through it as best you can on the front end. Work flow clarity and changes, knowing how
you want that form to operate and how you want it to move throughout your agency or
your program is very, very key. Avoka will allow you to change, but you could
spend a lot of time rerouting forms that were supposed to go to Destination A now to have
to go to Destination B. You’re spending a lot of time doing rework. It may sound counterintuitive, but you really
need to think backwards in terms of all of your data. You need to think about what the end goal
is, where you want that data to end up. Does it trigger other pieces of functionality? Do you only want to be able to report out
on it? Is it used in any other shape, form and fashion? And then think backward all the way to implementation
and how that data should look on the form. And lastly, align those data fields with your
existing database to ensure that once the data comes back in, you can report on it,
and you’re not going to spend time trying to translate and change data around. In terms of next steps, we really want to
move forward with fully integrating these forms and the forms automation platform into
FACES so that you can navigate to it through FACES.NET. And we want to continue to expand the forms
automation platform so it includes more case management tools – and expand more functionality. The examples that I’ve used are the strengths
and difficulties questionnaire. Right now, that current questionnaire, it
just identifies symptomatology and then it leads to a referral. But ultimately, you want to get that information
back from that second assessment and then be able to roll that into our case plan document. So right now, we’ve done Phase 1 so folks
can enter it, and we can report out on it. But now, we want to go a step further and
actually link that to other pieces in our SACWIS system so we can have a more robust
process from beginning to end. So with that, I’m going to turn it over to
Mr. Birdsong. I’m going to have him go over some very general
efforts.>>Brady Birdsong: Thank you, Spencer and
everyone. And as you can see, the way that we operate
in D.C. is that we move pretty fast and move through things pretty fast. We did all these enhancements and initiatives
in about 18 to 24 months. And we did our presentation in about an hour. So that’s a – we just rolled through. So one of the things – some of the general
lessons learned that we have up here – and first, I’m going to step back and say I think
one of the things, too, is we really did take on – as you all can hear, and I hope you
can understand – a lot of new initiatives and in this short amount of time. And I think there was a consistent theme throughout
the lessons learned was almost that we didn’t have enough time to – I mean these have
been successful implementations, but there was a lot of really fast moving because one
of the things was not only were we trying to do a lot, we also – because of – I’m
sure other States are the same way – we had – the budget was only available to us
for a very limited amount of time. And so we focused in on implementation of
these modernization efforts. And we’re getting really good use out of these,
but we still need to continue to ensure and push that we’re getting the full use out of
this investment – that we expect that we have – and the value out of these investments. So again, so the general lessons learned,
and you know, is have a destination – which I think we did. We knew what we were going to – what we
wanted to accomplish. And we had a plan to reach that destination. I’m going to just talk a little bit more about
just being comfortable in the messy middle and then communicate, communicate, communicate. And the visual below that is – it might
sort of sound like, you know, that we had this very level playing, you know, path from
our initial ideas and the plan to the end. But there was a lot of rocky places in between
and there were a lot of ad hoc conversations that affected the plans and decisions that
had to be made because these were new technologies for us. And we were dealing with vendors and integrators
for all of them. But it was a heavy learning curve for a staff
of people that primarily had been SACWIS and .net focused for over a decade. And so I applaud the team that just presented
their information for the amount of work that they have done over the past couple years
and all of the new things that they’ve had to learn. I think we may feel like we’ve spent a lot
of our time in the valleys that’s represented on the reality slide, but I think we’ve really
– at the end – we’ve accomplished a lot and are at a peak versus a valley right now. So that’s actually going to end our formal
presentation, and so now, we’ll open it up to – I think – Joyce or Kristy will open
it up to questions. And because we are all in one room, if somebody
asks a questions that is specific to one of the presenters, it may take them a few seconds
to get to the phone. So please go ahead.>>Joyce Rose: All right. Thank you, Brady. And I certainly want to thank all of your
presenters. They did a marvelous job. Before we start the Q and A session, I just
want to make two points. The first one is that I want…>>Coordinator: Hello, Joyce?>>Joyce Rose: Yes, hello.>>Coordinator: It’s okay.>>Joyce Rose: I’m sorry. I basically forgot to take us off of mute. Lesson learned. But before we start the Q and A session, I
want to issue a reminder to the attendees that you can enlarge any of the slides containing
graphics for better viewing. And secondly, I want to just issue a reminder
that the Children’s Bureau is not promoting or endorsing any of the products that were
mentioned. Those were simply the ones chosen by D.C.
as they modernize and implemented either existing or new functionality in their FACES application. So with those disclaimers, let’s turn it over
to the discussion. And do we have any questions from our attendees? Kristy?>>Kristy Stankovich: Hi, yes. We have our first one over the chat feature. How many developers, business process analyst
staff and testers do you have?>>Brady Birdsong: Well, let me say one thing
is as District FTEs, we didn’t increase our District state staff at all during this process. And so we have – we actually have a staff
FTEs of 27, but that’s including the supervisory staff, administrative staff, trainers and
some help desk staff. So we actually don’t have any – we have
some infrastructure. We have three infrastructure people on board. And we have a vendor that has – this is
just on the SACWIS side, though – approximately ten staff that are doing development and the
design and database administrator on that side. And then the vendors that came in were probably
only about five to ten additional resources doing the integration of the solutions that
we talked about today.>>Joyce Rose: No more questions, Kristy?>>Kristy Stankovich: Sure, I just got one
in. I would love to learn more information about:
functions, about the mobile app that allows currently, as well as how well those functions
are used by social workers in the field, and what functions D.C. would allow in the mobile
app. So there’s a three-part question, and I can
repeat that if you’d like.>>Brady Birdsong: Okay, we may take them
one at a time. So I think the first question, though is what
was the functions that were currently allowed in the foster parent app – and I mean in
FACES and our SACWIS mobile app – which I just highlighted. We’re also building a mobile app for foster
parents right now. So I’ll turn it over to Eldon Harmon to talk
about what the functions are in the existing – in FACES.>>Eldon Harmon: Sure. So at a high level, what the functions are
is that you can add contacts. You can put notes in there. You can track notes. You can also look at the child information. So if you have a child that you’re interested
in, you can look at their information that’s pulled from the FACES system. And then I believe you can also drill down
and – well, a feature that’s supposed to come in later is to take the pictures. But we don’t have that currently…>>Lori Peterson: We have that.>>Eldon Harmon: Oh, we do have that.>>Lori Peterson: We have that currently.>>Eldon Harmon: So we have that for investigations
where you could take – you can go in and take pictures. And that’s kind of like the high level of
stuff of what we’re able to do with the – the high level functions at least. Oh, there are also maps that you can use as
well.>>Eldon Harmon: Yes.>>Brady Birdsong: So I think the next question
was the type of usage that we were getting from the mobile app. And we’re really working right now on getting
solid metrics from the Google Analytics to really understand how its penetration into
our user market that we’re getting. But I believe it’s – during any given week
– it is 30 to 40% of folks with user accounts actually use the mobile app at some point. We have – from looking at the data right
now – we have some users who are very, very heavy users and actually enter – interacting
with the app in a much more way of recording information. I think some of them use it really just to
get information about cases, to maybe – as they said – there’s the mapping capability. So you can map out your visits, like, looking
at what kids you have to visit, so where does it fall on a map so you can schedule that
way. And then I believe the final question, Kristy,
was it what will we allow in the future?>>Kristy Stankovich: It stated what functions
would you like to allow in the mobile app?>>Brady Birdsong: Well, I mean that’s an
interesting question. So I think there’s – you know, one of the
big things is how do we use it for photographing kids mainly for a profile picture. There’s – we also – as Eldon said – we
are using it for photographing as it pertains to an investigation. But we really don’t have a District-wide policy
on how our foster parents and resource parents or social workers can actually take pictures
of kids. So that’s something that we’re working on. We really are trying to think – when we
created the mobile app, our idea was what are the activities that get done out in the
field, right? Knowing that we don’t case plan. A worker is not going to case plan on a Smartphone. It’s just too robust of an activity to do
there. So we really looked at the things that you
would do while you’re out of the office and not at a desk and working on a laptop or a
machine. So that’s why we did the app. That’s why we gave them schedules – I mean
the map – gave them schedules. We gave them the ability to record a contact. So we’re still also working with our staff
to say, “Where should we take this – right – next?” But I think a logical activity would be how
do you do a safety assessment in the field because those are things you’re doing face
to face on site in a real-time moment, and they want access – or I think there will
be a desire in the future to have access to our safety assessment and safety screening
– as well as perhaps getting the ability to have clients sign off on a document or
activity that’s in the – that the worker is completing. Any other questions?>>Joyce Rose: While waiting for someone else
to submit a question to the chat feature, I have something to ask you. And that is you certainly implement a lot
of new or changed technology from business intelligence, data visualization dashboards,
to forms automation to a mobile application. Can you speak to how you organized your end-user
training for all of that new functionality?>>Brady Birdsong: So, you know, we did a
number of different things. So with – let’s say there was not a one
size fits all training that we did. We actually did some new types of training
and new methods of training. But I’m going to talk about Burst first. And one of the things that we did with our
data visualization data dashboards was we didn’t want to train this from a technical
perspective because very little about this is technical. Right? It’s taking the data that was already there
and presenting it in a different way and adding similar functionality about how you drill
down. So Lori and our training supervisor, Belinda
Barton worked really closely with the stakeholders. So when we were releasing our CPS dashboard,
we worked with the leadership in that administration and said, “How do you want to use this with
your staff,” so that the training would be focused more on the usage at that level than
a technical… And so we partnered with them, and we’ve
looked at a number of different ways to get that information out – whether it’s bringing
them to a class or we go out and we take it on the road. We’ve done the same thing with the mobile
apps. But we’ve also done a webinar with the mobile
app and asked people, you know, they can stay wherever they are, call in and we’ll do it
that way. The forms automation is actually – the stakeholders
in the audience for those forms have been actually very specific. It’s not been something yet that we’ve done
an agency-wide form. So that’s been training at a very focused
user group. But also with that idea, we are automating
forms that are owned by a business group, and we’re really partnering with them – too
– to say, “We’ve automated the form for you. Now you train the people that need to be trained
on how to use this form, and we’ll be there as the technical folks to support it.” You know, one of the things that – and it
may sound sort of crazy that it’s taken me about 14 years to realize this – but, you
know, these technologies and these implementations are really solving a business problem. Right? They are technologies, but it’s not a technical
project per se or the end result. And so I think we have – in the District
at least – anything that’s new has been seen, “Oh, that’s an IT project,” and where
it’s like, there’s a technical solution that supports a real business problem. And so we need to be better at communicating
that this is a business solution, not a technology. And so I’m saying – I’m bringing that up
as an example because the past – with these new innovations, we’ve really tried to engrain
that a little bit more in our own activities that we’re partnering with people to make
it – to help drive the fact that this is solving a business problem. And it’s not a technology solution that we’re
forcing onto people.>>Joyce Rose: Thank you. Kristy, do we have any more questions?>>Kristy Stankovich: We do have one more
question. Did you write the mobile app or just delivered
data into an app created by an outside vendor?>>Brady Birdsong: I’m sorry. Can you repeat that?>>Kristy Stankovich: Sure. Did you write the mobile app or just deliver
data to an app created by an outside vendor?>>Brady Birdsong: No, our vendor system integrator
along with our tech, they wrote the app for us. So the app exists, and then we use APIs. When the app is being utilized, APIs call
data from the FACES system, and it shows on the mobile device. It’s not stored anywhere outside of our database
– if that answers the question.>>Joyce Rose: I suspect that question was
really focused on commercial off-the-shelf products, a COTS step – solution…>>Brady Birdsong: Okay.>>Joyce Rose: …versus written in house.>>Brady Birdsong: Yeah, I don’t believe there
is any COTS solution for child welfare mobility that I know of.>>Joyce Rose: Thank you.>>Brady Birdsong: Yeah.>>Joyce Rose: Kristy?>>Kristy Stankovich: That is all for now.>>Joyce Rose: Okay. Well, let us then move on to our today’s conclusion. And first of all, I want to thank Brady, Lori,
Eldon and Spencer. That was an excellent presentation. And Brady, if you would advance the slide,
please? So we hope that the information shared with
you today was both informative and valuable. As a reminder, please remember to register
for the November webinar once the announcement is released. Additionally, if you have any questions regarding
today’s topic, would like more information about any of our scheduled webinars or would
like to volunteer your site as a topic presenter, please do not hesitate to contact me at the
email listed above. Again, this webinar has been recorded and
will be made available online. When it is complete and posted, we will send
a message. We have a SACWIS managers’ listserv with
the link. And that concludes today’s webinar. Thank you for attending.>>Coordinator: Thank you for your participation
on today’s conference call. At this time, all parties may disconnect. END

Leave a Reply

Your email address will not be published. Required fields are marked *