One of thing, we can really use some help with is definition of episodeOfCare.reason
reason.use - I am not sure if I like the idea of mapping to a concept. It is from a predefined valueset and seems limited (example as of now). why not use just fixed code/string? We can start with existing example Valueset-encounter-reason-use - FHIR v6.0.0-ballot3 - so just - CC, HC, AD, RV, HM etc.
I am not sure how we would leverage reason.use, as of now, I can only think of reason.value.concept. Maybe someone would want to leverage reason.value.reference in combination with reason.value.concept in future.
reason.value.reference - I prefer keeping it just reference to a text which the client can subsequently resolve through another API. I would prefer we keep simple text - Condition/uuid, or Procedure/uuid. (I don’t prefer the pattern followed in fhir_reference table. I think it may cause a lot of database performance issues)
I know thats the right mapping but its going to be a a value from a limited set. Its like FHIR Encounter.class, where OpenMRS has it set to encounter_type. I am ok to leave it to a ref to a concept. We aren’t going to use it AFAIK, just to keep it compatible with future EpisodeOfCare.reason.use
An example binding to a terminology means just that. It’s just an example of the type of valueset you might use for that. We can, in essence, completely ignore it. And, unless we have a strong reason to use the reason.use field, it seems better just to ignore it, which would be what my vote is.
There may be more value to reason.value, but it should probably not be used to convey information about the Conditions addressed in the EOC. That’s what the diagnosis element is for (despite the name).
@ibacher
I agree on both (reason.use and episodeofcare.diagnosis ).
Episode diagnosis states them as the list of medical conditions that were addressed during the episode of care. They need not be known at the time of EOC creation.
For reason.use, I am inclined to go without it. Although I have the implementation already.
I believe, you are referring to ‘reason.value.concept’
However, there is also reason.value.reference which can actually be a reference to a problem (Condition/Observation/Procedure etc) - as reasons that are expected to be addressed during the episode of care. e.g a specific recording of ’ Angina as observation can be added as reasons expected to be addressed during the EOC, which can eventually lead to a diagnosis being done.
