Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

SubmitterIssuesDescriptionProposed Disposition
For resolution on 11/14/2019 Public Health WG call
Kevin Snow23871

Add support for risk conditions and other patient specific attributes

We need to develop a strategy for calling different versions of API version (different FHIR version, contraindication type resources are added in the future) if this happened would we want to create a new FHIR operation name or simply an updated version.  If it’s an updated version should we have the ability to call by version number and what we do to ensure we maintain backwards compatibility if we move forwards with adding something like risks i.e. – how do we ensure no breaking changes.

Craig - This was a comment from Kevin Snow. I think this is for future use.

This seems like something CPG might have thought about as well, we should ask them if they have a solution for this.

Eric - I agree. Future. Hopefully the next iteration.

Nathan - we need to see if we can express these as part of the Capability Statement or as extensions to the operation output.

We would make it more generic and remove any specific references to CDSi. 

Proposed Disposition: Considered for Future Use - this will be part of a future iteration of the IG 

Kevin Snow23872

Return additional data in the operation response

It would be nice to be able to receive data in the response about the CDS system (and inputs) that generated the forecast. For example:

-Ability to know the CDSi Supporting Data Version (could be returned via response headers or resource)

-Ability to know the Code/Software/Application Version of the CDS engine itself (could be returned via response headers or resource)

Craig - We should consider this alongside the first one which has similar support for returning guideline data

Eric - This feels more technical than the other one. But agree it's about adding more information in the response.

Nathan - see comment for 23871

Proposed Disposition: Considered for Future Use - this will be part of a future iteration of the IG 

Danny Wise24057

difference between profiled resources and R4?

I'm struggling a little bit to understand all the differences in the profiled ImmunizationRecommendation resource and the R4 version.  For instance, forecastStatus, forecastReason, and dateCriterion > code as listed on the "Differential" tab look nearly identical to R4 -- is it just that the terminology binding strength was updated from "example" to "extensible?"

Is it possible to highlight these differences more clearly, or this just a product of the IG format?

I have a similar question about doseStatus in the ImmunizationEvaluation resource.

P.S.  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....


Eric - I recall us discussing this situation where changing the vocab binding requires that the resource be profiled so I think this comment is correct as to the reason why. I also think the look/feel of the IG is something a bit out of our control, but I'm also told HL7 is working on this.

Proposed Disposition: Question Answered - changing the value set binding is what drives the new profile. The output is a product of the IG formatting. We will fix any typo if it's under our control

Keith Salzman24943

IG appears to be well written with good use cases and references to FHIR content

The IG appears to be well written with good use cases and references to the content used from FHIR resources (generic-not using as FHIR Resource)-I cannot evaluate the profiles so will leave that evalutation to those who can.

Not recommending any action

Proposed Disposition:  Considered - no action required and add a comment saying "thank you"

Nathan Bunker24949

How to handle bad input data. 

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.

Craig - 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

Proposed Disposition:  Persuasive - we can add a section that explains how to use OperationOutcome (and other base resources) to express the error conditions

Nathan Bunker24951

Add ImmunizationEvaluation to the example.

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
Arvind Jagannathan24953

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

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
Arvind Jagannathan24955

Typo correction on Use Cases page

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
Arvind Jagannathan24957

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.

Bonnie Briggs24959

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.
2. ImmunizationRecommendation should have an additional constraint to indicate that vaccineCode cannot be present with a contraindicatedVaccineCode in the same recommendation.

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

Suggestion #2: Not persuasive, we know of use cases where a recommendation may be needed but specific vaccines may be specifically contraindicated. Context specific testing can cover cases where we want to make sure that systems give the right results in terms of contraindicated vaccine.

Overall: Persuasive with Mod, we will implement a change for suggestion # 1 but not for suggestion #2

Daryl Chertcoff24961

Correct link in operation rendering, targetDisease should be bound to SNOMED CT, ImmunizationEvaluation reason codes don't make sense

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

2) From the caller's perspective, it appears that specifying immunity would be specified in the Immunization resource by using a "fake" CVX code for a vaccine and say, "this is the vaccine that targets the disease that the patient is immune to". There are SNOMED CT and ICD-10-CM codes which could be used to specify immunity and keep these elements conceptually different.

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.

Proposed Disposition:  

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

Suggestion #2: Considered for Future Use, immunity is out of scope for this phase of the project. We will include immunity in a future iteration of the IG that includes the exchange of other clinical data on the patient that may affect the patient's forecast

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

Peter Muir24963

Higher priority focus should be on transfer of immunization records

While CDS support for immunizations is helpful to patient and clinician, a higher priority should be accurate and easier transfer of immunization records including vaccines provided at pharmacies, schools, nursing homes, etc. Inaccurate or records will complicate CDS recommendations. This is often not contained in state db and is cumbersome to gather at the PCP level.

The transmission and compilation of vaccine records is beyond the scope of this ballot and defined operation. The current operation assumes that the requesting system has already compiled a complete immunization record. This system could be an IIS, EHR, pharmacy system, school system, nursing home, or any other system. The ballot neither prioritizes or precludes the use of any of these systems. 

