Stream: implementers
Topic: FHIR Resource
booma radhakrishnan (Jun 01 2021 at 10:47):
I am trying to get the patient resource from EPIC Sandbox with scope: 'Patient.Read, Patient.Search,Observation.Read,Observation.Search,QuestionnaireResponse.Create(Appointment and Series),QuestionnaireResponse.Read(Appointment and Series)'
To read a patient i am using https://github.com/Vermonster/fhir-kit-client and API Endpoint url i am using is :
https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/
fhirClient
.read({ resourceType: 'Patient', id: '2e27c71e-30c8-4ceb-8c1c-5641e066c0a4' })
.then((response) => {
console.log(response);
});
I am getting 401 unAuthorized in the below url
https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/Patient/erXuFYUfucBZaryVksYEcMg3
I am missing something or wrong API End points. Please provide suggestions.
Lloyd McKenzie (Jun 01 2021 at 13:51):
Have you established your OAuth connection?
booma radhakrishnan (Jun 02 2021 at 13:09):
I figured out the Bearar token was the wrong now EPIC EHR is able to add the QiuestionnaireResponse
I wanted to do the same with Cerner now i am geeting 403 forbidden error
Request URL: https://fhir-myrecord.cerner.com/dstu2/ec2458f2-1e24-41c8-b71b-0e701af7583d/Observation
Request Method: POST
Status Code: 403 Forbidden
Remote Address: 99.86.20.74:443
Referrer Policy: strict-origin-when-cross-origin
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: WWW-Authenticate, X-Request-Id
Connection: keep-alive
Content-Length: 207
Content-Type: application/json+fhir
Date: Wed, 02 Jun 2021 12:54:14 GMT
Via: 1.1 edb458e051043db21ceb60aa65326738.cloudfront.net (CloudFront)
WWW-Authenticate: Bearer realm="fhir-myrecord.cerner.com", error="insufficient_scope"
X-Amz-Cf-Id: TptHnGGD4ckRn_jV4IYxQmN22YLUk9EudMDbCz8Nb7YB_-JUPVfRCA==
X-Amz-Cf-Pop: BLR50-C2
X-Cache: Error from cloudfront
X-Request-Id: 8e4bafab-6afb-43b6-9775-2a16d876b504
accept: application/json+fhir
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
authorization: Bearer eyJraWQiOiIyMDIxLTA2LTAxVDAzOjQwOjU2Ljg1OC5lYyIsInR5cCI6IkpXVCIsImFsZyI6IkVTMjU2In0.eyJpc3MiOiJodHRwczpcL1wvYXV0aG9yaXphdGlvbi5jZXJuZXIuY29tXC8iLCJleHAiOjE2MjI2MzkwNTAsImlhdCI6MTYyMjYzODQ1MCwianRpIjoiYjUwMjFiN2YtMzIzMS00NmU4LWExYTQtOGMyNmRkNjMyYzJiIiwidXJuOmNlcm5lcjphdXRob3JpemF0aW9uOmNsYWltczp2ZXJzaW9uOjEiOnsidmVyIjoiMS4wIiwicHJvZmlsZXMiOnsic21hcnQtdjEiOnsicGF0aWVudHMiOlsiMTI3MjQwNjkiXSwiYXpzIjoiZmhpclVzZXIgb3BlbmlkIHBhdGllbnRcL0FsbGVyZ3lJbnRvbGVyYW5jZS5yZWFkIHBhdGllbnRcL0FwcG9pbnRtZW50LnJlYWQgcGF0aWVudFwvQmluYXJ5LnJlYWQgcGF0aWVudFwvQ2FyZVBsYW4ucmVhZCBwYXRpZW50XC9Db25kaXRpb24ucmVhZCBwYXRpZW50XC9Db250cmFjdC5yZWFkIHBhdGllbnRcL0RldmljZS5yZWFkIHBhdGllbnRcL0RpYWdub3N0aWNSZXBvcnQucmVhZCBwYXRpZW50XC9Eb2N1bWVudFJlZmVyZW5jZS5yZWFkIHBhdGllbnRcL0VuY291bnRlci5yZWFkIHBhdGllbnRcL0dvYWwucmVhZCBwYXRpZW50XC9JbW11bml6YXRpb24ucmVhZCBwYXRpZW50XC9NZWRpY2F0aW9uQWRtaW5pc3RyYXRpb24ucmVhZCBwYXRpZW50XC9NZWRpY2F0aW9uT3JkZXIucmVhZCBwYXRpZW50XC9NZWRpY2F0aW9uU3RhdGVtZW50LnJlYWQgcGF0aWVudFwvT2JzZXJ2YXRpb24ucmVhZCBwYXRpZW50XC9QYXRpZW50LnJlYWQgcGF0aWVudFwvUGVyc29uLnJlYWQgcGF0aWVudFwvUHJvY2VkdXJlLnJlYWQgcGF0aWVudFwvUmVsYXRlZFBlcnNvbi5yZWFkIHBhdGllbnRcL1NjaGVkdWxlLnJlYWQgcHJvZmlsZSJ9fSwiY2xpZW50Ijp7Im5hbWUiOiJDZXJuZXIgQXBwIChTdGFuZGxvbmUpIiwiaWQiOiJkYmQzOTc4ZS05MDllLTQ5ODktOGQyYi1iZDI4YWFhNzQ4OTYifSwidXNlciI6eyJwcmluY2lwYWwiOiJ3djZueTdqODdkMzljcDN5IiwicGVyc29uYSI6InBhdGllbnQiLCJpZHNwIjoiZWMyNDU4ZjItMWUyNC00MWM4LWI3MWItMGU3MDFhZjc1ODNkLWNoIiwic2Vzc2lvbklkIjoiMWYwNTZmYTctOTA4Ni00N2MwLWEwMWUtYTk2NWIxNTFkZDEyIiwicHJpbmNpcGFsVHlwZSI6InVzZXJuYW1lIiwicHJpbmNpcGFsVXJpIjoidXJuOmNlcm5lcjppZGVudGl0eS1mZWRlcmF0aW9uOnJlYWxtOmVjMjQ1OGYyLTFlMjQtNDFjOC1iNzFiLTBlNzAxYWY3NTgzZC1jaDpwcmluY2lwYWw6d3Y2bnk3ajg3ZDM5Y3AzeSIsImlkc3BVcmkiOiJodHRwczpcL1wvY2VybmVyaGVhbHRoLmNvbVwvc2FtbFwvcmVhbG1zXC9lYzI0NThmMi0xZTI0LTQxYzgtYjcxYi0wZTcwMWFmNzU4M2QtY2hcL21ldGFkYXRhIn0sInRlbmFudCI6ImVjMjQ1OGYyLTFlMjQtNDFjOC1iNzFiLTBlNzAxYWY3NTgzZCJ9fQ.P9sXlxmFuWqe4q5KPD-0UnpkMGG3whr1I0BFpuipyXDhN2lfeaooXYhkxVtnwSnOXZ9jpYjxlfquO747wehxIA
Connection: keep-alive
Content-Length: 559
content-type: application/fhir+json
Host: fhir-myrecord.cerner.com
Origin: http://localhost:3001
Referer: http://localhost:3001/
sec-ch-ua: "Google Chrome";v="89", "Chromium";v="89", ";Not A Brand";v="99"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36
{resourceType: "Observation",…}
item: [{linkId: "1", item: [{linkId: "1.1", text: "Q1", answer: [{valueString: "Yes"}]}]},…]
resourceType: "Observation"
Lloyd McKenzie (Jun 02 2021 at 13:46):
Does the server declare support for POST? Does your account have privileges to do so?
booma radhakrishnan (Jun 02 2021 at 13:52):
WWW-Authenticate: Bearer error="insufficient_scope", error_description="The access token provided is valid, but is not authorized for this service"
What scope i should have to read the QuestionnnaireResponse.
I have added the below scopes.
'scope': 'Patient.Read, Patient.Search,Observation.Create, Observation.Read,Observation.Search,QuestionnaireResponse.Create(Appointment and Series),QuestionnaireResponse.Read (Immunization)QuestionnaireResponse.Read(Appointment and Series)
Request URL: https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/QuestionnaireResponse?patient=erXuFYUfucBZaryVksYEcMg3
Request Method: GET
Status Code: 403 Forbidden
Remote Address: 199.204.56.200:443
Referrer Policy: strict-origin-when-cross-origin
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: origin, authorization, accept, content-type, x-requested-with, Epic-User-ID, Epic-User-IDType, Epic-Client-ID, soapaction, Epic-MyChartUser-ID, Epic-MyChartUser-IDType
Access-Control-Allow-Methods: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS
Access-Control-Allow-Origin: *
Cache-Control: no-cache,no-store
Content-Length: 0
Date: Wed, 02 Jun 2021 13:49:08 GMT
Expires: -1
Pragma: no-cache
Set-Cookie: EpicPersistenceCookie=!wXhoS6dvi209OMnkywGuayYXr7azRSD4X3MQ0xa4tQmG1XnWwldmMs794BBdnMle26oC6lMc2/LjdWo=; path=/; Httponly; Secure
WWW-Authenticate: Bearer error="insufficient_scope", error_description="The access token provided is valid, but is not authorized for this service"
Accept: application/json+fhir
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJ1cm46b2lkOmZoaXIiLCJjbGllbnRfaWQiOiJkMmIxN2VmMS1kZTAwLTQ4NTYtODUzOS0wMTBmYjQzYzk5OWYiLCJlcGljLmVjaSI6InVybjplcGljOk9wZW4uRXBpYy1jdXJyZW50IiwiZXBpYy5tZXRhZGF0YSI6ImhiaU5aNGFMblQ0U2F3bkRrVnQ3S09za0ZmaGJjMlNIWmltV3JpUnJ3Y2JxNWhHekk3dXhpelQ1eWVTOEFUM1dQa2lTTXRMTml3YVNJSzBORFNlamJlX3dId2p3d1N2bWJ2amYtZHpCZkpVNWFSWjJsSmg3dGVjM1gtMXlvdi12IiwiZXBpYy50b2tlbnR5cGUiOiJhY2Nlc3MiLCJleHAiOjE2MjI2NDUzNDcsImlhdCI6MTYyMjY0MTc0NywiaXNzIjoidXJuOm9pZDpmaGlyIiwianRpIjoiYjVhZjM5ZjMtOTc4YS00NzBjLWJmMzUtNTEwMTQ3ZWU3Y2ZjIiwibmJmIjoxNjIyNjQxNzQ3LCJzdWIiOiJlYjRHaWE3RnlpanRQbVhrcnRqUnBQdzMifQ.Qh0rnAOcyTyDA9Gfdt57Miq_vy8DwuOPmkVJTv6Z0JlRge1ZgP9193qiSjRvUGDIRPY-LyO5ggYAE0aPz9ogRNGEMYx1pkUVZ6DH8yzIanjjqPy0RZoDjJpsjJngMpL80q7KvV0h_w1WW_4uFKEgy9Jscf3OYN7FVeI4fOElnw1dTibXfbjCX1-0ZD9q52hJk9aN2e4XoX-bvEBJATCn8kPVZYJqz4TmwE9V49xKBM_TR54WPEhhumD202cRXZd4iYM9903-Yj5eeyVEc8NOokOFBXhww44ChlKt0z0Jjt-XXhnJZKFIrsP_KmAzs0WlwHfdUp2owEU9yTo_Mob74A
Connection: keep-alive
Host: fhir.epic.com
Origin: https://epic.rajamanir.repl.co
Referer: https://epic.rajamanir.repl.co/
sec-ch-ua: "Google Chrome";v="89", "Chromium";v="89", ";Not A Brand";v="99"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36
patient: erXuFYUfucBZaryVksYEcMg3
Lloyd McKenzie (Jun 02 2021 at 17:32):
Does the server's capability statement indicate that it supports create on Observation?
booma radhakrishnan (Jun 04 2021 at 11:20):
EPIC has support of QuestionnaireResponse Read and Write. But cerner is still development.
I would like to convert QuestionnaireResponse to the Observation.
Lloyd McKenzie (Jun 04 2021 at 14:07):
Typically a QuestionnaireResponse will result in multiple Observations. If you're having trouble with a particular EHR vendor, you'll need to reach out to their support contact
Lloyd McKenzie (Jun 04 2021 at 14:07):
For Cerner, that would be code.cerner.com or fhir.cerner.com
booma radhakrishnan (Jun 06 2021 at 23:36):
HI Llyod,
While Checking EPIC Capability statement It supports below interactions
"type": "QuestionnaireResponse",
"interaction": [
{
"code": "create"
},
{
"code": "read"
}
I am able to post the data against the QuestionnnarireReponse but While reading the questionnaire response i am getting below error
Bearer error="insufficient_scope", error_description="The access token provided is valid, but is not authorized for this service"
Scope i am using i
'scope': 'patient/Patient.read patient/QuestionnaireResponse.* patient/*.read Patient.Search DocumentReference.Read (Clinical Notes) Observation.Create Observation.Read Observation.Search QuestionnaireResponse.Create(Appointment and Series)QuestionnaireResponse.Read (Immunization) QuestionnaireResponse.Read(Appointment and Series)
IS anything i am missing. kindly provide suggestions.
Yunwei Wang (Jun 07 2021 at 00:40):
@booma radhakrishnan You would get better support by talking to Epic team. https://open.epic.com/Home/Contact
Lital Inghel (Sep 03 2021 at 12:12):
Hey
I have a Q
FHIR spec says:
The logical id of the resource, as used in the URL for the resource. Once assigned, this value never changes.
The only time that a resource does not have an id is when it is being submitted to the server using a create operation.
We wonder if this mean that this id needs to be "forever" persisted once assigned or can be re-generated based on the consumer's work flow and as long as it is generated with same id for same resource every time-it should be ok certification wise?
the workflow we'll suggest:
Query for patient by [code][system] (or name)
GET [base]/Patient?identifier=[system]|[code] ----receive back the Patient resource id---use this Patient id in the query:
GET [base]/AllergyIntolerance?patient=[patient] ----receive back all patient’s allergies (resources) - each will have its logical resource id
then query by GET [base]/AllergyIntolerance/[id]
our workflow will say that after X time the user must repeat this workflow to receive again the allergy id since it will only be saved for X time (cash) and not persisted forever. The user will receive the same id again.
We wanted to understand if we can have a solution that will generate the same exact id for a resource but will not be persisted (but only for X time, it will expire). it means even though we can create the same id every time, it is not acceptable based on FHIR definition?
thanks!
Daniel Venton (Sep 03 2021 at 13:17):
How you maintain (or calculate on the fly) the fhir logical id's inside your system is up to you. They must always remain the same in the resources you produce (and respond with).
However your workflow is incorrect.
Once you tell somebody "this is the [id] of this Allergy", 5 years from now, that id should work without having too "query for patient", "query for list of allergies". They SHALL be capable of going directly to the 1 Allergy resource via the read operation "GET /AllergyIntolerance/[remembered id from 5 years ago]"
Yunwei Wang (Sep 03 2021 at 14:10):
our workflow will say that after X time the user must repeat this workflow to receive again the allergy id since it will only be saved for X time (cash) and not persisted forever. The user will receive the same id again.
That is your internal business logic and should not mingled with FHIR data model.
You can have a counter behind your FHIR layer and returns either AllergyIntolerance or OperationOutcome based on the counter. But the content of AllergyIntolerance should not depend on the counter.
Lloyd McKenzie (Sep 03 2021 at 17:50):
FHIR doesn't care if your JSON is produced each time by a team of monkeys with typewriters. So long as what is spit out your endpoint is conformant, FHIR is happy :)
Hank Lenzi (Sep 03 2021 at 18:08):
RESTful design says your resources must remain consistent. It is your interface, after all, to a Resource. If you keep changing that, what's the point? Otherwise, you're back to doing stuff the old way. That's my understanding, at least.
Gino Canessa (Sep 03 2021 at 20:31):
Lloyd McKenzie said:
FHIR doesn't care if your JSON is produced each time by a team of monkeys with typewriters. So long as what is spit out your endpoint is conformant, FHIR is happy :)
April fool's IG? =)
Grahame Grieve (Sep 03 2021 at 20:33):
one clarification:
They SHALL be capable of going directly to the 1 Allergy resource via the read operation "GET /AllergyIntolerance/[remembered id from 5 years ago]
not quite; there's no obligation on your part to make this operation succeed; security approval may have been withdrawn, for instance, or you no longer retain that information
What you are obligated to ensure is that you never re-use that id for some other record
Hank Lenzi (Sep 05 2021 at 21:41):
@Grahame Grieve
Hello -
I'm a total newbie here, as a matter of fact, I'm a doctor snooping around, so pardon me if my question sounds a bit odd: that makes total sense to me, and it was very important that you clarified this not-so-fine-point, but is it: a) a general REST principle; b) something written in stone in the FHIR documentation (which I totally missed)?
TIA
-- Hank
Grahame Grieve (Sep 05 2021 at 21:53):
both. it's a general rest principle, and written in stone in the FHIR documentation
Once assigned, this value never changes.
Also see http://hl7.org/fhir/resource.html#id
Hank Lenzi (Sep 05 2021 at 22:19):
@Grahame Grieve
I see, "never changes" also means "once-only", including for perpetuity.
I'm not sure this point is widely understood. Honestly, I don't think one can comprehend, from the documentation that, say, once a patient dies, or access is revoked by, for example, by right-to-privacy petitions, that XXXXXX specific digit sequence can no longer be reassigned ever.
Good to know. Thanks.
Grahame Grieve (Sep 05 2021 at 22:20):
we probably take this for granted since it's an inherent property of record keeping systems. It would be like taking a medical record number for a deceased patient and using it for a different patient.
shouvik das (Sep 06 2021 at 12:40):
hello. Is there a way we can convert FIHR standard back to HL7 message?
René Spronk (Sep 06 2021 at 12:42):
Please create a new topic if your question is unrelated to the topic of a discussion thread.. that having been said, FHIR to HL7 version 2 mapping is covered by the #v2 to FHIR stream, please pose your question there. Thank you!
Last updated: Apr 12 2022 at 19:14 UTC
