@akanter would it make sense to add #8 below?
That’d be ConvSet/Text I would assume.
Currently, this hasn’t been implemented in the FHIR2 module, but it’s something we should think about.
FHIR displays immunizations as a separate resource, which doesn’t mean it can’t be stored in OpenMRS as an Obs group (we already provided multiple views into various tables via FHIR because, well, mapping FHIR ↔ OpenMRS is not a strictly one-to-one affair).
The ImmunizationRecommendation could simply be the result of one or more obs, but there may be some value in having a separate means of representing this than just a series of Obs, since, e.g., next vaccination time is not really a point-in-time datum the way most obs are.
I think it is possible to allow for non-coded immunizations, but I really would not want to allow that to be used very often. If people start doing that, then the resulting data will not be machine readable. Also, presume that it will not be FHIR compliant. Can i get specific examples of where there is a need to document non-coded immunizations so that we can determine why they can’t be coded?
I fully agree @akanter.
I don’t think that there’s cases where immunizations can’t be coded. I believe that this is meant to be a mechanism that keeps the door open “just in case” the target immunization isn’t available in database, as a fallback mechanism.
@rrameshbtech I think the business needs to be challenged on that point. Not sure if you did yet?
But that could be an obs date-typed, part of a group representing the recommendation?
I suspect that the reason why you tend to favour bespoke entities vs constructs made with obs groups is precisely for the ease of mapping from FHIR resources to OpenMRS’ data model? The bespoke entities would be made to be the FHIR representation (or a lightweight version of it) of some clinical data.
Even tho, in your case you can always go to the OpenMRS API. Like the one that existed for encounter diagnoses in EMR API before the actual table was introduced in Core. It’s more problematic for tools like DB Sync when we will come down to make it speak FHIR… Then having each table holding “FHIR records” would make everything a lot easier.
I was maybe being unclear that I’m thinking about this purely in terms of how to implement a “next vaccination” feature. Vaccinations stored as observations is very much the correct way to do things.
See, in my ideal world, “next suggested vaccination date” is not necessarily stored data.
Yes. I accept that all immunisations needs to be coded. As Dimitri mentioned this came as just in case. Let’s verify this once again with business team.
Hi @akanter, of course, this is a concern that has been voiced to the business side as well (cc @jesplana ) and I think is well understood by everybody. I think we will also make this to be configurable, so that by default non-coded vaccines can’t be keyed in using the new immunization history UI.
In the meantime, is it possible for you to provide a CIEL updated with that new ‘IMMUNIZATIONS NON-CODED’ as part of the immunization history construct? See here above:
I will have further questions about the protocol applied on the other thread, just to say that further changes might be needed on top of adding ‘IMMUNIZATIONS NON-CODED’.
Hi @akanter,
Do we have any updates about introducing IMMUNIZATIONS NON-CODED? As @mksd has mentioned above, it is a valid business scenario as well.
I created the concept 166011, but did not add it to the immunization history concept set. 
Already done, but it won’t show until the next release. You can use the current release and just add it manually for now.
Hello All,
We have been working on introducing an Immunization Widget in the Microfrontend Community.
We have a question similar to the one raised by @ssmusoke . We want to track the different doses for a vaccine, However we would like to also track schedule vaccines where the tracking doesn’t happen as dose-0/dose-1/dose-2 etc, but instead 2-Months/4-Months, 6-Months etc.
To do that, going with the similar approach as mentioned by @ball , we can add another sequence for scheduled vaccines as:
As of now we see two sequences:
dose sequence => 0,1,2,3...9
booster sequence => 11,12,13....19
(additional) scheduled sequence => 21,22,23,24,... etc
However we don’t know if there is a definite number of schedules for all vaccines. E.g, For a vaccine it could be (2 Months, 4 Months, 6 Months) and for another it could be (2 weeks, 5 weeks, 10 weeks) and totally different for another vaccine. So it will be hard to have a predefined fix number of schedules.
To overcome this problem we were thinking of changing the approach slightly. Instead of coming up with a general mapping of sequence numbering and labels these could be specific to vaccine. E.g.:
{
"vaccineName": "Some Vaccine",
"vaccineUuid": "XYZ",
"sequence": [{"doseLabel": "label.2months","doseNumber": 1},{"doseLabel":"label.4months","doseNumber": 2}]
OR
"sequence": [{"doseLabel": "label.2Weeks","doseNumber": 1},{"doseLabel": "label.5weeks","doseNumber": 2}]
OR
"sequence": [{"doseLabel": "label.dose1","doseNumber": 1},{"doseLabel": "label.dose2","doseNumber": 2}]
}
Another idea we were having, if there is a way this information could be defined in the vaccine concept ? Probably using (set-members/coded-anwers/attributes). This could be useful in case we want to use this mapping information at different places(MF widgets, RefApp widgets etc). Otherwise we would have to duplicate. @akanter We would like to hear from you on this point.
Let us know if there are any recommendations/suggetions.
I was under the impression we were going to be skipping an attempt to have something like the vaccine schedule for the MVP for this, the rationale being that it’s complex data and can require on-going maintenance (vaccine schedules vary not only depending on the vaccine in question, but the jurisdiction in which the vaccine is given, etc.). Is having this kind of information definitely a requirement or can we move forward without it?
Have you seen this presentation: https://slideplayer.com/slide/6024630/
I’d like to have someone walk me through the mockup and requirements you are working on.
Hi @akanter I realise that you were not there yesterday when I demo’d the latest version of the new immunizations screens for OpenMRS 3.0, and that is a pity. We need to make sure that you can comment on them at some point. Cc @grace @jesplana
While we are slowly wrapping this up, I came to wonder about those two:
(1) CIEL:1421, “IMMUNIZATION HISTORY”, Finding/N/A
Shouldn’t this be ConvSet/Coded?
This concept is the one that defines the obs group and that gathers the concepts that make the members of the obs group. For reference:
ConvSet – a group of concepts, typically questions, assembled for convenience, e.g. vitals signs
Apart from the more recent CIEL:166011 (“Immunization, non-coded”, Question/Text) all the concepts defining the obs members seem to be of the class Finding… I guess it’s an old mistake that we can’t undo anymore, right?
(2) CIEL:984, “IMMUNIZATIONS”, ConvSet/Coded
Shouldn’t this be Question/Coded?
That one defines the obs whose coded answer is the actual vaccine administered.
It is also a convenience default set of vaccines, it has a double use apparently.
Cc @ball
Can you attach a link to the recording and I will review the demo. Thanks!
I am surprised at the 1421 mistake, as it clearly is a set and I don’t know how people might be using it in another way. My tendency would be to change change the class to conv set.
As for 984, it is doing double duty, which perhaps is bad practice. It is a coded data type but classed as a conv set. unlike 1421, this is mostly used to hold the answer so having it as a coded class makes more sense.
