This IG is version 4.0.1, while the IG 'hl7.fhir.uv.subscriptions-backport.r4' is from version 4.0.0
warning
The jira specification file appears to be out of date with the versions, artifacts and pages currently defined in the IG. A proposed revised file to be reviewed and, if appropriate, submitted as a pull request against the XML folder in https://github.com/HL7/JIRA-Spec-Artifacts. To see the differences, perform a file compare on 'template/jira-current.xml' (a normalized view of what is in Github) and 'template/jira-new.xml' (reflects current IG content)
en/background.html
information
The html source contains the word 'MAY' but it is not in a text phrase marked as a conformance clause: 'Subscriptions provide two optional features that support order, referral, and transfer workflows: SubscriptionTopics: a data-holder MAY make a SubscriptionTopic available to which authorized data requestors may subscribe for updates. Such "dynamic subscriptions" let an actor specify their own endpoint, events of interest, and desired format from a menu of options chosen by the data holder. This is purely optional within Subscriptions: administrators may instead discuss updates out of band and manually configure Subscriptions, just as administrators do for HL7v2 interfaces today. Query guidance: subscription-notifications can include instructions for how a notification recipient (e.g. a Fulfiller getting a subscription-notification about a Task and a ServiceRequest being available at the Placer's FHIR server) may query for additional information later. For instance, if insurance coverage might change between when a referral is created and when service should be provided, the subscription-notification sent for the referral can guide a Fulfiller on how to retrieve updated Coverage data if or when it is needed later. 'CONFORMANCE_STATEMENT_WORD
en/cancelling-and-modifying-requests.html
information
The html source contains the word 'SHALL' but it is not in a text phrase marked as a conformance clause: 'This guide requires that in circumstances where FHIR servers are prevalent and where resources are discoverable, the Request resource that serves as the source-of-truth for the exchange SHALL be hosted on a FHIR server under the authority of the system from which it originated. Each party involved in an order, referral, or Transfer workflow may of course have their own internal representation as well. Actors SHOULD indicate if their own representation of a resource is not ‘primary’, however.'CONFORMANCE_STATEMENT_WORD
en/core-concepts.html
information
The html source contains the word 'MAY' but it is not in a text phrase marked as a conformance clause: ' Task resources can serve many purposes. In this guide, a Coordination Task serves a core role of helping a Placer and a specific potential, or eventual Fulfiller manage the status of a request (in scenarios where FHIR servers are used). Many Tasks MAY correspond to the same ServiceRequest, with a Coordination Tasks for each Placer and (potential) Fulfiller pair. In environments where several potential fillers may each contribute a partial output (such as multiple pharmacies each providing a partial dispense), Placers may also initiate a 'parent' Coordination Task that they own and only they may modify, in addition to the shared Fulfiller-specific Coordination Tasks. The overall status of the workflow may be represented using Request.status and the presence of Outputs or, when a parent Task exists, via the parent Task.businessStatus and Task.status. The page using Task provides additional guidance on the use of the Task resource. 'CONFORMANCE_STATEMENT_WORD
The link 'examples.ttl.zip' for "Turtle" cannot be resolvedHTML_LINK_CHECK_FAILED
en/fulfiller-need-for-additional-info.html
information
The html source contains the word 'SHOULD' but it is not in a text phrase marked as a conformance clause: 'A Fulfiller may find that additional information is needed that may only be obtained by communicating with the Placer asynchronously. While waiting for this information, the Fulfiller SHOULD update the status of their shared Coordination Task to indicate this by updating Task.businessStatus to an appropriate status.'CONFORMANCE_STATEMENT_WORD
en/order-initiation.html
information
The html source contains the word 'MAY' but it is not in a text phrase marked as a conformance clause: ' request.status is a coded element with required binding - the status of the request is limited to those statuses identified in the resource, and MAY NOT be extended. The request .status is the status of the authorization, not the status of execution. Orders can be created in active status, or may evolve from draft to active - an order instance may be created as "draft" and then be updated to become "active" … 'CONFORMANCE_STATEMENT_WORD
en/requests-events-tasks.html
information
The html source contains the word 'SHOULD' but it is not in a text phrase marked as a conformance clause: 'Sub-tasks that are created in relation to the overall Coordination Task SHOULD refer back to the Coordination Task via Task.partOf.'CONFORMANCE_STATEMENT_WORD
en/sharing-outputs.html
information
The html source contains the word 'MAY' but it is not in a text phrase marked as a conformance clause: 'Placers may choose to create their own local representation of that content, and additionally, to host their own copy of that content on their own FHIR server so that its information is discoverable for others involved in a patient's care. Provenance FHIR resources MAY be used to indicate that the originator of the latest version of the Output is the owner, though note that many Event resources will already implicitly indicate their source (such as in DiagnosticReport.performer and .resultsInterpreter).'CONFORMANCE_STATEMENT_WORD
ImplementationGuide/hl7.fhir.uv.cow: ImplementationGuide: Validated against fhir.ImplementationGuide
Path
Severity
Message
ImplementationGuide.dependsOn[2] (l1/c2847)
warning
The ImplementationGuide is based on FHIR version 4.0.1 but package hl7.fhir.uv.subscriptions-backport.r4#1.1.0 is based on FHIR version 4.0.0. In general, this version mismatch should be avoided - some tools will try to make this work with variable degrees of success, but others will not even tryIG_DEPENDENCY_VERSION_WARNING
=== CodeSystem for task code is now active, and the binding is extensible. Warning is not applicable
Reference to draft CodeSystem http://hl7.org/fhir/CodeSystem/task-code|4.0.1 (5 uses)
=== Extension is inherited, no control over it.
%The extension http://hl7.org/fhir/StructureDefinition/elementdefinition-maxValueSet|5.2.0 is deprecated% (1 uses)
=== OID assignment for ActorDefinition profiles is not intended in the first ballot
The resource ActorDefinition/filler could usefully have an OID assigned (OIDs are easy to assign - see https://build.fhir.org/ig/FHIR/fhir-tools-ig/CodeSystem-ig-parameters.html#ig-parameters-auto-oid-root) (1 uses)
The resource ActorDefinition/placer could usefully have an OID assigned (OIDs are easy to assign - see https://build.fhir.org/ig/FHIR/fhir-tools-ig/CodeSystem-ig-parameters.html#ig-parameters-auto-oid-root) (1 uses)
=== There are two code systems, one is temporary with example codes, the other is necessary for the Subscription Backport to work in R4
Most code systems defined in HL7 IGs will need to move to THO later during the process. Consider giving this code system a THO URL now (See https://confluence.hl7.org/display/TSMG/Terminology+Play+Book, and/or talk to TSMG) (2 uses)
=== ValueSet for subscription notification is not available in R4, it is added to this IG
Binding http://hl7.org/fhir/ValueSet/subscription-notification-type could not be located (1 uses)
The message is coming from the base ActorDefinition resource
Reference to deprecated ValueSet http://hl7.org/fhir/5.0/ValueSet/jurisdiction|5.0.0 (2 uses)
This element does not match any known slice defined in the profile http://hl7.org/fhir/StructureDefinition/obligation|5.2.0 (this may not be a problem, but you should check that it's not intended to match a slice)
This element does not match any known slice defined in the profile http://hl7.org/fhir/StructureDefinition/obligation|5.2.0 (this may not be a problem, but you should check that it's not intended to match a slice)
This element does not match any known slice defined in the profile http://hl7.org/fhir/StructureDefinition/obligation|5.2.0 (this may not be a problem, but you should check that it's not intended to match a slice)
This element does not match any known slice defined in the profile http://hl7.org/fhir/StructureDefinition/obligation|5.2.0 (this may not be a problem, but you should check that it's not intended to match a slice)
This element does not match any known slice defined in the profile http://hl7.org/fhir/StructureDefinition/obligation|5.2.0 (this may not be a problem, but you should check that it's not intended to match a slice)
This element does not match any known slice defined in the profile http://hl7.org/fhir/StructureDefinition/obligation|5.2.0 (this may not be a problem, but you should check that it's not intended to match a slice)
The ImplementationGuide is based on FHIR version 4.0.1 but package hl7.fhir.uv.subscriptions-backport.r4#1.1.0 is based on FHIR version 4.0.0. In general, this version mismatch should be avoided - some tools will try to make this work with variable degrees of success, but others will not even try
hl7.fhir.uv.cow
hl7.fhir.uv.tools.r4