FHIR Chat · Publishing IGs · committers

Stream: committers

Topic: Publishing IGs

Grahame Grieve (Mar 29 2019 at 19:54):

I have requests for publishing IPS and an updated QICore. Any other guides to publish? @Eric Haas US-Meds?

Grahame Grieve (Mar 29 2019 at 19:59):

and there's an argonaut guide waiting?

Grahame Grieve (Mar 29 2019 at 20:41):

also, what is this for: https://gforge.hl7.org/gf/project/tsc/tracker/?action=TrackerItemEdit&tracker_item_id=19486&start=0 @Eric Haas @Brett Marquard

Grahame Grieve (Mar 29 2019 at 20:43):

@Bryn Rhodes QI-Core needs some work on publishing readiness (check the QA...)

Brett Marquard (Mar 29 2019 at 20:57):

that tracker is for US Core which you published on 12/4/2018

Brett Marquard (Mar 29 2019 at 20:57):

US Meds is in holding pattern

Brett Marquard (Mar 29 2019 at 20:57):

Ideally ready again May.

Brett Marquard (Mar 29 2019 at 20:58):

Argonaut Clinical Notes has two minor issues in examples I need to fix...unless you see anything else.

Grahame Grieve (Mar 29 2019 at 20:59):

looks close...

Grahame Grieve (Mar 29 2019 at 21:00):

IPS, QICore, ClinicalNotes. ok

Eric Haas (Mar 29 2019 at 21:14):

Argo Q is ready pending a pass on the QR example errors which I believe are invalid

Eric Haas (Mar 29 2019 at 21:15):

(See my prior posts)

Bryn Rhodes (Mar 29 2019 at 21:46):

@Grahame Grieve , updated the history and package-list issues

Grahame Grieve (Mar 29 2019 at 21:47):

great. One more big new requirement coming...

Rob Hausam (Mar 29 2019 at 22:01):

@Grahame Grieve Not quite sure what "looks close .... ok" means?

Grahame Grieve (Mar 29 2019 at 22:02):

clinical notes is close. I haven't looked at IPS again yet

Rob Hausam (Mar 29 2019 at 22:04):

ok - they were listed together so I wasn't quite sure how to interpret
let me know whenever you are ready to look at IPS - not very many issues left

Grahame Grieve (Mar 29 2019 at 22:04):

ok

Grahame Grieve (Mar 29 2019 at 23:07):

@Bryn Rhodes @Rob Hausam @Brett Marquard I added a new test criteria - it's a technical thing to do with HTML. Lots of errors, but probably only one fix in your template....

Rob Hausam (Mar 29 2019 at 23:08):

ok - I'll take a look

Eric Haas (Mar 29 2019 at 23:08):

what about Argo Questionnaire?

Eric Haas (Mar 29 2019 at 23:09):

Clinical Notes and Argo Q use the exact same framework

Grahame Grieve (Mar 29 2019 at 23:10):

am I supposed to publishing that too?

Eric Haas (Mar 29 2019 at 23:10):

I've said it about 4 times

Grahame Grieve (Mar 29 2019 at 23:10):

ok. then that too

Grahame Grieve (Mar 29 2019 at 23:11):

Hl7/IPS, Hl7/QICore, Argo/ClinicalNotes, Argo/Questionnaire

Eric Haas (Mar 29 2019 at 23:42):

I still get the errors for every page like this one:

index.html  error   The html source does not contain the header marker

even though I added the header marker to everypage...

Eric Haas (Mar 29 2019 at 23:43):

pasted image

Eric Haas (Mar 29 2019 at 23:43):

see the figure above. what am I missing?

Grahame Grieve (Mar 29 2019 at 23:50):

did you read the doco?

Eric Haas (Mar 29 2019 at 23:51):

"This header is updated any time a new version of the IG is published - e.g. the old published versions of the IG are updated. In order to facilitate such actions, the IG - when presented for publication - SHALL have this HTML fragment in an appropriate place in the HTML source of the page:

