Stream: Covid-19 Response
Topic: The SANER Project
Keith Boone (Mar 24 2020 at 15:54):
The SANER Project had it's first meeting this morning at 10:00 eastern. I'll be posting minutes of the meeting on the project wiki site shortly, and a link to them here. I'm starting this stream for SANER Project discussions.
Keith Boone (Mar 24 2020 at 20:09):
OK, Meeting minutes are up. You can find everything you need on the Wiki Page https://github.com/AudaciousInquiry/saner-ig/wiki . I have one more automated generation to perform before I cut loose from that system to make it easier for multiple people to contribute using IG Builder. As soon as I get that build working, I'll start giving out committer access to those willing to contribute to this effort.
Keith Boone (Mar 24 2020 at 20:11):
I'm interested in thoughts from others about how to deal with the fact that it's MUCH easier in SUSHI to build profiles and examples than it is using other tools, and yet there needs to be an extra build step before sending things to the IG Build, which makes automation challenging.
Anyone know of a way to automate Sushi-fication and then sending a trigger to the IG Builder to trigger a build?
Josh Mandel (Mar 24 2020 at 20:31):
Can we just automate "sushi-fication" either as part of the IG build or as an upstream Github Action step?
Grahame Grieve (Mar 24 2020 at 20:31):
it's on my todo list but it's not close
Josh Mandel (Mar 24 2020 at 20:31):
Is this just a cookbook set of commands that you need to run? Is it necessary to commit the resulting files to the repo, or could they be used on the fly?
Josh Mandel (Mar 24 2020 at 20:32):
@Grahame Grieve are there steps we could follow to automate this out-of-band to start?
Grahame Grieve (Mar 24 2020 at 20:32):
automate "sushi-fication" either as part of the IG build
Grahame Grieve (Mar 24 2020 at 20:32):
I don't know.
Josh Mandel (Mar 24 2020 at 20:33):
OK. @Keith Boone if you let me know what commands you need to manually run, I can make suggestions about automation.
Grahame Grieve (Mar 24 2020 at 20:38):
It's probably better if the IG publisher runs the pre-process step but I'm not sure what the technical pre-requisites are
Grahame Grieve (Mar 24 2020 at 20:39):
@Chris Moesel is probably the best person to comment on this
Chris Moesel (Mar 24 2020 at 20:56):
We were going to look at creating GitHub Actions for SUSHI in the next two-week sprint. We are looking at a few options, but I think the first one was to create a workflow that used SUSHI to generate the IG source, then the IG publisher to build it, and finally checked in the results to gh-pages.
Chris Moesel (Mar 24 2020 at 20:57):
We were also looking at an approach that would use SUSHI to build the IG source, check it into some kind of shadow branch, and then ping the auto-builder to build that branch. We're trying to avoid checking in SUSHI output into the main src control branches.
Chris Moesel (Mar 24 2020 at 20:58):
I'd love to have it integrated into the IG Publisher and/or auto-build directly though! From a technology standpoint, it's probably more feasible to put it in the auto-builder right now, as it's an entirely different technology stack than the IG Publisher.
Chris Moesel (Mar 24 2020 at 21:00):
@Josh Mandel -- you're basically looking at:
$ npm install -g fsh-sushi $ sushi . -o build $ cd build $ ; run publisher from here
Chris Moesel (Mar 24 2020 at 21:01):
Well, you may want to check the return code after running SUSHI to ensure no errors. Or you can accept the errors and try to run the IG Publisher anyway (best effort approach).
Chris Moesel (Mar 24 2020 at 21:02):
Or we could say that for auto-build projects, all FSH source must be in a fsh folder. In which case you'd do:
$ npm install -g fsh-sushi $ sushi ./fsh -o . $ ; run publisher from here
Grahame Grieve (Mar 24 2020 at 21:15):
@Josh Mandel if you put npm install -g fsh-sushiin the autobuild script then I could do the actual launch of sushi from the IG publisher, and it would be the same experience for every one.
Grahame Grieve (Mar 24 2020 at 21:15):
@Chris Moesel I'm not sure I follow this enough though. What's the inputs and outputs to and from sushi
Grahame Grieve (Mar 24 2020 at 21:15):
you have a folder, and you run Sushi, and then...?
Chris Moesel (Mar 24 2020 at 21:20):
Hi @Grahame Grieve. A "FSH Tank" is a folder containing .fsh files (direct or in sub-folders), a package.json file, and a specific sub-folder called ig-data that contains supplemental files for your IG (pages, menu, package-list, etc). The first argument to sushi is the path to this folder (your "FSH Tank").
Grahame Grieve (Mar 24 2020 at 21:22):
and the output from it?
Chris Moesel (Mar 24 2020 at 21:22):
By default, SUSHI will build into a folder called build, but you can override this with the -o flag to build to a different folder. Whatever folder that is, SUSHI will build a full directory structure that can used as the input to the IG Publisher (using the template-based publishing).
Grahame Grieve (Mar 24 2020 at 21:23):
so I think that it makes sense to say that it goes in a .fsh sub-folder, then, per -o ., and I could run that from the IG publisher if there's a .fsh folder.
Josh Mandel (Mar 24 2020 at 21:25):
OK -- let me take a look at the dockerfile for the IG builder.
Josh Mandel (Mar 24 2020 at 21:25):
Might try to update openjdk while I've got this open ;-)
Jose Costa Teixeira (Mar 24 2020 at 21:27):
I agree it's much easier to start writing in sushi. In my experience it gets complicated when sushi takes an all-or-nothing approach. It will try to recreate the entire IG content.
Chris Moesel (Mar 24 2020 at 21:27):
@Grahame Grieve -- yes, I think that could work that way. But it will add another dependency for users -- Node.js.
Jose Costa Teixeira (Mar 24 2020 at 21:27):
Can we tell sushi what to exclude or what to include?
Grahame Grieve (Mar 24 2020 at 21:27):
but if users are using Sushi, they already have that dependency, right?
Josh Mandel (Mar 24 2020 at 21:27):
@Chris Moesel sorry for the naive questions but how can you avoid nodejs?
Josh Mandel (Mar 24 2020 at 21:27):
(Ah, same question as Grahame)
Grahame Grieve (Mar 24 2020 at 21:28):
if sushi doesn't delete any files, then you can make your own content anyway
Josh Mandel (Mar 24 2020 at 21:28):
Or, you mean for users not using sushi.
Josh Mandel (Mar 24 2020 at 21:28):
So Grahame's "speculatively auto-run sushi in all IG Builder invocations" needs to not crash if node and/or sushi is missing...
Jose Costa Teixeira (Mar 24 2020 at 21:28):
I stopped making use of Sushi :oh_no: because I did some changed my files and I did not want sushi to override
Grahame Grieve (Mar 24 2020 at 21:28):
no I won't run it speculatively. Only if I see fsh sub folder.
Grahame Grieve (Mar 24 2020 at 21:29):
And sushi shouldn't force you to do everything in fsh - there's all sorts of inputs that will come through other authoring methods
Chris Moesel (Mar 24 2020 at 21:29):
Right -- if Grahame builds the SUSHI call into the IG Publisher, then some users might not ever install SUSHI directly themselves, in which case they need to know that they need Node.js to support FSH compilation from the IG Publisher.
Grahame Grieve (Mar 24 2020 at 21:29):
I'll try and get that out today. (on site installing solutiosn today)
Jose Costa Teixeira (Mar 24 2020 at 21:29):
the template can also tell that node is missing.
Chris Moesel (Mar 24 2020 at 21:29):
Wow. That's great.
Grahame Grieve (Mar 24 2020 at 21:30):
in which case they need to know that they need Node.js to support FSH compilation from the IG Publisher
I will endeavour to make a clear error message in that case
Grahame Grieve (Mar 24 2020 at 21:30):
back later
Grahame Grieve (Mar 24 2020 at 21:30):
@Chris Moesel can you knock up a test ig for us to test with?
Jose Costa Teixeira (Mar 24 2020 at 21:32):
@Chris Moesel does sushi delete the existing ig content?
Chris Moesel (Mar 24 2020 at 21:32):
Sure. Do you want something that runs fast but is very simple or something that is robust but a slower build? In either case, SUSHI is pretty fast -- it's the IG Pub that goes slow since it's doing all the hard terminology stuff.
Chris Moesel (Mar 24 2020 at 21:34):
@Jose Costa Teixeira -- if you tell SUSHI to build to a folder that already exists, it will overwrite files in that folder (if the paths match), but it does not delete the contents of the folder. That said, if you've modified the ImplementationGuide JSON file, that will be overwritten.
Jose Costa Teixeira (Mar 24 2020 at 21:34):
json file, you mean?
Chris Moesel (Mar 24 2020 at 21:34):
Yes (fixed above).
Jose Costa Teixeira (Mar 24 2020 at 21:35):
I really do not want that.
Chris Moesel (Mar 24 2020 at 21:36):
We have a more robust strategy planned out for allowing more detailed configuration of the IG JSON file, but right now we're focusing on implementing the features that are specified in the upcoming FSH ballot.
Jose Costa Teixeira (Mar 24 2020 at 21:36):
but I was having an idea for fixing that and provide a different way to input content to the IG. I'll post the question in the IG stream.
Chris Moesel (Mar 24 2020 at 21:37):
@Jose Costa Teixeira -- glad to hear your ideas! In case you missed it, definitely check out this thread too: https://chat.fhir.org/#narrow/stream/215610-shorthand/topic/SUSHI.20Configuration
Chris Moesel (Mar 24 2020 at 21:38):
BTW -- we added support for BYOJ (Bring-Your-Own-JSON) resources in the last version of SUSHI too. It doesn't exactly address your issue, but it does allow you to more easily bring in JSON files authored elsewhere and have SUSHI pop them into the generated IG JSON file.
Josh Mandel (Mar 24 2020 at 21:41):
OK @Grahame Grieve -- sushi and node/npm will now be installed and on the system path in our IG builder (/usr/local/bin/sushi to be precise). per this commit (need a few minutes to build/push this to the container registry; will update here when done)
Keith Boone (Mar 24 2020 at 21:41):
I'm already doing hybrid Sushi BYOJ/BYOX builds in other projects. If you know how Sushi works, you can make sure it doesn't mess things up. The only big issue is that if you build a resource using sushi, then rename it, you have to manually delete it from input folder. It's a minor pain to deal with, and most of my local builds wipe input before running the Sushi step. For this work, I'd be VERY happy just to get an automated SUSHI run, and am already thrilled at the response.
Jose Costa Teixeira (Mar 24 2020 at 21:44):
Cool. BTW, the ig.ini etc is also a file that I hope sushi does not touch if it exists
Josh Mandel (Mar 24 2020 at 21:48):
@Keith Boone Where in https://github.com/AudaciousInquiry/saner-ig are you defining profiles like https://audaciousinquiry.github.io/saner-ig/StructureDefinition-saner-bed-group.html? I'm expecting to see a fsh source file or something (but maybe I'm confused).
Keith Boone (Mar 24 2020 at 21:48):
ig.ini is initialized based on user provided data in ig-data. Everything except the one thing is already knows (the ig content it built), is user customizeable. But it rebuilds it every time. So you have nearly what you want.
The other challenge is that SUSHI can only build a flat TOC right now (that may have changed in most recent release, I haven't pulled that yet).
Jose Costa Teixeira (Mar 24 2020 at 21:49):
( ok, i will mention the TOC thing in the IG creation stream :) )
Chris Moesel (Mar 24 2020 at 21:52):
@Grahame Grieve and @Josh Mandel -- here is a simple test SUSHI project from our FSH tutorial: fsh-tutorial-pub-test.zip
Keith Boone (Mar 24 2020 at 21:52):
@Josh Mandel Yeah, that's in a private repo right now along side the tools that are generating a lot of my IG structure and UML drawings and such. They've done what they need to, I can transfer those outputs over to the current IG, and handle the manual transforms of images-source on an as needed basis b/c I don't forsee much work in that space right now, and I can merge any useful content if that changes later if the actor/transaction stuff needs changing.
Josh Mandel (Mar 24 2020 at 21:54):
(I'd love to get some mermaid tooling for auto-generation of sequence diagrams, flowcharts, etc built into our IG pipeline ;-))
Jose Costa Teixeira (Mar 24 2020 at 21:58):
http://build.fhir.org/ig/hl7-be/be-core/branches/master/scenario-allergy.html
Jose Costa Teixeira (Mar 24 2020 at 21:58):
like this?
Josh Mandel (Mar 24 2020 at 21:58):
Yeah, this kind of stuff!
Josh Mandel (Mar 24 2020 at 21:59):
https://mermaid-js.github.io/mermaid/#/ is the best tool I've come across
Jose Costa Teixeira (Mar 24 2020 at 21:59):
I generate diagrams from an ExampleScenario.
Jose Costa Teixeira (Mar 24 2020 at 22:00):
just because I want those diagrams to be artefacts, not to be source in a file (which should also be valid).
Josh Mandel (Mar 24 2020 at 22:00):
Neat! (But the code for https://mermaid-js.github.io/mermaid/#/?id=sequence-diagram is so delightfully compact!)
Josh Mandel (Mar 24 2020 at 22:01):
@Grahame Grieve OK, updated IG builder image with sushi is in place; I'm testing to make sure OpenJDK 15 doesn't totally break everything....
Josh Mandel (Mar 24 2020 at 22:01):
Seems to work!
Jose Costa Teixeira (Mar 24 2020 at 22:01):
it's the same code - mermaid and plantuml
Jose Costa Teixeira (Mar 24 2020 at 22:01):
well not the same, but equally compact
Josh Mandel (Mar 24 2020 at 22:02):
Sorry, I thought you were saying you authored something like http://build.fhir.org/examplescenario-example.json.html in order to generate the diagram
Jose Costa Teixeira (Mar 24 2020 at 22:02):
I take the ExampleScenario and generate the code - that is my choice, I don't want to maintain code, i want to maintain named, versioned resources.
Josh Mandel (Mar 24 2020 at 22:03):
Cool. I'm saying that the final step, from code --> inline images would be a nice automation target in the IG Build.
Jose Costa Teixeira (Mar 24 2020 at 22:03):
yes. That example is here
http://blog.zeora.net/mma/examplescenario-mma1-scenario.html#iherx001bundle
Jose Costa Teixeira (Mar 24 2020 at 22:04):
plantuml is a standalone jar, so I have it in my build
Jose Costa Teixeira (Mar 24 2020 at 22:05):
(my machine does: examplescenario - source.txt - diagram.svg.
Then an xslt puts the svg inside the xhtml which is passed on to Jekyll)
Jose Costa Teixeira (Mar 24 2020 at 22:06):
I do need help to put plantuml in maven... the author has agreed to let us do that.
Jose Costa Teixeira (Mar 24 2020 at 22:07):
there's more stuff that IHE will use (basically what Keith demonstrates - actor diagrams, tables...
We could also take PlanDefinition and make an activity diagram...
same process, different xslts.
Jose Costa Teixeira (Mar 24 2020 at 22:08):
sorry, i got excited, but thanks for the feedback.
Josh Mandel (Mar 24 2020 at 22:08):
;-) Sure thing, and glad that there's excitement about this stuff.
Jose Costa Teixeira (Mar 24 2020 at 22:10):
If everyone loved to do documentation as much as I do, everything would be generated automagically
Mark Kramer (Mar 25 2020 at 00:33):
Wow, I'm blown away at the speed and cooperation here. :clap:
David Hay (Mar 25 2020 at 05:50):
Just (trying to) keep track makes my head spin!
Chris Moesel (Mar 25 2020 at 12:43):
@Grahame Grieve and @Josh Mandel -- how are things going? Is there anything I can help with?
David Pyke (Mar 25 2020 at 12:50):
Of course! Review the code, suggest enhancements!
Josh Mandel (Mar 25 2020 at 13:58):
@Chris Moesel I think we're waiting on Grahame to add "sushi" invocation to the IG publisher. Looks like @Keith Boone has added the .fsh sources to his IG repo. One question re: good practices: when the IG Publisher automatically runs sushi, does that mean we can stop checking the output of sushi into git?
John Moehrke (Mar 25 2020 at 14:04):
This is indeed going to challenge us. Functionally the .fsh files are the source that creates the IG directory tree, but the IG directory tree (i.e. structureDefinition) are the things that are normative. The .fsh files are not... for now...
I suspect that there is going to be a hybrid approach. I think some will use sushi to kickstart an IG directory, that they then primarily edit from there. Even these will want to put into Git both the source .fsh and the IG directory... as sometimes one does decide to go back to the .fsh... decisions, decisions, decisions...
Jose Costa Teixeira (Mar 25 2020 at 14:06):
Agree. Not all that I produce is using sushi, so i am still checking the json/xml content (which is the normative stuff). I could do it the other way around when hatchery(?) is there.
Josh Mandel (Mar 25 2020 at 14:09):
@John Moehrke I think you're crossing the "editorial process" with "the output". We'd of course capture snapshots of output as normative, but the source files aren't.
Josh Mandel (Mar 25 2020 at 14:10):
Just like the java code or spreadsheets in https://github.com/hl7/fhir aren't normative. This is just tooling.
Josh Mandel (Mar 25 2020 at 14:11):
(Also, I think we're over-loading this topic -- we should try to create topics in this same stream when discussion veers off.)
John Moehrke (Mar 25 2020 at 14:12):
sorry, I thought I was on topic. This whole stream doesn't seem specific to SANER project, but rather getting sushi into the build environment.
Keith Boone (Mar 25 2020 at 14:41):
Back to the main topic of this thread: Now building on build.fhir.org: http://build.fhir.org/ig/AudaciousInquiry/saner-ig/branches/master/index.html , and yes, the fish tank has been installed, now we just need the Sushi chef installed in the IG Builder, folks are working on that.
Blog post from late last night: http://motorcycleguy.blogspot.com/2020/03/the-saner-project.html
And the project wiki has been updated: https://github.com/AudaciousInquiry/saner-ig/wiki
Josh Mandel (Mar 25 2020 at 17:06):
From today's call:
Josh Mandel (Mar 25 2020 at 17:06):
Note action items are for: @Michael Donnelly @Gino Canessa @Keith Boone @Josh Mandel @Joe Wall
And Joe, you weren't subscribed here; I've added you. Can you also let me know your github id?
Grahame Grieve (Mar 25 2020 at 19:04):
will work on the ig-builder now; had to spend hours I didn't have getting the build fixed last night
Grahame Grieve (Mar 25 2020 at 19:10):
@Chris Moesel what's a reasonable upper limit for sushi before I give up waiting and kill it? 1 minute?
Grahame Grieve (Mar 25 2020 at 19:30):
sigh... npm... the install has failed, and it's also broken other parts of my system
Chris Moesel (Mar 25 2020 at 19:43):
Moving SUSHI talk to https://chat.fhir.org/#narrow/stream/226195-Covid-19-Response/topic/Sushi.20builds per a previous request.
Keith Boone (Mar 25 2020 at 19:56):
/poll Should we just start a separate Stream for The Saner Project?
Yes
No
Josh Mandel (Mar 25 2020 at 20:05):
Re: separate stream, would the conversations about Metrics, MeasureReport components, etc belong there?
Josh Mandel (Mar 25 2020 at 20:05):
I don't think there's any activity/discussion happening here that's not sparked by the Saner IG.
Josh Mandel (Mar 25 2020 at 20:06):
Even though I agree that the discussion has been wide ranging :)
Keith Boone (Mar 25 2020 at 20:07):
Fair response. I'll give it 24 hours and ask on the call tomorrow as well.
Keith Boone (Mar 25 2020 at 20:09):
@John Moehrke https://github.com/AudaciousInquiry/saner-ig/blob/master/fsh/ig-data/input/pagecontent/4_security_considerations.md is all yours!
Josh Mandel (Mar 25 2020 at 20:37):
Not sure if I'll be able to join the check-in tomorrow (internal training conflict) so it'd be great to have another volunteer note-taker.
Josh Mandel (Mar 26 2020 at 04:52):
Thanks to some heroic work by @Gino Canessa we've got sample bed data generated for 10 fake hospitals (or as many as you like), with reports generated using both of the approaches we discussed on our 3/24 call (Group-based and MeasureReport-based). There's documentation at https://github.com/microsoft-healthcare-madison/learning-spike-erp/blob/master/README.md#data-generation, and we point to examples of what each approach looks like. The most important files for discussion tomorrow are the -measureReport files and the -groups files.
Josh Mandel (Mar 26 2020 at 16:46):
Deep links to examples
Josh Mandel (Mar 26 2020 at 16:54):
We'll probably leverage the covid testing server James set up (HAPI) and also provide a Microsoft server.
Josh Mandel (Mar 26 2020 at 16:55):
We'll aim to populate one or more servers with bed data, as well as Group- and MeasureReport-based summaries, so we can try out queries.
Josh Mandel (Mar 26 2020 at 17:03):
I think we're not ready to call this until we've written some example queries... so we'll try to show these today.
Josh Mandel (Mar 26 2020 at 17:03):
And we'll comment on the relevant user stories to show how these queries work.
Josh Mandel (Mar 26 2020 at 17:13):
Regarding choice between Group and MeasureReport: the user stories today are about beds, but we do want to support things like "COVID-19 Encounters with a Presumptive Positive Test" from Epic's list, right? That's a measure with a percentage, numerator, and denominator, which is a good fit for MeasureReport, and I'm unclear on how it works with Group.
Michael Donnelly (Mar 26 2020 at 18:11):
We'd definitely want to communicate the components not just the percentage.
Michael Donnelly (Mar 26 2020 at 18:11):
Because the consumer might want or need the details.
Josh Mandel (Mar 26 2020 at 18:14):
I added https://github.com/AudaciousInquiry/saner-ig/issues/26 to capture some flavor of this use case, and to see if there's consensus that it's in-scope.
Gino Canessa (Mar 26 2020 at 18:55):
Josh Mandel said:
Deep links to examples
- Using Group
- Using MeasureReport
Update to the selection algorithm changed the default dataset generated. New Links (these should stay around now):
Large:
Small:
Josh Mandel (Mar 26 2020 at 19:37):
One more point about Group: if we're submitting, say, 30 groups to report on various facets... do we require the creation of Groups that capture zero-count facets? Normally I'd say no, but if we omit zero-count groups... then you have the problem that it's hard to know whether there was just a data transfer error, or there were no beds in that facet. With MeasureReport, if you see the report, you know all facets were evaluated / uploaded.
Gino Canessa (Mar 26 2020 at 22:13):
Note, the utility now does time sequencing. The samples in the repo are now over 3 days. Running the utility with -h will show help with all the parameters.
Josh Mandel (Mar 26 2020 at 22:32):
We're loading data into https://covid19-under-fhir.smilecdr.com/baseR4 and http://prototype-erp-fhir.azurewebsites.net/ based on 100 simulated hospitals (starting with one time point; will add more).
Josh Mandel (Mar 26 2020 at 22:40):
For example,
https://covid19-under-fhir.smilecdr.com/baseR4/MeasureReport?period=2020-03-24
Will get all available MeasureReport-based summaries for for March 16. We don't have a similar way to fetch Groups for a specific reporting date, but we are populating Group.characteristic.period once for each Group.
Josh Mandel (Mar 27 2020 at 04:13):
After fixing some little errors, we now have sample data loaded in both of these servers.
David Pyke (Mar 27 2020 at 16:27):
https://www.surveymonkey.com/r/7GHYRF2
David Pyke (Mar 27 2020 at 16:32):
Josh Mandel (Mar 30 2020 at 16:53):
Re: calls going forward -- I think things are starting to settle out and would suggest dialing back call frequency (3 per week?), duration (30 minutes), or both.
Josh Mandel (Mar 30 2020 at 16:54):
What do others think?
David Pyke (Mar 30 2020 at 16:54):
I think this is a good plan. moving to every other day is probably a good idea. Most of the major issues are in github issues, we can discuss here or there
Keith Boone (Mar 30 2020 at 17:05):
Let's discuss tomorrow, and implement going forward. I too am good with the idea.
Carl Anderson (Mar 30 2020 at 19:00):
My wife shared this with me this weekend, and thought it would be interesting to the group. I haven't investigated the data source yet, but I love their UI.
http://covid19.healthdata.org/
Josh Mandel (Mar 30 2020 at 22:41):
Are folks here familiar with https://www.juvare.com/emresource/? They mention 50k healthcare facilities using their resource management tools, and I'm curious if anyone has experience with this.
Virginia Lorenzi (Mar 31 2020 at 15:08):
Capacity reporting seems to be daily counts the actual reporting part is really not that labor intensive I don't think having trouble understanding benefit of SANER
Mark Kramer (Mar 31 2020 at 15:09):
@John Moehrke the integration is now working (1.0.75 IG Pub version +). The use of the feature is described here: http://build.fhir.org/ig/HL7/fhir-shorthand/sushi.html#new-ig-publisher-integration-autobuild-configuration
Josh Mandel (Mar 31 2020 at 15:09):
You're asking the right questions, @Virginia Lorenzi. Right now there's only one path to reporting, and CDC estimates ~30min/facility/day to follow that path. That's a big number across tens of thousands of acute care facilities, but in a manually-entered reporting paradigm you probably can't shave that much off. Still, two big opportunities as I see it:
1) Allow better UX for data submission, by focusing on an API
2) Allow more automation, by directly linking/pre-filling data that can be computably tracked from internal systems
Josh Mandel (Mar 31 2020 at 15:12):
So my take is that having an API-driven way to collect data is a really good general capability; and you get to re-use these models on the query/access/sharing side, too. It's nice because each week when you add new measures, you can do it using a consistent framework rather than appending columns to a CSV forever.
Josh Mandel (Mar 31 2020 at 15:13):
I want to know if you find this at all convincing :) We need more skeptics (and I've decided to sort of suspend disbelief on this for a bit, personally).
Mark Kramer (Mar 31 2020 at 15:15):
Well done, @Keith Boone
John Moehrke (Mar 31 2020 at 15:20):
Are we actually expecting roll out of the solution we are working on in SANER? I understand that it would be good for some to roll it out, rather than filling out an spreasheet and emailing it... but that our efforts are more to use the tools we have and this crisis as a bench test of how quickly our tools can support a better future than spreadsheets and email. If some use it, that is good, and it should gather the same data
Gino Canessa (Mar 31 2020 at 15:29):
Can't speak for anyone else, but I'd say yes.
I'm working on tools for modelling and tools for translation. My thinking is that once we have everything "right", we can start distributing pieces to make lives easier - e.g., a simple single source of truth that can export to FHIR servers, CDC (csv), etc.
As vendors add support for the IG (e.g., creating measure reports), more of the process becomes automatic until the entire process is hands-free.
Josh Mandel (Mar 31 2020 at 16:08):
Webinar detail are also at https://www.cdc.gov/nhsn/acute-care-hospital/covid19/index.html, for 2p ET today.
Josh Mandel (Mar 31 2020 at 16:08):
http://www.ustream.tv/channel/VWBXKBR8af4
Keith Boone (Mar 31 2020 at 19:15):
John Moehrke said:
Are we actually expecting roll out of the solution we are working on in SANER? I understand that it would be good for some to roll it out, rather than filling out an spreasheet and emailing it... but that our efforts are more to use the tools we have and this crisis as a bench test of how quickly our tools can support a better future than spreadsheets and email. If some use it, that is good, and it should gather the same data
Yes, we want to build software and roll out tools, Implementing and (Connectathon) Testing is next stage, then Pilot.
Virginia Lorenzi (Mar 31 2020 at 21:10):
well I am engaged so we can collectively learn but actually making a difference would be a good thing don't you think?
Ben Cooperman (Apr 03 2020 at 17:12):
I was able to join the call today for the first time. Great to be a part. I am wondering if there are roles for anyone who is not going to write code?
Last updated: Apr 12 2022 at 19:14 UTC
