There are already a few designs showing what a Lab Order form could look like (when the user clicks “Add+” for Lab orders, but this seems far too basic. I suspect this needs a deeper clinical look from someone like @wamz and by comparing Lab Order forms that already exist in OMRS deployments; however, most of the time OMRS systems are just recording that a lab was ordered, not actually digitally creating a lab order.
Current, simple Lab Order Form design:
In-Form Ordering Flow: @pauladams I recall you did a lot of work to design how meds, referrals, and tests could be ordered/started from within a form context (eg while doing an “HIV Return Visit” form). Can you point us to these designs?
Otherwise, Two groups have already done some related work:
Ampath Lab Order Creation: Ampath set up their O3 form(s) to automatically trigger a lab order (with an auto-generated lab order number) if a lab test was requested as a simple drop-down option within an O3 form. (Then they connceted this via the lab order # with an existing integration with a CHAI-backed Lab Order tracking system.) @eachillah do you have any screenshots of this? *Update: Video from Eric:
BM Lab Lite (tho mostly currently investing on cloud prep; later will return focus.) (@nouman) O3/Bahmni: Uploading Lab Results as an Image
The current Bahmni Lab Ordering UI still looks like this:
What we still need
(I’ll update this tomorrow - hopefully this gets us started)
Thanks @grace for innitialising this thread ,
@OHRI ,when do we want to start having the design calls around this . can we use 3.x calls ?? or we could shedule separate calls
cc @caseynth2@janflowers
@grace they are typical Requests made by providers for a test to be performed for a patient. Say Viral Load request.
In FHIR these are known as service requests with “intent”: “order” and a specimen to identify the sample and subject(patient) from which the sample was taken from
Sorry for confusion @slubwama I just meant that I’m confused about what’s happening w.r.t. implementing Lab Orders in O3, as described in the first post above
@grace we have a way for making test requests which exist in patient clinic forms (HTML). When moving forward to 3. x we are thinking that a generic way of ordering for tests is much more ideal to enable either a mini lab (capability of resulting in a test) provided in OpenMRS or integration to more sophisticated lab systems.
Sorry @grace for taking long to respond here. At U-Wash ,we havent yet started any work yet.
We are supposed to start collaborating with the @OHRI team and any other teams to work on a comprehensive design for the Lab Orders in 03.
The first step would be to choose a time when we could have design calls focused on the 03 Lab Orders
@grace currently there isnt much work that has been put in lab orders development. We are still using the generic lab order workflow of doing the orders through the forms in o3 and not the order basket. Would be glad to give my contribution though
@grace thank you for reviving the conversation and as we spoke previously @OHRI is interested on being part of this work and we have talked to @janflowers and @mozzy in one of the FHIR calls about this collaboration. What was preventing us to work on this was the Pharmacy work (prescription and dispensing) that is almost complete. My proposal is that we (all parties interested) start talking about this on the TAC calls to decide the way forward. Excited to collaborate with you all on this
Great suggestion @eudson! OK let’s do that. The next TAC call Sept 12 - shall we dedicate most of that one to discussing this? Would that work for you @mozzy? (I know you have an in-person ITECH meeting that day so LMK if I need to find a different time/day, maybe some time next week instead?)
@eachillah I think most folks have not seen the cool in-form lab orders workflow + integration that Ampath built in to your Ampath Forms. I couldn’t find a recent video of this - could you share a short screen recording here?
@mksd I added all the Lab Orders designs to the first post above that I could find in zeplin. I think the problem @pauladams ran into was that there was not yet enough involvement and thus unclear real-world requirements. As you can see, the design above is very very different/lacking compared to the scope of Lab Order information usually required - as any sample Lab Requisition Orders show. eg. things like:
Reason for test
Nuances required for certain tests (eg weeks gestation, specific medications they’re on including routes and last dose etc (eg for Vancomycin dose monitoring), height and weight for Creatinine clearance…)
Forward to other doctor(s) or programs?
Forward to Reference Lab? If Y, Referral Lab Name
Not to say we should explode the scope - I think we can scope V1 effectively, we just need explicit orgs pooling resources together and dedicated to working on this. Sounds like UCSF & ITECH may be those orgs so we just need to align timelines
Hey @grace here is a short recording of how we currently do lab orders in AMRS 3.x
FYI: We have done integration of our EMR with the lab system (EID/VL) from the Kenyan government National body NASCOP. It automatically syncs the lab results back into AMRS tracked by the order number.
Hey @grace. Apologies for the late response. We are so much interested in lab orders feature in o3. We are currently focusing on the ‘clinician’ features for our v1 of o3 for KenyaEMR. We are more than happy to participate in the discussions and designs around the features.
As we have seen with drug orders, the information needed for orders can vary (e.g., simple dosing vs. free text dosing … and eventually tapers, combination dosing, etc.). This will become even more important for lab orders.
Some labs are very simple (e.g. blood counts, metabolic panels, viral load, etc.), where identifying the lab ± indication is sufficient. Other labs will need additional details (sample type, how collected, etc.). If we are including all tests (e.g., including imaging, procedures, etc.), questions could eventually vary by order (e.g., asking about test-specific requirements like whether the patient has a recent EKG when ordering a cardiac procedure).
To accommodate the flexibility needed for test orders, I would strongly encourage us to approach the order form as being largely data-driven, not hardcoded. Even if our first pass at lab orders only supports a few pre-defined sets of fields, it would be good to define the variable bits using our form schema or, at a minimum, write any hardcoded order form with the expectation that it will be replaced with a data-driven form in future iterations.
Are we focusing on lab orders? Or all tests (i.e., support not only labs, but also procedures, imaging, etc.)?
@grace@mksd@burke I just started playing with the new O3 order basket (in conjunction with the work we are doing with Dispensing) and found a feature that seems a bit suspect:
As soon as you open a new drug basket a, new Drug Encounter is created (if there isn’t one already associated with the visit). So, ie, if you just open a basket and close it again without even adding a drug (no mind saving it you’ll end up with an empty drug order encounter. In my opinion, this encounter should not be created until the order is saved. (There’s bigger discussion @mseaton started about even needing to create a separate encounter altogether see Associating data with the correct encounter - #10 by jdick )
Is this the best place to raise this issue?
(And, for what it’s worth and a little humor, I noticed it because due to something that could arguably be considered an unexpected quirk in a custom visit validator provided by PIH EMR , in the PIH EMR case, when I opened the order basket it started endlessly creating thousands of drug order encounters in the visit… )
Thanks @mogoodrich for reporting this, I’d say that you should open an O3 ticket/bug and ask the @Frontend_Team (← @grace I just created this) to have a look at it.
)