(feat) O3-4223: Allow adding different order types in the order basket #2109
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: -597 kB (-3.59%) Total Size: 16 MB
ℹ️ View Unchanged
|
ibacher
reviewed
Nov 22, 2024
| _type: Type.String, | ||
| _description: 'Order type UUID to be displayed on the order basket', | ||
| }, | ||
| orderableConcepts: { |
There was a problem hiding this comment.
Having to list all of the orderables for an order type is not going to be something we want to support.
There was a problem hiding this comment.
Agreed. This should be done via concept sets, ideally in a manner similar to what we do in the O2 ordering OWA (I don't remember exactly what that does, but you can look at that code to find out... it likely has a global property that points to a set of drug and lab orderables.) See: https://github.com/openmrs/openmrs-owa-orderentry
There was a problem hiding this comment.
Sorry for the wrong name, but this is orderableConceptSets where you list the concept set UUID and we use the setMembers of the given concept set for placing orders.
If the implementer has provided a concept set, we get the orderable concepts from the set, else get all the concepts with the conceptClass mentioned in the orderType.
There was a problem hiding this comment.
For historical reasons, I don't love the idea of getting all concepts with a given concept class as orderables. Our metadata management hasn't been disciplined enough to make that useful.
Sidebar, does this also support orderableConceptSets where the members themselves are concept sets? This is helpful for things like lab test results, and I think that's a pattern we'll want with, e.g., procedure orders at the very least.
There was a problem hiding this comment.
Hi Ian!
I don't love the idea of getting all concepts with a given concept class as orderables.
If the implementer mentions the concept sets, then it'll be given higher priority than the conceptClass if mentioned.
does this also support orderableConceptSets where the members themselves are concept sets
Currently not, but I can push the change for that.
There was a problem hiding this comment.
To be clear about this, conceptClass for this is, at best, a kludge—and really an abuse of concept metadata. This is because there are always multiple ways concepts can be classified. For example, from the perspective of an EMR, a radiology test is... just a test the same way as a lab test is. It has a different workflow, etc., but it's still just a test.
The bigger issue here, though, is that relying on concept class to distinguish types of orderables requires metadata that is not present in CIEL and hence will not be present in most implementations—and over the long term, relying on things that are not part of the default community-supported thing is a great way to end up relying on a feature that will not be long-term sustainable.
There was a problem hiding this comment.
I was going to say that I didn't mind conceptClass as a fallback method as long as conceptSets is the preferred method but @ibacher seems to be making a strong case for not supporting concept classes, adding @mseaton for his thoughts.
As a tangential rabbit hole, I was looking at the O2 Lab configuration, and it currently is configured via single concept set but this is a set of sets, where each member is the a lab order category, and within each category are the orderables... and then within the orderables, some of these are setsrepresent a panel:
For instance, in the above, the categories (Hematology, Biochemstry, etc) are the concepts that are members of the "Lab Orderables" concept set.
Then all the tests listed in "Panels" and "Tests" are the concepts that are members of the "Hematology Concept Set".
And within that "Tests" are stand-alone tests, while "Panels" are concept sets that contain all the tests within that panel.
Not saying we need to do this now (especially since the O3 Lab Orders functionality is already in production ) but just an FYI while we are working on this that this is something we will need to support in the future for O2 compatibility (basically: 1) breaking the labs up into categories and 2) allow ordering tests as a panel or individually) so if we are expanding this new functionality to support "sets of concept sets" we should take this into consideration when designing.
Sorry for the long post!
There was a problem hiding this comment.
Hi @mogoodrich!
The above implementation can be used in the O3 as well, you can list both the Hematology Concept Set and Lab Orderables in the orderableConceptSets, it's just that it'll come in a single list, rather than the above grouping.
@ibacher, should I go ahead and remove the implementation supporting the conceptClasses?
There was a problem hiding this comment.
Hi @ibacher, I have removed the support for fetching the orderables by their concept classes.
Please review the rest of the changes.
Thanks!
packages/esm-patient-orders-app/src/components/test-order.component.tsx
Outdated
Show resolved
Hide resolved
packages/esm-patient-orders-app/src/order-basket/order-basket.workspace.tsx
Outdated
Show resolved
Hide resolved
packages/esm-patient-orders-app/src/order-basket/order-types/generic-order-panel.scss
Outdated
Show resolved
Hide resolved
packages/esm-patient-orders-app/src/order-basket/order-types/generic-order-panel.scss
Outdated
Show resolved
Hide resolved
packages/esm-patient-orders-app/src/order-basket/order-types/generic-order-type.component.tsx
Outdated
Show resolved
Hide resolved
packages/esm-patient-tests-app/src/test-orders/add-test-order/test-order-form.component.tsx
Outdated
Show resolved
Hide resolved
|
I also want to be clear that we cannot merge this in if it breaks the existing lab order functionality in any way, so be careful that things still work there with no code or configuration changes for implementers. Since this is widely-used in production, we have less freedom to break things "just because". |
vasharma05
force-pushed
the
feat/add-order-types
branch
5 times, most recently
from
bc1e953 to
e99c807
Compare
vasharma05
changed the title
vasharma05
changed the title
3 tasks
|
Looking into the failing E2E test. |
vasharma05
force-pushed
the
feat/add-order-types
branch
from
3a52372 to
c0f8c4b
Compare
vasharma05
force-pushed
the
feat/add-order-types
branch
from
9853a06 to
bea7dc6
Compare
ibacher
reviewed
Dec 3, 2024
.../esm-patient-orders-app/src/order-basket/general-order-type/general-order-type.component.tsx
Outdated
Show resolved
Hide resolved
.../esm-patient-orders-app/src/order-basket/general-order-type/general-order-type.component.tsx
Outdated
Show resolved
Hide resolved
.../esm-patient-orders-app/src/order-basket/general-order-type/general-order-type.component.tsx
Outdated
Show resolved
Hide resolved
|
Hi @ibacher! |
…/openmrs-esm-patient-chart into feat/add-order-types
ibacher
approved these changes
Dec 6, 2024
|
@vasharma05, when adding orders i have noticed that this error pops up and disappears upon refreshing the page. I wonder if it might be related to this PR |
|
Yes @VeronicaMuthee , |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Requirements
Summary
This PR allows the implementers to list additional order types in order basket, with keeping the labs and drug order changes intact.
Order Type
An order type has the following properties:
The reference application supports 3 types of ordertype's javaClassNames, as mentioned in the code block above. We use the
javaClassNameas the identifier to determine which kind of order it it, aDrugOrder,TestOrder, or a GeneralOrder.As per the current implementation, the Drug Order was implemented by the
@openmrs/esm-patient-medications-appand the Lab Order (Test order) is implemented by the@openmrs/esm-patient-tests-app.Since the order type's
javaClassNamedetermines the Data model used by the respective OrderType, the idea is that all the order types having thejavaClassName=org.openmrs.TestOrdershould be handled by the@openmrs/esm-patient-tests-appsince all the different order types will use the same Data Model in the backend.Similarly, for the different order types with the
javaClassName=org.openmrs.Order, a new implementation for these order types is added in the@openmrs/esm-patient-orders-app, under the name ofGeneral Order Type.This will allow the developer, that whatever flow they want for an Order Data Model, the same flow will be used for all the order types using the same Data Model, i.e.
javaClassName.How to add new order types in the configuration
To add an order type in the configuration, we need to determine whether it's a Test Order Type or a General Order Type (order type
javaClassName=org.openmrs.Order.Adding a Test Order type
Currently, the lab order is implemented in the
@openmrs/esm-patient-tests-app, and the configuration was built accordingly. Since changing an existing configuration can break things in another implementation, the configuration for the Order Type = "Test Order" with the UUID:52a447d3-a64a-11e3-9aeb-50e549534c5eis kept the same, which is:To add more order types with javaClassName
org.openmrs.TestOrder, you can add it in the following configuration:In the
additionalTestOrderTypes, the implementer can add theorderTypeUuidalong with 2 more propertiesorderableConceptClassesandorderConceptSets, which will be explained in the below sections.Adding a general Order Type
A new implementation is added for supporting the order types with
javaClassName=org.openmrs.Orderin the@openmrs/esm-patient-orders-app. New order types with the abovejavaClassNamecan be added in the following config:Similar to adding the
TestOrderOrder types, the same properties are defined for the General Orders.Defining an Order Type
All the configuration point mentioned above supports 3 types of properties for the order Types.
orderTypeUuidThis is the UUID of the order type.
orderableConceptSetsThis is an array, where the implementer can list the UUIDs of the concept sets. The
setMembersof the concept set mentioned will be used and listed as an orderable for the given order type UUID.Screenshots
Dev3
Screen.Recording.2024-12-06.at.15.13.25.mov
Ozone HSC Server
Configuration
Screen.Recording.2024-12-06.at.15.09.45.mov
Related Issue
https://openmrs.atlassian.net/browse/O3-4223
Other
Note to developers
The orders were grouped by 2 names:
medicationsandlabs, but since we have multiple order types available, the grouping for the orders (except the drug orders) is changed fromlabsto the UUID of the orderType.