hl7/immunizationfhirds

A FHIR implementation guide to support Immunization Decision Support

immunizationfhirds's Issues

Update ImmunizationRecomendation.targetDisease and ImmunizationEvaluation.targetDisease value sets to use SNOMED

http://jira.hl7.org/browse/fhir-24959

Recommend targetDisease binding to SNOMED CT instead of CVX, additional constraint for ImmunizationRecommendation

1. ImmunizationRecomendation.targetDisease and ImmunizationEvaluation.targetDisease should be bound to SNOMED CT instead of CVX. CVX represents vaccines, not diseases.

Craig - For the first one, do we indicate that this is a US Realm IG and in the US, CVX is the vocabulary used for vaccine groups as a proxy for diseases? We should also keep in mind that while the binding is "extensible", the meaning of that is such that a non-CVX code cannot be use so long as CVX contains a code for that disease. We could extend the value set to include both CVX and SNOMED if we want.

I'm not sure the second one is correct. We were thinking that there would be scenarios where you might indicate the need for influenza but then contraindicate the live nasal vaccine for some reason. If we agree with this, we should also put the same constraint in the R5 base standard as there is nothing specific about the IG that requires this constraint.

Eric - I'm open to the first one if we think we should move to a different concept for disease - which I don't think would be a bad idea. The second comment is wrong in my opinion. Along with Craig's example, there is also a Rotavirus (I think) situation where a patient with an allergy to latex would be contraindicated against one Vaccine Product, but could receive the other Vaccine Product.

Proposed Disposition:

Suggestion #1: Persuasive, we will update the ImmunizationRecomendation.targetDisease and ImmunizationEvaluation.targetDisease value sets to use the list of SNOMED codes for vaccine preventable diseases currently captured in http://build.fhir.org/valueset-immunization-target-disease.html

Reword this to not have repeated use of the phrase "common interface"

http://jira.hl7.org/browse/fhir-24953

Admittedly, this is nitpicking but the repeated use of common interface in the General Guidance section is unnecessary

This common interface will be used for two main purposes:

Provide a common interface that health information systems may write to and gain access to their choice of CDS engines.
Provide a common interface that may be used for testing and verifying the output of CDS engines.

→

This common interface will be used for two main purposes:

Create a place that health information systems may write to and gain access to their choice of CDS engines.
Allow users to test and verify the output of CDS engines.

Proposed Disposition: Persuasive, text will be updated as suggested

'

Birthdate

I may have missed it if it was defined elsewhere, but the StructureDefinition: ImmDSPatient doesn't include any mention of a birthdate. I think it probably needs to be added and made required.

Remove white space

At the risk of being nitpicky, I notice a white space difference in the names of the value sets as listed in the structure view of this IG vs. R4 (e.g., "ImmunizationRecommendationStatusCodes" vs. "Immunization Recommendation Status Codes"), though the "Reference" links in the "Terminology Binding" section below it don't have any white space characters in either this IG or R4. I first wondered if that causes the IG authoring tool to call out those elements as diffs until I noticed the binding strength difference....

Add section to explain use of OperationOutcome

http://jira.hl7.org/browse/fhir-24949

How should an immunization CDS engine respond if the patient or immunization information had logic errors that prevented calculating a proper response? For example if the administration date for the immunization was before the birth of the patient or the vaccination code was not recognized by the receiving system? In these cases it might not be possible to produce a sensible result or the result may be missing critical information. How does the server signal properly to the requestor that it was unable to respond and the reason why? Suggested by Brian Lee at STC.

raig - I agree that we should comment on this, but I'm not sure what the answer is. I would imagine that there is a general response to any operation that fails. Is the answer to respond with an OperationOutcome and/or DetectedIssue? The operations page says "An HTTP status code of 4xx or 5xx indicates an error, and an OperationOutcome SHOULD be returned with details.".

Eric - I looked into this when we were creating this and that was my understanding too Craig is that this is part of the standard and OperationOutcome should be used. Maybe we just need to connect the dots for the readers on where to find OperationOutcome? Unless we plan to get much more specific about our error codes.

Nathan - Brian Lee has created an example implementation that returns these types of outcomes and has proposed a list of these outcomes. These have been placed into confluence for discussion and review by the group: Ballot #2 Operation Outcomes https://confluence.hl7.org/pages/viewpage.action?pageId=66927793

Security page link

I was looking at the Security page in the ImmDS FHIR IG, and should the link be to the base standard safety page or the security page?

http://build.fhir.org/ig/HL7/ImmunizationFHIRDS/security.html

should point to
http://hl7.org/fhir/R4/safety.html (existing)
or
http://hl7.org/fhir/R4/security.html

