Having been working on an MHD project, I’ve spotted a few oddities about how the DocumentReference resource has been constructed, including what I believe to be a misunderstanding about how the XDS class and types codes are intended to be used.
The normal expectation in XDS is that broad “classCode” (FHIR Documentreference.class) should be the broad “inclusive” categorisation which users would utilize for searching, with the typeCode(FHIR Documentreference.type) being a much finer specificaiton used primarily for “display”, allowing a user to pick what might be of interest. I’d be the first to accept that the IHE specificaitons are rather ill-defined in this respect, but amonst those of us who have been using XDS for the last decade it is “common knowledge”. In the vast majority of respects, the alignment between the Documentreference resource and XDS is extremely good (even including wierd and confusingly named fields such a practiSettingCode!), but for these 2 particular fields, there are 2 problems:
DocumentReference.class is optional. Clearly this is a problem for interoperability via MHD between the two. It can of course be “hacked” with a server-side type=>class mapping, but this does seem odd, given how well the rest of the content is aligned. Is there a good rationale for this decision?
The STU3 descriptions of these fields appear to be reversed:
- class (in “requirements” ! ) : Helps humans to assess whether the document is of interest when viewing a list of documents.
- type (in Comments) : Key metadata element describing the document, used in searching/filtering.
At the very least, it would be nice to see standardisation on comments/requirements, but much more importantly the conflict between these uses and the normal expected XDS use, combined with the cardinality of “class” seems to create a significant and avoidable barrier between XDS & FHIR interoperability.
Am I “late to the party”, having missed discussions as to why this has turned out the way it has, or have I just spotted a genuine mistake?