Stream: implementers
Topic: Observation value attachment
Vassilis Kilintzis (Sep 13 2018 at 12:52):
Hello,
I would like a proposal/solution about the preferred way to create a specific resource after the decision to remove valueAttachment from Observation resource (the change in tracker is here https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_id=677&tracker_item_id=13421).
I have a scenario in mind:
I want a resource that it is not Media resource (not a photo or video) and not a document (e.g. pdf) it is an file with relatively high sampling rate (1sample/sec) that is unpractical to create distinct resources for a period of time (e.g. 5 minutes).
valueSampledData works well if the sampling rate is fixed.
if the sampling rate is irregular (e.g. continuous heart rate measurements ) use of valueAttachment could be a solution using timestamp,value pairs as csv or any type of binary.
What is the preferred way to handle this situation?
Lloyd McKenzie (Sep 13 2018 at 15:27):
@Eric Haas ?
Eric Haas (Sep 13 2018 at 18:23):
a string?
Eric Haas (Sep 13 2018 at 18:30):
Using sampled data with a Null value when no data??? SampledData @John Moehrke What experience do you have with irregularly sampled data?
John Moehrke (Sep 13 2018 at 18:33):
Seems irregularly sampled data would be different Observations.
John Moehrke (Sep 13 2018 at 18:33):
however @Vassilis Kilintzis have you looked at Sequence?
Vassilis Kilintzis (Sep 14 2018 at 06:32):
Thank you for your responses,
@Eric Haas Using string could be a solution for the specific case since more or less the format of the csv must be agreed outside of the resource description, on the other hand attachment.contentType(text/csv) is very valuable property of the resource and can help in automatic management of the resource.
Regarding the conversion of the signal to a fixed frequency sampled signal this solution requires significant effort since the procedure requires interpolation and resampling since even if we determine the maximum sampling frequency of the signal adding NULL to non sampled timepoints we can not guarantee that the samples align to the resulting timepoints.
@John Moehrke Using different observations is a semantically correct solution but performance-wise is very impractical (i.e. in a scenario that we want to exchange an hour of the aforementioned heart rate measurements we would need ~4800 requests.
Regarding Sequence does not solve the problem for two reasons A)semantically Sequence is too narrow to "genetic sequence information" ,
b) but even if we ignore that Sequence.observedSeq is merely a string not providing additional semantics.
@Eric Haas I may be missing additional conversations but just by reading the tracker item of the decision to remove valueAttachment is not clear to me the rationale behind that decision. My humble personal opinion is that introduction of Media does not necessarily require the removal of attachment from observation.
John Moehrke (Sep 14 2018 at 13:20):
So @Vassilis Kilintzis you are trying to record EKG? I have previously modeled a FHIR Resource from the IEEE 11073. I did this when I was part of GE, but couldn't get GE to endorse the proposal to FHIR as a Resource. If this is what you are interested in, I still have the model. It would need to be proposed and sponsored by an appropriate workgroup.
John Moehrke (Sep 14 2018 at 13:37):
I put that 2015 model for FHIR source Resource onto GITHUB https://github.com/JohnMoehrke/FHIR-ECG
Lloyd McKenzie (Sep 14 2018 at 14:35):
Why was valueAttachment removed?
Vassilis Kilintzis (Sep 17 2018 at 06:52):
Thank you John (@John Moehrke ), but i would prefer the flexibility of the DTU3 observation resource with valueAttachment and let the profile/extension mechanism to describe the exact nature of the resource.
@Lloyd McKenzie i believe that at some point valueAttachment will return, since we can not predict all possible payloads beforehand.
John Moehrke (Sep 17 2018 at 11:58):
The ECG/EKG model I did was not a replacement for Observation. There would still be an Observation based on the data. What the IEEE model does is record the details of the ECG/EKG in sufficient detail that it can be used in future analysis comparing past and present. Much like an ImagingStudy, or Sequence.
John Moehrke (Sep 17 2018 at 12:11):
I would expect that where valueAttachment felt like the right thing that it would be better to put that attachment into a DocumentReference or Media... and use Observation.derivedFrom.
Lloyd McKenzie (Sep 17 2018 at 14:47):
@Eric Haas Can you shed light on why valueAttachment went away?
Eric Haas (Sep 18 2018 at 16:05):
1) This change eliminates the ambiguity and duplication on how to represent multimedia observations. The committees felt that Media was a more appropriate way to represent these types of Observations.
Eric Haas (Sep 18 2018 at 16:12):
How is a csv file fundamentally different from a pdf image. They are both documents in my mind and Media would work. Otherwise you are adding back into observation this ambiguity of when to use which resource each time you come up with an attachment.
Lloyd McKenzie (Sep 18 2018 at 17:03):
Media is tightly scoped to images and video though. There are all sorts of other types of Observations that fall outside that space.
Lloyd McKenzie (Sep 18 2018 at 17:03):
Perhaps we should loosen the scope of Media?
Eric Haas (Sep 18 2018 at 17:05):
I think of a pdf or word doc as being media @Elliot Silver ??
Lloyd McKenzie (Sep 18 2018 at 17:07):
I do too, but the spec clearly says that Media is: A photo, video, or audio recording acquired or used in healthcare. The actual content may be inline or provided by direct reference.
Lloyd McKenzie (Sep 18 2018 at 17:08):
Something like a PDF or Word doc (shudder) can be handled using DocumentReference. But an EKG or something like that doesn't have a clear home anymore.
Elliot Silver (Sep 18 2018 at 17:08):
I envisioned Media as audio/video/still images, but others felt that it could function as more a generic clinical blob. I don't think we ever nailed down the boundaries on the DocReference<>Media<>Observation continuum.
Eric Haas (Sep 18 2018 at 17:28):
"Something like a PDF or Word doc (shudder) can be handled using DocumentReference. " DocRef only referenced through derivedBy or .focus so is not a direct result value. I think Media would makes sense if you want a document/file as a direct result. because I agree we have a gap for files that are not images, video or audio. and DR is not a type of Observation.
Eric Haas (Sep 18 2018 at 17:30):
Possibly another option may be a DR reference extension for values that are other file types?? ( My preference is for media to be liberally defined)
Eric Haas (Sep 18 2018 at 17:32):
audio/video/still images/other??
John Moehrke (Sep 18 2018 at 19:27):
More proof that we have not yet figured out the difference between Media and DocumentReference. I think they should be either better clarified, or merged into one resource. I see no reason for continued dancing around this. I see no need for differentiation.
John Moehrke (Sep 18 2018 at 19:29):
so @Eric Haas why have you gravitated toward Media when DocumentReference can carry your example PDF or CSV?
John Moehrke (Sep 18 2018 at 19:30):
is it the 'name' of the DocumentReference resource? Renaming suggestions are welcome.
Lloyd McKenzie (Sep 18 2018 at 19:31):
What matters to me is that in R4 there's a clear place to send stuff like EKGs
John Moehrke (Sep 18 2018 at 19:32):
to me the answer for all of this is DocumentReference.
John Moehrke (Sep 18 2018 at 19:33):
if we are talking about a blob of data that has a defined mime-type, then DocumentReference.
Lloyd McKenzie (Sep 18 2018 at 19:35):
DocumentReference doesn't make any sense for an EKG
Lloyd McKenzie (Sep 18 2018 at 19:35):
An EKG is an Observation
Eric Haas (Sep 18 2018 at 19:35):
DR is not an Observation. The question is I have a code = ekg and result value is this file containing a set of irregularly sampled data. How would DR handle that?
John Moehrke (Sep 18 2018 at 19:36):
What part of the EKG are you asking about? The medical statements (observations), or the raw material measured from the body?
Eric Haas (Sep 18 2018 at 19:36):
the raw data.. This is analogous to 80 mg/dL for a blood glucose observation
Eric Haas (Sep 18 2018 at 19:39):
I understood that there was going to be a specializations like imagingstudy for EKG, EEG etc but this has not happened yet. So I guess we are looking for interim - longterm solutions.
John Moehrke (Sep 18 2018 at 19:39):
I think you are not thinking about the full potential of an EKG, but rather are thinking only about a simple resting-EKG. Even a resting-EKG can reach a Meg bytes in size. But there are Stress EKG that far exceed that and reach the size of a CT exam (hence why DICOM is one of the standards defined to hold the raw EKG data).
John Moehrke (Sep 18 2018 at 19:39):
yes there is a DICOM specification for EKG
John Moehrke (Sep 18 2018 at 19:39):
yes it fits in ImagingStudy
Eric Haas (Sep 18 2018 at 19:40):
So are you suggesting redefining imaging Study?
John Moehrke (Sep 18 2018 at 19:40):
no, ImagingStudy works already for all DICOM
John Moehrke (Sep 18 2018 at 19:41):
However most uses of EKG are made portable by committing them to printed form in PDF... and that is best represented by DocumentReference
John Moehrke (Sep 18 2018 at 19:42):
I tried to get a formal EKG/ECG Resource in FHIR back two years ago when I was part of GE. But couldn't get sponsorship or find a workgroup. See https://github.com/JohnMoehrke/FHIR-ECG
John Moehrke (Sep 18 2018 at 19:44):
so Observation may point at an ImagingStudy, and/or documentReference for further details. But the Observation should carry the 'observations' made from that raw material (the Serial Comparison statements, waveform analsysis, or human observations), along with critical parameters (who, where, when, how, length, etc)
Lloyd McKenzie (Sep 18 2018 at 19:48):
An EKG is absolutely an Observation - it's not something appropriate for DocumentReference. You might have your whole diagnostic report as a document, but not the raw pieces.
Eric Haas (Sep 18 2018 at 19:50):
We are talking in circles. "in PDF... and that is best represented by DocumentReference"
"Lloyd McKenzie: DocumentReference doesn't make any sense for an EKG
Lloyd McKenzie: An EKG is an Observation"
ergo and EKG as a PDF or a screen capture or a picture on my iphone is .....Media ( for now since there is no EKG resource.)
(And I agree that I don't know all the other stuff that an ekg may need )
Lloyd McKenzie (Sep 18 2018 at 19:52):
I'm thinking about an EKG as a raw data file
John Moehrke (Sep 18 2018 at 20:02):
EKG has a few standards based formats (Not printed form which most clinicians see). The raw data is only ever processed by AI (Serial Comparison) code -- which compares last-previous with current; or by algorithm that looks at just this waveform (e.g. 12sl). This raw format is proprietary format originally written by Marquette Electric, now owned by GE. This format has been re-architected in IEEE under 11073 standard as the abstract model. That abstract model has an encoding in DICOM.
John Moehrke (Sep 18 2018 at 20:02):
I have provided the GITHUB location where I attempted to map IEEE 11073 into a FHIR Resource... two years ago. It never went anywhere
John Moehrke (Sep 18 2018 at 20:04):
If we are going to use the 80% rule... then this discussion can be shortened as 80% of the time none of that is used.. what is used 80% of the time is a PDF rendering into human readable form
John Moehrke (Sep 18 2018 at 20:04):
thus leaving the raw form behind in an ECG management system (MUSE).
John Moehrke (Sep 18 2018 at 20:08):
that PDF form is usually (should be) a vectored PDF, so that close inspection (zoom in) enables very careful measurement using the red-grid in the background (red-grid, another proprietary standard from Marquette made ubiquitous standard). If it is rastered graphics PDF it is not medically useful.
Lloyd McKenzie (Sep 18 2018 at 20:18):
Hi John,
My point wasn't to focus on EKGs. It was to deal with the fact that there are a number of Observation types where the end result is binary data that is not an image, video or sound recording. That information needs to have a mechanism for it to be stored. I'm fine if the decision is for that to be Media. I'm fine if the decision is to add an extension to Observation to allow valueAttachment until such time as we can put valueAttachment back. I'm not ok with the notion of using DocumentReference for such a purpose though.
John Moehrke (Sep 18 2018 at 20:18):
why not?
Lloyd McKenzie (Sep 18 2018 at 20:24):
Because DocumentReference is about documents - and these things aren't. They're clearly observations. They're raw data. They're no different than a blood pressure reading or a white blood cell count.
John Moehrke (Sep 18 2018 at 20:32):
I am not trying to extract measurements out of Observation. I would agree that where measurements exist they should be enumerated in Observation. I am just observing that sometimes the source for that Observation is only available as a blob of bytes that have a mime-type and thus need metadata (DocumentReference resource purpose) to describe and provide a handle for Observation to point at. DocumentReference is only (lowercase) document based in that it must point at a blob that has a mime-type... just like the word document means in the http world. DocumentReference is not constrained to (uppercase) Document as is defined and described by HL7 structured documents workgroup.
John Moehrke (Sep 18 2018 at 20:35):
the inspiration for DocumentRefenence is much wider than Structured Documents definition of "Document". Hence why ownership by Structure Documents workgroup is not the best fit for DocumentReference (and DocumentManifest). Would ownership by OO or FHIR-I help get this clarity? Would be glad for a change of the name of the Resource, as the name seems to be causing misunderstanding. That misunderstanding seems to be causing duplicate effort in FHIR (aka Media).
Lloyd McKenzie (Sep 18 2018 at 20:55):
Media has notions of bodySite, device and other Observation things. And doesn't have masterIdentifier, docStatus, authenticator and a whole bunch of other elements that are highly document-centric.
Lloyd McKenzie (Sep 18 2018 at 20:55):
Also, Media ties into Observation in all the right ways. DocumentReference doesn't (and shouldn't).
John Moehrke (Sep 18 2018 at 21:08):
why not?
Grahame Grieve (Sep 18 2018 at 21:09):
so this discussion has been pretty unfocused, it seems to me, now that I'm catching up on it.
I have several questions:
- if DICOM has a format for EKG, why would also do one?
- I would've thought that this would be DiagnosticReport.imagingStudy
- why specifically do we want an observation? If your answer is yes, why hasn't this been an issue or other kinds of imaging?
- I do not think that the correct answer here is to make DocRef ever more generic and central
- Nor do I think that media should be made more generic
- I suppose we could take the EKG format on directly... but they are very large, and there are existing formats... so it seems low yield to me
Lloyd McKenzie (Sep 18 2018 at 21:12):
EKG isn't the focus. I care about EKGs, genetic files, tummy bands for pregnant moms and all other sorts of observation results that can't be expressed as a single Quantity but which certainly aren't "documents". In the past, I'd have said "send those using Observation.valueAttachment", but that doesn't exist anymore - and there doesn't seem to be an adequate alternative.
John Moehrke (Sep 18 2018 at 21:13):
yup, what Lloyd said... (On EKG, yes you got the point there. and why EKG didn't get into a FHIR Resource)
John Moehrke (Sep 18 2018 at 21:16):
so, back to what Lloyd said... I am possibly distracting from Lloyds point, saying that when one has something beyond a single Quantity one should have one choice. It is not clear that choice should only be Media, but what about DocumentReferenece. Media and DocumentReference need to be rationalized, harmonized, or homogenized. I would like to see them merged into one blob describing resource
John Moehrke (Sep 18 2018 at 21:18):
If they can't be merged, then we need a distinction that is clear. Today, Lloyd seems to see a distinction that Media can be used as input to an Observation, but DocumentReference can NOT be used as input to an Observation. That is not a distinction.
John Moehrke (Sep 18 2018 at 21:19):
I get the bodySite argument... no problem adding that to DocumentReference... etc... a few spare elements are not problematic as long as the use-case and scope are clear.
Eric Haas (Sep 18 2018 at 21:39):
I already asked if it should be imagingStudy and was told not in scope...
Eric Haas (Sep 18 2018 at 21:46):
So John wants to mush dr and media together. Lloyd syggests to reverse our multiple discussions and meetings about valueAttachment and put it back into observation. (and get rid of Media sInce its not that apecIal after all?)
Lloyd McKenzie (Sep 18 2018 at 21:48):
I'm fine with Media being made broader. I'm fine with ValueAttachment coming back. However, getting rid of valueAttachment and leaving Media tight means there's a lot of stuff we can't express anymore, and that's a problem.
Eric Haas (Sep 18 2018 at 21:52):
I am still stuck on when an image file not an image. A pdf is just a file format. It could be a picture of my cat or my resume
Lloyd McKenzie (Sep 18 2018 at 21:53):
So could a JPEG. Though if it's your resume, I wouldn't expect a lot of job offers... ;)
Eric Haas (Sep 18 2018 at 21:53):
:-)
Eric Haas (Sep 18 2018 at 21:56):
What I liked about what gg said is that if there is a Dixon format it should flow through an imagingStudy like resource
Vassilis Kilintzis (Sep 19 2018 at 08:07):
Although i understand @Eric Haas 's reason that all binaries can be viewed as media so valueAttachment is obsolete i am with @Lloyd McKenzie that not every media is actually video or photo. Making media semantics more loose to accept other types of blobs would solve the issue (although several fields are not applicable for all non video/photo blobs e.g. Media.view or Media.bodySite) . Also keeping valueAttachment with comment to avoid using for videos or photos could solve the problem.
John Moehrke (Sep 19 2018 at 12:59):
And I am happy with the model as it is today with derivedFrom supporting DocumentReference, ImagingStudy, Media, Sequence, QuestionnaireResponse, and other Observations. This seems most logical to me. All of these could be source material for -this- Observation.
John Moehrke (Sep 19 2018 at 13:00):
I would indeed like to see Media and DocumentReference resolved. Either more clear separation, or merging. Today they overlap too much. Yet there seems to be some unsaid reason why Media is preferred in Observation land over DocumentReference.
John Moehrke (Sep 19 2018 at 13:04):
I will agree with the text found currently in Observation regarding use of Media, DocumentReference, and ImagingStudy. It seems evenhanded. I guess it might be useful to mention PDF is the boundary where move to DocumentReference over Media is appropriate. Overall I would like the community to help by reviewing these all and help add clarity based on what we all know, as new readers don't know what we know.
Eric Haas (Sep 19 2018 at 16:16):
@Grahame Grieve
Nor do I think that Media should be made more generic
Why not ? I
@Elliot Silver @Lloyd McKenzie @John Moehrke can we talk about expanding the scope of Media at the WGM. @Vassilis Kilintzis will you be available too and can you send an actual example file so we can see your use case?
John Moehrke (Sep 19 2018 at 18:20):
If by expanding the Scope of Media, you are considering how DocumentReference factors in... YES I am not clear what expanding of Media you are pursuing? Are you considering existing DocumentReference?
Lloyd McKenzie (Sep 19 2018 at 18:48):
DocumentReference is appropriate if what you're pointing to is actually a document and you don't need any Observation-specific metadata, such as what device was used, what method was used, etc. to capture the data represented by the blob. But DocumentReference wouldn't be appropriate when you need that sort of Observation metadata or when the blob you're pointing to isn't actually a document.
Vassilis Kilintzis (Sep 20 2018 at 06:00):
DocumentReference is appropriate if what you're pointing to is actually a document and you don't need any Observation-specific metadata, such as what device was used, what method was used, etc. to capture the data represented by the blob. But DocumentReference wouldn't be appropriate when you need that sort of Observation metadata or when the blob you're pointing to isn't actually a document.
100% agree, that is the source of the problem upon which i created this thread.
@Eric Haas where can i find details about WGM to see if i can manage. The scenario of use i have explained earlier, i will try to find an actual example and send it.
Mariano Garuz (Sep 20 2018 at 09:35):
Hello everyone,
I take advantage of this thread.
I have to upload a vector pdf of a multiple-lead ECG, captured by a mobility device.
What would be the best way to do it directly through FHIR STU3 then?
Vassilis Kilintzis (Sep 20 2018 at 10:52):
Hello everyone,
I take advantage of this thread.
I have to upload a vector pdf of a multiple-lead ECG, captured by a mobility device.
What would be the best way to do it directly through FHIR STU3 then?
@Mariano Garuz To me, for STU3, the answer is clear "valueAttachment" , it is a binary file with specific mime type that it is not just a document but the actual observation of ECG.
John Moehrke (Sep 20 2018 at 12:18):
Hello everyone,
I take advantage of this thread.
I have to upload a vector pdf of a multiple-lead ECG, captured by a mobility device.
What would be the best way to do it directly through FHIR STU3 then?
@Mariano Garuz Given STU3, Observation.valueAttachment is your only choice. However you see the spec has evolved based on community comments so that your use-case in R4 (ballot)be Observation.derivedFrom pointing at DocumentReference pointing at Binary with your PDF. This change between STU3 and current is the crux of the discussion in this thread. I think the argument is what goes into the .value element to be the primary observation in this case. .derivedFrom is a good element, with good flexibility. The hope is that one can extract out useful elements from the PDF to fill sufficient elements in Observation so that one has a useful Observation.
John Moehrke (Sep 20 2018 at 12:41):
So @Lloyd McKenzie is this your point? Where the 99% of the observation is in a PDF and will not be extracted out into useful elements in the Observation (such as this PDF of the ECG)? In this case I would agree it does seem odd to have a Observation that is mostly empty except for a category, code, and derivedFrom; that points at a DocumentReference that points at a PDF. Where interpretation is extracted and the Observation is more a coded extract of the PDF, this feels less bulky. But I would agree that if the Observation is minimally populated, this is messy. My first point is that it should not be disallowed, which I understood you to be saying. That said, this does seem to argue for valueAttachment for specific use-cases.
Eric Haas (Sep 20 2018 at 14:47):
This was discussed a year ago - and it was decided to go with Media and not both. I propose that we have actual use cases (vs hypothetical) on the table at the WGM so we can what our options are.
Lloyd McKenzie (Sep 20 2018 at 14:49):
I'm fine with using Media - but if we're going to do that, Media needs to be broader. Usecases already on the table include ECGs and genomics data.
John Moehrke (Sep 20 2018 at 18:35):
This was discussed a year ago - and it was decided to go with Media and not both. I propose that we have actual use cases (vs hypothetical) on the table at the WGM so we can what our options are.
What was discussed? What was concluded? There have been many things discussed on this thread.
the elimination of valueAttachment has no obvious replacement except for derivedFrom. I have expressed how that is not a reasonable replacement.
John Moehrke (Sep 20 2018 at 18:36):
the use-case is specifically where the attachment 'is' the observation. There is no observation derived from the attachment.
Eric Haas (Sep 20 2018 at 22:34):
I have penciled this topic into the OO's Wed Q2 Quarter which is a OO/II and others joint session.
Eric Haas (Sep 20 2018 at 22:35):
@John Moehrke as I recall we had joint OO/II meetings where you were present.
Patrick Werner (Sep 21 2018 at 09:07):
I would expect that where valueAttachment felt like the right thing that it would be better to put that attachment into a DocumentReference or Media... and use Observation.derivedFrom.
I can follow that idea, but derived from has a different semantic meaning than putting in Binarys or links to them directly into valueAttachment.
John Moehrke (Sep 21 2018 at 12:46):
yes, I eventually came to that conclusion too. Seems we need valueAttachment, with clear scope that it is for when the attachment 'is the observation'. Or have something like valueReference that can point at Media, DocumentReference, ImagingStudy, or Sequence.
Eric Haas (Sep 21 2018 at 16:14):
Nm
Eric Haas (Sep 21 2018 at 16:18):
Why don’t we make John the OO editor?
Lloyd McKenzie (Sep 21 2018 at 16:48):
OO made the decision to drop valueAttachment with the presumption that Media would handle all of those cases. But they didn't open up Media to handle all the cases that valueAttachment supported. At this point, reverting the valueAttachment isn't possible without yanking Observation from Normative for R4. So that leaves two choices - add an equivalent of valueAttachment as an extension or expand the scope of Media.
Patrick Werner (Sep 24 2018 at 15:53):
added GF#18216
Jose Costa Teixeira (Oct 01 2018 at 10:22):
from what i read,I am more in favour of expanding media. My use case is recording of a procedure. Not the outcome or observation, but the procedure itself.
Jose Costa Teixeira (Oct 01 2018 at 10:23):
so I need a place to put mostly videos. Media should cover that. But the other stuff that we will have may not fit in DR or
Jose Costa Teixeira (Oct 01 2018 at 10:23):
observation
Patrick Werner (Dec 07 2018 at 08:19):
OO made the decision to drop valueAttachment with the presumption that Media would handle all of those cases. But they didn't open up Media to handle all the cases that valueAttachment supported. At this point, reverting the valueAttachment isn't possible without yanking Observation from Normative for R4. So that leaves two choices - add an equivalent of valueAttachment as an extension or expand the scope of Media.
after giving the issue some thought i would be in favor of opening the scope of Media.
John Moehrke (Dec 07 2018 at 14:09):
DocumentReference fits this very nicely. What is it that doesn't fit? I am continually frustrated at the growing overlap without a distinction between Media and DocumentReference. I am sure most of this is caused by the names of the two resources; as their normative scope and usage are clear and distinct.
Elliot Silver (Dec 07 2018 at 17:14):
I believe there is a plan for a valueAttachment extension on observation to address some of those use cases. @Eric Haas ? (I agree that there is confusion about Media/DocumentReference.)
Eric Haas (Dec 08 2018 at 03:19):
I don’t know the solution but adding attachment back to Observation doesn’t solve the problem. if we reverse course and go with valueAttachment then Media is superfluous and docref overlaps observation. I personally would like to see docref renamed too.
Lloyd McKenzie (Dec 11 2018 at 01:57):
DocumentReference has major issues. The name does not reflect its ever-evolving scope. I do however think there's a major difference between an "indexing" resource (which is what DocumentReference is) and an Observation - which is a point-in-time statement. DocumentReference should always be a reference to a something. We still need a resource for the "something" when we're talking about a complex observation that's not media.
John Moehrke (Dec 11 2018 at 14:20):
DocumentReference has major issues. The name does not reflect its ever-evolving scope. I do however think there's a major difference between an "indexing" resource (which is what DocumentReference is) and an Observation - which is a point-in-time statement. DocumentReference should always be a reference to a something. We still need a resource for the "something" when we're talking about a complex observation that's not media.
I very much agree... so when can we get this discussion going?
Lloyd McKenzie (Dec 11 2018 at 16:06):
I think it is going... :) I'd like DocumentReference to be renamed to be a general "index" resource. But it also means that doing things like using DocumentReference as the primary way to represent a clinical note is problematic.
Eric Haas (Dec 11 2018 at 17:58):
We still need a resource for the "something" when we're talking about a complex observation that's not media.
Eric Haas (Dec 11 2018 at 18:00):
what do you mean by this? a new Observation resource for things not covered by the old Observation resource and Media?
Elliot Silver (Dec 12 2018 at 17:30):
But it also means that doing things like using DocumentReference as the primary way to represent a clinical note is problematic.
I think using DocumentReference as the primary way to represent a clinical note is problematic. I would much rather see clinical notes in a new resource or supported in DiagnosticReport (possibly renamed and with a modified scope).
Rob Hausam (Dec 13 2018 at 02:36):
I still think that Composition may work for clinical notes (many or most of them), too.
Lloyd McKenzie (Dec 13 2018 at 02:39):
Composition is a grouper - it's like MessageHeader. It doesn't generally stand on its own.
Lloyd McKenzie (Dec 13 2018 at 02:39):
Though I guess I prefer it to DocumentReference
Rob Hausam (Dec 13 2018 at 02:46):
Yeah, we've certainly discussed that before. The way it's documented doesn't limit it to being exclusively a grouper (in my opinion) - the second sentence describes it as "A Composition defines the structure and narrative content necessary for a document." So at least there's some agreement about needing something other than DocumentReference.
Eric Haas (Dec 13 2018 at 03:00):
agreement where exactly? ... There is agreement among Argonaut vendors to use DR and DR. So if implementers follow Argonaut and HL7 hims and haws over this during then next cycle ... what direction do you think the implementation community is going to take?
Eric Haas (Dec 13 2018 at 03:02):
ç'est un fait accompli time to move on in my opinion
Lloyd McKenzie (Dec 13 2018 at 03:06):
DocumentReference could be significantly revised in R5, so revisiting may be necessary.
Brett Marquard (Dec 13 2018 at 16:28):
The name of DocumentReference could be improved.
John Moehrke (Dec 13 2018 at 17:03):
I would like to see ONE resource that is metadata for Binary and other external resources. Essentially anything that uses Attachment datatype should be looked at closely. Not to say there should not be uses of Attachment, but rather to evaluate if there is specific scope and bright difference between general metadata of Binary. Is this possibly another 'pattern' we should have?
As to name... we need a better name. How about we keep Media, and merge in DocumentReference, so that Media is what survives and DocumentReference goes away?
Lloyd McKenzie (Dec 13 2018 at 17:12):
I'm fine with that notion. Though "metadata for binary" would clearly exclude clinical notes as part of the scope - which means we'd need to find a more appropriate home.
Brett Marquard (Dec 13 2018 at 17:33):
Well, changing documentReference to 'Metadata for binary' may be a bit too far!
John Moehrke (Dec 13 2018 at 17:49):
reasonable... so what then is the clear definition of this thing that merges Media+DocumentReference? Do we also merge in Attachment?
Are there others from this list that are really general (clearly many are clearly distinct)?
Attachment is used in the following places: RelatedArtifact, ProdCharacteristic, BodyStructure, Claim, ClaimResponse, Communication, CommunicationRequest, Consent, Contract, DiagnosticReport, DocumentReference, ExplanationOfBenefit, HealthcareService, Library, Media, Patient, Person, Practitioner, Questionnaire, QuestionnaireResponse, RelatedPerson, SubstanceNucleicAcid, SubstancePolymer, SubstanceProtein and SubstanceSpecification
John Moehrke (Dec 13 2018 at 17:50):
none of those others look general... okay just needing to merge Media and DocumentReference
John Moehrke (Dec 13 2018 at 17:51):
How about "Attachment" as the new resource name?
John Moehrke (Dec 13 2018 at 17:54):
wow, that was all rather incoherent... sorry
Lloyd McKenzie (Dec 13 2018 at 18:05):
Attachment is a data type. There's lots of places where you'll want to have a binary where the relevant metadata is in the referencing resource. My leaning would be BinaryMetadata - i.e. Extra/indexing information about a binary stored somewhere.
Brett Marquard (Dec 13 2018 at 21:25):
What about the indexing to a Composition?
Brett Marquard (Dec 13 2018 at 21:26):
Notes could be stored in a lot of places, DocumentReference was selected becasue it provides a nice index to all the places
John Moehrke (Dec 13 2018 at 22:58):
Attachment is a data type. There's lots of places where you'll want to have a binary where the relevant metadata is in the referencing resource. My leaning would be BinaryMetadata - i.e. Extra/indexing information about a binary stored somewhere.
Yeah, sorry.
John Moehrke (Dec 13 2018 at 22:59):
Re: BinaryMetadata... Is it good to emphasize the 'binary' aspect? binary can contain anything... many people think of binary as in non-text... I am not arguing that the Binary resource needs to be changed. I am just saying that applying that word again to the metadata may be overkill and cause wrong impressions. That said, it likely would be more understood than "DocumentReference".
we could get very informal "Blob"
or "Appendix", "Extra", "Supplement", "Adjunct", "Auxiliary", "Ancillary",
Eric Haas (Dec 14 2018 at 04:05):
I like ValueAttachment
Eric Haas (Dec 14 2018 at 04:06):
NoteGetter !!
Eric Haas (Dec 14 2018 at 04:06):
(kidding)
Elliot Silver (Feb 05 2019 at 01:26):
@Eric Haas: @Jonathan Whitby, @John Moehrke and I have prepared a proposal for merging Media into DocumentReference, and adding Observation.valueAttachment. We've also provided some feedback on your skinny media proposal, https://docs.google.com/presentation/d/1FBbnMKqF6WUv4iDpJuwqrwfqMcxLLpiYaQNg-3otXkc/edit?usp=sharing, and some comments on the (still limited) set of use cases, https://confluence.hl7.org/pages/viewpage.action?pageId=40735720.
I will attempt to join the O&O on FHIR call tomorrow.
Eric Haas (Feb 05 2019 at 01:27):
I am not a huge fan of skinny media option, but wanted to put it out there.
Mikael Rinnetmäki (Feb 06 2019 at 12:10):
In case it's of interest, I just described another related use case for Media (or Observation.valueAttachment, or DocumentReference) at https://chat.fhir.org/#narrow/stream/179222-finnish-PHR/topic/NutritionIntake/near/157592099. @Elliot Silver
John Moehrke (Feb 06 2019 at 13:40):
That is indeed a good use-case for DocumentReference. That DocumentReference and image could be used as evidence for an Observation. Most likely as derivedFrom, and would not likely be that the image itself that is considered an observation (valueAttachment). This seems the way you have described it. Right?
Mikael Rinnetmäki (Feb 06 2019 at 15:31):
Pretty much, although I used the Media resource in the original proposal. I did have hard time choosing, though.
Last updated: Apr 12 2022 at 19:14 UTC
