For Search endpoint, how to deal with all of FHIR's fields?

[jmandel]

There are lots of required FHIR fields that might not make sense for BB+ (e.g. a link to a @patient resource from a document).

This kind of densely linked data would be great in the future, but if we're trying to expose a simple search endpoint that works for any document collection, I think the bar's too high.

See list of required fields: http://www.hl7.org/implement/standards/fhir/xdsentry.htm

See example XdsEntry: http://www.hl7.org/implement/standards/fhir/xdsentry-examples.htm

[kwboone]

We don't have to support all the search capabilities in FHIR for BB+. I certainly didn't in what I specified.

[jmandel]

Right, sorry -- the question is what to do about fields FHIR requires but that don't make sense for us. like patient...

[kwboone]

Actually, in the metadata, patient certainly makes sense. If you were pulling data from an HIE, you'd expect to get different patient metadata from different providers (e.g., patient identifiers). And, there's enough in the metadata to enable some error spotting (e.g., to protect against wrong patient errors), which could go unnoticed if you just used an ID. It's why few if any products just use an identifier alone for patient data.

[jmandel]

Hmm, but FHIR isn't using the 'patient' property for metadata per se: if I understand correctly, it is being used as linked data (to link a document reference to its patient resource). On Apr 23, 2013 7:46 PM, "kwboone" notifications@github.com wrote:

Actually, in the metadata, patient certainly makes sense. If you were pulling data from an HIE, you'd expect to get different patient metadata from different providers (e.g., patient identifiers). And, there's enough in the metadata to enable some error spotting (e.g., to protect against wrong patient errors), which could go unnoticed if you just used an ID. It's why few if any products just use an identifier alone for patient data.

— Reply to this email directly or view it on GitHubhttps://github.com/blue-button/blue-button-plus-pull/issues/10#issuecomment-16905345 .

[kwboone]

And how is that not metadata about the document?

[jmandel]

Just mean to say it is a patient identifier that's designed to dereference to another FHIR resource (of type Patient) ... which I don't think we want to host because it's beyond our intended scope for BB+. So we could embed the resource via 'contained'... but it's all a bit complex. On Apr 23, 2013 8:41 PM, "kwboone" notifications@github.com wrote:

And how is that not metadata about the document?

— Reply to this email directly or view it on GitHubhttps://github.com/blue-button/blue-button-plus-pull/issues/10#issuecomment-16906577 .

[kwboone]

I think we stay silent on how to fill it out. It shouldn't be hard, and it doesn't, according to BB need to be one way or the other. The end point may be exposed or not by the data holder.

Keith

On Apr 23, 2013, at 11:54 PM, Josh Mandel notifications@github.com wrote:

Just mean to say it is a patient identifier that's designed to dereference to another FHIR resource (of type Patient) ... which I don't think we want to host because it's beyond our intended scope for BB+. So we could embed the resource via 'contained'... but it's all a bit complex. On Apr 23, 2013 8:41 PM, "kwboone" notifications@github.com wrote:

And how is that not metadata about the document?

— Reply to this email directly or view it on GitHubhttps://github.com/blue-button/blue-button-plus-pull/issues/10#issuecomment-16906577 .

— Reply to this email directly or view it on GitHub.

[jmandel]

Fair enough. So we'll say that for BB+, the following are required:

• format
• type
• url

And the following is needed if date-based search is going to work:

• context/period