thanks
Craig

Incompatible Project Structure for SUSHI 2.0

Problem: This project uses a project structure that will no longer be supported by SUSHI, as of SUSHI 2.0.0. If your project uses the HL7 IG Autobuild, auto builds will fail after SUSHI 2.0.0 comes out of beta.

Preferred Solution: The preferred way to fix this problem is to update your project to use the supported project structure and configuration (e.g., standard IG template project structure with an input/fsh folder). We suggest following the Migrating from Older Versions instructions on FSH School.

Alternate Solution: If it is not feasible to make these changes in a timely manner, you can "lock in" the version of SUSHI that the IG Publisher uses by creating or updating a fsh.ini file at the root of your project. For example, the following fsh.ini file would tell the IG Publisher to always use SUSHI 1.3.2, even after SUSHI 2.0.0 is released:

[FSH]
sushi-version=1.3.2

Timeline: In order to avoid being affected by the official SUSHI 2.0.0 release, we recommend you implement one of the above solutions by July 6, 2021.

More Information / Questions: For more information about SUSHI 2.0, you can read the
SUSHI 2.0.0 Beta 1 Release Notes. For more information about updating your project to the supported project structure, see Migrating from Older Versions on FSH School. If you have questions, you can reach out to the SUSHI team via the #shorthand stream on Zulip or by logging an issue on SUSHI.

Typo correction on Use Cases page

http://jira.hl7.org/browse/fhir-24955

I think this is just a minor typo

relative to an immunization schedule (as set of recommendations → relative to an immunization schedule (a set of recommendations

Proposed Disposition: Persuasive

Define extended set of values for reason codes

http://jira.hl7.org/browse/fhir-24961

3. The reason codes (http://hl7.org/fhir/R4/valueset-immunization-evaluation-dose-status-reason.html) are: adverse storage condition, cold chain break, expired lot, administered outside schedule, product recall. All of these (except administered outside schedule) aren't things that a CDS engine would return to the caller; it's something the caller would pass up to the CDS engine. So having this as a part of ImmunizationEvaluation does not make sense.

Suggestion #3: For things like storage conditions and recall, that information will typically be supplied by the caller as part of Immunization.subpotentReason. Expired or Outside of Scheduled can be determined by the CDS engine based on the patient history and other data. CDS engines may want to be more specific about the schedule issues (eg. given too soon, patient too young) which may be a problem if we provide a generic "out of schedule" code in an extensible value set. On 10/31/2019, the Public Health WG reviewed the value sets for Immunization.subpotentReason and ImmunizationEvaluation.doseStatusReason. We will come up with an extended set of values for the value set, drawing on experience from CDS engines and CDSi. We think we'll want to expand the "out of schedule" to be more specific.

Overall: Persuasive with Mod

Further Examples

As I was going through the examples, I was wondering if we could post an example of an invalid dose with the reason? There are currently only valid doses posted, but I think it would be helpful to show some using the status codes with the status reasons. (especially given this change).

Add doseStatusReason to Guide

Add these value set concepts to the guide: https://confluence.hl7.org/display/PHWG/2020-01-17+ImmDS+Meeting+notes

Add ImmunizationEvaluation to the example.

http://jira.hl7.org/browse/fhir-24951

Example section has an example that doesn't include the ImmunizationEvaluation. For completeness it would be good to see this in the example. Suggested by Brian Lee at STC.

Proposed Disposition: Persuasive, an example will be added

Update swim lane diagrams to clarify distinctions between them

http://jira.hl7.org/browse/fhir-24957
Section 3.4 and 3.5 seem to be describing the same use case (with 3.4 being a more specific scenario) so condense into one use case

The use cases given for 3.4 and 3.5 seem to be largely the same scenario but with section 3.4 being a more specific case of section 3.5. Perhaps consider condensing this into a single section.

Eric - I see these as different, and have a thought on how we can separate them better. One uses HL7 v2 Query and the other does not, but since both have 3 swim lanes and similar colors, the reader scans them and assumes they are the same. I think a 4th swim lane in the EHR example will help.

Proposed Disposition: Persuasive with Mod - we think it's important to keep them as separate use cases, but we'll enhance the swim lane diagrams to clarify the distinctions between them.

Fix broken link on ImmunizationRecommendation to Immunization

http://jira.hl7.org/browse/fhir-24961

1. In http://hl7.org/fhir/uv/immds/2019SEP/OperationDefinition-immds-forecast-operation.html, the ImmunizationRecommendation link points to the Immunization resource, not the ImmunizationRecommendation resource

Suggestion #1: Persuasive, we will correct the broken link