Stream: argonaut
Topic: US core tracker question
Eric Haas (Jan 17 2018 at 18:10):
GF#14472: Jan 2018 Ballot: US Core Profile DocumentReference shouldn't require additional format posted by
jsyed
@Grahame Grieve and @John Moehrke This is something I carried over from the original argonaut DR profile that Grahame created a couple of years ago. I can' t remember why I kept it anymore and before I go digging I'd thought I'd ask you two why it was included in the first place.
John Moehrke (Jan 17 2018 at 18:30):
This could be solved either way. the formatCode is required in IHE, so it is possible that the IHE profile make it manditory. I would prefer though that US-Core and IHE-MHD be identical unless there is a compelling reason to have a difference. Note that IHE has just last year added a formatCode to be used as a kind of nullFlavor.
John Moehrke (Jan 17 2018 at 18:33):
I am working with Grahame to get the IHE FormatCode vocabulary turned over to IHE control. I have published their vocabulary through Simplifier, but it somehow is not showing up on registry.fhir.org
John Moehrke (Jan 17 2018 at 18:34):
see all the IHE published conformance and vocabulary at ftp://ftp.ihe.net/TF_Implementation_Material/fhir/
Jenni Syed (Jan 17 2018 at 19:01):
I'm not sure providing a nullFlavor most of the time is going to be any better than just leaving it unset...
Jenni Syed (Jan 17 2018 at 19:06):
This seems to assume doc ref is only used for strict inter-system doc exchange, where the primary use for us right now is SMART apps and patients viewing data
John Moehrke (Jan 17 2018 at 21:13):
I understand... My first acknowledgement was that IHE-MHD could add the constraint... I just want it recognized as a incompatible delta, and want that decision made in the open with full knowledge.
Jenni Syed (Jan 17 2018 at 22:50):
I don't know that it makes it incompatible. We would add the format if it has one. I assume the IHE profile wouldn't want the simple PDF/HTML (non-standard) documents that aren't really meant to be parsed and processed? Or do those formats listed (especially all the text/html based ones) not actually have content requirements?
Jenni Syed (Jan 17 2018 at 22:51):
I do want to understand what the format is intended to convey :)
John Moehrke (Jan 18 2018 at 13:38):
The format is more specific than the mime-type. There are many profiles on CDA, thus knowing only that the document is a CDA document is not sufficient to know if your system can fully process it. The formatCode is intended to allow more specific technical formats. I go into greater detail here https://healthcaresecprivacy.blogspot.com/2017/10/granularity-of-formatcode.html and https://healthcaresecprivacy.blogspot.com/2015/10/ihe-formatcodes-are-mandatory.html
John Moehrke (Jan 18 2018 at 13:39):
MHD/XDS/XCA is perfectly happy with PDF/HTML/TEXT documents. They are quite common, especially for historic, or less formal content.
Jenni Syed (Jan 18 2018 at 16:02):
We use the CCDA format codes, it's one of the scenarios where we actually have one
John Moehrke (Jan 18 2018 at 16:33):
yes, for CCDA there are already assigned ones... so you don't have a gap
Jenni Syed (Jan 18 2018 at 20:51):
Sorry, still trying to make sure I'm following the purpose of the additional format.
If I'm interpreting your posts and the Value Set correctly, this is essentially trying to take a post-coordinated set of codes and make it pre-coordinated? At least in cases like simple PDF? IE: this is a simple clinical note, in PDF version rather than looking at the doc type (note) and contentType (application/pdf)? Or is there more to it than this? (or less -ie, is there such a thing as "just pdf" on the formatCode? I didn't see an example like that in the value set)
Jenni Syed (Jan 18 2018 at 20:53):
Again, CCDA makes total sense to me since it's far more specific that application/xml. Thre are actual schemas required for the content that are more restrictive than "plain" XML
John Moehrke (Jan 18 2018 at 22:45):
Take a look at the codes that have been defined. They are specific IHE profiles, that then have specific encoding rules. Remember that this concept predates C-CDA... It also is content agnostic. Where in CDA you can look for templateID values to understand the encoding... this mechanism is similar in a content agnostic way.
John Moehrke (Jan 18 2018 at 22:47):
Using your PDF example. the mime-type can only tell you that the content is PDF. Yet there is a Healthcare specific PDF (PDF/H) that can carry encoded elemental data, can carry a CDA inside the PDF. Thus it would be important to know this, prior to downloading the document and realizing that it has content beyond simply displayable PDF content.
Jenni Syed (Jan 27 2018 at 21:36):
@Brett Marquard See above for other questions ^^
Brett Marquard (Jan 28 2018 at 00:05):
Planning to relax...
Last updated: Apr 12 2022 at 19:14 UTC