<!--ReleaseHeader--><p id="publish-box">Publish Box goes here</p><!--EndReleaseHeader-->
This must present in the product section of the page (see below) and must be rendered as a yellow box with a maroon border (as shown above)."

Eric Haas (Mar 29 2019 at 23:57):

so i added this to my publish-box html

<!--ReleaseHeader-->
<p id="publish-box">
This is the {% if {{site.build}} == "ci" %}
    Continuous Integration Build
   {% else %}
    (release {{site.data.fhir.ig.version}})
  {% endif %}
  {% if {{site.build}} == "ballot" %} {{site.ballot}} Ballot {% endif %}
  of the {{site.data.fhir.igName}} Implementation Guide,  based on <a href="{{ site.data.fhir.path }}index.html">FHIR Version {{ site.data.fhir.version }}</a>.  See the <a href="{{ site.historypath }}">Directory of published versions.</a>
</p>
<!--EndReleaseHeader-->

which is included into the layouts.

Grahame Grieve (Mar 30 2019 at 00:18):

just change it to this directly: <!--ReleaseHeader--><p id="publish-box">Publish Box goes here</p><!--EndReleaseHeader-->

Grahame Grieve (Mar 30 2019 at 00:18):

don't do anything else at all. The tools are taking over managing the content of it completely

Eric Haas (Mar 30 2019 at 00:19):

ok so it is the literal text....got it.

Eric Haas (Mar 30 2019 at 00:55):

updated both Argo-Clinical Notes and Argo Questionnaire. Like Brett said there are a couple of errors in Clinical Notes we need to iron out.

David Pyke (Mar 30 2019 at 00:59):

You're an evil, evil man adding requirements this late in the game.

Eric Haas (Mar 30 2019 at 01:06):

sigh ...the autobuilder produced dozens of links errors for all the us-core dependencies which are not present in my local build.

it looks like a local file but not a local file that is recognizeable for my machine?

The link 'file:C:\work\org.hl7.fhir.publish\hl7.fhir.us.core#2.0.0\output/StructureDefinition-us-core-patient.html' for "US Core Patient Profile" cannot be resolvedThe link 'file:C:\work\org.hl7.fhir.publish\hl7.fhir.us.core#2.0.0\output/StructureDefinition-us-core-patient.html' for "US Core Patient Profile" cannot be resolved

David Pyke (Mar 30 2019 at 01:08):

Mine too.

David Pyke (Mar 30 2019 at 01:11):

I also just updated the IGpublisher and was fine but the autobuilder got "Version mismatch. This IG is version 4.0.0, while the IG 'core' is from version 3.0.1 (will try to run anyway) (34.0598sec)"

Grahame Grieve (Mar 30 2019 at 02:12):

neither of these are new things

Eric Haas (Apr 01 2019 at 17:14):

this bad link thing is indeed new :

'file:C:\work\org.hl7.fhir.publish\hl7.fhir.us.core#2.0.0\output/ValueSet-us-core-medication-codes.html' for "Medication Clinical Drug (RxNorm)" cannot be resolved

I get this for all my STU3 based IG which have a dependency on US-Core including DEQM now.

here is an example: Argo-Q : https://github.com/argonautproject/questionnaire/tree/20190401-badlinksbranch

this built with zero errors on March24th : https://chat.fhir.org/#narrow/stream/179297-committers.2Fnotification/topic/ig-build/near/161573866

after refreshing the package I now get these error locally and don't know how to to fix it.

something changed and I looked at US Core repo and nothing has been touched there. Curiously the the error suggests a windows path with the "\" ....

Grahame Grieve (Apr 01 2019 at 19:22):

ok I'll investigate

Grahame Grieve (Apr 01 2019 at 19:24):

@Bryn Rhodes please look at the QICore errors on the current build

Bryn Rhodes (Apr 01 2019 at 20:44):

@Grahame Grieve , done, except for the QUICK sub-pages. Does the publish marker need to be on those pages too?

Eric Haas (Apr 01 2019 at 21:27):

ty

Grahame Grieve (Apr 01 2019 at 23:01):

