Questions about resources in Allergy UI module

Development
21

Why does PatientService have removeAllergy and voidAllergy methods? When they both do the same, i.e. remove delegates to void

22

@Wyclif, those methods were transferred from allergyapi module in TRUNK-4747.

@darius, DELETE patient/uuid/allergy as a way of deleting all allergies is proving difficult to implement. DelegatingSubResource does not have a method which can be overridden to implement this behavior as its getAll method can be used to implement GET patient/uuid/allergy. Even if we assume in DelegatingSubResource.delete(allergy, reason, context) that the allergy parameter is null, I can’t see a way to access the parent Patient without which the list of allergies can’t be retrieved. An alternative is to require the client to delete all allergies one by one. What is the way to go?

23

Can’t you override public void delete(String parentUniqueId, String uuid, String reason, RequestContext context) and if uuid is null delete all allergies? I assume that parentUniqueId = uuid of patient (maybe I’m wrong).

24

Great, that is the solution I am I am looking for.

25

That’s the same thing i mentioned on IRC about delete. As for the duplicate methods, we should get rid of remove since it is doesn’t follow our naming convention for void methods

26

I’m assuming:

  • DELETE /patient/{uuid}/allergy would set the allergy list to an unknown status (i.e., we don’t know anything about the patient’s allergies).

  • DELETE /patient/{uuid}/allergy/{uuid} on the last known allergy for a patient (i.e., a patient with one allergy) would have the same effect. @jteich has argued that deleting the last allergy from the list should take the patient’s allergies to an unknown status and I agree.

But how does a client set the patient’s allergies to “No known allergies” – i.e., it’s not that we don’t know about the patient’s allergies; rather, we know the patient’s allergies and it’s an empty list. I’ve reviewed Darius’ summary, but didn’t see this in the list. Setting the patient’s allergy list to “no known allergies” (i.e., an empty list) is a very commonly used operation.

Would it be PUT /patient/{uuid}/allergies with an empty list? If so, that should return a 400 error if the patient has any known allergies (we shouldn’t silently void existing allergies).

27

@burke if you set the allergy status to unknown, the wouldn’t imply we need to void all the patient’s allergies? Which i think @jdegraft is having trouble with

28

Would it be PUT /patient/{uuid}/allergies with an empty list? If so, that should return a 400 error if the patient has any known allergies (we shouldn’t silently void existing allergies).

A problem is this will not allow a patient to move from having allergies to no known allergies if we need to support this. A child might be allergic and grow out of it. The allergies may have been attached by mistake and have to be removed.

It seems we need to differentiate the initial state and the state that is empty, from an explicit void state. If we start with Unknown Status and return to Unknown Status when all Allergies are voided, then we must be able to set No Known Allergies at any time irrespective of whether there are attached allergies or not.

As @Wyclif indicates the webservices infrastructure does not support

DELETE /patient/{uuid}/allergy would set the allergy list to an unknown status (i.e., we don’t know anything about the patient’s allergies)

it may support

PUT /patient/{uuid}/allergies with an empty list

however.

29

@wyclif, @burke is raising a different issue (though a bit related).

In the UI there is a “No Known Allergy” button, which is only available if the patient’s allergy state is unknown and will put them in the no known allergies state. However we have never stated how you would put a patient in this state via REST.

I agree with @burke that PUT /patient/{uuid}/allergies with body [] makes the most sense from an API standpoint.

We haven’t used PUT anywhere else, because elsewhere we only support updating certain properties, rather than putting the complete state of the resource. However in this case we are talking about putting the complete state of the resource, so


  1. PUT /patient/{uuid}/allergies with body [], for a patient in the “unknown allergies” state should move them to the “no known allergies” state by calling Allergies.confirmNoKnownAllergies(). It should return the patient’s allergies as its response.
  • PUT /patient/{uuid}/allergies with body [], for a patient already in the “no known allergies” state should have no effect. It should return the patient’s allergies as its response.
  • PUT /patient/{uuid}/allergies with body [], for a patient with 1+ allergies recorded should fail with a 4xx response.
  • PUT /patient/{uuid}/allergies with any value for its body besides the empty list should fail with a 4xx response
    • Our API doesn’t allow creating multiple allergies at a time. This might actually be nice behavior to have but it would be part of another ticket, and we’d only do this if a real consumer requests it.

Aside: for another kind of reasoning why you wouldn’t use PUT, but that doesn’t apply in our case, you can read about REST without PUT in the ThoughtWorks Tech Radar.

30

The (intentional) idea is that you’re not allowed to directly go from the state of “some known allergies” to “no known allergies”, but rather you (either via the UI, or via the REST API) have to delete/void all of the patient’s existing allergies, which automatically puts them in the “unknown allergies” state. Then you can do a PUT to move them to the “no known allergies” state.