Our IG has an pre-condition that the system initiating the operation has as complete a picture of the patient's immunization history as possible. The CDS engine is not responsible for collecting (or othewise knowing about) the patient's immunization history beyond what the initiating system is supplying. How they accumulate that history is out of scope for this document. We'll make sure that this pre-condition is clearly stated in the IG.

Proposed Disposition:  Not Persuasive with Mod. Our IG has an pre-condition that the system initiating the operation has as complete a picture of the patient's immunization history as possible. The CDS engine is not responsible for collecting (or othewise knowing about) the patient's immunization history beyond what the initiating system is supplying. How they accumulate that history is out of scope for this document. We'll make sure that this pre-condition is clearly stated in the IG.

From Peter Muir (11/1) -

Agree with IG position.

But I anticipate that down the road it will land on the PCP’s desk to gather the info that they do not receive now from patient, pharmacy, payer, etc. - which they do not have time for. 

Howard Strasburg24965

ImmunizationRecommendation targetDisease should be bound to SNOMED CT, additional constraint on vaccineCode needed

1. ImmunizationRecomendation.targetDisease and ImmunizationEvaluation.targetDisease should be bound to SNOMED CT instead of CVX. CVX represents vaccines, not diseases.
2. ImmunizationRecommendation should have an additional constraint to indicate that vaccineCode cannot be present with a contraindicatedVaccineCode in the same recommendation.

Proposed Disposition:  Duplicate to #13 - the same disposition will be applied








For Future Resolution
Bryn Rhodes24009

Consider returning a reference to the guideline used to make the recommendation

Consider including at least a reference to the guideline and/or evidence that supports the immunization recommendation.

The CPG-on-FHIR implementation guide has an immunizationrecommendation profile that describes some of this content:

http://hl7.org/fhir/uv/cpg/2019SEP/StructureDefinition-cpg-immunizationrecommendation.html

In particular strengthOfRecommendation, qualityOfEvidence, and instantiatesCanonical. If this profile is not appropriate for this IG, we would welcome feedback on the gaps preventing usage, and be happy to make update in support of this use case.

Need to discuss. Seems to be a good idea. Is this in current scope? What would this look like? Are any engines currently returning this information? Might need to review the CPG-on-FHIR IG to see if any of this makes sense. 

Craig - there are other differences in the profiles. Specifically, the cpg ImmunizationRecommendation profile requires:

-identifier (1..*) versus (0..*) - I don't think this would be a big deal for us

-Must Support of:

--patient (no problem for us)

--date (no problem for us)

--recommendation (no problem for us)

--recommendation.vaccineCode (no problem for us)

--recommendation.forecastStatus (no problem for us)

--recommendation.dateCriterion (no problem for us)

--recommendation.supportingPatientInformation (this is the one I'm not sure about)

Overall, this probably makes sense.

It's not clear if the last two extensions apply to the guideline being applied or the patient specific recommendation.

It's not clear what the instantiatesCanonical means. Is this a pointer to the guideline or the activity that is used to fulfill the recommendation. If the former, we don't have clear protocols defined to instantiate (and won't have in the near future). If the latter, the CDS engine probably wouldn't provide that sort of guidance.

Nor do we have clear scales for strength or quality of evidence.

We don't think our current scope (age based) requires supportingPatientInformation and it's not clear how a CDS engine would meet this Must Support requirement.

It's not clear how this relates to US-Core and/or QI-Core ImmunizationRecommendation profiles. Should CPG be defining their own profile straight from the base resource.

Eric - I agree with Craig's analysis, but I don't think CPG-on-FHIR is published yet. Are we proposing to reference this one, or duplicate (so that we could later reference)?  

Regarding the question about whether Immunization systems do this today? Not that I'm aware of, but there isn't any standard supporting this concept used by IIS today either. I think we could do strengthOfRecommendation easy enough, qualityOfEvidence maybe, but instantiatesConanical would be really difficult for us if I understand what that is. Here's the definition of it (The URL pointing to a FHIR-defined protocol, guideline, orderset or other definition that is adhered to in whole or in part by the event or request resource.). Does that mean we would have to have a "hepA FHIR Resource" of the ACIP guideline? As well as all other Vaccines on the Schedule?


Proposed Disposition: Considered for Future Use

If ACIP (the recommendation creation body) creates more structured recommendation, then supporting these extensions make sense, but it may be premature to support them in this version of the IG. This out of our defined scope for this iteration. It may be helpful to us (and possibly others) to allow the option to point to a URL for the protocol/guideline that is the basis of the recommendation (eg. a publication in the MMWR journal that discusses the recommendation from ACIP).

Ken Kawamoto24945

Recommend enabling desired functionality via a CDS Hooks interface

Proposed Disposition: Not Persuasive
Issac Vetter24947

Why not CDS Hooks?

Guys, this operation accepting a Parameters resource of defined context is somewhat recreating CDS Hooks. Have you considered using this existing standard for immunizations? Probably you have. Would you mind sharing the gaps you've found in CDS hooks?

Proposed Disposition: Not Persuasive

However, we should review the CDS Hooks interface and document the gaps and share these with CDS. 

Nathan will write something up that we can share with the commenters. If they still don't agree, we can invite them to this call to discuss further. We don't think this will make it into the final IG though.





...