@Bryn Rhodes there's kind of 2 answers. In principle, we don't want people looking at old copies of the quick doco and thinking it's current. So I'd like the same yellow box on every page for that reason

Grahame Grieve (Apr 01 2019 at 23:01):

but.... the quick doco isn't constructed like the other pages, so the box wouldn't appear in every page, right?

Bryn Rhodes (Apr 02 2019 at 19:46):

Right, the index is a container page, so I just committed what I think will add the marker at the right place in the container page: http://hl7.org/fhir/us/qicore/quick/QUICK-index.html

Grahame Grieve (Apr 02 2019 at 19:47):

ok. I'll look at what to do about the rest of the messages

Bryn Rhodes (Apr 02 2019 at 19:50):

Thanks!

Grahame Grieve (Apr 08 2019 at 02:14):

@Bryn Rhodes I've cut down the error list for qi-core. There

Grahame Grieve (Apr 08 2019 at 02:16):

There's a few real issues there, other then the US-Core caused brokne links. can you look at the non-US core links?

Grahame Grieve (Apr 08 2019 at 03:16):

@Rob Hausam IPS has an html issue - do you want me to fix this?

Grahame Grieve (Apr 08 2019 at 03:33):

@Eric Haas - Argonaut Questionnaire has a number of errors. can you look at them and tell me which you think are not issues you should fix?

Grahame Grieve (Apr 08 2019 at 03:52):

@Brett Marquard Argonaut clinical notes has some broken references to search parameters

Grahame Grieve (Apr 08 2019 at 03:52):

All of you: other than the QA issues, is your IG ready to publish?

Rob Hausam (Apr 08 2019 at 10:50):

What is the html issue - that you are referring to?

Rob Hausam (Apr 08 2019 at 11:02):

Never mind. I see the issue. It appears to be a new one with the missing header marker. It seems to be global - is it an issue with the framework?

Grahame Grieve (Apr 08 2019 at 13:41):

yes it's a new rule I am imposing that you solve in the framework. (or I can)

Eric Haas (Apr 08 2019 at 16:05):

@Grahame Grieve for Argo-Q:

see these post for the existing errors that I think are spurious

https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/another.20qa.20error.20for.20QR
https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/qa.20errors.20for.20Q.20and.20QR.20examples
https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/more.20qa.20errors.20for.20contained.20patients

I need to fix this one:

URL value 'http://hl7.org/fhir/us/core/ImplementationGuide/ig' does not resolve

Eric Haas (Apr 08 2019 at 16:27):

I can not debug the error:
URL value 'http://hl7.org/fhir/us/core/ImplementationGuide/ig' does not resolve
Inspecting the package shows its redirect as http://hl7.org/fhir/us/core/ImplementationGuide/ig = ig-r4.json?
when I refreshed the us-core package it does not show up on my local build.

Eric Haas (Apr 08 2019 at 16:30):

I can remove it if is an issue.

Lloyd McKenzie (Apr 08 2019 at 17:04):

I've updated the SDC framework. There's a bunch of new spurious errors about hyperlinks to stuff that exists - either defined in the IG or defined inside bundles in examples. And the old errors caused by publisher problems are still there too.

Lloyd McKenzie (Apr 08 2019 at 17:13):

Spurious hyperlink errors in CRD as well.

Bryn Rhodes (Apr 08 2019 at 21:46):

@Grahame Grieve , I've committed fixes for what I think is everything. The MedicationDispense and Request example error says the SNOMED code is not valid, but it is; I don't know what to do about the urls in the ImplementationGuide resource not resolving, same as the error referenced above in Argo-Q, I think; the Coverage value set reference is the right URL for that in the VSAC's FHIR server; and the rest are errors in ValueSet that say "The extension http://hl7.org/fhir/StructureDefinition/valueset-extensible is unknown, and not allowed here", but the source resources for those value sets don't have that extension in them.

Bryn Rhodes (Apr 08 2019 at 21:46):

With that round of fixes, I think yes, QI-Core is ready for publishing.

