Yes, unique to the PIH EMR… ideally, the code would be robust enough so that if a suitable encounter could not be created it wouldn’t continually create it, but it is a real edge case what the PIH Encounter Validator does (behind-the scenes it removes the encounter from the visit).
Yeah, I’ve complained about that behaviour before. It may have been fixed recently.
Does the PIH EMR return some kind of error when this happens? If so, that should be easy enough to fix… I’m not sure where the orders will end up though.
The current situation is definitely not the situation we want to be in long-term. I think we need to investigate exposing encounters as more of something that’s part of the “context” of working in the patient chart, similar to how visits are handled now and then be attaching data (from forms, orders, etc.) to that contextual encounter, but obviously we’re not there yet.
It doesn’t actually return an error, but I wouldn’t worry too much about it, we can work around it. I’m more concerned about the creation of an empty encounter in general. And, yes, having a context (which I know @mseaton has discussed in another post would be my preferred long-term approach).
Take care, Mark
Discussed the O3 refapp behavior today w @vasharma05 who will also contribute to this thread.
Back to Lab Orders: for those interested we’ll be having a preliminary design call this Friday at 4pm EAT / 8am EST at om.rs/zoomo3
Hi @mogoodrich , yes the behaviour was kept with the next iteration for creating an encounter before the order is placed.
The flow in here is:
- We checkout for any encounters present in the current visit.
- If there’s any encounter, all the orders in the current visit will be mapped to the same encounter.
Yes, the encounter is made beforehand the order is placed, but the upside to this is that the time to save an encounter reduces as compared to creating an encounter when creating an order.
But on a bigger scale, I am ready to work on this.
Thanks @mogoodrich!
Are we meeting in the next 15 minutes? Thanks!
@ibacher / @vasharma05 did we settle on a workable design that could be implemented soon? And that could make it for 3.0.0-beta.2?
In which case, what’s the ticket for this?
Hi @mksd ! The corresponding ticket as mentioned in previous replies:
https://issues.openmrs.org/browse/O3-1780
@ibacher @dkigen , can you review the PR?
Thanks!
Update on the plan with Lab Orders:
- UCSF is supporting the design resources, and has engaged Paul Adams to kick off the design & research work. We met on Friday last week to lay out the kick-off requirements with several orgs.
- This week Paul A has made some progress but was waiting on some resources and calls with providers which happened late this week.
- So we will have an open review on Monday Feb 6 at the weekly O3 Design Call for community review and feedback on Paul’s first round of designs.
1 Like
@vasharma05 @mksd I’m wondering how the lab orders work is progressing for 3.x? We’re looking at Ozone with OpenELIS, but are interested in using the standard FHIR workflow built into FHIR2 and Lab on FHIR modules that we’ve already built OpenELIS to use. We don’t want to duplicate work, so trying to figure out status of that work.
What’s that? Ozone isn’t leveraging anything else than the FHIR2 module.
We use the Lab On FHIR module to implement Lab Order Workflows between OpenMRS and OpenELIS based on the standard FHIR communication patterns and also based on the OpenHIE lab work flows.
Is there any progress on creating Lab Orders in 03 yet ??
How do you create Lab orders in ozone ?
1 Like
If we are waiting on a review on the O3 lab orders page, I’d be happy to take a look from my LIS perspective, or if there is an upcoming design session, I’d be happy to join!
I tried to access the Zeppelin designs for this one, but I don’t have access to the workspace (caseyi at uw if someone can invite me!)
Right now we’re just using an AMPATH form for lab test ordering, and that’s a temporary workaround for demo purposes until a proper lab test order UI exists and is usable.
We haven’t been able to prioritise this yet, looks like a good opportunity for UW to step in and lend some manpower 
1 Like
Oh , that makes sense.
Am using 3.x form builder whenever I try to save the form it brings an error. The server is running on webservices.rest 2.39.0-SNAPSHOT
Resource does not exist. Please check the documentation for implemented resources and their paths [Unknown resource:
@abertnamanya could you provide some detail? Which form are you saving, how you are doing it and which docs are guiding you?
Thank you @ruhanga ,
Am creating custom forms using form builder which is a module in 3.x . The aim is to have a form that will be used for lab ordering. Initially I thought the issue was coming from the versions of microfrontend, I changed the docker image tag to the lastest(within zone docker-compose file) still the error stayed.
Could you refer to the Ampath Forms documentation and try with the demo Lab entry form that comes with Ref App 3.x?
Thank you @ruhanga, The issue was with the nightly image it seems not yet stable, We actually used the demo tag, Then there is also an issue with the insertion of the data dictionary(some concepts are left out), when starting a visit it complains of the missing concept.
Visit Punctuality - d81d4698-e78c-420d-aac5-cb1f606fb32e
1 Like