Where is the profile for fhir-ehr.sandboxcerner.com?

[Yunwei Wang]

Hello: 

I am trying to check the profile for fhir-ehr.sandboxcerner.com to see if my client need to have extra validation rules. But the metadata doesn't mention where the profile is. Could someone tell where I can get that profile?

Thank you

Yunwei

[Michele Mottini]

To the best of my knowledge there is no Cerner-specific profile (that is the case also for other FHIR production implementation by the way)

  - Michele

  CareEvolution Inc

[Jenni Syed (Cerner)]

Hi Yunwei,

We publish some of this in informal form on fhir.cerner.com, we haven't gotten to publishing the formal profiles yet. However, we do try to conform to the Argonaut profiles, though there are still a few gaps there (most notably with DiagnosticReport and "grouping" of panels).

If you let us know what specific questions you have that aren't clear from fhir.cerner.com, we can answer them here.

~ Jenni

[Yunwei Wang]

What I tried to create a Condition resource with multiple coding. According the both base standard and Argonaut profile, I must send a CodeableConcept instance in Condition.code. And CodeableConcept can have more than one Coding instance. But when I send such Condition with multiple codings, the message is rejected.

Another observation of this resource is that if I send snomed code for a diagnosis Condition or icd-10 code for a problem Condition, the message is also rejected. I agree with the validation logic but just wondering when such rules are specified.

 

Yunwei

[Jenni Syed (Cerner)]

Hi Yunwei,

We currently try to conform to the Argonaut profile: http://www.fhir.org/guides/argonaut/r2/StructureDefinition-argo-condition.html (obviously, this is read only, but this is the basis for our bindings)

We also have currently supported terminologies on our fhir doc: http://fhir.cerner.com/millennium/dstu2/general-clinical/condition/#terminology-bindings

We currently don't support writing multiple codings in, though that's on the list of things I believe we'll need to do for this app.

The underlying system has to have knowledge of the coding that's being sent in. Do you have an X-Request-Id for the failures? I can double-check that it's just because the underlying coding isn't acceptable vs. the system isn't even recognizing the system url in question.

~ Jenni

[Yunwei Wang]

Hello Jenni:

I just hacked my system to make it send both ICD-10 codes in a request.

The X-Request-Id: ca50e416d83a075c9d602c95af1e017f

The response is Status: 422 Unprocessable Entity

I also attached the json request body.

Thank you.

Yunwei

[Jenni Syed (Cerner)]

The error for this was that there was more than one code passed in, but there was no "user selected" marked in the list, and they both had the same system. This isn't currently allowed because our system doesn't know what to do with the codes right now. We're hoping to improve some of this logic in the future. 

For the other error around ICD and SNOMED (and only ICD and SNOMED being sent) - I don't see an error for your app in sandbox outside of this (for Conditions). Are you still experiencing this?

~ Jenni

[Yunwei Wang]

After we noticed that error, we split the codings to separate Condtions instance. For the one above, we would actually send two Conditions, one for each ICD-10 code. The above example is a mocked message I created using Postman.

So if I mark one ICD-10 code as user selected, then the message could be accepted by server?

Yunwei

[Jenni Syed (Cerner)]

It should "work" (not error), but there's an underlying issue that I've logged where we're not handling this correctly. 

However, even if we fixed this part of the issue with honoring userSelected, currently the system would only honor the coding marked as "userSelected" until we enhance the service to better support multiple codes inbound and outbound for Conditions (it would only record that userSelected ICD-10, not the second translation provided). I'm not sure what the functionality would be if both systems were the same - we haven't gotten that deep into investigating support of this yet.

~ Jenni