Grahame Grieve (Apr 09 2019 at 03:18):

@Bryn Rhodes : The link 'http://hl7.org/fhir/us/core/search.html' for "search" cannot be resolved ?

Bryn Rhodes (Apr 09 2019 at 03:25):

As near as I can tell, that's coming from the definition of the AllergyIntolerance.category element in the US Core profile: http://hl7.org/fhir/us/core/StructureDefinition-us-core-allergyintolerance-definitions.html#AllergyIntolerance.category

Grahame Grieve (Apr 09 2019 at 03:39):

ah yes it is - ok

Grahame Grieve (Apr 09 2019 at 04:21):

@Bryn Rhodes found a problem while investigating errors in QI-Core: ValueSet-qicore-bodysite-precoordinated.xml.html has the same content as ValueSet-qicore-bodysite-precoordinated.html

Bryn Rhodes (Apr 09 2019 at 04:44):

I'm not sure how that would happen, I've verified that the bodysite-precoordinated ValueSet is only defined in the value set resources (not in any Bindings as a code list). What would cause them to have the same content?

Grahame Grieve (Apr 09 2019 at 05:59):

it's an error in the template that will be probably be the same for all your value sets

Rob Hausam (Apr 09 2019 at 06:05):

@Grahame Grieve Yes, please go ahead and fix these html errors for IPS, when you have a chance.

Grahame Grieve (Apr 09 2019 at 06:07):

@Bryn Rhodes fixed your template. I think QI-Core is good to publish now

Grahame Grieve (Apr 09 2019 at 06:22):

Bryn, the documentation is all over the place on whether it's QI-Core or QICore

Grahame Grieve (Apr 09 2019 at 06:46):

I standardised it. If you don't like QI-Core, it should be QICore everywhere. that's a simple search/replace

Grahame Grieve (Apr 09 2019 at 07:34):

@Eric Haas looking at qa for Argonaut questionnaire, I see a lot of text/display errors. Why?

Grahame Grieve (Apr 09 2019 at 07:35):

also lots of "value should not start or finish with whitespace"

Grahame Grieve (Apr 09 2019 at 07:44):

I sent you a patch...

Grahame Grieve (Apr 09 2019 at 11:25):

@Brett Marquard there are still problems with search parameters in the clinical notes IG

Grahame Grieve (Apr 09 2019 at 11:45):

@Rob Hausam done. What's with Any.html?

Rob Hausam (Apr 09 2019 at 13:12):

I thought that was gone. I know it was addressed before and I thought resolved. Not sure why it's showing up now, but I'll check.

Bryn Rhodes (Apr 09 2019 at 14:08):

@Grahame Grieve , thanks so much!

Brett Marquard (Apr 09 2019 at 15:25):

@Grahame Grieve Eric and I looked into the base FHIR 3.01 package and it appears a few of the search parameters on DiagnosticReport are missing:
- SearchParameter-DianosticReport-patient
- SearchParameter-DianosticReport-code
- SearchParameter-DianosticReport-date

Brett Marquard (Apr 09 2019 at 16:49):

and
- SearchParameter-DocumentReference-type

Brett Marquard (Apr 09 2019 at 16:51):

Diagnostic Report DSTU3
Document Reference Report DSTU3

Brett Marquard (Apr 09 2019 at 16:54):

...and yes I did fix some that were wrong on my end!

Eric Haas (Apr 09 2019 at 17:24):

re missing sps see GF#20741

Eric Haas (Apr 09 2019 at 17:33):

@GG

also lots of "value should not start or finish with whitespace"

this is markdown text in the cap statements or prefixes in the Questionnaire and it is important

Eric Haas (Apr 09 2019 at 17:34):

for my narrative generation

Eric Haas (Apr 09 2019 at 17:38):

@GG

looking at qa for Argonaut questionnaire, I see a lot of text/display errors. Why?

see https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/another.20qa.20error.20for.20QR

these are display items and have no questions

Eric Haas (Apr 09 2019 at 17:44):

@GG I see 20 display warnings with regards to code display. is that what you are talking about? I tried to fix but the warnings persisted as I recall.

