Whether both medicationCodeableConcept and medicationReference are both mandatory data elements

[Healthedata1]

During the Sprint 4 t was decide that clients should be prepared to deal with either medicationCodeableConceptand medicationReference.

In the IG we would like to further clarify
Options are:

1. Server always returns medicationCodeableConcept
2. Server always returnsmedicationReference
3. Server always returns medicationReference contained

[Healthedata1]

Cerner (Andrew) supports option 1 and 3 above since not supporting cabability to support an independent medication resource only contained Medication resources.

Epic ( Danielle) supports only option 2 reference to Medication resource.

[brettmarquard]

We plan to proceed with option 3, Server always returns medicationReference contained.

Note, we didn't have full agreement on option 3, but put a stake in the ground so we can discuss offline what is the best way forward

[brettmarquard]

New proposed compromise:

1. Server may support medicationCodeableConcept
2. Servers must support _include request on `medicationReference'

[Healthedata1]

example query using _include:
http://fhirtest.uhn.ca/baseDstu2/MedicationOrder?_include=MedicationOrder:medication&patient=70112

[Healthedata1]

Summary of proposed resolution based on the fhir chat discussion and within the Argonaut project team.

Simplest approach:

Clients must support all three methods and Server must choose to support any combination of the three to return all the medication data.

1. Search returns code for medications in MedicationOrder.medicationCodeableConcept
2. Search returns reference(s) for medications and the contained Medication Resources
3. Search returns reference(s) for medications and Medication Resources in the result bundle by using the _include parameter in the query.

Note: For this option to work the Servers must all agree to support the _include parameter for this use case. ( i.e they don't have to support it generally but must for MedicationOrder.medicationReference and MedicationStatement.medicationReference)

Alternate approach

If we can not get agreement to to support the _include parameter for this use case then we need an alternative plan which would add additional constraints on how the Server behaves if the _include is used in search:

Would require the Servers allow Clients to pass an _include parameter without causing an error but behave "nicely" with a hint on how to fetch the Medication resources.

There several ways to query for the Medication resources, but I think we should agree to a single alternative - namely this one suggested by Jenni:

using comma separated search by id (?_id=a,b,c,d,...)

[p2]

FWIW, from a client perspective: options 2 and 3 are virtually equivalent, at least when using the Swift client. That client library resolves included and referenced resources the same way, meaning the programmer need not care and it's not important whether _include is supported. All that's left to do for a client programmer is to check the presence of either medicationCodableConcept and medicationReference.

[jmandel]

@p2 there's the code you need to write, and there's how long it takes to run, right? If servers don't reliably support something way to get a whole bunch of meds all at once, then the user is sitting there waiting while a whole bunch of http requests complete. That's the main issue I see in wanting to make sure there's some method that all servers need to support.

[Healthedata1]

I am proposing that the Search returns reference(s) for medications and Medication Resources in the result bundle by using the_include parameter in the query.

Can we agree to support the _include parameter for this use case?

[Healthedata1]

After reaching out to servers. Move forward with a single _include for this use case. Eric to document use case. Reference PD work.