Stream: implementers
Topic: VacinnationProtocol (Immnunisation)
Kevin Mayfield (Nov 21 2017 at 10:14):
Am I correct in believing this is the immunisation schedule. So it's 'static' look up data.
Kevin Mayfield (Nov 21 2017 at 10:16):
When implementing this in a SQL database I could have a Immunisation table which points to a VaccinationProtocol table entry.
Grahame Grieve (Nov 21 2017 at 10:17):
it will be tailored to the individual. btw, @Bryn Rhodes I've been meaning to ask you about this resource - can it go away in favour of a generic decision support outcome?
Kevin Mayfield (Nov 21 2017 at 11:04):
Thanks that's more than what we need to show in our examples, so will leave that section off for now.
Bryn Rhodes (Nov 21 2017 at 17:37):
@Grahame Grieve yes, I think you could use PlanDefinition to represent both Immunization.vaccinationProtocol, as well as ImmunizationRecommendation.protocol, and it would make sense to have those defined as a resource, rather than repeating that information in every instance. We'd need to work through an example of what that would look like.
Grahame Grieve (Nov 21 2017 at 18:37):
interesting, so you'd still retain the wrapper resource?
Bryn Rhodes (Nov 21 2017 at 18:39):
No, I would think that ImmunizationRecommendation should be a recommendation for a single immunization, and use a RequestGroup or CarePlan to group them.
Richard Townley-O'Neill (Nov 24 2017 at 00:51):
Immunization.vaccinationProtocol contains some data that is not part of a definition of the protocol: .doseSequence, .doseStatus and .doseStatusReason.
Richard Townley-O'Neill (Nov 24 2017 at 00:58):
If it makes sense for doseSequence or doseStatus to depend upon the protocol, something like the vaccinationProtocol backbone element will still be needed.
Last updated: Apr 12 2022 at 19:14 UTC