Grahame Grieve (Apr 09 2019 at 21:14):

the missing search parameters are not missing. note that each of those 'missing ones' you identify are shared across multiple resources, and so they have a common identifier. e.g. what you are looking for as SearchParameter-DianosticReport-code is actually SearchParameter-clinical-code

Eric Haas (Apr 09 2019 at 21:27):

Thanks, there are numerous other resources that have a patient or code SearchParameter such as: 'http://hl7.org/fhir/SearchParameter/Media-patient' so this was confusing. I will withdraw the comment. @Brett Marquard FYI I think a simpler table than http://build.fhir.org/searchparameter-registry.html that lists the Type, paramter and url would be helpful trying to create one now.... may not be that simple... I just now fully understand that table

Eric Haas (Apr 09 2019 at 21:40):

@GG pinging you on this: https://chat.fhir.org/#narrow/stream/179165-committers/topic/Publishing.20IGs/near/162832546

Grahame Grieve (Apr 09 2019 at 21:47):

why do you have markdown in the prefix?

Eric Haas (Apr 09 2019 at 21:48):

that case it is not markdown but a significant space for my rendering.

Eric Haas (Apr 09 2019 at 21:50):

prevent the prefix from being smushed into the question if {prefix}{question}

Grahame Grieve (Apr 09 2019 at 21:51):

then you have a rendering problem.

Grahame Grieve (Apr 09 2019 at 21:51):

{prefix} {question} not {prefix}{question}

Eric Haas (Apr 09 2019 at 21:52):

I know that but its a warning and I think its not that big of a deal. But if you insist I'll remove the spaces.

Eric Haas (Apr 09 2019 at 21:53):

my point is was done intentionally

Grahame Grieve (Apr 09 2019 at 22:06):

well, I think it matters in the IG. Why not fix the rendering?

Grahame Grieve (Apr 09 2019 at 22:07):

with regard to search parameters... it would be good to have a task to clarify

Eric Haas (Apr 09 2019 at 22:07):

Ok

Eric Haas (Apr 09 2019 at 22:08):

I’ll fix

Grahame Grieve (Apr 09 2019 at 22:08):

but for now, the only real way to do this is to get a copy of search-parameters.xml|json and search for the path you are looking for

Brett Marquard (Apr 10 2019 at 02:16):

I think I got em...

Grahame Grieve (Apr 16 2019 at 01:06):

@Eric Haas back to argonaut questionnaire.. why is there text mismatch between Q and QR in the examples?

Grahame Grieve (Apr 16 2019 at 01:48):

ok I have cleared clinical notes to be published

Eric Haas (Apr 16 2019 at 03:44):

can you point to an example?

Grahame Grieve (Apr 16 2019 at 04:09):

in the qa.html: If text exists, it must match the questionnaire definition for linkId score

Eric Haas (Apr 16 2019 at 14:42):

OK I'll look into it more...

Eric Haas (Apr 16 2019 at 14:49):

