Is there a "formatCode" for FHIR documents?


#1

Is there an established formatCode for a FHIR document when referenced externally, either via XDS or (somewhat obscurely, I admit) as a DocumentReference? Mime type is no problem (application/fhir+xml or application/fhir+json) but I can’t find a format code - am I missing something obvious?


#2

No. we haven’t defined on yet.


#3

Graham,

Thanks for responding!

Would it make sense for this to be some sort of “descriptor” for the content (profile name for bundle or composition)? Perhaps as a url pointing to the definition?

Dave


#4

I have a suggestion to make here (which I’m happy to make formally once I know it makes sense to people know more about this than me!).

I propose that the formatCode(XDS)/format(FHIR DocumentReference) for a FHIR document should be the url of the resource type, so for instance if a medication administration document were ever to be submitted to an XDS system, then the format code would be: http://hl7.org/fhir/StructureDefinition/MedicationAdministration

  • In FHIR this is 100% legit (I believe) as format is merely a “token” and a URL satisfies this requirement fine
  • In XDS things are a little more complex as the XDS specification says that “Format codes defined by non-IHE domains should be a valid unique URN”. Whilst all URNs are URIs, then reverse is not true, so this mechanism breaks the XDS rule, but
  • It would seem silly to have to replicate the URL as another form to be maintained
  • XDS already has examples (e.g. the DICOM content) which do not conform to this rule, so nothing should break.
  • A change in the XDS wording from URN to URL could perhaps be considered.

Whilst predominantly intended for XDS use, it is possible (via potential convoluted MHD pathways) that such content may end up back in the FHIR world as a DocumentReference resource, so it would be good to ensure that the two worlds agree here.

Thoughts anyone?


#5

Yes I am about to publish FHIRish documents to an XDS repository. FHIR header and PDF payload.
In the absence of a additional granularity if have gone to:

https://www.hl7.org/fhir/valueset-formatcodes.html

and chosen

urn:ihe:pcc:xds-ms:2007 XDS Medical Summaries

For england we need to engage with the NHS D FHIR team
Kevin Sprague. As format code is used to “refine” rendering below is the link to the current NHS renderer.

The renderer for FHIR is at https://github.com/nhsconnect/ITK3-FHIR-Documents-Renderer

Likely to have more documents soon.
So yes keen to be engaged


#6

There would not be a FormatCode until someone profiles a specific type of document using FHIR. This is to clarify that the FormatCode is a sub-classification more fine grain than the mimeType. As you point out there is already a perfectly good mimeType.

IHE did finally decide to give a formatCode to be used for the times when the mimeType is sufficient, or where a more specific FormatCode has not yet been defined.
urn:ihe:iti:xds:2017:mimeTypeSufficient

John


#7

I am somewhat confused by your post. A single resource is not a “Document”. It is true that we are using the definition of document as broad as http uses, so a single resource could be a document. However the expectation is that one would really only need a DocumentReference if one has something more self-contained, and something that has more of the document characteristics as defined by Structured Documents WG, and expressed in FHIR definition of Document http://build.fhir.org/documents.html. I also cover it a bit on my blog https://healthcaresecprivacy.blogspot.com/2011/10/critical-aspects-of-documents-vs.html

I have heard of people trying to publish individual FHIR resources using XDS. That is, they already have XDS/XCA infrastructure in place that can handle the discovery and routing. So rather than create new infrastructure based on http/REST, they will just put FHIR Resources into XDS. I suspect they have only a few resource types they would do this with.

I like your proposal for FormatCode when the ‘document’ is a FHIR resource. I see absolutely no reason not to use the method you present for formatCode. It is perfectly acceptable. In fact it is quite elegant. If someone has profiled that resource then it could be the URI of their profile. The unfortunate problem is that the metadata element is a code so needs an codeSystem, so that also must be filled in. I presume one could just use the root of the FHIR spec for that?

The point you make that the IHE specification says “should” be a URN… this is just a should, so no problem. The IHE specification was trying to get organizations that were inventing formatCodes to invent them in a way that would be controlled and discoverable.


#8

When publishing a FHIR Header and PDF payload, the better FormatCode would be the one for XDS-SD. This format code is specifically for that kind of a use-case, carrying a “Scanned Document” (aka PDF or TEXT). Yes the name of the URN is rather confusing.
urn:ihe:iti:xds-sd:pdf:2008

john


#9

John,

Yes, I am specifically looking at "reverse MHD when (for one reason or another) there is a wish to access FHIR resources as “XDS documents”, so we’re on the same page, and thanks for your support for my suggestion. I’ll point the IHE PCC folks at this thread, and hope that the necessary heads can be knocked together to get this formalised.

Dave


#10

I am unclear what it is that you think PCC should say? A general rule like you have defined is not the kind of thing that PCC is the body of governance. PCC would be the body that would define specific codes aligned with their specific profiles. They know this, they do this quite often. Please express what it is you think needs to be said, and why you think that needs to be said?

John


#11

Reading your comment again… You should look at the IHE-QEDm profile, paired with IHE-mXDE. In this model one would do normal FHIR like queries to access observations, allergy and intolerances, conditions, diagnostic results, medications, immunizations, procedures, encounters. There is an option in QEDm “Provenance” that is the linkage to the Document from which that information was derived. see http://wiki.ihe.net/index.php/Query_for_Existing_Data_for_Mobile