I'm new to FHIR and resources.
I'm on the search for a specific resource type, is there a resource type for Rules?
Rules contain 0 to * conditions and 1 to * actions. All conditions are connected with the 'and'-Operator. If all conditions are met, all actions shall be performed.
If there is no specific resource-type for such rules, how am i able to define rules with FHIR?
It sounds like what you're trying to do is decision support. Look at look at http://hl7.org/fhir/2016sep/decisionsupportservicemodule.html. If you're thinking more about protocols, look at http://hl7.org/fhir/2016sep/plandefinition.html
Related
One of the benefits being promoted for API-first design or OpenAPI is that of their use as a single source of truth. To my mind, these schemas only serve as a contract - the actual source of truth for your API lies in your microservices implementation (typically a http endpoint).
How can OpenAPI claim to be a single source of truth when the contract cannot be enforced until the implementation on the API side is complete? I realise there is tooling available to assist with this, such as validation middleware that can be used to match your request and response against your schema, however this is typically only validated at the point that a network request is made, not at compile time.
Of course you could write api tests to validate, but this is very much dependent on good test coverage and not something you get out of the box.
TLDR - OpenAPI markets itself as being a single source of truth for APIs, but this simply isn't true until your API implementation matches the spec. What tools/techniques (if any) can be used to mitigate this?
Did a bit of additional research into available tooling and found a solution that helps mitigate this issue:
open-api-backend (and presumably other such libraries) have capabilities to map your api routes/handlers to a specific openAPI operation or operationID. You can then enforce schema validation such that only routes defined in the spec can be implemented, else a fail-fast error is thrown)
I'm trying to extend and override the FHIR schema and run it on the local server.
Could you please suggest me is there any way to customize the FHIR schema and run in local
Obviously if you want to just download the FHIR schemas, you're free to edit them to your heart's content and, but if your instances aren't valid against the un-edited schemas, then your systems will not be FHIR-conformant and you won't interoperate with systems or tools that depend on FHIR conformance (which is most of them).
Also, be aware that the schemas only reflect a small portion of the rules for conformance. XML schemas don't check slicing, vocabulary bindings, invariants or logs of other rules that must also be met. Most systems using FHIR don't use schema validation at all, or use it only as an initial "quick check" and will still conduct more thorough code-based validation against he rules in the FHIR spec.
There should never be a situation where you need to modify the FHIR schemas. The expectation in FHIR is that the 'extension' element will be used to convey additional data elements if any are required. If you need to represent a concept that FHIR doesn't have a resource for at all, then you can use 'basic'. In some cases (if the element doesn't have a required vocabulary binding) you may be able to send an extension such as 'data-absent-reason' in place of sending an actual value. The only situation where there's no mechanism to avoid populating an element and sending it as FHIR requires is if there's a mandatory coded element with a required binding. Those are both rare and generally easy to satisfy, though you may need to map your internal codes to FHIR to populate the element.
Rather than trying to modify the schema, you might be better served by asking the community (e.g. http://chat.fhir.org) how to meet your needs within the FHIR specification as it stands.
I want to know if is it possible define in FHIR a strategy about read / write specific resource field.
i.e. I have a ServiceRequest resource.
I want to grant for a specific profile / role write on authoredOn field and I want to prevent the write for another profile / role.
I try to read CapabilitySystem resource but I think it don't fit my aim.
In FHIR, in which part of it, I can define profiles and roles?
In general, updates are to the whole resource, not to individual fields. You're free to define business rules that reject an update on the grounds that a field has changed that a user isn't authorized to manipulate, but there's no standard way to express this limitation in the CapabilityStatement. (You could define an extension though.)
I want to implement some business logic rules on FHIR resources and I want to work with RESTFUL API methods.
An example: I've a ServiceRequest resource with a status, I want to prevent change of status depends of the actual value
Suppose if ServiceRequest has status completed I don't want to change with status draft
To manage this scenario, I must implement my custom method or exists a standard bahaviour on FHIR to accomplish this?
Yep, you'd implement this with a custom method.
Maybe this answer and the Vadim answer is "apples and apples", but I think the term is Operations.
base resource:
https://www.hl7.org/fhir/servicerequest.html
then an operation off of that resource.
See
https://hapifhir.io/hapi-fhir/docs/server_plain/rest_operations_operations.html
http://hl7.org/fhir/operations.html
Here is a well known operation:
https://www.hl7.org/fhir/operation-patient-match.html
What would be a rest API convention to get a resource based on a different identificator?
For example
GET
/resource/{id}
GET
/resource/{guid}
Since this could be considered as a dupliate resource and setting routes for this could be a problem, what is an alternative then would follow rest API guidelines?
Maybe
/resources/?guid={guid}
or
/resources/guid/{guid}
or something else?
Short answer
You could use both /resource/{id} and /resource/{guid}. Many frameworks support regular expressions for matching path parameter values.
Long answer
REST is an architectural style and not a cookbook for designing URIs (see notes below). It doesn't enforce any URI design and it's totally up to you to pick the URIs that better identify your resources.
What you should keep in mind is: it's perfectly fine to have multiple mappings for the same entity. And each mapping is a resource, according to Fielding's dissertation:
A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.
With that being said, if you are supporting DELETE, it's important to mention how it's supposed to work:
4.3.5. DELETE
The DELETE method requests that the origin server remove the association between the target resource and its current functionality. In effect, this method is similar to the rm command in UNIX: it expresses a deletion operation on the URI mapping of the origin server rather than an expectation that the previously associated information be deleted. [...]
Note 1: The URI syntax is defined in the RFC 3986. As general rule, the path is organized in hierarchical form (with segments separated by /) and can contain non-hierarchical data in the query component (starting with ?).
Note 2: The REST architectural style is described in the chapter 5 of Roy T. Fielding's dissertation and it defines a set of constraints that must be followed by the applications that follow such architecture. However it says nothing about what the URIs must be like.
Note 3: The examples of a popular article written by Martin Fowler explaining a model defined by Leonard Richardson suggest a URI structure that looks friendly and easy to read.
I wouldn't normally duplicate an endpoint. The question would be:
why does one client have an id while another has a guid?
what design choice allowed that to happen?
I would leave it as a single resource endpoint:
GET
/resource/{id}
so clients who access resources via their id will use the above endpoint. I'd allow clients who access resources via their guid to exchange what they have (guid) for what they need (id):
GET
/id/{guid}
The above returns a resource id for the given resource guid. The client can then call the main resource endpoint with the id they have just received:
GET
/resource/{id}
but ultimately I'd look into why some clients use a guid rather than an id and change that so all clients access the API in the same way.