OK so here is an example and I am impressed with the validation tooling for being so thorough. ( I totally misinterpreted the error message so my mistake for not recognizing the issue earlier....

Here is the QuestionnaireResponse item that the validator caught

"linkId" : "d1", "text" : "The Alcohol Use Disorders Identification Test C
(AUDIT-C) is scored on a scale of 0-12 where the higher the score, the more
likely the patient's drinking is hazardous. A score of 4 ormore for men and 3 or
more for women is considered positive for hazardous drinking or active alcohol
use disorders. If the points are all from Question 1 alone where 2 and 3 are 0,
it is likely the patient is drinking below recommended limits. The care provider
may review the patientsalcohol intake over that past few months to confirm
accuracy. (this is hidden text/should not be displayed to the user)" }

Here is the corresponding Questionnaire item

"linkId" : "d1", "text" : "The Alcohol Use Disorders Identification Test C
(AUDIT-C) is scored on a scale of 0-12 where the higher the score, the more
likely the patient's drinking is hazardous. A score of 4 ormore for men and 3 or
more for women is considered positive for hazardous drinking or active alcohol
use disorders. If the points are all from Question 1 alone where 2 and 3 are 0,
it is likely the patient is drinking below recommended limits. The care provider
may review the patientsalcohol intake over that past few months to confirm
accuracy.", "type" : "display" }

Eric Haas (Apr 16 2019 at 15:00):

Notice in the QuestionnaiResponse my Rendering tool pedantically added notations for the reader stating that is not normally displayed. Since my rendering tool uses the the the structured content to render it triggerred this error. But I can not find a hard and fast rule for If text exists, it must match the questionnaire definition for linkId d1 in the spec. Nevertheless I can remove it if you want.

Eric Haas (Apr 16 2019 at 15:05):

I think there I value in either approach, I certainly want the rendered output to diplay the reader notes.

Lloyd McKenzie (Apr 16 2019 at 15:14):

Rendering shouldn't impact the content of the resources. Agree that the text in the specification isn't clear that, if present, the 'text' for an item needs to match what it is for the corresponding Questionnaire. Can you submit a change request?

Eric Haas (Apr 16 2019 at 15:16):

I don't agree with that rule so no I won't . I think that is a good guideline. but you may need to modify the output (like I did ) for the benefit of the recipient. but happy to discuss

Lloyd McKenzie (Apr 16 2019 at 15:18):

Your use-case should have been met with a question and a contained display item with instruction text. I can't see any use-case for the item text in the response ever varying from the Questionnaire except if the Questionnaire has been edited in the interim.

Lloyd McKenzie (Apr 16 2019 at 15:22):

GF#20859

Eric Haas (Apr 16 2019 at 15:37):

Your use-case should have been met with a question and a contained display item with instruction text.

can you show me an example of this?

Eric Haas (Apr 16 2019 at 15:47):

My immediate thought is an extension like QR-Comment or designNote but I don't want to define and introduce new extensions like those into an IG since that is not its focus.

Lloyd McKenzie (Apr 16 2019 at 15:50):

There is an extension for design notes - those don't get rendered. However, if it's something that should be rendered on the screen, just use a nested item of type "display".

Grahame Grieve (Apr 16 2019 at 22:25):

I don't see how it's acceptable for a QuestionnaireResponse to answer a different question than the one in the questionnaire. In principle. But in practice, I can see several reasons why the text might not match exactly. Language, for instance.....

Eric Haas (Apr 16 2019 at 22:32):

But in practice, I can see several reasons why the text might not match exactly. Language, for instance.....

Well these examples are a tool for showing how it is done and are annotated

Eric Haas (Apr 16 2019 at 22:33):

I still don't get what lloyd is saying about nesting display in QR. how is that different? you are still adding additional context to the question.

Eric Haas (Apr 16 2019 at 22:35):

Bottom line - I can remove my annotations from the structured data, but I don't think that the rule is enforceable over the questionnaire space.

Lloyd McKenzie (Apr 16 2019 at 22:43):

A display is a separate item - and has its own text. I believe your situation was the questionnaire had an extra "display" item that wasn't in the QuestionnaireResponse.

Grahame Grieve (Apr 16 2019 at 22:44):

so I think that your comments should be added as design notes in the Questionnaire (as a matter of best practice in an Argonaut IG). And I'll change the error to a best practice note when I work on questionnaire validation next - there's some known problems with it

Lloyd McKenzie (Apr 16 2019 at 22:44):

It's not an enforceable rule. The best it can be is a warning. But it's not something that should be violated in our IGs.

Lloyd McKenzie (Apr 16 2019 at 22:44):

I wouldn't make it a "best practice". I'd make it a warning. If the response is different than the questionnaire, it's a sign there might be problems.

Grahame Grieve (Apr 16 2019 at 22:45):

best practice means a warning unless people turn on a flag to make it an error

Lloyd McKenzie (Apr 16 2019 at 22:47):

Ah, so best practices become errors for IG publication. That works.

Eric Haas (Apr 17 2019 at 00:24):

OK that sounds like a good plan... now I get what lloyd is talking about

Eric Haas (Apr 17 2019 at 05:52):

OK now I removed all the errors in QR and introduced a bunch in Q by using an R4 displayNote extension in an STU3 IG. I also tried to fix the bad url for us-core 2.0.0 ig but is still an error. I noted that the url I originally had was the one used in the resource. The package cache.ini has this:
http://hl7.org/fhir/us/core/ImplementationGuide/ig = ig-r4.json so I am at loss what to do and may just remove it from the capabilitystatement

Grahame Grieve (Apr 17 2019 at 06:28):

I'll have a look

Eric Haas (Apr 17 2019 at 14:35):

After sleeping on it, I am open to defining an Argonaut extension for displayNote for STU3. let me know if that is preferable.

Grahame Grieve (Apr 17 2019 at 21:29):

well, the problem is that the designNote extension is defined in R4 and not known in the context of R3. That's come up on several different IGs as an issue

Grahame Grieve (Apr 17 2019 at 21:30):

but I don't want to work around what is either a definitional, methodology and/or tooling issue by asking implementers to use a different extension that they'll have to change later.

Grahame Grieve (Apr 17 2019 at 21:31):

so @Eric Haas Argonaut Questionnaire is extremely close. One last error:

Profile http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient, Element 'QuestionnaireResponse.subject.contained.identifier': minimum required = 1, but only found 0

Grahame Grieve (Apr 17 2019 at 21:32):

and also publishing issues - top of QA page

Eric Haas (Apr 17 2019 at 21:42):

The contained patient is not a US-Core Patient. We discussed this here. https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/more.20qa.20errors.20for.20contained.20patients

Eric Haas (Apr 17 2019 at 21:44):

i'll fix the publishing stuff.

Grahame Grieve (Apr 17 2019 at 22:02):

why is the contained patient not a US-Core patient? the QR profile says that it is

Eric Haas (Apr 17 2019 at 22:22):

is just patient:

  </element>
    <element id="QuestionnaireResponse.contained">
      <path value="QuestionnaireResponse.contained"/>
      <comment
               value="Contained patient provides additional context for searching and interpretation of responses."/>
      <requirements
                    value="QuestionnaireResponse may need additional context when searching."/>
      <min value="0"/>
      <max value="1"/>
      <type>
        <code value="Patient"/>
      </type>
      <mustSupport value="true"/>
      <isModifier value="false"/>
    </element>

I did not define globals either.

A contained patient resource in the QuestionnaireResponse can be used to allow for searching on the Patient. So it is not going to conform to US Core since the use case may be to supply minimal demographic data like dob, sex and no PHI like name.

Grahame Grieve (Apr 17 2019 at 22:28):

the profile on QuestionnaireResponse says that the subject is a US Core patient. So the validator is just checking that it is

Eric Haas (Apr 17 2019 at 22:29):

Ok I missed that...

Lloyd McKenzie (Apr 17 2019 at 23:01):

Did us-core define any globals? Those would come into play too.

Eric Haas (Apr 18 2019 at 00:45):

nope, I failed to follow the trail from the contained patient to the subject. I updatde the contained to us-core patient so other will not make the same mistake. I DARed patient name in example too.

Eric Haas (Apr 18 2019 at 00:46):

OK @GG I made all the updates to argo-q and fixed a few minor glitches in the framework, should be good to go.

Grahame Grieve (Apr 18 2019 at 02:08):

ok great

Grahame Grieve (Apr 18 2019 at 06:01):

ok both are published now:

• http://fhir.org/guides/argonaut/clinicalnotes/
• http://fhir.org/guides/argonaut/questionnaire/

Grahame Grieve (Apr 18 2019 at 06:01):

let me know if you find any problems with them

Eric Haas (Apr 18 2019 at 16:27):

there is one issue similar to what I discovered yesterday. I generate the capabilitystatement narrative in xhtml using templates and use the canonical as hyperlinks. two issues with this approach:

example: http://www.fhir.org/guides/argonaut/questionnaire/CapabilityStatement-assessmentbank.html

• the links go to the fhir foundation's page not found page but is not picked up in the QA - example : http://www.fhir.org/guides/argonaut/questionnaire/SearchParameter/Questionnaire-publisher (will they resolve in future?)
• I had assumed they would resolve to internal links by the IG-Publisher. And they don't so I should probably map them myself when I create them using the package.

Is this an expected capability in the ig-publisher or should I avoid using the canonicals in the cases where I would prefer an internal link?

Grahame Grieve (Apr 18 2019 at 20:18):

I see that this is a broken link: https://argonautproject.github.io/questionnaire/index.html#security-and-privacy-considerations

Grahame Grieve (Apr 18 2019 at 20:20):

your search parameter table refers to the wrong fhir version

Grahame Grieve (Apr 18 2019 at 20:56):

the missing redirects should be in place now

Eric Haas (Apr 18 2019 at 21:11):

ty for the redirects -
for the wrong version canonicals I assume I use for example

http://hl7.org/fhir/SearchParameter/Resource-id|3.0.1
instead of
http://hl7.org/fhir/SearchParameter/Resource-id

Grahame Grieve (Apr 18 2019 at 21:31):

maybe...

Eric Haas (Apr 18 2019 at 22:52):

I can go ahead and fix these issue, can you update the Argo-Q ig? will the autopublisher work?

fix

• change sdc link to publish hx (currently points to ci build)
• update canonicals to stu3 ( as you pointed out above )
• fix security links in cap statements ( as you pointed out above )
• fix failed markdown links to [chained], and [Argonaut QuestionnaireResponse responsePeriod Extension]

*fix these typos:

• added DAR name.family and DAR name.given to the inline examples
• 'change Whether the item' to 'Whether the item is hidden'
• "the questionnaire's context" to "The questionnaire's context"
• " may need available in" to " may need to be available in"
• "tha" to "that"
• "as a contained resource with the" to "as a contained resource within the"
• "Provider Ehr" to "Provider EHR"

Grahame Grieve (Apr 22 2019 at 20:28):

hmm. we should have fixed all that before publishing....

Grahame Grieve (Apr 22 2019 at 20:28):

@Micky Tripathi needs to sign off on fixing that

Grahame Grieve (Apr 22 2019 at 20:32):

@Rob Hausam @Giorgio Cangioli I would like to get IPS closed out so that @Lynn Laakso and I can publish it next week before Montreal. Is that likely?

Rob Hausam (Apr 22 2019 at 20:46):

With our current state and recent discussions, I would say at this point likely not. We have come to the conclusion (but would still consider any good arguments otherwise) that we should include the changes that we will make for Argonaut alignment and incorporation of the SNOMED CT free set (plus some additional post-ballot feedback). Plus there are still changes needed in the IPS spec and also very likely in the infrastructure that are needed for all of our slicing to work as specified/intended, and we will need some of your time for that. Those are all significant and aren't going to be able to be completed prior to Montreal. We anticipate that some further discussion(s) will be needed in Montreal. So we would incorporate the results of all of that in the September ballot (with the ballot scope limited to the changes since the January ballot) and officially publish following successful ballot resolution. In the meantime, though, we would also like to tag a stable snapshot version (as of the end of this week or the first of next week) to be used for the Montreal Connectathon and other subsequent activity prior to the official publication. This is clearly different than what you are asking, but how does that sound (pro and/or con)?

Grahame Grieve (Apr 22 2019 at 21:04):

ok we can do a snapshot. I can't remember whether FMG approves these or whether I just do them. @Lloyd McKenzie / @David Hay ?

Lloyd McKenzie (Apr 22 2019 at 22:08):

Snapshot requests should come to FMG so that we can coordinate and minimize impact on Grahame's (and hopefully eventually Lynn's) time.

Grahame Grieve (Apr 23 2019 at 00:20):

well, that will be a request for this week then

Rob Hausam (Apr 23 2019 at 14:43):

sounds good - thanks

Last updated: Apr 12 2022 at 19:14 UTC