I'm implementing FHIR at the moment and I'm having trouble dealing with appointment reasons.
I know I can use the value set available here : https://www.hl7.org/fhir/valueset-encounter-reason.html
or implement my own value set for it but it's still problematic because reasons are a resource in my app and practitioners can add, modify and delete them. Reasons also have various fields such as a color, ...
A value set won't be enough for my app.
Do you have any hints / ideas on how could I implement such thing ?
So you want to point to Condition or Observation as a reason? Or perhaps point to a ReferralRequest or ProcedureRequest the appointment is based on? If so, submit a change request - having these things would also be in alignment with the Request pattern which Appointment should be trying to align with. In the meantime, you're free to define an extension to convey the same meaning.
For us, the "reason" basically indicates what type of service the appointment is going to provide, so we actually map reasons to services, which we represent reason as a HealthcareService resource.
Basically, from the patient's perspective, they care about the "reason" they are going to the doctor. But from the healthcare provider's perspective, they care about the type of service they will provide to treat the reason.
Related
We want to categorize patients in our system. For example, in organ transplant, we want to "tag" a Patient FHIR resource as a donor or recipient (ignoring the scenario where a living donor can later become a recipient) since these types of "patients" are stored separately in the back end system. So when someone does a PUT HTTP request with a patient resource, we need to know what kind of patient it is before we can do the update in the database.
It's hard to determine the best way to approach this. Using the meta area seems promising, combined with the UsageContextType of "focus" perhaps, taking on values of "donor" or "recipient".
It's not clear though how to actually code something like this in a Patient resource (JSON for us). Any guidance/examples would be very much appreciated.
Sadly, I think the FHIR folks are going down the same path they used with the V3 RIM....lots of impenetrable standard definitions, but very few practical examples of how to use some of these FHIR standards in the real world. But that is another issue.
Don't understand ignoring the scenario where someone can be both donor and recipient. However, if you needed to, you could add an extension that differentiated. You could also use Patient.meta.tag.
With the RIM there'd have been an esoteric modelling mechanism to define what you wanted, likely walking through 3-4 classes to get to one element (and a whole lot of fixed values along the way). With FHIR, if you're doing something esoteric, you just define an extension.
If you see something in the core specification you find impenetrable, please submit a change request asking for the language to be improved. (There's a "propose a change" link at the bottom of every page and registration is free.)
As far as I know, POST is usually used for changing the state of the server, and PUT usually for updating the information. If I am creating a new index, should it not be POST instead of PUT? PUT does make sense when creating a document as it changes the state of data.
Your statement
As far as I know, POST is usually used for changing the state of the server, and PUT usually for updating the information.
does conform to the conventional HTTP vs CRUD semantics:
HTTP method
CRUD equivalent
Description
POST
Create
Let the target resource process the representation enclosed in the request.
PUT
Update
Set the target resource’s state to the state defined by the representation enclosed in the request.
However, the PUT spec also stipulates that:
The PUT method requests that the state of the target resource be
created or replaced with the state defined by the representation
enclosed in the request message payload
As such, PUT can (and is) used in Elasticsearch to both create an index AND update its
[settings and mappings].
Also, keep in mind that it's rarely just a matter of strict adherence to the semantics. One of the creators of ES put it this way:
It's all about REST semantics.
And our understanding of the semantics at the time when we made the APIs. And backwards compatibility constraints. And whatever "feels" natural to the person who implemented the API.
Where it makes a lot of sense Elasticsearch maps the HTTP verbs to
useful things. But when it doesn't make a ton of sense we just go with
whatever verb feels good rather than trying to be super strict about
REST. Also, we don't do linked data, instead relying on you to build
links from context. I'm told that is particularly non-REST. But it is
what we do.
As a newcomer to spring I would like to know the actual difference between:-
#PostMapping
#PutMapping
#PatchMapping
My understanding is PUT is for update but then we have to get the element by its id and then save() it. Similarly the save() method is again used by Post which automatically replaces by its identifier(PRIMARY). In my application I am able to use three of these methods interchangeably.
What is the point of having PATCH, POST, PUT types when we use repository save methods for all?
HTTP method tokens are used to define request semantics in such a way that general purpose components (browsers, reverse proxies, etc) can exploit the information to do intelligent things.
The easiest of these is that PUT has idempotent semantics; if an http response is lost, a general purpose component knows that it may autonomously retry sending the request. This in turn gives you a bit of extra reliability over an unreliable network, "for free".
The fact that your origin server uses the same persistence mechanism for each is an implementation detail, something deliberately hidden behind the "uniform interface".
The difference between PATCH and POST is subtle; PATCH gives you an unambiguous way to designate that the enclosed entity is a patch document, and offers a mechanism for discovering which patch document formats are understood by the origin server, neither of which you get from POST alone.
What's less clear, at least to me, is whether PATCH semantics allow an intermediate component to do something intelligent with a request - in other words, do the additional constraints (relative to POST) allow intermediaries to do anything interesting?
As best I can tell, the semantics of a PATCH request are more specific, but not actionably more specific -- certainly not as obviously as we have in the case of safe or idempotent request semantics.
POST is for creating a brand new object.
PUT will replace all of an objects properties in one go.
Leaving a property empty will empty the value in the datastore.
PATCH does a partial update of an object.
You can send it just the properties which should be updated.
A PATCH request with all object properties included will have the same effect as a POST request. But they are not the same.
The HTTP method is a convention not specific to Spring but is a main pillar of the REST API specification.
They make sure the intent of a request is clear and both the provider and consumer are in agreement of the end result.
Kind of like the pedals or gear shift in our cars. It's a lot easier when they all work the same.
Switching them up could lead to a lot of accidents.
For us as developers, it means we can expect most REST APIs to behave in a similar way, assuming an API is implemented according to or reasonably close to the specification.
POST/PUT/PATCH may look alike but there are subtle differences.
As you mention the PUT and PATCH methods require some kind of ID of the object to be updated.
In an example of a combined POST/PUT/PATCH endpoint, sending a request with an object, omitting some of its properties. How does the API react?
Update only the received properties.
Update the entire object, emptying the omitted properties.
Attempt to create a new object.
How is the consumer of the endpoint to know which of the three actions the server took?
This is where the HTTP method and specification/convention help determine the appropriate course of action.
Spring may facilitate the save method which can handle both creation, updates and partial updates. But this is not necessarily the case for other frameworks in Java or other languages.
Also, your application may be simple enough to handle POST/PUT/PATCH in the same controller method right now.
But over time as your application grows more complex, the separation of concerns makes your code a lot cleaner, more readable and maintainable.
So as a project matures it will almost certainly be necessary to modify attributes of the resource definitions to cope with additional requirements.
Let's use two trivial examples - to add a country code to a client address, or to remove a middle initial and swap in a middle name field instead.
Currently if the resource definition changes, composer won't read whatever values are extant in the repository. I didn't exhaustively try all combos, but have had to reconstitute my blockchain at least twice because of this problem.
Is there a way to mark fields either as "new" or "deprecated" to get past this that I overlooked? It will be hard to make a case to move a system that can't be changed forward to production.
In the same vein it doesn't seem to like empty or null strings much (at least for participant attributes). Having an "optional" override somewhere would save a lot of extra bounds checking in my application. Is there one of those I missed too?
So you can use the APIs or REST to expose the legacy data? You may be referring to Playground above (its not really a tool for looking at production data, its for model prototyping/sandbox/testing type stuff).
On optional question - can just add that the field is optional in the model - example here -> https://github.com/hyperledger/composer-sample-networks/blob/master/packages/pii-network/models/pii.cto#L20
Right now you can only set 'Allowed', 'Inherited' and 'Prohibited' per Joomla ACL. That's fine but far from complete. Consider the simple case you want to set a string per ACL, like 'allowed upload extensions'. There seems little or no information about.
Any ideas on this ? Its seems even more complicated when you want to register 'dynamic' parameters on the fly, so all this XML based persistence model you have in Joomla will fall a part as well...
Thanks!
This would be wrong, and a nightmare to debug (imagine guiding users when they start calling because they can't do something, and you have no idea where to look).
If you want your component to have more user-configurable actions, you can define some params in the config, where you set the list of extensions allowed in a custom action level, such as "extensions.safe", then assign that. You can create as many as you want. Find more info here
Unless you're proposing that existing components take into consideration arbitrarily defined dynamic parameters, it's hard to see how it could work.