Stream: smart/scheduling-links
Topic: Inferno Slot Publisher tests
Robert Scanlon (Apr 09 2021 at 19:51):
We just released a draft set of validation tests for the slot publishing actor, and deployed them on our qa/test site. To try them out, you can go to https://infernotest.healthit.gov/community, or run it locally by downloading and running https://github.com/onc-healthit/inferno (using docker-compose).
Robert Scanlon (Apr 09 2021 at 19:52):
A quick way to try it out is plug in https://raw.githubusercontent.com/smart-on-fhir/smart-scheduling-links/master/examples/ as the 'FHIR endpoint', and leave the two input fields blank when you run the tests. That will download and validate all of the example resources.
Robert Scanlon (Apr 09 2021 at 19:57):
This is definitely a work in progress: there are a few optional things we don't check, and we redundantly check a few things. But we look forward to feedback and are planning on iterating on this quickly next week.
Josh Mandel (Apr 09 2021 at 21:15):
Super cool!
Josh Mandel (Apr 10 2021 at 08:20):
I've already got a few good results from Inferno that I can use to shape up my sample data next week ;-)
(It'd be great to recognize if someone pastes https://raw.githubusercontent.com/smart-on-fhir/smart-scheduling-links/master/examples/$bulk-publish/$bulk-publishinto the front-page text box too.)
Robert Scanlon (Apr 11 2021 at 03:46):
Yeah, Inferno as a platform has a FHIR RESTful API bias, which is why it expects the 'base FHIR url' to be the starting point. But I agree in the context of this IG, the manifest itself is the obvious starting point to test publishers, and breaking if the user pastes that into the front box is silly. I just pushed up an update that will work if you paste in a direct link to the manifest in the front-page box (e.g. https://raw.githubusercontent.com/smart-on-fhir/smart-scheduling-links/master/examples/$bulk-publish). Future versions of Inferno will likely remove the front page input box.
Robert Scanlon (Apr 11 2021 at 04:05):
Is this formally built on top of FHIR's RESTful API, and if so, should I add a capabilities interaction (/metadata) test? I left it out of the first set of tests, because it felt like it might be a distraction given goals and general tone of the spec ("publishers expose data according to the FHIR standard, but don't need specific experience with FHIR to follow this guide"). But on the other hand, support for the capabilities interaction is a hard requirement in FHIR for a reason.
Josh Mandel (Apr 11 2021 at 04:33):
Thanks! (Hosting a capability statement is not something we are currently asking participants to do. We can talk through whether it makes sense in the longer term, but I don't want to distract from the simplicity of just focusing on the data at this stage.)
Robert Scanlon (Apr 11 2021 at 16:29):
Sounds good regarding capability statements. I do think it's worth the conversation eventually, because from a validation perspective selectively checking requirements depending on use case is problematic. But definitely not the most pressing problem here.
Last updated: Apr 12 2022 at 19:14 UTC
