I'm struggling a bit with reverse chaining in fhir search.
I can find all PractitionerRole resources for a given Practitioner with:
[base]/PractitionerRole?practitioner:Practitioner:id=100
How do I combine chaning and reverse chaining to find all HealthcareService resources for a given Practitioner? I tried the below and some variations of it.
[base]/HealthcareService?_has:PractitionerRole:practitioner:Practitioner:id=100
I would use:
[base]/PractitionerRole?practitioner=100&_include=PractitionerRole.service
It's more likely to be supported, and would also give you the roles in which the Practitioner is associated with the service.
Related
Is there a way for us to define the policies of a GraphQL API, which is both machine-readable and human-readable, which contains a set of rules (in other words, a specification) to describe the format of the API? I'm not talking about the schema, but of a spec where we can add security-related details (for example, complexity value to be assigned per field and depth limitation values) or any other related details. Any thoughts or ideas? Or can we send all of this within the SDL itself?
For example, for REST APIs, we use Swagger to define information on how to define paths, parameters, responses, models, security and more. Is there a need for a similar approach for GraphQL APIs? Your response is highly appreciated
We are working in an approach to add policies to your GraphQL API and allow you to better manage it, especially as you expose the interface externally.
Part of the challenge is that as opposed to a REST call that can easily be differentiated from others, all GraphQL requests look the same, unless a deeper analysis is performed on the incoming query.
This blog post describes how we perform this analysis: https://www.ibm.com/blogs/research/2019/02/graphql-api-management/
if this is of interest let's connect!
As per my understanding you need a tool to make documentation for the APIs you have build for parameters and so on.
If that's what you are searching, there is like swagger for GraphQL - Swagger-to-GraphQL
Hope that helps.!!
I'm working on extracting patients info in FHIR server however, I've came across two types of searching methods that were somewhat different. What is the difference between the search method of
Bundle bundle = client.seach().forResource(DiagnosticReport.class)
.
.
and
GET [base]/DiagnosticReport?result.code-value-
quantity=http://loinc.org|2823-3$gt5.4|http://unitsofmeasure.org|mmol/L
It's very confusing as it seemed that there isn't much that is mentioned about these two search methods. Can i achieve the same level of filtering with the first method compared to the url method?
The first is how to perform a search using the Java reference implementation. The latter explains what the actual HTTP query looks like that hits the server (and also specifies some additional search criteria). Behind the scenes the Java code in the first example is actually making an HTTP call that looks similar to the second example. The primary documentation in the FHIR specification deals with the HTTP call. The reference implementations work differently based on which language they are and are documented outside the FHIR specification on a reference implementation by reference implementation basis.
I would like to know what FHIR resource has to be used for bringing the list of specialities that are available for an organisation. These specialities are encounter specific so the response must be returned along with its encounter information based on the organisation.
Is that advisable to use List resource in FHIR?
If you search a FHIR server for a 'collection' of resources (like Encounter, HealthcareService or any other) the standard response would be a Bundle rather than a List.
Laravel beginner here. So as you can guess I am creating an blog where user can create an article under a category and have different tags.
I have defined plenty of routes for articles already.
public/article/{id}/show
public/article/{id}/delete
public/article/create
So if I define a CategoriesController and a TagsController, I'm going to have to to define all of these CRUD methods in it and the routes too as:
public/categories
public/categories/{id}/delete
public/categories/create
public/tags
public/tags/create
public/tags/delete
Should I move ahead and build it this way or is there a better way to do this?
If you're talking about an administration system, you need CRUD to maintain your tags table.
In a curated system, where tags are controlled, the process of adding tags involves finding existing tags, perhaps asynchronously. You could utilize id's behind the scenes, assuming you have a relational database.
As people type some characters into the tagging portion of the UI, the system asynchronously finds a matching tag and displays it. Once that has occurred, there is no reason not to use the tag ID, and in that case, having a full set of tag routes is useful, but is not essential unless you have curated tags. For example, even if you want to use relational keys to store the relationship, you probably just need a search function which takes a tag string, searches for the matching tag, and returns that matching data.
In some systems, whatever tags are provided are added on the fly, but even in those cases, they are usually at least conformed. For example, you might want to eliminate bad words, mixed case, punctuation etc.
In short, if you need to maintain a tag table, then you will want CRUD for tags. If not, then adding tags, would just be part of the dataset that is operated on probably as part of the POST, when an article is created.
Also, just logically speaking, you shouldn't have a route for /public/article/{id}/create. It should just be /public/article/create
here are some good directions to look for
use RESTful Resource Controllers so you don't have to define each and every CRUD operation seperately. It would make your routes and controllers neat and clean. plus RESTful its a recommended nice way.
RESTful Resource Controllers
Another way is patterns. use good patterns for designing structure and behavior. here are some good reads. have a look
https://www.ibm.com/developerworks/library/os-php-designptrns/
http://shawnmc.cool/the-repository-pattern
https://sourcemaking.com/design_patterns
one nice and common way is to use repository pattern. In repository pattern the repositories work in between models and controllers.
"Repository commonly refers to a storage location, often for safety or
preservation." - Wikipedia
This would make your controllers and models simple and clean.
Is use of search parameters limited to the common search parameters (ie. _id, _text) and those defined at the bottom of each resource definition? For instance, family, that's defined on the Patient resource # https://www.hl7.org/fhir/patient.html#search.
I'd like to know if it's possible to use any element of a resource directly as a search parameter? For example:
to search ImagingStudy with more than 3 series: /ImagingStudy?numberOfSeries>3
to search ImagingStudy with any series with ONLINE availability:
/ImagingStudy?series.availability=ONLINE. This is similar to Complex Type filter from Odata (http://www.odata.org/getting-started/basic-tutorial/#filter), where the same query could be written in OData as /ImagingStudy?$filter=series/any(s:s/availability eq 'ONLINE')
Following added on 2015-11-28:
Our server is a read-only service that aggregates data from various source systems and implements an API based on FHIR. Here are some interesting facts and challenges about the infrastructure:
Most of source systems can only provide primitive query capability,
for instance, filter by date.
We are not able to create indexes as we do not own the data repository.
In a typical scenario, we would first retrieve the date filter from the client's request and use it to reduce the amount of data that needs to be returned by a source system. Then our service will process the remaining filter, sorting, and paging on the aggregated result.
As an example, we have a requirement to implement string searching against ImagingStudy.procedure.code.coding[].display.
It is nice to know that server has the ability to define extra search parameters in the conformance statement; however, for our scenario, the search parameters are mostly driven by the clients needs. Any change or update to this needs could trigger a change to the server's conformance. This makes the conformance/contract vulnerable to changes.
This is the motivation that prompted my question, that since FHIR client and server already have a well defined contract defined via FHIR resources, would it be possible to extend this contract for search parameters, where the client and server will be able to leverage the existing object graph of the FHIR resource as the search parameters without having to define a separate list.
The search parameters are defined separately and mapped to actual paths within the resources to allow servers to maintain indexes via something like map/reduce rather than execute the queries long hand against unindexed content. You cannot simply query against arbitrary paths in the resources. Note: This includes the _filter search parameter.
Servers are allowed, however, to define their own search parameters and map these to arbitrary paths in the resources. If the server exposes a search parameter, it should declare it in the conformance statement, and then you'll know whether you can use it or not.
(btw, Servers are also allowed to choose not to use map/reduce, and to execute the queries long hand, and therefore to allow any path to be used as a parameter, if that is an effective strategy for their technology base - though I don't know of one that does this.)