Have you had a look at https://wiki.openmrs.org/display/docs/Patient+Image+Module ??
Unfortunately , the above module doesnt support ui-framework, and i would think thats some thing we would want to implement , it only supports the Legacy UI
Am trying it out but seems it has some glitches…
What would be your suggestion as an approach to archieve that? It also seems the developer had this in mind. I wonder if he started work on it @sunbiz
well , we could probably create doable simpler tickets to achieve that ,and either make them community priority or intro tickets , either way , we need to break down the entire tasks into simpler manageable tickets ,
Is your suggestion to
- build it with-in coreapps?
- Improve the current patient’s photo module
- A different module altogether?
Also when i tried playing around with the patient image module in the legacy ui; When i try to either upload or just take a picture, a get a pop up to log in again( and indeed the session gets ended)
Not sure about that behavior , but probably you could investigate further.
I wouldnt support extending that functionality in core apps , better if we just improve the existing module.
Let’s be smart at this point when adding brand new features to the Ref App because we risk to run into duplicated efforts with what the MF Squad is building for OpenMRS 3.0.
My suggestion is to first ensure that there is a FHIR way to save/fetch what you need. In this case an ID picture. Then, carefully analyse where those FHIR endpoint(s) will be used in the Ref App.
Thanks @mksd for looking at this…The client was satisfied using the attachment module for saving patients images…I was attempting the said ticket to see if we could have such a feature for the Ref App. I have pushed one final commit which has everything in place if we ever need it…The only features lacking on it are.
Making it an opt-in feature
Ability to display the image in the summary( currently it shows the uploaded file name or a default name if taken by webcam
Improving on the styling of the webcam. Otherwise thanks for the efforts in MF… Will be waiting.
In FHIR, there’s a
photo element for the
Patient resource, which is how you’d represent a patient identification photo. This element could either directly encode the picture data or pass along a URL to the correct data (to minimize the size of resources, I think we would generally only want to send a thumbnail with the patient resource and have a URL pointing to a larger resolution image in general).
I would agree with @dkayiwa’s comment here that patient images are best implemented as person attributes first because I don’t see the value in maintaining a history of patient identification images (and there may be privacy considerations) and second because it gives us a framework for adding, e.g., provider images, if that becomes a requirement (this is a pretty typical feature of EHRs in the US and UK).
Re: Dmitri’s comment on that ticket:
What happens to the old one when an ID picture is updated? Is there a FHIR recommendation around this?
FHIR generally avoids making these kinds of business logic recommendations. It would be perfectly legitimate in FHIR to return several different
Patient.photo elements with a single resource or to have the
Patient.photo elements store history using the FHIR versions API or only to have the latest patient photo available.