Stream: implementers
Topic: Azure API for FHIR
Lauri Karppinen (May 10 2019 at 06:51):
Not sure if this is the right stream for this question? Please guide me elsewhere if it's not. Does anyone have experience about Microsoft Azure cloud? Any pros and cons? If someone has experience of corresponding alternative in mind I would be interested hearing? Is there any restrictions or does it support everything in FHIR. I might be testing this service soon but wanted to ask first if there is something is should know before? Thanks in advance.
Elkhan Yusubov (May 10 2019 at 21:04):
Hi @Lauri Karppinen i have some experience with Azure FHIR API. The metadata tells what it supports. Did you have any specific question?
John Silva (May 10 2019 at 21:54):
@Lauri Karppinen -- I believe Azure FHIR API was discussed at the Microsoft Build conference this week -- here's an article about it:
https://msdynamicsworld.com/story/latest-azure-news-outage-powershell-azure-functions-azure-machine-learning-api-fhir-channel
and a pointer to the Azure FHIR API: https://azure.microsoft.com/en-us/blog/deploy-a-fhir-sandbox-in-azure/
Josh Mandel (May 10 2019 at 23:33):
(Also from the team that makes the server: @Michael Hansen and others are subscribed here.)
Michael Hansen (May 11 2019 at 01:39):
I am happy to take any specific questions.
Bjørn Erik Nordal (Jul 05 2019 at 13:02):
We are in the process of starting up development on a large and critical medication information system. We have decided to implement FHIR, and are looking at different options re implementing this. We would really like to move forward with Azure FHIR API, but we are dependent upon R4 support, as our focus is medication information (we are not really interested in the other stuff). The information on this page (https://github.com/microsoft/fhir-server/blob/master/docs/Roadmap.md) is not sufficient for us. So I will ask my questions here instead:
- When does MS plan to release a version of Azure FHIR API with R4 support?
- When does MS plan to support profiles?
- When does MS plan to support preloading?
Thank you for any help in this.
Lloyd McKenzie (Jul 05 2019 at 14:14):
@Michael Hansen
Peter Jordan (Jul 05 2019 at 20:23):
Support for SQL Server and FHIR R4 announced here... https://azure.microsoft.com/en-gb/blog/microsoft-fhir-server-for-azure-extends-to-sql/. Microsoft NZ are holding a WebCast next week to encourage local uptake.
Michael Hansen (Jul 05 2019 at 22:52):
Yes R4 is in our OSS codebase now and work is underway to offer it in PaaS this quarter.
Peter Jordan (Jul 09 2019 at 01:09):
@Michael Hansen many thanks for today's excellent Webinar on the FHIR API for MS Azure! Good numbers and participation - certainly by Kiwi standards.
Michael Hansen (Jul 09 2019 at 20:47):
@Peter Jordan it was a pleasure. Great to see all the interest in FHIR in NZ. I hope we can make a visit out there at some point.
Bjørn Erik Nordal (Jul 10 2019 at 09:00):
Thank you for responding so promptly. R4 in PaaS this quarter is good news. Does anyone have more information re profiling support?
Bjørn Erik Nordal (Aug 07 2019 at 08:41):
Bump Does anyone (@Michael Hansen perhaps?) have information about when profiling support will be implemented in the API? Thank you for any help. Besides that: Currently it seems the API is not available in Northern Europe Region. Are there plans to make the API available also there?
Michele Mottini (Aug 07 2019 at 12:06):
What would count as 'profiling support'? Validating against a profile?
Michael Hansen (Aug 07 2019 at 15:11):
We will support $validate (and ancillary "stuff") later this year. Northern Europe will be end of summer, early fall. R4 is very close in PaaS.
Grahame Grieve (Aug 07 2019 at 21:43):
the other thing that profiling support might mean is being able to choose a base profile that the server requires conformance to when resources are posted/put
Bjørn Erik Nordal (Aug 15 2019 at 10:38):
With "support" I mean the following: 1.Validating against a profile ($validate), 2.automatic conformance checking, and 3.indexing of extension fields for query operations. $validate is supported later this year I see. Good. My hope is that "ancillary stuff" includes points 2 and 3. Thank you.
Lauri Karppinen (Sep 17 2019 at 09:19):
I am happy to take any specific questions.
@Michael Hansen Took a long time but I ended up testing Azure FHIR. I am able to get the metadata for the server. And even the token but when I try to POST patient to the server for furher testing. I keep getting error:
{
"resourceType": "OperationOutcome",
"id": "b506c05db27645479d76f50dd2a19d00",
"issue": [
{
"severity": "error",
"code": "login",
"diagnostics": "Authentication failed."
}
]
}
First I tried with following this tutoria: https://docs.microsoft.com/en-us/azure/healthcare-apis/access-fhir-postman-tutorial
and then with some youtube tutorials for the same purpose. Now I have environment saved in Postman with: tenantid, clientid, clientsecret, subscriptionid and bearerToken. Token is in header as Authorizarion : Bearer{{bearerToken}} and other values in Params. Every Key has a value. Now I should be able to POST some demo patient to the server? Or is there something obvious I'm missing?
EDIT: Here is snip from Postman. Token should be ok that way?
pasted image
Lauri Karppinen (Sep 17 2019 at 12:09):
Some extra questions that came in mind while trying to figure this out. While deploying the Azure API for FHIR there was some additional settings I would like to confirm. Authority: https://login.microsoftonline.com/xxx where xxx is tenant-id? Audience: https://azurehealthcareapis.com or should it be https://xxxxxxx.azurehealthcareapis.com? Allowed object id's: here i have tenantid as well. This could be my problem? I tried to use this: https://docs.microsoft.com/en-us/azure/healthcare-apis/find-identity-object-ids to find object id's with no luck. Could not get anything with either powershell or CLI.
Lauri Karppinen (Sep 17 2019 at 12:42):
When I go to the header of the response there seems to be something wrong with my token: Bearer error="invalid_token", error_description="The audience is invalid". This led me to this tutorial where I should be able to get those object id's which I was guessing to be the problem earlier: https://docs.microsoft.com/en-us/azure/healthcare-apis/find-identity-object-ids#code-try-0 . There is a command which should give me the object id's but I'm not been able to get them. I should just replace the e-mail in the 'myuserconsoso.com' with my microsoft account e-mail? This is what I get as answer: Resource 'xxxxxx@outlook.com' does not exist or one of its queried reference-property objects are not present.
Lauri Karppinen (Sep 17 2019 at 13:28):
Finally I was able to get the Object id with $(Get-AzureADServicePrincipal -Filter "AppId eq 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'").ObjectId command. And I updated returned id value to the field for Allowed object IDs in Authentication. I still get the same error to header: Bearer error="invalid_token", error_description="The audience is invalid".
Michael Hansen (Sep 17 2019 at 15:27):
@Lauri Karppinen can you take a look at the return headers, they should give you some indication as to what is wrong. I see you are getting a 401, so I would guess that your audience (aud) claim in the token invalid. Please inspect your token with something like https://jwt.ms and see what the aud claim is. Then verify your authentication settings for the Azure API for FHIR instance....it could be something small like you have a slash at the end of one of them and not the other.
Michael Hansen (Sep 17 2019 at 15:29):
Sorry, I didn't see your additional message. Please check what the audience is set to for the instance and what you have in the token.
Lauri Karppinen (Sep 18 2019 at 06:08):
Thanks for the help so far @Michael Hansen !! I got the help from the link you sended. I actually had wrong value in the audience of my token. It helped that I got the token decoded. Thanks!
Lauri Karppinen (Oct 02 2019 at 07:33):
@Michael Hansen Is there something limiting POSTing transaction bundle? I'm not been able to POST bundle containing several transactions with requests. Here is simple example I'm able to POST to http://hapi.fhir.org/baseDstu3 but not to https://xxxxxxx.azurehealthcareapis.com/. Is it something to do with R4? Any ideas? Here is my example:
`
{
"entry": [
{
"resource":
{
"birthDate": "2005-01-02",
"gender": "female",
"id": "93a14fea-0c87-1000-b132-4d4c00001111",
"name": [
{
"family": "BundleTest",
"given": [
"BundleDude",
"Seppo"
]
}
],
"resourceType": "Patient"
},
"request": {
"method": "PUT",
"url": "Patient/93a14fea-0c87-1000-b132-4d4c00001111"
}
},
{
"resource": {
"id": "c04d8694-0c17-435c-ab0c-28dce1c94444",
"name": [
{
"family": "Testinen",
"given": [
"Hoitaja",
"Hanna"
]
}
],
"resourceType": "Practitioner"
},
"request": {
"method": "PUT",
"url": "Practitioner/c04d8694-0c17-435c-ab0c-28dce1c94444"
}
},
{
"resource": {
"category": [
{
"coding": [
{
"code": "vital-signs",
"system": "http://hl7.org/fhir/observation-category"
}
]
}
],
"code": {
"coding": [
{
"code": "8302-2",
"display": "Body height",
"system": "http://loinc.org"
}
]
},
"effectiveDateTime": "2019-05-06T12:02:34Z",
"id": "93a1e2ae-0c87-1000-b3a6-db1200002222",
"issued": "2019-05-06T12:02:58Z",
"language": "en",
"meta": {
"profile": [
"http://phr.kanta.fi/StructureDefinition/fiphr-bodyheight-stu3"
]
},
"performer": [
{
"reference": "Practitioner/c04d8694-0c17-435c-ab0c-28dce1c94444"
}
],
"resourceType": "Observation",
"status": "final",
"subject": {
"reference": "Patient/93a14fea-0c87-1000-b132-4d4c00001111"
},
"valueQuantity": {
"code": "cm",
"system": "http://unitsofmeasure.org",
"unit": "cm",
"value": 155
}
},
"request": {
"method": "PUT",
"url": "Observation/93a1e2ae-0c87-1000-b3a6-db1200002222"
}
}
],
"id": "93a1e2ba-0c87-1000-b622-915900003333",
"resourceType": "Bundle",
"type": "transaction"
}
`
Lloyd McKenzie (Oct 02 2019 at 14:12):
Not every server necessarily supports transaction. What message are you getting back?
Michael Hansen (Oct 02 2019 at 14:56):
The Azure API for FHIR does not (yet) support transaction bundles. The work is in progress as part of the SQL server based persistence provider we are working on, but it is not quite there yet.
Lauri Karppinen (Nov 18 2019 at 11:41):
Hi @Michael Hansen . Do You have any update on SQL Server/transaction bundles? Is there any estimates how long it will take it to work?
Michael Hansen (Nov 18 2019 at 15:04):
The work is going in right now. Should be completed by end of year.
Lauri Karppinen (Nov 19 2019 at 12:23):
Great to hear @Michael Hansen . That sounds promising. If I have understood correctly FHIR is at the moment based on cosmos database in Azure. I'm able to send and recieve resources to azure through Postman. I have not been able to find any view or solution to see data in actual database. I would like to see the structured data in database itself. Is there any demo or presentation how that works with cosmos database?
Michael Hansen (Nov 19 2019 at 13:58):
In the managed service (the Azure API for FHIR), you do not have direct access to the database. It is an implementation detail. If you would like to interact with the database directly (Cosmos or SQL), you can run the OSS version of the server, which you can find deployment instruction for here (https://docs.microsoft.com/en-us/azure/healthcare-apis/fhir-oss-portal-quickstart). And in the context of your question before, the transaction stuff will be available in the OSS server first and then later next years in the managed service.
Bjørn Erik Nordal (Dec 12 2019 at 09:57):
Export: Trying to export data from FHIR API. Getting "The supplied value for \"_destinationType\" paramter is invalid." Value provided is "azure-block-blob". Any hints?
Douglas DeShazo (Aug 21 2020 at 12:55):
Does Azure API for FHIR support any extended operations? Particularly $everything, $submit.
Josh Mandel (Aug 21 2020 at 15:49):
@Brendan Kowitz
Brendan Kowitz (Aug 21 2020 at 17:06):
We don't have these operations yet. We have mostly prioritized features based on customer feedback, I'd suggest creating some issues at https://github.com/microsoft/fhir-server/issues, I look at these regularly. $everything is on my radar, I don't have any etas on this yet though. I was also going to suggest visiting https://docs.microsoft.com/en-us/azure/healthcare-apis/fhir-features-supported but it looks like it doesn't list the extended operations (e.g. $export), I'll look into getting this updated too
Vidhi Shah (Dec 23 2020 at 13:31):
I have my own database and if I use Azure API for FHIR, can we have Azure API point/use and connect with our external database server outside Azure?
Lloyd McKenzie (Dec 23 2020 at 14:50):
@Michael Hansen
Josh Mandel (Dec 23 2020 at 15:00):
@Caitlin Voegele probably has a better answer, but I think the answer is: you'd need to write your own "persistence provider" for the open source FHIR Server for Azure, capable of translating FHIR interactions into your schema. If you want to use the managed service, you need to use one of the persistence providers that come out of the box (where the managed service hosts your server and your db).
Gino Canessa (Dec 23 2020 at 16:24):
Adding @Brendan Kowitz for eyes as well.
Brendan Kowitz (Dec 23 2020 at 20:54):
Correct, the Azure API for FHIR managed service contains the database as an implementation detail, there is no way to expose this or have the app layer point to another datasource.
If you use the open source code, although its technically possible to write your own data provider implementation (https://github.com/microsoft/fhir-server/blob/master/src/Microsoft.Health.Fhir.Core/Features/Persistence/IFhirDataStore.cs), most of the complexity is translating search requirements (https://github.com/microsoft/fhir-server/blob/master/src/Microsoft.Health.Fhir.Core/Features/Search/SearchService.cs).
Vidhi Shah (Dec 30 2020 at 07:36):
Thank you very much @Brendan Kowitz and @Josh Mandel . This was very helpful.
Brian Postlethwaite (Jan 11 2021 at 00:40):
And if you're doing a facade to your own storage, you might also consider Vonk's facade layer, or the one that I wrote which is on nuget too.
Source is at http://github.com/brianpos/fhir-net-web-api
Vibin_chander (Jan 31 2022 at 08:22):
In the Azure API for FHIR when I try to send a condition bundle it throws an error saying Condition.subject is must to have. But the standards of FHIR r4 does not mandate it. Isn't it a flaw in the implementation of Azure API for FHIR?
Josh Mandel (Jan 31 2022 at 14:22):
There shouldn't be a requirement to populate fields with a minimum cardinality of zero. Can you share an example of what you mean by "send a condition bundle"?
John Moehrke (Jan 31 2022 at 14:25):
this is likely a use-case like HL7, DICOM, and IHE have had for decades.. We know that some systems don't have this data, but for those that do have this data it must be sent... aka, R2 or RE. (This is what IHE uses Must-Support to convey).
David Pyke (Jan 31 2022 at 14:33):
In R4 Condition.subject is 1..1 So, it is required.
David Pyke (Jan 31 2022 at 14:34):
@John Moehrke your comment may be misplaced
John Moehrke (Jan 31 2022 at 14:38):
well, I simply didn't look that it was 1..1... oops
Vibin_chander (Feb 09 2022 at 10:42):
@David Pyke I really dont understand. I've physician related data. I have details on the conditions a physician treated & procedures a physician attended. Both are related to physician not a patient(subject). In this case why do we need to refer subject?
Vibin_chander (Feb 09 2022 at 10:45):
Also if R4 is used then Doesn't HAPI and AZURE API for FHIR behave in the same way? The condition bundle without referring the subject in the HAPI works fine. But it does not work in the Azure API for FHIR
Vibin_chander (Feb 09 2022 at 10:46):
so probably someone (a certification body) needs to validate the server functionalities
René Spronk (Feb 09 2022 at 10:55):
Every server may set its own 'rules' above and beyond what may be required by a jurisdiction. So you'll have to talk to the offending system vendor in question, of use a workaround. Only very few jurisdictions do certification of FHIR servers.
Vibin_chander (Feb 09 2022 at 11:06):
1...1 does it mean is it mandatory?
Vibin_chander (Feb 09 2022 at 11:06):
just trying to understand
Vibin_chander (Feb 09 2022 at 11:12):
R4 setting subject 1...1 in a procedure resource is obfuscating
René Spronk (Feb 09 2022 at 12:41):
Going back to the docs: Condition.subject is 1..1 in R5, and 1..1 in R4. as such a server SHOULD create an error if one posts a condition without that reference.
Vibin_chander (Feb 09 2022 at 12:58):
so HAPI is unreliable
Daniel Venton (Feb 09 2022 at 13:05):
Is HAPI unreliable or is it lenient enough to allow you to do what you want? I'm sure there is either an option or an overload that will force valid resources for your instance of HAPI. (Guessing).
Vibin_chander (Feb 09 2022 at 13:10):
all FHIR servers should be lenient enough to allow us to what we want
David Pyke (Feb 09 2022 at 13:16):
No, that is exactly what a standard is designed to prevent. If everyone does what they want, then we don't have interoperability
Lloyd McKenzie (Feb 09 2022 at 15:04):
If you feel there's a valid use-case for sharing patient-specific conditions that don't actually identify the patient, you can submit a change request asking for the cardinality to be loosened. However, if you want to know what conditions a physician treated, those are absolutely tied to a patient - a patient had the condition. If you're wanting a summary - E.g.. "this physician has treated 5 hernias and 7 abdominal rashes", then the Condition resource isn't appropriate - you'd need to use Observation to capture the point-in-time statistics.
Lloyd McKenzie (Feb 09 2022 at 15:05):
If it's a situation where you want to capture the details of everything the physician has done, but have the data anonymized, then the solution is to anonymize the record to point to an anonymized Patient - where the only details might be gender and birth-year or something like that.
Josh Mandel (Feb 09 2022 at 15:13):
(You can even technically satisfy this requirement with a contained patient that has no demographic data at all.)
Brian Postlethwaite (Feb 11 2022 at 01:27):
Or a data absent reason extension in the subject.
Vibin_chander (Feb 11 2022 at 04:47):
@David Pyke In this case when I send an Condition / Procedure resource with a subject reference that does not exist (an dummy GUID), the Azure API for FHIR does not validate it. I was expecting it to throw an error saying that "there is no patient reference mentioned exists". An FHIR server is suppose to validate if the patient actually exist or not right?
Brian Postlethwaite (Feb 12 2022 at 03:55):
Checking RI would be up to the server. It might be fine in some cases.
Last updated: Apr 12 2022 at 19:14 UTC
