search

CDCgov / prime-reportstream

ReportStream is a public intermediary tool for delivery of data between different parts of the healthcare ecosystem.
https://reportstream.cdc.gov
Creative Commons Zero v1.0 Universal
72 stars 40 forks source link

Onboarding Internal Tools and Improvements #2470

Closed MauriceReeves-usds closed 1 year ago

MauriceReeves-usds commented 3 years ago

This epic will be a collection of internal facing tools for the onboarding team, specifically centered around the process of onboarding and supporting both senders and receivers. I'd like to enumerate a set of tools that we can build as an iteration, and then start collecting some feedback and ideas for a second iteration.

fysa: @Adrian-Brewster @anshulkumar-usds @rachelhanster

anshulkumar-usds commented 3 years ago

Come thoughts on onboarding operations. I phrased some of these as problem areas, and not necessarily as ideas or solutions so we can all brainstorm.

  1. Sender Onboarding via a more self-service model: So far, Jim and I have held several "Intro to RS" type kickoff sessions for potential and prospective senders. These sessions have become very routine now and follow a set of points we shared with the senders. Hence, a level of automation and self-service-ability can be introduced here. For example, we can create a recording / video / FAQs for these senders so that they can educate themselves on us, our platform and service and next steps. @BerniXiongA6 may be able to help us here with content development.

  2. Sender Onboarding Form / Questionnaire: Similar to our state intake form, we need to have something for sender onboarding. This was ot prioritized before due to the very low number of senders in the queue. While the senders are still few, our product has reached a maturity level where we should have a formal intake process for senders. Some of the senders are more established companies like ImageMover and InBios, while others are startups and have ways to go before receiving FDA clearance (e.g. Xtrava, Intrivo). Furthermore, including the small facilities currently supported by Sender-Automation, we need to develop a dynamic form that caters to a few use cases and type of sender.

  3. CLIAs: States are becoming more and more demanding on the immediacy and accurateness of CLIAs. When onboarding senders, we advise them of our commitments with states around reporting CLIAs ahead of time. Currently, the process to report CLIAs to states has transitioned thrice from James > Anshul > Adrian, while remaining largely intact in its manual and burdensome nature. We need to find a way to automate the reporting of CLIAs to states. Additionally, we also need a process to handle states' questions about these CLIAs such that we can validate CLIAs with senders and respond to states in a timely order. (something like a CLIA database that gets enriched every x number of days).

BerniXiongA6 commented 3 years ago

Hi @anshulkumar-usds !

1) Love the idea and I'm totally aligned with designing and developing that type of content since you've identified it hasn't or won't change much.

For #2 and #3, I'll share these points/ideas with the design team too so that we have them on our radar as we prioritize. Will circle back soon. Feel free to do the same.

MikeC-A6 commented 3 years ago

@MauriceReeves-usds Any thoughts on including the zip code file maintenance in this Epic? I love the idea of - if a zip code is not in a table:

rhood23699 commented 3 years ago

@MauriceReeves-usds LADOH has requested an alternative to how we are currently validating new Senders.

Background: Some states want to receive PROD data for validation before allowing a new Sender to move to Production. Some will allow de-identified data for testing, but most want to see untouched unaltered data because too many times they have received bad data because testing with test data only isn't a true picture of what might happen in production.

Problem: We currently move our schema into Prod and LADOH blocks all messages from the new Sender based on the MSH.4, so they can validate them without the data hitting PROD. Then when the messages are validated and OK'd, LADOH must remove their blocking code before we send allow our Sender to transmit more data.

Request: Can Production results be routed to LADOH's test environment instead of their production environment? This would prevent LADOH from having to block messages for validation, and then unblock the messages once they are validated. If so, can this be a simple setting that could be changed via a CLI command?