FHIR - What are profiled resources in FHIR Specification - hl7-fhir

I've read it on some websites about the term profiled resources for example:
Vonk FHIR Server supports all resource types and search parameters in the FHIR specification, including profiled resources.
But I'm not sure about the term profiled resource here. I tried to search it but couldn't get satisfactory definition.

Profiled resources are those that conform to a specific profile which constraints them further from the base specification. [1]

Related

Are FHIR code systems available in OMOP from Athena?

FHIR seems to have implemented their own coding systems. For example, this was found in a Synthea patient:
"valueCoding": {
"code": "2106-3",
"system": "urn:oid:2.16.840.1.113883.6.238",
"display": "White"
}
Which seems to be from:
https://www.hl7.org/fhir/us/core/CodeSystem-cdcrec.html
I'm not seeing anything on the Athena terminology download page for this (login required).
https://athena.ohdsi.org/vocabulary/list
The code '2106-3' does appear in the standard download of terminology from Athena but as a LOINC code for a Choriogonadotropin test (so, not the same thing).
Are these FHIR terminologies available for OMOP in Athena (or elsewhere)?
Is there a place to download all of these FHIR terminologies in csv (or other bulk uploadable format)?
The FHIR terminologies can be downloaded as XML or JSON. Some have hierarchy and relationships, so flat CSV files are harder, though I believe there's a proposal to add that to FHIR IG publication tooling in the future. Note that FHIR is a data exchange standard and the terminologies themselves are defined in a variety of places - some on http://terminology.hl7.org, some in the core FHIR specification and some in different FHIR implementation guides (which can be defined by anyone). As such, there won't be a single place to download content, though there are registries you can use to search and download large sets of them.

FHIR interoperability platform choice

I want to create an interoperability platform FHIR compliance with a complex business logic.
Our clients can send FHIR resources to platform.
The best architecture by best practise documentation is an ibrid system FHIR + SOA, as this link says.
Now I write two examples of scenario I must to manage:
The first:
I want to create a ServiceRequest resource with a subject where I know only the fiscal code as identifier. If I need other informations about the subject I can query an external database, for example, to know name, surname and others.
I can do this, send to my interoperability platform only a Service Request as follow?
"resourceType" : "ServiceRequest",
"subject" : {
"reference" : "Patient?identifier=FISCALCODE"
}
and so on
The second:
I want to create a ServiceRequest resource with a RelatedPerson linked in the requester tag.
The RelatedPerson is not a fully registry, I know only name and surname and a link to patient.
I must create a SOA method createServiceRequest where I must to pass two parameters the ServiceRequest and RelatedPerson? Or I can use a CRUD method for Bundle resource where I put as entries my ServiceRequest and my RelatedPerson?
So if I try to summarize, the possible ways are:
Create a method createMyMethodName(ServiceRequest serviceRequest, RelatedPerson relatedPerson)
Creation and exposure of this method is it FHIR standard?
If the answer of first quesiton point is YES, in my platform I'll have a lot of custom methods but I have a very strict control on the input informations
Use a CRUD Bundle method where I pass into the Bundle resource the following entries: ServiceRequest, RelatedPerson
In this way I expose only one method to write on my platform, but I must to implement a lot of code to manage all input bundles with several different entries (I suppose a mega switch and then for each branch I apply the business logic controls to accomplish my business logic rules)
This response is not intended as a complete response to your question and comes from a US perspective; however, you may find the perspective useful.
Gotcha with identifier queries
"reference" : "Patient?identifier=FISCALCODE"
As written, your ?identifier=FISCALCODE will query the FISCALCODE key against all code systems. I think what you want is to specify a code system, e.g. ?identifier=<CodeSystem>|<FiscalCode>
This is a common gotcha that's buried in the FHIR search documentation.
You'll either have to reference an existing code system, e.g. an Italy specific implementation guide analogous to US Core that contains the list of FiscalCodes, or author your own.
Which FHIR integration paradigm are you using?
Before diving into the createMethod vs Bundle question, I think it'd be useful to step back and pick an overall FHIR integration approach.
In my opinion, there are three major approaches:
Load data into an existing stand-alone FHIR server
Challenge: Drift between data loaded in FHIR server and other data warehouses
FHIR server queries non-FHIR API
Challenge: Duplication between FHIR API and non-FHIR API
NB: In the limiting case, there is no data stored in the FHIR server proper. Adding to the confusion, some will call this implementation a "FHIR gateway" instead of a "FHIR server."
FHIR server queries staging database for FHIR data
Challenge: Must write data access for each FHIR resource and each data element.
In the future, there may be a fourth approach where one uses the FHIR mapping language in real-time from an intermediate source model to multiple targets.
Your "CRUD Bundle method" is more in-line with POSTing data to a stand-alone FHIR server, whereas your "createMyMethodName" is more in-line with writing DAOs (Data Access Objects) to an external database.
In the limit where you don't need to maintain synchrony between the FHIR server and source data systems, importing data into a stand-alone FHIR server is much less work.
In the limit where you already have mappings to an intermediate data model (in the US, many large service providers will have mappings to either the USCDI or the Common Clinical Dataset), you'll have an easier lift writing CRUD in the FHIR server against an existing database.
For a more in-depth discussion, there was a FHIR integration patterns talk at FHIR Dev Days 2018, starting at Slide 21. Note that the author assumes a familiarity with architectural patterns such as the facade pattern.
Select a stand-alone server or library
Unless you have a compelling requirement or are a large company, it's advisable to use an existing open-source stand-alone server or library implementation. The three most popular are:
HAPI-FHIR (Java)
Microsoft (.NET)
IBM (Java)
If taking the stand-alone option, popular commercial FHIR servers
Microsoft (hosted in Azure)
Smile CDR (commercial version of HAPI-FHIR)
Firely Vonk

