I'm new to FHIR and need to implement a simple interface. So far I'm trying to understand from the documentation the basics but there are lots of new terms so simple question...
Patient/{ID}
In this case I return a resource type of Patient with the details of a patient. So far so good!
Patient?name.given=Joe&name.family=Blogs
The above would be the index method. However, in this case I can return multiple patients.
What "type" or structure do I use to simply return an indexed list of responses?
I've seen possible candidates as List, Group, Composition and Bundle.
I need to know this generally so I can return the correct type for all "index" methods in RESTful Fhir.
Use Bundle.
{
"resourceType:"Bundle",
"type": "searchset",
"entry":[...]
}
Check https://www.hl7.org/fhir/bundle.html and see what you need to implement based on your requirments. As you can see almost everything in FHIR is optional.
Related
I want to implement a data structure that allows for powerful filtering within my application.
The closest implementation I've found is from Prisma https://www.prisma.io/docs/1.27/prisma-graphql-api/reference/queries-qwe1/#combining-multiple-filters (which is actually from GraphQL specification, for what I understand)
Example:
{
OR: [
{
AND: [
{ title_in: ["My biggest Adventure", "My latest Hobbies"] }
{ published: true }
]
}
{ id: "cixnen24p33lo0143bexvr52n" }
]
}
The idea is to compare a context against the filters and see if it's a match.
In the above example, the "context" would be an object with the id, title and published fields.
I'm looking for an algorithm that would perform the comparison and resolve whether it's a match or not.
As I'm not looking at reinventing the wheel (especially that it's a complex algorithm IMHO, as AND/OR/NOT conditions can be nested), I wonder if that particular algorithm already exists, or is based on some standards (as we can find that particular data structure on several apps, such as Prisma, PipeDrive and other).
I'm looking for documentation, implementation examples or even open source implementations. (I'm using JS)
I was also looking for such an implementation but couldn't find one.
So I created a prototype for it: https://github.com/Errorname/logical-object-match
We couldn't find a solution that matched our requirements, so built our own and released it as OSS (MIT).
https://github.com/UnlyEd/conditions-matcher
Compares a given context with a filter (a set of conditions) and resolves whether the context validates the filter. Strongly inspired by GraphQL filters.
I understand the principles of querying via graphql from the docs you could search:
{
"hero": {
"name": "R2-D2"
}
}
but how about you want to do something a bit more intricate such as:
{
"hero": {
"name": "R2-D2 AND C-3PO AND BB-8 NOT K-2SO"
}
}
is there any way to pass a string like this and get the appropriate results?
No, there isn't.
You can read through the GraphQL spec and see what it does and doesn't define. In particular the spec doesn't define any sort of filtering, any sort of expression language, or any sort of Boolean combinators. (There is no native way to say the equivalent of SQL's WHERE NAME='foo' without a field resolver explicitly adding it.)
What GraphQL allows for field arguments is sufficiently open-ended that you can build richer queries on top of it, but that's very specific to some application or library. Two prominent examples are the GitHub GraphQL API (which tends to allow exact-match queries on selected fields but nothing richer) and the Prisma API (which has an involved multi-level object scheme to replicate SQL queries).
I have been looking at some GraphQL implementations and what I understand is that GraphQL lets you traverse through the data in the form of a Graph.
Which means you get a list of books which is a REST call. The books might have an Author Name.
When the user wants more info on an author he says so and another REST call is made to fetch more details about that author.
Similarly the books list may have a field called Publisher and so on.
So here you fetch data as if you are connecting a node of Book to a node of Author or Publisher.
But I have seen some implementations where data from two rest calls are combined using for loops and presented in the UI. e.g. make a call to REST API of Books, then make a call to REST API of Authors who have written those books. Run a for nested for-loop(n^2 complexity) to combine the result and show information of both books and authors in one single summary view.
Is this an acceptable practice or is it breaking some core concepts of what GraphQL is not supposed to do?
I'm not sure I would saying doing so is "breaking some core concepts", but there is a potential disadvantage to "front loading" all your calls to the REST endpoint this way. GraphQL allows you to define a resolver for each field, which determines what value the field returns. A "parent" field is resolved before its "children" fields, and the value of the "parent" is passed down to the resolvers for each "child".
Let's say you have a schema like this:
type Query {
book(id: ID): Book
}
type Book {
title: String
author: Author
publisher: Publisher
}
Here, the book field would resolve to an object representing a book, and that object would be passed down to the resolvers for title, author, and publisher.
If no resolver is provided for a particular field, the default behavior is to look for a property on the parent object with the same name as the field and return that. So, your resolver for book could fetch both the book, the author and the publisher from some REST endpoint (3 calls total) and returned the combined result. Alternatively, you could just fetch the book, and let the author field resolver fetch the author and the publisher field resolver fetch the publisher.
They key is that a resolver is only called if that field is requested. The difference between these two approaches is that you could potentially query a book and only request the title.
query SomeQuery {
book(id: 1) {
title
}
}
In this scenario, if you front load all your API calls, then you're making two additional calls to the REST endpoint (for the author and the publisher) unnecessarily.
Of course, if you have a field that returns an array of books, you may not want to hammer your REST endpoint by fetching the author for each book requested, so in those situations it may make sense to fetch both books and authors all in the root query.
There's no one right answer here, since there may be trade-offs either way. It's a question of how your schema is designed, how it will be used and what costs are acceptable to you.
I run a Java GraphQL server with Apollo client. My model is based on personas - each one can be an 'Actor', 'SoccerPlayer', 'Politician', etc.., all implement the 'Person' interface.
I have a 'Search' field, returning list of 'Person', however one entity might be of two types..
For example, when querying for
Search (text: "Ronald Reagan"){
id
name
... on Actor{
films{
name
}
}
... on Politician{
party{
name
}
}
}
I would expect to get both 'films' and 'party' for the former US president and actor, although typeResolver (on server side) forces me to return only one type. Is this doable at all with GraphQL? Maybe my model is wrong?
Thanks
GraphQL spec does not allow for multi-level inheritance, so with your specific structure, a Person can either be one or the other, but not both Actor and Politician.
You could get slightly closer to your goal if you turned Actor and Politician into interfaces themselves, but you'd have to repeat the fields from Person in each one as, again, no multi-level inheritance is possible.
In this great book about Domain-Driven Design, a chapter is dedicated to the user interface and its relationship to domain objects.
One point that confuses me is the comparison between Use case optimal queries and presenters.
The excerpt dealing with optimal queries (page 517) is:
Rather than reading multiple whole Aggregate instances of various
types and then programmatically composing them into a single container
(DTO or DPO), you might instead use what is called a use case optimal
query.
This is where you design your Repository with finder query
methods that compose a custom object as a superset of one or more
Aggregate instances.
The query dynamically places the results into a
Value Object (6) specifically designed to address the needs of the use
case.
You design a Value Object, not a DTO, because the query is
domain specific, not application specific (as are DTOs). The custom
use case optimal Value Object is then consumed directly by the view
renderer.
Thus, the benefit of optimal queries is to directly provide a specific-to-view value object, acting as the real view model.
A page later, presenter pattern is described:
The presentation model acts as an Adapter. It masks the details of the
domain model by providing properties and behaviours that are designed
in terms of the needs of the view.
Rather than requiring the
domain model to specifically support the necessary view properties, it
is the responsibility of the Presentation Model to derive the
view-specific indicators and properties from the state of the domain
model.
It sounds that both ways achieve the construction of a view model, specific to the use case.
Currently my call chain (using Play Framework) looks like:
For queries: Controllers (acting as Rest interface sending Json) -> Queries (returning specific value object through optimal queries)
For commands: Controllers (acting as Rest interface sending Json) -> Application services (Commands) -> domain services/repositories/Aggregates (application services returns void)
My question is: if I already practice the use case optimal query, what would be the benefit of implementing the presenter pattern? Why bother with a presenter if one could always use optimal queries to satisfy the client needs directly?
I just think of one benefit of the presenter pattern: dealing with commands, not queries, thus providing to command some domain objects corresponding to the view models determined by the presenter. Controller would then be decoupled from domain object.
Indeed, another excerpt of Presenter description is:
Additionally, edits performed by the user are tracked by the
Presentation Model.
This is not the case of placing overloaded
responsibilities on the Presentation Model, since it's meant to adapt
in both directions, model to view and view to model.
However, I prefer sending pure primitives to application services (commands), rather than dealing directly with domain object, so this benefit would not apply for me.
Any explanation?
Just a guess :)
The preseneter pattern could reuse your repository's aggregate finder methods as much as possible. For example, we have two views, in this case we need two adapters(an adapter per view), but we only need one repository find method:
class CommentBriefViewAdapter {
private Comment comment;
public String getTitle() {
return partOf(comment.getTitle());
//return first 10 characters of the title, hide the rest
}
.....//other fields to display
}
class CommentDetailViewAdapter {
private Comment comment;
public String getTitle() {
return comment.getTitle();//return full title
}
.....//other fields to display
}
//In controller:
model.addAttribute(new CommentBriefViewAdapter(commentRepo.findBy(commentId)));
// same repo method
model.addAttribute(new CommentDetailViewAdapter(commentRepo.findBy(commentId)));
But optimal queries is view oriented(a query per view). I think these two solutions are designed for none-cqrs style ddd architecture. They're no longer needed in a cqrs-style arichitecture since queries are not based on repository but specific thin data layer.