FHIR protocol questions - hl7-fhir

We are a HISP connecting doctors and patients looking at adopting FHIR protocol. I have few questions regarding FHIR.
We are looking at serializing FHIR resources as JSON in Couchbase. Is serializing FHR resources as-is a right approach?
How can I add new resources in addition to already defined ones? I read about creating "Other" resource and define all properties as extensions.
Is it the right approach?
How can I define value sets like medication code, gender etc or any kind of lookup as a resource?
I see "Contained" resource as a way to add a reference. In some scenarios it can be expensive to send many references.
Is it possible to define a resource that has "Contained" resource but has actual value instead of reference? Here is an example:
I'm an intermediary site where patients can book appointments and I send the data to a practice's EHR. I'd like to send full patient resource instead of display name alone (see example below). How do I do this?
Part of appointment resource sample:
"participant":[{"individual":{"reference":"Patient/example","display":"Peter James Chalmers"},"required":"required","status":"accepted"},{"type":[{"coding":[{"code":"attending"}]}]
How are resources defined in FHIR correspond to C-CDA? For example, if a C-CDA document comes from a EHR, how can I transform to a FHIR resource?
If an EHR consumes only C-CDA, how can I convert FHIR resource to C-CDA before sending to EHR.
Are there push notification mechanism built in FHIR? For example, I may want to push record changes to a patient's iPhone or push changes to an EHR.
Are there open source .Net libraries for FHIR that can help us jump start?
What is the recommended way to do authentication & authorization? I'd like to use oAuth2.
Thanks.

1 . We are looking at serializing FHIR resources as JSON in Couchbase. Is serializing FHR resources as-is a right approach?
it's "a" right approach, yes. There are others
2 . How can I add new resources in addition to already defined ones? I read about creating "Other" resource and define all properties as extensions. Is it the right approach?
Yes, for now; in principle it is intended to be possible to define real additional resources, but what the rules will be are not yet defined
3 . How can I define value sets like medication code, gender etc or any kind of lookup as a resource?
using the value set resource.
4 . I see "Contained" resource as a way to add a reference. In some scenarios it can be expensive to send many references. Is it possible to define a resource that has "Contained" resource but has actual value instead of reference?
I don't know what you mean.
5 . How are resources defined in FHIR correspond to C-CDA? For example, if a C-CDA document comes from a EHR, how can I transform to a FHIR resource? If an EHR consumes only C-CDA, how can I convert FHIR resource to C-CDA before sending to EHR.
Roughly, an section corresponds to the List resource, and an entry to a resource. There's no formal published work on alignment between C-CDA and FHIR yet, though some operational work exists here:
6 . Are there push notification mechanism built in FHIR? For example, I may want to push record changes to a patient's iPhone or push changes to an EHR.
Well, in the EHR case, the EHR should offer a FHIR server, and you create/update on the EHR. For a mobile client, the rules are different. You can't just push stuff at a phone, you need some kind of client initiation. We have added Subscriptions to the development version of FHIR (see the continuous build), but these are not in the DSTU version
7 . Are there open source .Net libraries for FHIR that can help us jump start?"
yes. see http://hl7.org/fhir/downloads.html
8 . What is the recommended way to do authentication & authorization? I'd like to use oAuth2.
We recommend OAuth

Related

Is there an FHIR Extension to indicate a Practitioner or Patient Resource has been validated against a registry

When I construct a Patient or Provider resource from incoming data I query a registry to confirm the incoming data is correct.
What I'd like to do is put a field in the resource to notify the receiving system that the data is either correct or is out of sync with the registry. I cold create my own extension, however wondering if an extension currently or will soon exit?
I've reviewed the HL FHIR site and cannot find reference to an extension like this
The VerificationResult resource is intended for that purpose, as if you're interested in verification information it's typically more than just a simple boolean - at least when the data is being shared outside a tight context where the verifying entity, verification mechanism, etc. might be able to be implicit.

Micro-service: How to provide an aggregated documentation?

Here is a simple use case to illustrate my question : imagine a bank mobile app, the features to implement are:
List the beneficiaries
Do a payment
We have one micro-service to handle the payments "PaymentService" and one to deal with the beneficiaries "BeneficiaryService". Both have a documented contract with RAML or OpenAPI.
I think it's not a good idea to let the mobile app call the two micro-services independently: it would expose too much the internal structure of the information system and provide no abstraction and so no mitigation.
So, we need to build a "facade" API that expose the routes of "PaymentService" + "BeneficiaryService" to ease the integration. Let's call it "MyAwesomeMobileApp"
I assume "MyAwesomeMobileApp" can be achieved by writing code (i.e. via an ESB or a dedicated Spring app) or via an API Gateway by configuration.
The thing is how do you provide aggregated documentation to your customer (the people coding the mobile app frontend) ?
By aggregated documentation I mean, a documentation with a set of routes from "PaymentService" and from "BeneficiaryService". A sort of third contract made with a subset of each micro-services.
Thank you
If you're providing (requiring) a gateway API between the application and the other services (which seems like a good choice in your example), you provide documentation only for the gateway API endpoints as the services it consumes are not relevant to the mobile app developer.
The way your facade implements communication with any services behind it could well be different than the services themselves (for example: hiding a field that is for internal use or using different field names) and, as such, the contract even for the service-specific models could well be different.
So, document the facade/gateway API well (and independently) and be on your way. It should internally have brokers or some other separation between the endpoints it exposes and the specific requirements of the services it consumes that allows them to be independently updated without too-tight coupling.
If you are looking for a simple concatenation of the contracts or in other words a "unified" public documentation that contains endpoints from both API specification documents/contracts, then you can give APIMatic's merging feature a try.
A detailed step-by-step walkthrough can be found here: https://docs.apimatic.io/manage-apis/api-merging/#merging-two-api-specifications---a-basic-example . However, in brief, the steps for your scenario can be:
Structure your API contracts in a root directory like shown in an example below:
dir\
payments\
openapi.json
beneficiary\
main.raml
APIMATIC-META.json
Here openapi.json and main.raml can be your OpenAPI and RAML contracts respectively.
A minimalistic APIMATIC-META.json configuration file can look like this to enable merging:
{
"MergeConfiguration": {
"MergedApiName": "My title",
"MergeApis": true
}
}
ZIP the directory, upload it and import it into the APIMatic Dashboard (You will need to sign up first).
Preview your public documentation by doing Generate > Proceed > Preview API Portal. Publish/host it as required.
If you are looking to automate the process, APIMatic has an API too: https://www.apimatic.io/docs/api#/http

Opening a public folder item via code and confusion about ids

After some reading I'm beginning to understand that there are multiple formats for the various ids used in exchange and Outlook. I'm trying to clear up some confusion, here is the scenario.
We have a vendor product that is crawling public folder content in Exchange server and identifying messages that meet certain criteria. When this software captures each message it stores an id that looks similar to the following:
AAIARgAAAAAAGkRzkKpmEc2byACqAC/EWgkAzDDxpv7lakqqtxgSLYsXTwAAAoOedgAA+v7vRoYnskqzbHwT4KwucwAAIH9adQAALgAAAAAAGkRzkKpmEc2byACqAC/EWgMAzDDxpv7lakqqtxgSLYsXTwAAAoOedgAA
I'm responsible for writing a WinForms application that presents these messages in a list and among other things allows them to open the message in Outlook. For purposes of this question, you may assume the user has access to the message.
In looking through the Outlook API and inspecting the message properties it looks like the only id I can find there takes the form:
000000001A447390AA6611CD9BC800AA002FC45A0900CC30F1A6FEE56A4AAAB718122D8B174F000002839E760000FAFEEF468627B24AB36C7C13E0AC2E730000207F5A750000
I've read material that suggests these could be the same id expressed in different formats but have had no luck using the ConvertId operation in the EWS services.
Can anyone confirm whether these are truly different representations of the same id or completely different entities? And whether it is possible to get from one to the other?
These are not the same ids - they are different ids referring to the same object.
If you are having problems with the ConvertId EWS separation, you might want to post a separate ConvertId specific question.

FHIR: Get all encounters, patients, appointments for the practice

I'm trying to use FHIR to pull all patients, encounters and appointments into an intermediate database for further analysis. Most of the FHIR API's appear to be designed to handle one patient ID at a time, or one encounter at a time, etc. What is the most efficient way to pull the full set of encounters and then keep it current, as well as appointments, etc.?
Please take a look at the FHIR specification website, specifically the page about the RESTFul API and look at search. The APIs have methods to support the interactions described on the website.

how to implement Complex Web API queries in ASP Core

I'm new to web API design, so I've tried to learn best practices of web API design using these articles:
1.Microsoft REST API Guidelines
2.Web API Design-Crafting Interfaces that Developers Love from "Apigee"
Apigee is recommending web API developers to use these recommendations to have better APIs.
I quote here two of the recommendations:
I need C# code for implementing these recommendations in my Web APIs (in ASP Core) which is a back-end for native mobile apps and AngularJs web site.
Sweep complexity behind the ‘?’
Most APIs have intricacies beyond the base level of a resource. Complexities can include many states that can be updated, changed, queried, as well as the attributes associated with
a resource.
Make it simple for developers to use the base URL by putting optional states and attributes behind the HTTP question mark. To get all red dogs running in the park:
GET /dogs?color=red&state=running&location=park
Partial response allows you to give developers just the information they need.
Take for example a request for a tweet on the Twitter API. You'll get much more than a typical twitter app often needs - including the name of person, the text of the tweet, a timestamp, how often the message was re-tweeted, and a lot of metadata.
Let's look at how several leading APIs handle giving developers just what they need in
responses, including Google who pioneered the idea of partial response.
LinkedIn
/people:(id,first-name,last-name,industry)
This request on a person returns the ID, first name, last name, and the industry.
LinkedIn does partial selection using this terse :(...) syntax which isn't self-evident.
Plus it's difficult for a developer to reverse engineer the meaning using a search engine.
Facebook
/joe.smith/friends?fields=id,name,picture
Google
?fields=title,media:group(media:thumbnail)
Google and Facebook have a similar approach, which works well.
They each have an optional parameter called fields after which you put the names of fieldsyou want to be returned.
As you see in this example, you can also put sub-objects in responses to pull in other information from additional resources.
Add optional fields in a comma-delimited list
The Google approach works extremely well.
Here's how to get just the information we need from our dogs API using this approach:
/dogs?fields=name,color,location
Now I need C# code that handles these kind of queries or even more complex like this:
api/books/?publisher=Jat&Writer=tom&location=LA?fields=title,ISBN?$orderBy=location desc,writerlimit=25&offset=50
So web API users will be able to send any kind of requests they want with different complexities, fields, ordering,... based on their needs.

Resources