Referencing DRS Objects

[allisonheath]

Requester information

Please provide the following information:

• Name: Allison Heath
• Affiliations: CHOP (KFDRC)

Request Details

Please provide the following information about what you wanting to accomplish with your model change request:

• Purpose: Being able to provide a reference to relevant data that resides in a DRS object
• Who it benefits: Any platform that is utilize the DRS standard, e.g. KFDRC, but there are an increasing number in the GA4GH service registry.
• Use case: The NCPI system interoperability group has converged on DRS as the initial standard protocol for providing a reference to both public and controlled access objects. The most common use case currently is for genomic data files (see #23), but it is general enough to represent any data objects.

[allisonheath]

We went through a couple of iterations on this (thanks @bwalsh!) as there's not necessarily one clearly "right" way to do this. The best resource to profile does appear to be DocumentReference, although DiagnosticReport was also suggested as an option as well.

Given we're using DocumentReference, there are still multiple ways to approach profiling it. Two key things we want to accomplish by profiling are:

• If you get a profiled resource, the client systems can assume this references a DRS Object and act accordingly
• Ability to quickly subset/search and find all referenced DRS objects
• Validate that the url/uri provided starts with "drs://" as defined in the DRS spec

Take 1: Include all of the DRS fields

The first pass was to include all of the DRS object fields in FHIR. So for example including a drs-size drs-name drs-checksum and so on. The advantage of this approach is that within FHIR a user could search on these fields if desired. However, DRS is currently more widespread than FHIR and so the disadvantage is that then there might be two locations of the same information to stay synchronized, the DRS service itself and the FHIR server and may be prone to erroneous information. In the future, it may make sense to build a DRS service with the FHIR information being the backend and/or have a closer integration between the two. At this point in time and in the spirit of starting out a bit more minimal with the NCPI FHIR model, the next step was to look at just including the DRS URI (Take 2 below). This will make the assumption that all callers will go to the DRS API to retrieve further file information stored there.

Take 2: Include just the DRS URI

Within DocumentReference, there is a content element with an attachment of datatype Attachment. The Attachment has a Url element that seems the most reasonable place to put the DRS URI. However, this then provides multiple levels at which the profiling can occur, as described by the following options (may be more, but these appeared to be the initial reasonable ones).

Option 2.1: Create a profile on Attachment "ncpi-drs-attachment"

There's even two suboptions here, one could just utilize the url element and constrain it to start with "drs://" or one could add a drs-uri element that is constrained to start with "drs://" and require the ncpi-drs-attachment to have a ncpi-drs-uri element. In either case, no further profiling would occur, one would just use ncpi-drs-attachment in the DocumentReference when it is a DRS object. This is relatively simple and would allow the ncpi-drs-attachment to be reused in other places. The downside is that since the profile is not on the DocumentReference, one would first find ncpi-drs-attachment and then if looking for specifically DocumentReferences have to check if that is what it is contained in.

Option 2.2: Create a profile on DocumentReference "ncpi-drs-document-reference"

One could just profile the DocumentReference and utilizing FHIR constraints have a rule that enforces that the url must start with "drs://". This is also relatively simple and allows the one to easily find the DocumentReferences that validate against this profile. The downside is that there is no reusable attachment component.

Option 2.3: Profile both Document Reference and Attachment

This would create a profile as described in Option 2.1 as well as one on DocumentReference "ncpi-drs-document-reference". But instead of using the FHIR constraints, ncpi-drs-document-reference would be required to utilizing the "ncpi-drs-attachment". This is likely the most complex option, but also provides flexibility for reusing the attachment profile in other resources such as DiagnosticReport.

One final consideration for the DocumentReference profiling options (2.2 and 2.3) is that we should likely enforce there is at least one content element that contains a DRS URI (no matter which option is chosen).

[bwalsh]

Options that retrieve a drs url will use the DRS service to fulfill object meta data, signing manifests, etc.

More

[mattions]

I like the idea to have the minimal link to DRS via the URL instead of replicating the information, so I think this will also avoid to keep up with the DRS specs, in case they will change, so we can simply handoff that to the DRS Client which will implement that (which will need to keep up anyway, so no duplication of work)

[allisonheath]

Closed by #42