Stream: ihe
Topic: FHIR based XDM
John Moehrke (Aug 15 2018 at 20:52):
As a possibility for a new work item for ITI... I am wondering if there is interest in producing an IHE Profile similar in function to XDM, but using FHIR rather than the XDS Metadata XML file. Likely solution just produces a parallel FHIR based file (json) holding DocumentManifest+DocumentReference, with the documents still represented as files. Alternatives would certainly be considered. The intent is the same use-cases as XDM. That is a portable persistence of a patient documents onto media (CD, DVD, USB-Memory, and email attachment).
Possible enhancement to support ALL possible FHIR data, not specifically only Document Sharing. This would not be the same use-case as XDM, but would still be for portable persistence onto media.
Grahame Grieve (Aug 15 2018 at 23:25):
possible enhancement is a good idea.
Grahame Grieve (Aug 15 2018 at 23:26):
get lots of media kudos if you extend this to specify how to put this stuff in a blockchain. Whether that's actually a good idea or not
Simone Heckmann (Aug 16 2018 at 09:01):
How would this be different from FHIR Bulk Data?
Simone Heckmann (Aug 16 2018 at 09:02):
(other than that FHIR Bulk Data at this point only allows media/documents to be represented as Binary Ressources)
Simone Heckmann (Aug 16 2018 at 09:10):
I'd be definitely interested, if this XDMm (or mXDM? :thinking_face: ) uses the FHIR Bulk Data approach as an option to Invoke the export/define requested content but added some improvements around handling non-FHIR data (Ping @Stefan Lang @Frank Oemig )
Stefan Lang (Aug 16 2018 at 09:27):
That's definitely something of interest, especially when it goes beyond the document oriented approach.
I, too, think that FHIR Bulk Data should be taken into account here, while it would not cover everything involved in something I would imagine as "mXDM" yet.
Apart from discussing this here: would a BoF session at the Baltimore WGM be good as a starter for brainstorming?
John Moehrke (Aug 16 2018 at 12:41):
IHE governance would do a complete standards search... so if FHIR Bulk is the right solution, we will find it. I kind of agree.
John Moehrke (Aug 16 2018 at 12:42):
A BoF during FHIR Connectathon sounds like a good idea.
John Moehrke (Aug 16 2018 at 12:48):
I could certainly see general-purpose media persistence. I would like that Binary would be files on the media, rather than encoded in the main stream. If we accept files as parts, could that be generalizable to any Resource could be a file. Thus there could be one well-known file as the entrypoint. That file might contain everything in one big huge Bundle, or that file might just be the starting point. GIven REST, and the dominant directionality of the References in FHIR, it seems we might need to have a manifest that minimally lists all the files that should be found on the media, and what that file is, possibly a method of signing for integrity sake...
John Moehrke (Aug 16 2018 at 13:03):
Where one variation of this is the XDM use-case of Patient+DocumentReference+DocumentManifest+Binary... aka, document centric... but the solution could be any FHIR data...
John Moehrke (Aug 16 2018 at 13:04):
XDM is focused on ONE Patient... I like starting with this limitation... but am open to discussion. (How XDM does it is to say that any branch of a filesystem is focused on one patient, so large media can have many patients each with their own directory branch...
Stefan Lang (Aug 16 2018 at 13:42):
Sounds good to me.
But I also would consider the multi-patient use case as a very relevant one. As you say, this might just be one meta-level above the single patient structure.
Also, including non patient related information would be essential. Think of value sets that are actually maintained by the organization that created the data. You would need those to have a correct understanding of the actual, patient related, resources.
But any kind of other resource type come to mind here, from practitioners, organizations, coverages via things like PlanDefinition and eventually to StructureDefinitions (yes, I have a certain use case in mind).
Stefan Lang (Aug 16 2018 at 13:56):
Regarding BoF: shall we spread the word then?
And should we fix a time or just see when it fits during the connectathon?
John Moehrke (Aug 16 2018 at 14:02):
Bringing along non-patient resources would need to be supported (Practitioner, Organization, etc). I am not sure the value of ValueSets and StructureDefinition... I suspect you have another use-case in mind? Trying to do too much is not good, enabling expansion is not bad.
Stefan Lang (Aug 16 2018 at 15:16):
Regarding ValueSets: it is, at least in Germany, not uncommon to have "house catalogs", i.e. certain value sets specific to a hospital or GP. And these also may contain codes not only from well known code systems, but also codes that are made up by the organizations themselves.
Now, finding such a code in some patient's Observation.code (eventually even without display and/or text) will result in loss of information - you just don't know what the observation was about.
I know that's not the way interoperability ideally works, but it's reality. A part of my daily work consist of exactly that: trying to find out the actual meaning of certain codes in some proprietary and non-documented data structure. This often is time consuming and that's the reason why I think it should at least be an optional part of such a specification.
John Moehrke (Aug 16 2018 at 15:25):
If an observation uses a local code, it is fully understandable. Having the ValueSet from which it came is not more informative than the encoding of the code within the Observation. this is why persisting the valueset is not important in this case. -- but I could be missing something
John Moehrke (Aug 16 2018 at 15:26):
I am figuring that carrying all of the profile conformance details is not important... however if done, then must be fully done.. possibly a whole nother directory holding all the conformance resources necessary... I think this is just overhead that is not justified by the use-case need, and not supported by the typical size of a portable media
John Moehrke (Aug 16 2018 at 15:31):
I think going beyond simple portability on media of a Patient data is moving into the space of a different work item on FHIR persistence model that is being discussed as a potential FHIR Foundation project
Stefan Lang (Aug 16 2018 at 15:33):
As long as the consumer of the data has already access to the value set, it is unimportant. But that's not always the case.
Think of a patient changing his GP, bringing the data along. The new GP then at least is able to retrieve display values via the ValueSet/CodeSystem. Which is not the case when your Observation just says:
...
<code>
<coding>
<system value="http://gp-old.com/myCodeSystems/myObsevationTypes" />
<code value="852" />
</coding>
</code>
John Moehrke (Aug 16 2018 at 15:35):
well.. there is a URL to retrieve the details from the system... THAT should be published... The gap is an organization not willing to publish their codesytem, that also does NOT populate the <coding> properly, but is willing to put the whole thing onto patient carried media... I am not sure I am convinced these exist.
Stefan Lang (Aug 16 2018 at 15:36):
There is a German law that enforces exactly what you say
Stefan Lang (Aug 16 2018 at 15:37):
Except that "willing" may be the wrong word ;-)
Stefan Lang (Aug 16 2018 at 15:42):
But maybe that's more the FHIR Foundation project than "mXDM" then.
In any case, whatever would be specified for a single patient by IHE should not differ from the respective concept in the FHIR Foundation project
Stefan Lang (Aug 16 2018 at 15:47):
I also completely agree that code systems should be made available publicly. Unfortunately, this is something that will not happen in many cases due to the "what's mine is mine" doctrine. So a different way to make them available not publicly, but when needed, is required.
John Moehrke (Aug 16 2018 at 15:48):
so, there is a solution... fully describe the code in the data.
Stefan Lang (Aug 16 2018 at 15:54):
True, apart from the case when it says "XYZ, other" (as a display value). You would not know what "other" is when you don't know all variants of "XYZ".
But surely you will argue, you'd just put into code.text (for example), what the exact meaning of "other" is in that special instance, right?
John Moehrke (Aug 16 2018 at 16:06):
I am more and more convinced that the organizations you speak of are not going to listen to any recommendations...
Stefan Lang (Aug 16 2018 at 16:11):
I wouldn't say so, since there is definitely a change starting, but as always in such cases, it may take some time to catch up with the new things and I consider it relevant to have some "multi-step" path available.
Elliot Silver (Aug 16 2018 at 20:03):
I could certainly see general-purpose media persistence. I would like that Binary would be files on the media, rather than encoded in the main stream. If we accept files as parts, could that be generalizable to any Resource could be a file. Thus there could be one well-known file as the entrypoint. That file might contain everything in one big huge Bundle, or that file might just be the starting point. GIven REST, and the dominant directionality of the References in FHIR, it seems we might need to have a manifest that minimally lists all the files that should be found on the media, and what that file is, possibly a method of signing for integrity sake...
I'm having visions of multipart/related, cids, and xop -- correction: nightmares.
Grahame Grieve (Aug 16 2018 at 20:23):
I think it makes perfect sense to publish code systems as part of an XDM content set. Value Sets, not so much. Also it makes perfect sense to publish extension definitions.
Grahame Grieve (Aug 16 2018 at 20:24):
of course, these may be published somewhere in a registry, and that would be preferable. but registries might not be maintained, and/or institutions might not want to publish in public what they are prepared to put in an extract of a clinical record
Stefan Lang (Aug 16 2018 at 22:28):
Obviously I agree on the CodeSystem part. But if you consider extensions, this will include extensions with bound ValueSets, so you have to include these also, at least when they are custom.
Another use case is archiving, which definitely should include at least custom ValueSets. But according to John, this might be beyond the scope of XDM on FHIR?
Grahame Grieve (Aug 16 2018 at 22:30):
yes value sets too for that reason
John Moehrke (Aug 17 2018 at 12:41):
So this is why I figured there might be a non-patient section on the media. to hold codesystems, and extension definitions. This space could also hold other things as deemed needed.
John Moehrke (Aug 17 2018 at 12:43):
It was the ValueSets that I was mostly pushing back on... The valueset does not add to understanding the data. I would acknolwedge one need when an extension calls for a specific valueset.
John Moehrke (Aug 17 2018 at 12:45):
So, given one puts codeSystems on the media... now a CD-ROM is filled by SNOMED,LOINC, DICOM, and HL7 vocabulary... no space left to put the patient data... Clearly I am using an absurd point to drive home that there would need to be some guidance on what CodeSystems should go on, and which should NOT.
Grahame Grieve (Aug 17 2018 at 13:10):
there's a few places where value set is a necessary link between definition and code system.
Stefan Lang (Aug 17 2018 at 13:50):
So, given one puts codeSystems on the media... now a CD-ROM is filled by SNOMED,LOINC, DICOM, and HL7 vocabulary... no space left to put the patient data... Clearly I am using an absurd point to drive home that there would need to be some guidance on what CodeSystems should go on, and which should NOT.
I would basically leave that to the specific use case, allowing both options:
- have a reference to a publicly available CodeSystem
- have a complete CodeSystem stored
I consider it perfectly ok to mix both, e.g. just referring to SNOMED, but putting "internal" CodeSystems onto the media.
But neither (meaning: "use only references" or "use only full resources"), and also not a fixed "when to use which" should be part of the spec. That should rather be a recommendation ("if you expect run out of media space, a reference to publicly available code systems is encouraged")
Grahame Grieve (Aug 17 2018 at 20:29):
best practice would be not to create licensing issues by reproducing snomed cpt4 icd etc ;-)
Stefan Lang (Aug 18 2018 at 10:35):
That's true for sure ;-) Still not more than a recommendation in the spec, I think.
Last updated: Apr 12 2022 at 19:14 UTC
