Stream: terminology / utg
Topic: Release 2.0.0 planning
Ted Klein (Aug 04 2020 at 19:21):
Initial tentative plan is to do the release week of August 10, 2020 if possible. Items to be addressed are: 1) NUCC code errors and value set expansion errors; 2) missing deprecation information disabling coremif generation; 3) incorrect URLs for the title extension for Naming Systems. The goal is to have a completely clean build.'
Ted Klein (Aug 11 2020 at 17:11):
Items to be addressed week of August 10:
Ted Klein (Aug 11 2020 at 17:12):
- Deprecation information in Provenance resources for value sets and code systems for coremif gen support
Ted Klein (Aug 11 2020 at 17:12):
- Deprecation information for concepts not imported from coremif originally
Ted Klein (Aug 11 2020 at 17:12):
- Fixing URL for NamingSystem.title extension where still not fixed
Ted Klein (Aug 11 2020 at 17:13):
- Correcting of remains erroneous v3 coremif-imported NUCC bad codes (those ending in 'N')
Ted Klein (Aug 11 2020 at 17:16):
- Finding some way to suppress the classes of warnings so the build is more tractable for finding 'real' errors. @Grahame Grieve is there something that we can do about this? Even just changing the boilerplate text for the warnings to not include the string "error" so that string can be used when searching through the QA report to find real errors? Going through 4000+ entries in the table on top to try to find the one or two real errors manually looking at the error totals columns on the right side is not really effective.n. Better would be able to suppress whole classes of warning or errors.
Ted Klein (Aug 11 2020 at 17:17):
- Get the new codes for Designation Use value set into FHIR properly (some are already in approved tracker tickets but have never been implemented). Discussed with @Rob Hausam on August 11. FHIR content (code systems) include the code 'display' - addressing the missing 3 values will remove nearly 1700 warnings/errors from UTG build.
Ted Klein (Aug 11 2020 at 17:19):
- Get process for merging approved ticket changes into the UTG Git Master more reepeatable and less fragile so we can go to industrial production. This is a Ted and @Joshua Procious issue and effort primarily.
Ted Klein (Aug 11 2020 at 17:23):
- Need both documentation of and the mailing list setup for UTG participants to sign up to be a reviewer/voter. The plan is for this to be a simple send to an email address which will be rerouted to @Joshua Procious and @Ted Klein to add the person's permissions settings to the UP JIRA project. The other half is a system for WG cochairs to request SGB to add a named person as an oversight group voter to one of the identified Groups for the change request types. Can use same mail system so it can be vetted and then forward to SGB.
Ted Klein (Aug 12 2020 at 18:40):
- We absolutely need a solution for the versioning issue with the imported FHIR code systems rooted at terminology.hl7.org -they were all 4.2.0 when imported, the R5 preview set then to 4.4.0 whether or not they changed, and we have an adopted and approved Vocabulary WG policy on CS versioning which this also violates. We need to solve this and apply the solution for the 2.0.0 release @Grahame Grieve
Grahame Grieve (Aug 13 2020 at 11:38):
- you can suppress classes now
Grahame Grieve (Aug 13 2020 at 11:38):
you can also look at the qa.min.html file instead of qa.html file
Ted Klein (Aug 13 2020 at 21:12):
OK let me mess with it. I did put in a FHIR tracker to get the codes added to core.
Ted Klein (Aug 13 2020 at 21:22):
1.1.11, or do I need to be running 1.1.12?
Grahame Grieve (Aug 13 2020 at 21:32):
1.1.12 is not released yet
Ted Klein (Aug 13 2020 at 23:08):
ok. Well, with same IG input, error count has gone from 2 to 1449. I've got a bit of work to do to figure them out and suppress the ones we know about and need to suppress (the designationUse ones primarily).
Ted Klein (Aug 25 2020 at 14:03):
- We still do not have the additional codes used in UTG and some FHIR code systems for http://build.fhir.org/valueset-designation-use.html There are FHIR tracker items for these, and at some point they need to be added to the value set.
Ted Klein (Aug 27 2020 at 18:09):
Some change made between IGP 1.1.13 and 1.1.15 has introduced 494 errors into the UTG build. @Grahame Grieve you made a decision months ago about the extension URL to be used for the URL for NamingSystem, and we put that in all our NamingSystem resources. Now in IGP 1.1.15, every NamingSystem gives an error like: NamingSystem/SNT: NamingSystem.extension[1][url='http://hl7.org/fhir/5.0/StructureDefinition/extension-NamingSystem.url'] error Extension url 'http://hl7.org/fhir/5.0/StructureDefinition/extension-NamingSystem.url' is not valid (invalid Version '5.0')
NamingSystem/SNT: NamingSystem.extension[1].url error URL value 'http://hl7.org/fhir/5.0/StructureDefinition/extension-NamingSystem.url' does not resolve
Ted Klein (Aug 27 2020 at 18:09):
Did you change the URL and now we need to update to the new one in all of our resources?
Grahame Grieve (Aug 27 2020 at 21:34):
no. that's some problem in the infrastructure. Don't change anything
Ted Klein (Aug 27 2020 at 22:35):
ah ok thank you I won't worry about it then.
Ted Klein (Sep 14 2020 at 13:31):
we are still unable to do a ci build of UTG - I can build it locally (but I have a beast of a laptop), but @Rob Hausam and @Josh Mandel are still unable to do so, We cannot go to release or really continue the pilot as we cannot build the consensus review pages without the ci build running. @Grahame Grieve my perception is this is critical to get addressed, but I am biased :-) How can we proceed?
Vassil Peytchev (Sep 14 2020 at 14:15):
Since it seems you are the only one who can build it, is it possible that there is some unchecked change that was not pushed to the server?
One way to check of this is to do a local checkout to an empty directory and do the build there. From the local directory that contains the latest branch (assuming master, substitute if necessary):
mkdir /tmp/build_check
git --git-dir=<your curent git working dir> --work-tree=/tmp/build_check checkout -f master
Then build in /tmp/build_check to confirm that what is currently checked in can indeed build.
Grahame Grieve (Sep 14 2020 at 17:12):
@Josh Mandel I am investigating this. Ruby memory usage during the Jekyll run is pretty stable at 1857MB.
Josh Mandel (Sep 14 2020 at 17:13):
Okay, thanks! There should be at least 6GB reserved for Jekyll in the current auto build configuration (I would like to dial this back once we get everything under control)
Grahame Grieve (Sep 14 2020 at 17:15):
for me, Jekyll started at 11 minutes, and took 719 seconds. It claimed to succeed but returned an non-zero exit code
Grahame Grieve (Sep 14 2020 at 17:18):
looking at the build, I don't see any entries in the ig-build zulip topic since August
Grahame Grieve (Sep 14 2020 at 17:19):
but I see this from the build registry:
Generating Summary Outputs (06:33.0968)
Sending Usage Stats to Server (08:55.0484)
Jekyll: Source: /scratch/ig-build-temp-AZ79WF/repo/temp/pages (08:58.0687)
Jekyll: Generating... (08:58.0688)
Jekyll: done in 53.817 seconds. (09:52.0505)
Checking Output HTML (12:07.0736)
found 31287 files (12:07.0845)
Grahame Grieve (Sep 14 2020 at 17:20):
its
Grahame Grieve (Sep 14 2020 at 17:20):
it's running a lot faster than for me, but produced the right amount of files. So I don't know why we think jekyll is a problem
Grahame Grieve (Sep 14 2020 at 17:21):
can this line:
*** Timeout -- deadline reached
say what the deadline is?
Grahame Grieve (Sep 14 2020 at 17:25):
in the post Jekyll html review phase, my memory utilization is 17,131 MB (the java process).
Josh Mandel (Sep 14 2020 at 17:32):
Deadline has been 3600s for months at least; can add more logging
Josh Mandel (Sep 14 2020 at 17:32):
(At least at the start of a run, to print the deadline.)
Josh Mandel (Sep 14 2020 at 17:33):
Ah, it sounds like Java needs more than the 15GB allotted to it
Grahame Grieve (Sep 14 2020 at 17:34):
I'm re-engineering that part. It's not faster to load the entire html into an object structure to save from parsing the files twice
Grahame Grieve (Sep 14 2020 at 17:59):
it's also not necessary to continue to hold a bunch of information in memory that will no longer be used while Jekyll runs
Ted Klein (Sep 17 2020 at 02:47):
@Vassil Peytchev took a fresh new clone from the master and built locally just fine. Grahame can also build it without trouble.
Ted Klein (Sep 24 2020 at 20:11):
@Grahame Grieve did you JUST within the last hour or two make some change related to the UCUM discussion yesterday? A value set the has not given any trouble for over a year now is breaking the UTG build...the CLD for it is: <compose>
<include>
<system value="http://unitsofmeasure.org"/>
<version value="2.1.0"/>
<concept>
<code value="[lb_av]"/>
</concept>
<concept>
<code value="[oz_av]"/>
</concept>
<concept>
<code value="kg"/>
</concept>
<concept>
<code value="g"/>
</concept>
</include>
</compose>
Ted Klein (Sep 24 2020 at 20:11):
did you change the uri http://unitsofmeaasure.org?
Ted Klein (Sep 24 2020 at 20:28):
It builds locally but not on the UTG ci build
Grahame Grieve (Sep 24 2020 at 20:53):
how is it 'breaking' the build?
Ted Klein (Sep 24 2020 at 21:17):
It is timing out in expand calls to tx.fhir.org so I likely misdiagnosed the later error message from Jekyll. @Grahame Grieve maybe a transient issue kicked the build off again I'll let you know if it worked this time or not.
Ted Klein (Sep 24 2020 at 21:22):
well now it gets interestinger: the error from the build just kicked off is: NFO:root:about to clone!
DEBUG:root:running: git clone --recursive https://github.com/HL7/UTG --branch master repo
DEBUG:root:Time to deadline 3479.997547 seconds
Cloning into 'repo'...
DEBUG:root:running: wget -q https://github.com/HL7/fhir-ig-publisher/releases/latest/download/publisher.jar -O publisher.jar
DEBUG:root:Time to deadline 3473.959357 seconds
DEBUG:root:running: npm -g install fsh-sushi
DEBUG:root:Time to deadline 3473.742036 seconds
/usr/local/bin/sushi -> /usr/local/lib/node_modules/fsh-sushi/dist/app.js
- fsh-sushi@0.16.0
added 16 packages from 32 contributors and updated 5 packages in 9.027s
DEBUG:root:running: java -Xms19000m -Xmx19000m -jar ../publisher.jar -ig ig.json -auto-ig-build -target https://build.fhir.org/ig/HL7/UTG/ -out /scratch/ig-build-temp-U5PFP2/repo
DEBUG:root:Time to deadline 3464.234981 seconds
Error: Invalid or corrupt jarfile ../publisher.jar
Ted Klein (Sep 24 2020 at 21:22):
corrupt publisher.jar file
Ted Klein (Sep 24 2020 at 21:22):
she something is seriously awry
Grahame Grieve (Sep 24 2020 at 21:32):
try again - maybe it was while Mark was releasing the new version
Ted Klein (Sep 24 2020 at 22:23):
Must have b been as it just worked now
Jessica Bota (Oct 05 2020 at 17:37):
@Grahame Grieve and @Lloyd McKenzie , can you provide an update and remaining estimates on where we are with fixing the FHIR R5 versions and the coremif generation? It has been decided that publishing v2.0.0 with these fixes is a blocker for going live with UTG so I need to plan accordingly. Thanks in advance!
Jean Duteau (Oct 05 2020 at 18:14):
Jessica Snell said:
It has been decided that publishing v2.0.0 with these fixes is a blocker for going live with UTG so I need to plan accordingly.
@Jessica Snell I'm just a lurker on this stream, but I was wondering if you could give some clarification on the above statement. I thought that UTG was live and that it needed to be used for all FHIR terminology.
Jessica Bota (Oct 05 2020 at 18:22):
@Jean Duteau , while UTG is technically in 'Pilot' phase, the process for vocabulary maintenance is live in the sense that if you propose changes and they are approved, they will be implemented in the current build of the HL7 Terminology. We are awaiting final blessing from TSC, CTO, etc. to make official announcements and it was agreed that V2.0.0 of the content must be published first. V1.0.0 (our current published version) has several issues that need to be fixed before we are comfortable going live with the content as well. I apologize that it is a bit confusing.
Grahame Grieve (Oct 05 2020 at 18:57):
I don't know what this means:
fixing the FHIR R5 versions
Jessica Bota (Oct 05 2020 at 19:00):
@Grahame Grieve , this was discussed on the joint FHIR-I/Vocab call. Please see https://confluence.hl7.org/display/VOC/Sept+2020+-+Virtual+HL7+WGM+-+Thursday+6PM+Minutes at 6:50 for the details.
Jessica Bota (Oct 05 2020 at 19:00):
I could have noted it better :)
Ted Klein (Oct 05 2020 at 19:05):
@Grahame Grieve you said in the joint WGM session that you would have to fix it, ie figure out the version numbers of the FHIR content and set the properly depending upon what has been changed since the import from R4 to the R5 preview and then update the FHIR content in the UTG SoT. So I am not touching the FHIR stuff, and I am sitting on Bryn's updates (UP-68) to the FHIR stuff for ECQM until you do your thing. Jess was just following up I think as we are all coming under pressure to do the release here.
Grahame Grieve (Oct 05 2020 at 19:23):
ah ok
Grahame Grieve (Oct 05 2020 at 19:39):
@Ted Klein do we have a definitions of which code systems and value sets this is about? any with version 4.x.x?
Ted Klein (Oct 05 2020 at 20:48):
@Grahame Grieve no the is the issue. You pushed R4 all at version 4.2.0 to UTG months ago and I have no idea which of the FHIR objects may have been updated in FHIR since then. The only one that has been updated in UTG is http://hl7.org/fhir/codesystem-measure-population.html
Grahame Grieve (Oct 05 2020 at 21:16):
I re-pushed them. They are all up to date in UTG. The open question that the minutes refer to is different - what version should all these value set and code systems have
Grahame Grieve (Oct 06 2020 at 10:52):
ok. using this algorithm:
- for each FHIR value set or Code System:
- give it version 0.1.0
- for each milestone version it has been published in, and changed, increment the minor version
- if it's got FMM 3-5 in R4 increment the minor version to 0.5.0
- if it's normative in R4, increment the major version so it's 1.0.0
Grahame Grieve (Oct 06 2020 at 10:53):
that gives this map:
Grahame Grieve (Oct 06 2020 at 10:53):
(snip)
Grahame Grieve (Oct 06 2020 at 10:53):
@Ted Klein if you're happy with this, I'll make all these changes, and create entries in the history for the change.
Grahame Grieve (Oct 06 2020 at 10:58):
Rob Hausam (Oct 06 2020 at 12:57):
I guess the assumption here is that R4 will only have a small number of further changes that would affect these code systems and value sets (i.e. only R4B?), so anything that isn't already at FMM 3-5 could never get to 0.5.0 with just further changes (unless it's moved up to at least that level in maturity)? But I'm not sure how this works once we do get to R5 and beyond. Can you elaborate? Having the version ranges tied to FMM could become an issue at some point?
Ted Klein (Oct 06 2020 at 14:20):
I think this is good - do you want to switch the order of sub=bullets 2 and 3? Just so then if it has been updated from R4.0.1 to R5 preview it does not miss a minor version increment? Btw the vocab code system policy approved last month was that almost all code system changes except very minor typos and such were major number increments (I did not agree as I think that causes more trouble in the community than it is worth, but I lost the vote). I think its good - hold off commit/push to the Git UTG master Josh and I discovered some strange sync/merge/tag issue early this morning we are looking into don't want to make it worse today.
Ted Klein (Oct 06 2020 at 14:21):
@Rob Hausam this for for those FHIR items that are rooted at terminology.hl7.org, and going forward after this re-synch all updates to them will be only through UTG, NOT using the FHIR ecosystem.
Ted Klein (Oct 06 2020 at 14:22):
It is my understanding that at this time all changes to things rooted at hl7.org/fhir will continue to be maintained as they have been in the past.
Jessica Bota (Oct 06 2020 at 16:17):
@Lloyd McKenzie @ any update on the coremif stuff?
Lloyd McKenzie (Oct 06 2020 at 18:11):
not yet
Grahame Grieve (Oct 06 2020 at 19:02):
@Rob Hausam after this algorithmically driven reset, UTG versioning applies
Ted Klein (Oct 12 2020 at 21:44):
@Grahame Grieve do you have an estimate on which day you will do this?
Grahame Grieve (Oct 12 2020 at 22:14):
oh. forgot. I'll try to get to it today
Ted Klein (Oct 13 2020 at 00:47):
that would be great. I want us to shoot for release 2.0.0 sometime next week; Lloyd can't get to the coremif debug until the weekend.
Grahame Grieve (Oct 13 2020 at 00:48):
should I make a new history bundle? or keep adding to the one of the existing ones?
Ted Klein (Oct 13 2020 at 12:13):
probably best to add the entries to utgrel1hx-1-0-6.json
Ted Klein (Oct 13 2020 at 12:29):
I am leaning towards having no more than 10 hx bundles per main release
Ted Klein (Oct 13 2020 at 21:36):
When you do the change and commit to the source of truth, please remember to bump up the build number in the utg.xml ig file version. Thanks.
Grahame Grieve (Oct 14 2020 at 05:38):
I am not resetting "v3-DataOperation" and "v3-KnowledgeSubjectObservationValue" though they look like candidates to me
Ted Klein (Oct 14 2020 at 13:24):
Those are in FHIR? I thought they were in v3...from the coremif...let me look into these two. Thanks for getting this done.
Ted Klein (Oct 14 2020 at 13:27):
When will you remove the duplicate entries - the "External(FJIR)" tab - in the R5 ci build?
Ted Klein (Oct 14 2020 at 17:50):
OK those 2 v3 objects (a CS and a VS) had their versions updated as per Vocab WG versioning policy through several UTG revisions and thus ended up have a same version ID as the FHIR ones you were updating. So just an artifact, and they will remain the same.
Grahame Grieve (Oct 14 2020 at 19:17):
don't know when I'll get around to removing them from R5. Soon
Grahame Grieve (Oct 14 2020 at 19:17):
I believe I'm done with this
Ted Klein (Oct 14 2020 at 23:12):
ok - another question: since you started messing with the search and history stuff the ci build has the error: searchform.html#/html/body/div/div/a/img/div/div/nav/div/div/ul/li/a at Line 64, column 21 error The link 'history.html' for "History" cannot be resolved
Jean Duteau (Oct 14 2020 at 23:13):
that's an error that every guide appears to have
Ted Klein (Oct 14 2020 at 23:13):
is this something I have to fix somehow? or will it go away when another fix is done to the Publisher?
Ted Klein (Oct 14 2020 at 23:14):
Yes Jean, it seems so. I am trying to get the last of the errors out of the UTG build so we can do release 2.0.0 next week.
Grahame Grieve (Oct 14 2020 at 23:26):
that issue won't stop publishing whatever. But it should have gone away with the latest release
Jean Duteau (Oct 14 2020 at 23:48):
it didn't - as I'm using the latest release.
Ted Klein (Oct 15 2020 at 18:24):
yes just ran a build with 1.1.35 and the error is still there
Ted Klein (Oct 22 2020 at 22:18):
@Grahame Grieve I want to schedule the 2.0.0 release of UTG for next week (week of October 26), I think nearly all of the items listed at the head of this thread have been addressed with the exception of a couple remaining Provenance and property values I am working on today and tomorrow, the coremif thing I have been nagging @Lloyd McKenzie about for weeks and weeks, and the new extension and processing of it in the Publisher that you promised @Reuben Daniels and myself a couple weeks ago to finish the resolution of the code system stubs for infrastructure code systems. Please note that INHO this same extension can be used to inhibit processing of (validation and expansion) of the retired value sets (to solve the last bits of the NUCC issue). Perhaps you and I can have a brief chat on this before you start your weekend so we can make sure all the ducks are in a row and we are ready to go.
Grahame Grieve (Oct 25 2020 at 23:42):
@Reuben Daniels
http://hl7.org/fhir/StructureDefinition/codesystem-properties-mode
it's a code with a value of not-present | partial | complete, e.g.
{
"extension" : [{
"url" : "http://hl7.org/fhir/StructureDefinition/codesystem-properties-mode",
"valueCode" : "not-present"
}]
}
Grahame Grieve (Oct 25 2020 at 23:43):
will be in build.fhir.org some time soon
Ted Klein (Oct 26 2020 at 17:22):
thanks much Grahame - I'll go over this with Reuben when he is up and going later today.
Ted Klein (Jun 16 2021 at 23:20):
Need to rename this stream to just 'THO Release Planning'; currently working on last merges into ci build before freeze for the 2.2.0 release, which has been approved by TSC and CTO. Expect to begin the release process tomorrow June 17 North America time. Is this ok for you @Grahame Grieve ??
Grahame Grieve (Jun 16 2021 at 23:29):
ok
Ted Klein (Jun 21 2021 at 21:28):
@Grahame Grieve did you get a chance to look into why the 600 new errors on the NamingSystem extensions used in UTG/THO were introduced by one of the recent Publisher updates? I would really like to get these resolved rather than having to do a release with 600+ errors...
Ted Klein (Feb 07 2022 at 20:11):
@Grahame Grieve I have in hand the request from TSMG (will be ratified by TSC this week I am sure) for the next release of THO. So I need to go over a few items with you in order to plan doing the release. The UTG/THO ci build will be frozen February 20 (Sunday in North America) and the release will proceed the following week. Need to ask you about the 400+ warnings about the case sensitivity element in CodeSystem resources that you had said you could fix straightforwardly - do you still plan to do that, or not enough cycles? I also expect that as in every prior release, new and unknown issues will arise during the publishing process. Please let me know a time we can spend 10 minutes or so discussion and planning; I will be out of pocket for several weeks beginning March 1, so we have limited time to get it done.
Grahame Grieve (Feb 07 2022 at 20:38):
hmm. I'm authorised to fix them?
Ted Klein (Feb 07 2022 at 21:04):
@Grahame Grieve well...ummm...not sure what you mean 'authorized'. Do we want to proposal a wholesale fix for all fo the offending ones? ie a script that just adds the element in the right place...I am not sure the best way to proceed.
Ted Klein (Feb 07 2022 at 21:06):
It would involved the add of the element, increment of the minor digit of the version tag value, and a creation of a Provenance entry for the history...thus not only just adding the element.
Grahame Grieve (Feb 07 2022 at 21:12):
I can do all that easily. The problem was not the doing of it, it was the change control process
Ted Klein (Feb 07 2022 at 21:29):
well we put it all in a UP ticket that is type pro-forma, and process it and send it through. the Provenance entries get the audit information - and I was going to ask you is it possible to put the URL link for the ticket in the text there? e.g. the entries for the text for the reason in them is encoded right now as: "text": "Add CMS Prescription Drug Hierarchical Condition Categories per HTA; UP-269". It would be nice in the build to have the "UP-269" be a link to point to https://jira.hl7.org/browse/UP-269 I am unsure if the publisher when it builds the rendered History page can process the input json file to put a navigable link into the generated html pages. If not, I'll put in a low priority ticket to add it; if so, let me know what I should have as input syntax in the json for URLs that look like this one. Thanks.
Ted Klein (Feb 07 2022 at 21:30):
Let me know if you need me to create the UP ticket to apply the changes to effect the add of the case sensitive element to the CodeSystem resources
Grahame Grieve (Feb 07 2022 at 21:33):
the entries for the text for the reason in them is encoded right now as: "text": "Add CMS Prescription Drug Hierarchical Condition Categories per HTA; UP-269".
where exactly does this go?
Grahame Grieve (Feb 07 2022 at 21:33):
and sure, create the task
Ted Klein (Feb 07 2022 at 21:36):
Sorry I didn't quote you the entire provenance resource in the bundle for the example. Here it is:
Ted Klein (Feb 07 2022 at 21:36):
"fullUrl": "http://terminology.hl7.org/fhir/Provenance/CMSRxHCC-ns-3-0-5",
"resource": {
"resourceType": "Provenance",
"id": "hx1i-CMSRxHCC-ns-3-0-5",
"target": [
{
"reference": "NamingSystem/CMSRxHCC"
}
],
"occurredPeriod": {
"end": "2022-01-29"
},
"recorded": "2022-01-29T00:43:55-06:00",
"reason": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-ActReason",
"code": "METAMGT"
}
],
"text": "Add CMS Prescription Drug Hierarchical Condition Categories per HTA; up-269"
}
],
"activity": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-DataOperation",
"code": "CREATE"
}
]
},
"agent": [
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
"code": "author"
}
]
},
"who": {
"display": "Jessica Bota"
}
},
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
"code": "custodian"
}
]
},
"who": {
"display": "HTA"
}
}
]
}
Grahame Grieve (Feb 07 2022 at 21:43):
Shouldn't the task reference go in Provenance.meta.source?
Grahame Grieve (Feb 07 2022 at 21:44):
... no, I suppose not
Grahame Grieve (Feb 07 2022 at 21:44):
it just seems like too much information for the reason.text
Ted Klein (Feb 07 2022 at 21:46):
yes that was my thought as well, but no other sensible place to put it that I could see. Right now I just have the text of the ticket (e.g. 'UP-269') which can be used to search in Jira. Ah well. If a great notion occurs to you, let me know. Here is your ticket for the caseSensitive element: https://jira.hl7.org/browse/UP-286
Grahame Grieve (Feb 07 2022 at 21:54):
@Lloyd McKenzie the extension would be http://hl7.org/fhir/extension-event-basedon.html would be appropriate for this, but it's constrained to point to a resource. Would we consider a jira reference to be an implicit reference to a task?
Ted Klein (Feb 07 2022 at 21:58):
It is actually (once fully implemented) no longer a task, but the audit trail for the decision including voting and discussion. So technically...ummm...not a task. And definitely not a FHIR resource...
Lloyd McKenzie (Feb 07 2022 at 21:59):
You could model a Jira instance as a Task I guess. Though I think a better long-term solution is allow basedon to be a URI as well.
Ted Klein (Feb 07 2022 at 22:00):
@Lloyd McKenzie completely agree, as even for the original intended use for Provenance it might be a pointer to some external document somewhere. Or any event for that matter...but using an extension then begs the question of how to render it in THO on the History tab...
Grahame Grieve (Feb 08 2022 at 01:34):
oh I have to render it however we solve it
Grahame Grieve (Feb 08 2022 at 01:36):
@Ted Klein so can we make it based on:
"extension" : [{
"url" : "http://hl7.org/fhir/StructureDefinition/event-basedOn",
"valueUri" : "https://jira.hl7.org/browse/UP-286"
}]
Grahame Grieve (Feb 08 2022 at 01:36):
I can render that
Ted Klein (Feb 08 2022 at 03:02):
yes I can add that to the resource easy enough, I have a bash script to generate the json based on fields in the ticket and the <id> of the resource...any particular place in the provenance json it needs to be?
Grahame Grieve (Feb 08 2022 at 04:01):
just an extension on the root of the provenance. order doesn't matter in the json resources
John Moehrke (Feb 08 2022 at 13:34):
Sure seems to me you all are inventing a basedOn concept when you actually have a .entity.what.
I do like the idea of moving what to a Reference(Any) or URI.
But, why if you have a URL can't you put that into .entity.what.identifier.value and be done?
Grahame Grieve (Feb 08 2022 at 20:14):
how could it be an entity - it's the cause, not the source
Grahame Grieve (Feb 08 2022 at 20:15):
and basedOn is added in the R5 draft, and it's very much 'basedOn'. @John Moehrke
John Moehrke (Feb 08 2022 at 21:29):
Well, yes it is in the R5 draft. That means it was not part of a ballot yet. I don't particularly agree with all of the decomposition of .entity into root level elements like basedOn, encounter, etc... That said, I entertain CR changes so as to inspire ballot comments.
John Moehrke (Feb 08 2022 at 21:29):
.entity is "an entity used in this activity". It is not only "sources".
John Moehrke (Feb 08 2022 at 21:30):
source is only one .entity.role
John Moehrke (Feb 08 2022 at 21:30):
no question that the .entity.role vocabulary may need improvements.
John Moehrke (Feb 08 2022 at 21:32):
likely need to move the Provenance modeling discussion to a stream for that.
Grahame Grieve (Feb 08 2022 at 21:36):
well, sure but there
Grahame Grieve (Feb 08 2022 at 21:36):
there's no role for 'prompted by' now
John Moehrke (Feb 08 2022 at 21:39):
yes, i get the need. just would prefer if all of the kinds of entity (in W3C terms) were all clearly understood as entity. The way it is decomposing makes relating the current UML diagram for Provenance to the W3C Prov model very hard to visualize.
Ted Klein (Feb 10 2022 at 19:52):
Well we will definitely not be doing any of these things in the THO Provenance resources until this all gets settled and is in the balloted spec. Right now it is only comment text that can be used for those needed to track down the details for a particular change.
Ted Klein (Feb 15 2022 at 14:32):
@Grahame Grieve can all of the warnings about the missing <caseSensitive> element be suppressed in one go in the ignorewarnings.txt file? Or would they have to be put in there one by one? Just trying to figure some way to clean up UTG/THO for the release without the pressure of having to fix all this stuff in this coming week; content freeze is next weekend Feb 20.
Ted Klein (Feb 18 2022 at 21:37):
@Grahame Grieve I am prepping for the Release next week of THO 3.1.0 - first question: did the base infrastructure of ReleaseRootWeb change? If not, I don't need to update it prior to starting the process. Let me know, thanks.
Grahame Grieve (Feb 18 2022 at 21:57):
it hasn't changed, but I think I made changes to the HTML, putting https everywhere in the script references, so update the source anyway
Ted Klein (Feb 18 2022 at 22:24):
ah ok will do
Ted Klein (Feb 19 2022 at 21:40):
these are al part if the server copy of ReleaseRootWeb, yes? Pulling a fresh copy should take care of it? Or are these updated files elsewhere?
Grahame Grieve (Feb 20 2022 at 11:13):
yes just pull a fresh copy. Nothing from anywhere else
Ted Klein (Feb 22 2022 at 18:33):
another question before I run the publish build on it: do I need to do a pull to refresh/update the ighistory and igregistry git repo local copies before running the publish java command?
Grahame Grieve (Feb 23 2022 at 06:30):
yes
Ted Klein (Feb 23 2022 at 13:53):
well I didn't do that...so good thing the publish build failed and I have to fix some bullcrap and run again.
Ted Klein (Feb 23 2022 at 22:49):
@Grahame Grieve at very end (I think) the THO/UTG publish scripts failed, mysterious error. Gonna need your help to do the release, something looks broken. Complains when writing dist-hist file, source and destination the same. Unknown cause.
Ted Klein (Feb 23 2022 at 23:24):
Source '/users/tedklein/documents/tedhl7/vocabulary/projects/utg/ReleaseSupport/ReleaseRootWeb/dist-hist' and destination '/users/tedklein/documents/tedhl7/vocabulary/projects/utg/ReleaseSupport/ReleaseRootWeb/dist-hist' are the same
Exception publishing: Error Processing /users/tedklein/documents/tedhl7/vocabulary/projects/utg/ReleaseSupport/ReleaseRootWeb, cannot continue. (Source '/users/tedklein/documents/tedhl7/vocabulary/projects/utg/ReleaseSupport/ReleaseRootWeb/dist-hist' and destination '/users/tedklein/documents/tedhl7/vocabulary/projects/utg/ReleaseSupport/ReleaseRootWeb/dist-hist' are the same)
Ted Klein (Feb 23 2022 at 23:25):
This error occurred three times in a row and the publishing halted and returned to command line. I do not know how to proceed from here.
Ted Klein (Feb 23 2022 at 23:40):
the log file does not appear to be on my system: Full log in /var/folders/74/3b8b0jws0nnc0plccd08gm940000gn/T/publication-process.log
Ted Klein (Feb 23 2022 at 23:42):
The milestone release 3.1.0 folder with what looks like complete content does appear to have been created in the 'bldpubtmpf' folder (passed as the argument in the -temp parameter to the java publish command).
Ted Klein (Feb 23 2022 at 23:46):
Actually, the 3.1.0 WAS created in ReleaseRootWeb, and the history.html page there looks actually ok. The content in the release folders also looks ok.
Ted Klein (Feb 23 2022 at 23:47):
looks like just some bits for dist-hist were not properly created. No 'dist' folder, and 'dist-hist' is empty in the new ReleaseRootWeb folder. Really is starting to look like an error maybe a typo in the script near the end.
Ted Klein (Feb 23 2022 at 23:49):
@Grahame Grieve really need to get to the bottom of this, hopefully something very simple and quick and I can get the release out.
Ted Klein (Feb 24 2022 at 00:36):
dunno how to check if the redirects (php scripts?) were generated; dunno how far in the publish build process it got before it error terminated.
Grahame Grieve (Feb 24 2022 at 00:38):
I think this is a start again thing, and I think I have figured out what is going on. I'll issue a new publisher
Ted Klein (Feb 24 2022 at 00:42):
sigh. ok can do. restore again the copy I made of ReleaseRootWeb. Will run again when you get publisher 107 released. Hopefully soon so I can let it run overnight tonight; there are now over 330000 files to upload, and I am offline from the weekend...until April.
Ted Klein (Feb 24 2022 at 00:42):
anything else you need? anything from me to make sure we have the issue licked? you need to look at anything on my system?
Grahame Grieve (Feb 24 2022 at 00:44):
Don't think so
Ted Klein (Feb 24 2022 at 00:44):
should I do another pull of ighistory? or igregistry?
Grahame Grieve (Feb 24 2022 at 00:56):
n
Grahame Grieve (Feb 24 2022 at 01:14):
try again
Ted Klein (Feb 24 2022 at 02:27):
ok thanks just ran a regular local build with 107 to make sure all is well there. will now kick off the publish build and let it run whilst I sleep - will check results in the morning when I get up. thanks.
Ted Klein (Feb 24 2022 at 14:40):
ok just up and about this morning. I guess this is the message we were looking for, eh?
Ted Klein (Feb 24 2022 at 14:40):
Finished Publishing
Success
Ted Klein (Feb 24 2022 at 14:54):
I note that now there are folders 'assets', 'assets-hist', and 'dist-hist'. There is no folder 'dist'. I assume this is correct and as intended?
Grahame Grieve (Feb 24 2022 at 19:51):
I think so
Ted Klein (Feb 24 2022 at 19:53):
Hmmm...your definitiveness makes me nervous :-)
Last updated: Apr 12 2022 at 19:14 UTC
