Stream: genomics/committers
Topic: Branches
Jamie Jones (Dec 02 2019 at 18:06):
Merging branches with our current setup seems rough, I'll make some time this week to get recent proposals for pgx implications integrated into Kevin's branch if that sounds good to everyone
Jamie Jones (Dec 02 2019 at 18:07):
Don't suppose anyone has identified steps towards using newer tools for development yet?
Kevin Power (Dec 02 2019 at 18:14):
I haven't yet, no - but it is an STU2 theme :slight_smile:
Kevin Power (Dec 02 2019 at 18:20):
This is a great example of getting not only 'content' related feedback on those STU2 themes, but also prioritization feedback is also requested. I know current state of the tooling behind our IG is less than ideal, and could use an 'upgrade' - however, what we have works pretty well. I would prioritize that fairly low personally.
Patrick Werner (Dec 03 2019 at 09:05):
I agree, but i think it would be easier for us to work on the IG if we were using StructureDefinitions instead of Spreadsheets. Also the new IG template(s) are nice. I can dedicate some time on this in Jan. @Lloyd McKenzie any ETA on the new IG templates?
Lloyd McKenzie (Dec 03 2019 at 14:22):
The IG templates are technically "here", but not super-well documented. I can convert the IG over, most likely during the holidays.
Lloyd McKenzie (Dec 03 2019 at 14:24):
In terms of using StructureDefinitions, it certainly makes Git use easier, but it's not necessarily intuitive for most people to author in XML. One of the things on my to-do list is to set it up so that spreadsheets can save to StructureDefinitions and load from StructureDefinitions. Are there other issues you're encountering with the spreadsheets?
Jamie Jones (Dec 03 2019 at 14:26):
I think git and diffs is the main concern
Patrick Werner (Dec 03 2019 at 14:47):
another issue is that for constrains the IG publisher still needs XPATH and FHIRPATH, but i think that is an IG Publisher issue?
Patrick Werner (Dec 03 2019 at 14:48):
Are there other issues you're encountering with the spreadsheets?
Grahame telling us that spreadsheets are deprecated :smiley:
Lloyd McKenzie (Dec 03 2019 at 18:20):
Grahame's been saying that for 4+ years. The challenge is that we don't want to be limited to only one commercial tool that can support authoring profiles against the 'current' FHIR release. I think the accurate statement is "Grahame would like to not have to actively maintain the spreadsheet tool".
Grahame Grieve (Dec 03 2019 at 18:56):
I want people to stop using them, but certain people keep refusing to
Lloyd McKenzie (Dec 03 2019 at 19:07):
We can't stop using spreadsheets until we have multiple free-for-use (and useable) tools that support the complete set of authoring capabilities needed for the set of releases designers need to author against. And even then, spreadsheets allow certain types of authoring changes and viewing of authored content that none of the other tools can yet match. If the tooling environment had evolved to the point that spreadsheets were unnecessary, no-one would be arguing to keep them.
Grahame Grieve (Dec 03 2019 at 19:10):
I don't see why users should expect more than edit the SD directly if they're looking for free-to-use. Tools cost real money to develop/support, and people are paid real money to use them. Some transfer seems appropriate to me. So I have no commitment to provide anything but editing resources directly by hand on a free-for-use basis
Lloyd McKenzie (Dec 03 2019 at 19:55):
Why don't we maintain the resource definitions in raw XML? Why did we create the spreadsheet mechanism in the first place? Answer: profile creation is too complex for most people to manage doing it using the raw resources. Spreadsheets are clunky and non-elegant and they can't do lots of things, but they open up authoring to a much broader set of people. Failing to support the free tools we have makes the community hostage to the commercial space - both in terms of functionality and in terms of cost barriers. I don't think the current commercial tooling environment is robust enough that that's a smart risk for the FHIR community to take.
Grahame Grieve (Dec 03 2019 at 20:07):
I don't think the current commercial tooling environment is robust enough
This is at least partly because the $$ flowing in the consulting community are not being shared with the tooling providers.
Grahame Grieve (Dec 03 2019 at 20:07):
profile creation is too complex for most people to manage doing it using the raw resources
I agree. but tooling to change that costs real $$ to develop
Lloyd McKenzie (Dec 03 2019 at 21:27):
So remove the crutch of free (and sometimes superior) tooling that we don't want to maintain to force the community to invest in the commercial tooling - hoping that the commercial tooling will a) catch up to what's needed; and b) eventually drop prices down to a level that's affordable to the much broader community of users we want to be able to author these artifacts?
Grahame Grieve (Dec 03 2019 at 21:28):
well, someone pays for this tooling in question. Guess who...
Lloyd McKenzie (Dec 03 2019 at 21:39):
Is it really going to be significant ongoing effort to keep spreadsheets alive now that StructureDefinition is normative? Obviously I'm not expecting you to invest in the process to load and save from a spreadsheet. But if that were done by someone else, would you still be urgently wanting them to go away @Grahame Grieve ?
Grahame Grieve (Dec 04 2019 at 00:04):
probably not... but if it ever became so....
Kevin Power (Dec 05 2019 at 17:58):
@Lloyd McKenzie - I appreciate your offer to convert the IG, but perhaps that is something the WG committers should take on? Is there a 'How to 101' type document that would help guide us?
Lloyd McKenzie (Dec 05 2019 at 20:09):
There's a partial one, but not yet complete, which is why I made the offer. Once the documentation is done, I'll point you to it
Kevin Power (Dec 05 2019 at 20:22):
I suppose I should never turn down an offer for excellent assistance, but if it makes more sense for you to develop the documentation and have one of us do it, that makes sense to me. Now, if you want to practice on an IG while you develop the documentation, well, I suppose we could offer up ours ;)
Jamie Jones (Dec 06 2019 at 22:28):
Got the branch up and building locally, going to work on adding some of the proposed PGx changes for folks to view Monday (won't be able to update the UML diagrams but may draw something else up in google stuff)
Kevin Power (Dec 06 2019 at 22:42):
Nice - same branch, or new?
Jamie Jones (Dec 06 2019 at 22:43):
Same so far but I'm contemplating that now... I really don't want to have to do the merging between them
Jamie Jones (Dec 06 2019 at 22:45):
Also, I think I would recommend applying the new PGx approach on the slides to the somatic one you built in this branch--single code, switching value
Jamie Jones (Dec 06 2019 at 22:45):
Thoughts?
Jamie Jones (Dec 06 2019 at 22:46):
Switching code, single valueset seems much more difficult a situation to manage in terms of complexity in answer lists
Kevin Power (Dec 06 2019 at 22:46):
I would say stick the same branch, we can rename it to something more generic after you do your thing
Jamie Jones (Dec 06 2019 at 22:47):
And switching both code and value seems like just having multiple profiles crammed together for little added value
Kevin Power (Dec 06 2019 at 22:48):
So you are talking about the approach of Observation.code = "Implication", and Observation.valueCodeableConcept = "Type of Implication"
Jamie Jones (Dec 06 2019 at 22:49):
Yes. I could do that just for the PGx space if we want to see them up at the same time
Kevin Power (Dec 06 2019 at 22:50):
Nah don't do it just for PGx, I think I am fairly convinced that is the right way to go - so switch away
Kevin Power (Dec 06 2019 at 22:55):
Thanks @Jamie Jones
Jamie Jones (Dec 09 2019 at 21:55):
publisher change seems to have found us a new ~1k errors or so for the time being... bunch of broken links, I can look into it later. For now, I can push the 2 new proposed implications up to the dev branch. We can roll it back if we need to but everything seems to render fine? I know there are some issues but not nearly the amount in QA
Jamie Jones (Dec 09 2019 at 21:56):
Let me know if anything jumps out as terrible and I may have time tonight to do some corrections
Jamie Jones (Dec 09 2019 at 21:56):
I didn't remove the old profiles, just added 2 new ones to the bottom of the 'general' grouping
Kevin Power (Dec 09 2019 at 22:11):
Yea, looks like the Publisher is generating bad links?
The link 'http://hl7.org/fhir/"element-definitions.html#Element.id' for "id" cannot be resolved
In the HTML, it looks like:
<a href="http://hl7.org/fhir/"element-definitions.html#Element.id">
Kevin Power (Dec 09 2019 at 22:17):
Might want to post to #IG creation
Kevin Power (Dec 10 2019 at 21:39):
Posted the issue here: https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/IG.20Publisher.20generating.20bad.20links.3F
Jamie Jones (Jan 02 2020 at 21:22):
pesky '"' looks like it's still not taken care of yet, but I pushed a slicing fix that Bob D found
Jamie Jones (Jan 02 2020 at 21:24):
We have a few examples of reports that are throwing errors now for not declaring category, which I'm pretty sure we meant to enforce (we previously had put a constraint on all slices of category.coding instead of creating a mandatory slice).
Jamie Jones (Jan 02 2020 at 21:34):
This is how US Core defines category on their profiles, but if anybody thinks this category change is not what was intended, please let me know and I can change the cardinality back to 0..*
Lloyd McKenzie (Jan 03 2020 at 14:56):
Category should be 0..*. We can require a specific value to be present, but we shouldn't prevent other values
Jamie Jones (Jan 03 2020 at 15:03):
We've had it as 1..* on Observation for a while, but 0..* on DiagnosticReport
Jamie Jones (Jan 03 2020 at 15:04):
I'll log a tracker for updating to 1..* so we don't lose the discussion
Jamie Jones (Jan 06 2020 at 15:54):
broken links seem fixed! (though we do have ~29 on http://build.fhir.org/ig/HL7/genomics-reporting/conversion.html due to some other changes)
Bret H (Jan 07 2020 at 16:27):
did it fix on its own? or was a change made?
Jamie Jones (Jan 07 2020 at 16:27):
Grahame must have pushed the fix to the publisher, it was pending for some time
Patrick Werner (Jan 07 2020 at 17:38):
there were several publisher updates. (and FHIR core)
Patrick Werner (Jan 07 2020 at 17:39):
i just pushed:
http://build.fhir.org/ig/HL7/genomics-reporting/branches/tmb_msi/artifacts.html
Patrick Werner (Jan 07 2020 at 17:39):
- added MSI/TMB in the general section
Patrick Werner (Jan 07 2020 at 17:44):
as the LOINC codes are ready now i used LOINC for all the codings and VS
Patrick Werner (Jan 07 2020 at 17:47):
to avoid merge nightmare i'd like to merge soon.
Patrick Werner (Jan 07 2020 at 17:48):
So if anyone finds a problem/error please fix/ give me a message and i will fix it.
Jamie Jones (Jan 07 2020 at 17:48):
MSI looks great, but I'm concerned at suggesting an interpretation coding using https://r.details.loinc.org/AnswerList/LL2160-1.html for TMB
Patrick Werner (Jan 07 2020 at 17:52):
uh, this seems to be a LOINC error?
Patrick Werner (Jan 07 2020 at 17:52):
i used https://loinc.org/LL2160-1/ as this is linked from: 94077-5
And is a neutral low/high VS
Jamie Jones (Jan 07 2020 at 17:54):
interesting, I guess they do reuse the answer list, and just display the first context it was defined for
Kevin Power (Jan 07 2020 at 18:19):
Seems to be a difference in how the different LOINC websites show the data, or maybe a difference in the versions of LOINC they are displaying.
Kevin Power (Jan 07 2020 at 18:21):
Question - Did you want to add these to GenomicsReport.results[] ?
Kevin Power (Jan 07 2020 at 18:22):
Question 2 - Should any of the Implications be able to deriveFrom MSI or TMB?
Jamie Jones (Jan 07 2020 at 18:31):
both seem yes to me
Kevin Power (Jan 07 2020 at 18:45):
Question 3 - Should we include some 'how to use these' text somewhere, and if so, does this deserve its own page?
Jamie Jones (Jan 07 2020 at 18:49):
Currently we are relying on loinc for the text
Kevin Power (Jan 07 2020 at 18:59):
I suppose that is not the worst idea ever :slight_smile:
Patrick Werner (Jan 08 2020 at 09:38):
1&2: yes.
3.: I think we could include a short explaining paragraph into : http://build.fhir.org/ig/HL7/genomics-reporting/general.html
Patrick Werner (Jan 08 2020 at 10:19):
Should we also include them into Fig1.?
Kevin Power (Jan 08 2020 at 14:56):
Should we also include them into Fig1.?
I would say yes.
Kevin Power (Jan 08 2020 at 14:59):
Regarding when to merge - Did we ever vote on the JIRA for this? Or is this branch just to show a prototype? If we haven't voted, I would say we need to vote before we merge. I think it is a reasonable expectation to vote on a change before committing to master.
Jamie Jones (Jan 08 2020 at 14:59):
We have the white box for "other observations" in figure 1 that was previously meant to cover these use cases. Might be best to list those two profiles there as examples
Jamie Jones (Jan 08 2020 at 15:00):
Or rework the image a slightly different way
Jamie Jones (Jan 08 2020 at 15:02):
Haven't voted on tmb jira yet to my knowledge, and haven't really created one for the implication work yet
Kevin Power (Jan 08 2020 at 15:28):
Good call on Implications - we need to resync on where we are, remaining to dos, getting a JIRA created, etc ...
Jamie Jones (Jan 08 2020 at 15:30):
I think I want to make the proposal to add the report sentence/text the value of the implication
Kevin Power (Jan 08 2020 at 15:31):
OK - I was just reviewing the last discussion on that between you and Bret. So we don't mix topics, we should probably resume this conversation on that thread.
Jamie Jones (Jan 08 2020 at 15:32):
A question relevant to this thread, then: @Patrick Werner are you planning to merge with the implications branch or with master?
Kevin Power (Jan 08 2020 at 15:39):
I would keep it out of the Implications branch - we should act like one might get approved, and another might not (even tho we will likely continue to tweak until they are both approved)
Patrick Werner (Jan 08 2020 at 15:49):
as this is based on already voted on tracker items i would merge this into the current branch (master)
Patrick Werner (Jan 08 2020 at 15:50):
We have the white box for "other observations" in figure 1 that was previously meant to cover these use cases. Might be best to list those two profiles there as examples
my profiles are derived from GenomicsBase, so the other Observations aren't a fit
Patrick Werner (Jan 08 2020 at 16:05):
as this is based on already voted on tracker items i would merge this into the current branch (master)
the tracker is there but not voted on:
https://jira.hl7.org/browse/FHIR-18988
Could be voted on next Tue
Jamie Jones (Jan 08 2020 at 22:09):
For TMB interpretation, Observation.interpretation extensibly bound to http://build.fhir.org/valueset-observation-interpretation.html?
Patrick Werner (Jan 09 2020 at 10:16):
no it is bound to the loinc low/high answerlist. In TMB the value are Mut/MB, Interpretation is high/low
Jamie Jones (Jan 09 2020 at 19:21):
pasted image
The binding on the base resource was my concern
Jamie Jones (Jan 09 2020 at 19:26):
Also @Bob Dolin it sounds like you are free to branch the github repo and develop your proposal for the new content there. Once approved, we can either merge the branch or manually import the needed xml.
@Kevin Power I'm wondering if we ought to have extra disclaimers on development branches, or create some policies for naming conventions/upkeep/etc...
Bob Dolin (Jan 09 2020 at 19:35):
Thanks @Jamie Jones . Is there some type of orientation I can read, to better understand what I need to do to get started? Also, do I need some type of permissions?
Jamie Jones (Jan 09 2020 at 19:37):
Last set of instructions I knew was https://wiki.hl7.org/FHIR, which states, "For Commit privileges, send a request to lloyd@lmckenzie.com" @Lloyd McKenzie :)
Patrick Werner (Jan 09 2020 at 19:41):
pasted image
The binding on the base resource was my concern
ahhh, fair point. You are right, didn't see the issue as extensible is only validatable by humans, and i trusted my computer..
Patrick Werner (Jan 09 2020 at 19:41):
will create a VS containing H and L from: http://hl7.org/fhir/valueset-observation-interpretation.html
Kevin Power (Jan 09 2020 at 19:59):
Kevin Power I'm wondering if we ought to have extra disclaimers on development branches, or create some policies for naming conventions/upkeep/etc...
What sort of disclaimers are you talking about? I am always OK providing guidance to keep things consistent - but sometimes bad guidance is worse that no guidance :slight_smile:
Jamie Jones (Jan 09 2020 at 20:09):
Likely more of a concern for FHIR-I / IG creation, but the box disclaimer at the top of even a stale branch says something along the lines of
pasted image
Jamie Jones (Jan 09 2020 at 20:15):
"not an authorized publication;" hopefully covers most concerns, but "based on the current content ..." is a bit tricky. Just thinking about the theoretical possibility for someone to make unauthorized changes to an older branch and pass them off as official or pending.
Proposed policy would be to require commiters' names in the branch title and have that person assume responsibility for performing QA on changes made to the branch.
Kevin Power (Jan 09 2020 at 20:21):
Yea, the IG publisher doesn't really think about 'branches' and it adds the text in the box. At least I think that is the case. The good news is that all branches will only build/publish to "build.fhir.org" and says "continuous build" as well - so if someone tries to pass it off as official or pending, it is still going to be hosted on the build server.
RE: name in the branch - after doing that, I sort of disagree with that approach. I think the name should just reflect what we are doing. I am at least ok with having a name in the branch, but still feels weird.
RE: responsible for QA - yes, agree with that, and maybe this is why we should have a name in the branch - they ultimately own what is going on?
Jamie Jones (Jan 09 2020 at 20:23):
Github likely has enough transparency in the commiters' names without needing it in the branch title, but if we don't put an owner on the branch itself we may need a separate doc/system to keep track
Jamie Jones (Jan 09 2020 at 20:25):
We could default to whichever user created the branch. I wouldn't want putting their name on the url to deter volunteers from learning the tools and helping draft proposals
Jamie Jones (Jan 09 2020 at 20:27):
For a relevant example, is there anything we should do about http://build.fhir.org/ig/HL7/genomics-reporting/branches/BretOperationsExampleXMLpage/ ?
Jamie Jones (Jan 09 2020 at 20:28):
I don't even see this branch on github, but it shows up on http://build.fhir.org/ig/HL7/genomics-reporting/branches/
Jamie Jones (Jan 09 2020 at 20:30):
I at least have a good idea of who I could reach out to for more information on it, which I might not have if it were named differently.
Jamie Jones (Jan 09 2020 at 20:33):
looks like Patrick deleted the branch on 10/2/2019 but HL7 is still somehow hosting the output as a full version of the IG
Kevin Power (Jan 09 2020 at 20:37):
I am betting the tooling doesn't hook into delete of branches to clean up build.fhir.org ? Or perhaps it didn't that time for some reason?
Lloyd McKenzie (Jan 09 2020 at 20:39):
For commit privileges, I need an email indicating the repository you need commit to, your git id, an indication that you've read and agree to abide by Chapter 16 of the HL7 GOM and an assertion that you've signed up for and agree to monitor the committers/announce stream.
Kevin Power (Jan 09 2020 at 20:39):
I think that Josh Mandel manages the build side of the tooling world
Kevin Power (Jan 09 2020 at 20:41):
looks like Patrick deleted the branch on 10/2/2019 but HL7 is still somehow hosting the output as a full version of the IG
@Jamie Jones Just curious - where did you find that date?
Jamie Jones (Jan 09 2020 at 20:42):
Closed pull requests had it
Kevin Power (Jan 09 2020 at 20:43):
Ahhh, thanks.
Bob Dolin (Jan 09 2020 at 21:07):
Thanks @Lloyd McKenzie , understood
Bob Dolin (Jan 12 2020 at 18:21):
@Kevin Power @Jamie Jones I created a branch 'fhir_operation', and I tried to create a new page 'src/pagecontent/operations.xml', which I reference from 'src/genomics-reporting.xml'. The build succeeds, but the Table of Contents doesn't reflect the new reference, and operations.xml didn't get converted to html.
Can you tell me what the steps would be to create a new page, and reference it from the table of contents?
Bob Dolin (Jan 12 2020 at 18:28):
Also, I'm trying to figure out how to add an Operation into the IG. I filled out the Operation tab in the DiagnosticReport spreadsheet, but the build failed (not sure why - spreadsheet is attached). So, I reversed those changes, and placed the OperationDefinition resource (hand-crafted, json format) into src/resources. That doesn't break anything, but I'm not sure from there how to reference the resource.
So, a couple questions, and maybe @Lloyd McKenzie could offer some advice? Is there any reason we can't also include json resource definitions in src/resources, in addition to the spreadsheets, and if we do that, how would we reference them?
Bob Dolin (Jan 12 2020 at 18:28):
diagnosticreport-profile-spreadsheet.xml
Jamie Jones (Jan 12 2020 at 18:50):
Operations tab on the report spreadsheet sounds like a great start, do you recall the errors you got during build?
Bob Dolin (Jan 12 2020 at 19:04):
Using the spreadsheet attached above, here is the build.log file that I get
Bob Dolin (Jan 12 2020 at 19:04):
Bob Dolin (Jan 12 2020 at 19:38):
@Jamie Jones Here's a crazy thought - what if for now, we simply create a new Operations page, and just do what we need to do using markdown, foregoing the spreadsheet? Then, down the road when HL7 has a more uniform IG production process and we can include OperationDefinition resources, we go back and formalize it?
Jamie Jones (Jan 12 2020 at 19:39):
I'm in favor of introducing it just as markdown
Jamie Jones (Jan 12 2020 at 19:41):
I don't see how an operation as an xml structuredefinition would be easily implemented without a complex framework already in place (other than validating a returned resource). It feels more like describing a workflow
Kevin Power (Jan 12 2020 at 19:42):
I might have some time tomorrow to see about getting it into the IG properly, I am also fine with getting the Operations page running for now
Bob Dolin (Jan 12 2020 at 19:42):
Here's a draft OperationDefinition resource for find-variants:
Bob Dolin (Jan 12 2020 at 19:42):
find-variants_operation.fhir.json
Bob Dolin (Jan 12 2020 at 19:43):
But I'm not sure how to link to it.
Bob Dolin (Jan 12 2020 at 19:45):
If we wanted to just start with an Operations page with markdown, I've created operations.xml and placed it into src/pagecontent, but can't figure out how to make it show up in the table of contents. Do you know how we modify the table of contents?
Kevin Power (Jan 12 2020 at 19:58):
I am not at my computer now and don’t do that enough to tell you off the top of my head. You can do a search for other pages (like sequencing.xml) to see where all they are referenced?
Lloyd McKenzie (Jan 12 2020 at 19:58):
If you're defining an operation, you should certainly use an OperationDefinition (whether hand-authored by XML or using a spreadsheet). In either case, you'll need to reference it in the ImplementationGuide
Bob Dolin (Jan 12 2020 at 21:12):
@Lloyd McKenzie I can't seem to figure out how to reference the hand-authored OperationDefinition (json format) or the Operation inserted into the spreadsheet. I also can't figure out why I don't seem to be able to reference the new operations.xml page from our table of contents. Feeling kinda stuck...
Lloyd McKenzie (Jan 12 2020 at 21:35):
Referencing would be by declaring it as a resource in your IG. Take a look at the SDC IG (http://github.com/hl7/sdc). It defines several operations.
Bob Dolin (Jan 12 2020 at 22:43):
Thanks @Lloyd McKenzie , that seemed to work - I'm able to reference the hand-crafted operationDefinition (xml format) from the IG (genomics-reporting.xml) without breaking the build. But it doesn't show up anywhere and it's not listed in the Table of Contents artifact list.
Lloyd McKenzie (Jan 12 2020 at 23:44):
Did you reference it in your IG?
Bob Dolin (Jan 13 2020 at 04:53):
@Lloyd McKenzie I think so... I referenced 'src/resources/operationdefinition-find-variants.xml' in the IG like this: <resource>
<reference>
<reference value="OperationDefinition/find-variants"/>
</reference>
<name value="Find variants"/>
<description value="Find variants operation"/>
<exampleBoolean value="false"/>
</resource>
Lloyd McKenzie (Jan 13 2020 at 05:05):
That should work. Is everything committed?
Jamie Jones (Jan 13 2020 at 14:55):
Looks like @Kevin Power's gotten a look at it, any open questions?
Kevin Power (Jan 13 2020 at 14:55):
You actually had the OpDef showing on the Table of Contents (at the bottom), and I just pushed a change to add a 'groupingId', which makes it show up on the Artifact page as well. It is probably intentional, but your "operations.xml" page seems to just be a copy of the implications page.
Kevin Power (Jan 13 2020 at 14:57):
New build:
http://build.fhir.org/ig/HL7/genomics-reporting/branches/fhir_operations/artifacts.html#operations
Kevin Power (Jan 13 2020 at 14:58):
http://build.fhir.org/ig/HL7/genomics-reporting/branches/fhir_operations/find-variants.html
Bob Dolin (Jan 13 2020 at 15:11):
Awesome. Thanks! Everything is very draft, but I'll take care of that now that the plumbing is working. thanks again.
Last updated: Apr 12 2022 at 19:14 UTC
