Do we need more MIME types for document formats?

[jmandel]

Current spec says an app can ask for text/xml... but if you want a CCD 1.0 vs CCR vs. CCDA, you need to specify this using a different parameter (e.g. format URL parameter), not by content-type negotiation.

This works but it's awkward.

[jmandel]

Now more pressing: FHIR's DocumentReference now represents a document with a format that is a simple string (qtoken) MIME type. So if we want to align here, we'll need to provide different formats for:

CCD 1.0 (e.g. application/hl7-ccd-1.0+xml?) CCDA (e.g. application/hl7-ccda-1.1+xml?) CCR (e.g. application/astm-ccr+xml?)

... or is there a cleaner approach to cataloging these? ...

[kwboone]

Nope, these aren't separate mime types today, and I don't want to break existing HIE's using XDS from which this came. The mime type for all of the above right now is text/xml. I had, in my existing documentation, come up with mimeType, classCode and formatCode values that addressed these variations, along with typeCode and classCode values that addressed various types of CCDA documents. What I did works with existing and new content combinations, and conforms to existing IHE specifications for XDSEntry.

[jmandel]

But XDSEntry is gone from FHIR now. Can you take a look at http://www.hl7.org/implement/standards/fhir/documentreference.htm and take a stab at fitting into this structure?

[kwboone]

Yep, it just went on my todo list.

[kwboone]

This is one the of the reasons why I hate tracking these things in flight. It's just more work, even when it is the right thing to do.

[jmandel]

Agreed! Any way around it that you see? On Apr 23, 2013 7:26 PM, "kwboone" notifications@github.com wrote:

This is one the of the reasons why I hate tracking these things in flight. It's just more work, even when it is the right thing to do.

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

[kwboone]

Start from a milestone and resync as needed from time to time (or as I prefer, wait until A is closer to done before starting on B). Unfortunately, waiting is not the ONC way, even if it is the best way to coordinate across multiple projects.

[jmandel]

OK. How about for now we:

1. always use MIME type text/xml for XML documents
2. revive the format parameter (calling it standard because format is already taken in DocumentReference) that used to be part of XdsEntry

... all pending a more appropriate solution from FHIR.

This would let us move forward for the time being.

Thoughts?

[jmandel]

From @kwboone: change standard to conformsTo.