FHIR: do I need to have StructureDefinition for all the resources?

FHIR Conformance Layer include StructureDefinition resource, and I'm trying to understand if it is mandatory to provide anything there, when my server does not have any custom resources?
We are going to support multiple Implementation Guides (e.g. US Core and CarinBB), which have their own profiles and extensions. But all their StructureDefinitions are already definied on hl7.org and I can have links to those profiles from my CapabilityStatement and instances. So do I need to expose those structure definitions on my server?
Or it should be just empty, since I don't have anything custom?
Your CapabiltyStatement should declare a StructureDefinition for each resource you support that indicates what your actual system capabilities are - I.e. what data you can actually consume or produce. Typically this will involve a combination of the expectations of a variety of profiles as well as some additional stuff. You may have limits on repetitions, you might not support certain optional elements from some profiles, and might support some additional elements or extensions that none of the profiles expect support for. Very few implementations will have internal support that exactly matches an official published profile. However, if you do, you could technically point to that official profile rather than creating one of your own.

Why GraphQL is termed as Query Language for "API" and not any Data?

I have just started reading about GraphQL and the description says it's a query language for API. Why is it termed as query language for API? Can't Graphql API service directly talk to Database or any other data source directly?
It's just poor word choice. Elsewhere on the official site, they refer to it as a "query language for your API" (emphasis mine), which is a bit less ambiguous. Other API endpoints can certainly be used as data sources for your GraphQL service, as can databases, file systems or just about anything. However, the intended meaning is that GraphQL can be used to create an API, not that it's used exclusively to interface with other APIs.
Here's a more technical and complete description from the spec:
GraphQL is a query language designed to build client applications by providing an intuitive and flexible syntax and system for describing their data requirements and interactions.
GraphQL is not a programming language capable of arbitrary computation, but is instead a language used to query application servers that have capabilities defined in this specification. GraphQL does not mandate a particular programming language or storage system for application servers that implement it. Instead, application servers take their capabilities and map them to a uniform language, type system, and philosophy that GraphQL encodes. This provides a unified interface friendly to product development and a powerful platform for tool‐building.

FHIR Query resource missing in Continuous Integration spec

We have detected FHIR Query resource is missing in FHIR Continuous Integration page.
Nevertheless,it´s present in Java implementation in zip library for that branch.
We are using this resource in certain FHIR messaging services which are already implemented: Message Bundles with at least MessageHeader and Query resources.
Will Query be present in DSTU2 or the missing is simply an integration error for documentation?
Thanks in advance for clarification.
Regards
Query has been supplanted by the notion of OperationDefinition, though how this is done in the messaging space isn't fully documented yet. The reference implementations aren't yet fully aligned with the draft specification. Both of these deficiencies will be corrected before the DSTU ballot opens in April.
Section 2.1.1.5 here (http://hl7.org/implement/standards/FHIR-Develop/search.html) will describe this usecase for you, however this section is not finished yet. It will be based on the way operations are invoked asynchronously (see 2.2.0.5 here http://hl7.org/implement/standards/FHIR-Develop/operations.html). This section is also sketchy. I will take this up with Grahame and Lloyd to flesh it out.

Resources