Presented by: Gregorio Canal (Arsenàl.IT) to ITI Technical Cmte Brief Profile Proposal: Sharing platform for Documents not related to a single patient Presented by: Gregorio Canal (Arsenàl.IT) to ITI Technical Cmte

The Problem: the sharing of documents that are not related to a specific patient (stylesheets, workflow Definitions, Policy Definition, etc.). IT Infrastructure does not provide any guideline to facilitate the sharing of those documents, that usually need to be Searched / Discovered / Updated as commonly done in a patient-centric sharing infrastructure (such as XDS.b).

Use-cases of reference (1/4): Management of Stylesheets: An HIE has identified the set of stylesheets that can be used for the rendering of CDA documents. A Document Creator wants to discover the existence of those stylesheets in order to reference it in the XML Signature. The stylesheet can be versioned, and a Content Creator wants to submit a new version of the stylesheet.

Use-cases of Reference (2/4): Sharing of Workflow Definition: An HIE has defined a set of workflows that can be managed. Those workflows are represented by a BPMN document that can be consumed by Workflow Participants to identify workflow rules.

Use-cases of reference (3/4): Sharing of Policy Definitions: The BPPC profile relies on policy definitions that can be accessed both by BPPC Consumer and BPPC Creators. Policy Definitions are documents that describes a policy that can be subscribed by patients Policy Definitions changes during time, and all the system involved in creation and consuming of BPPC Consent Documents shall be aware of the existence of all available policies.

Use-cases of reference (4/4): Standards of interest: HL7 RLUS , ebXML , XDS.b, FHIR ? Systems Affected: Many…

Actors & Transactions Create File File Registry File Creator File Consumer

Actors & Transactions Create File File Registry Search File File Creator File Consumer

Actors & Transactions Create File Retrieve File File Registry Search File File Creator File Consumer

Actors & Transactions Create File Retrieve File File Registry Search File Update File File Creator File Consumer

Technical Approach: Actors New Actors: File Source: can create and/or update a Resource File Consumer: can search and/or retrieve a Resource File Registry: register and stores not patient-related documents Existing Actors: Extending the capabilty of XDS.b/MHD actors

Technical Approach: Transactions Create File: for Providing the document to the File Registry Update File: for updating the document stored in the File Registry Search File: for searching the document by specific metadata Retrieve File: for retrieving a specific document

Technical Approach: Risks We have to cover the scope, but in a way that this approach will be extensible in the future to cover other types of documents.

FHIR-based Solution Doesn’t affect other existing profiles The resource “Document Reference” exchanged it’s flexible

FHIR Transactions Create File: provide a new resource to a File Registry which stores it Update File: provide a resource to a File Registry which replace an existing resource by it’s Id Search File: used by a File Consumer for searching in the File Registry the resource based on some filter criteria. If it’s shared just one resource with the metadata and the document itself attached, it will search and retrive the resource containing all of them

Discussion Points: Reduce the Scope: there are relevant use-cases related to Secondary Data Usage (Public Health Report, Research Reports, Clinical Articles, etc.). We can take two approaches: Focus on a sub-set of use-cases (first tackle of this matter can be focused on “technical” documents… there is ongoing activities on this topic in some DICOM work groups) Identify a generic platform to cover the problem and leave to specific domains to identify details (such as Metadata) Should we use the same infrastructure used for Patient-centric documents ? This can be one of the approaches. PROS: reduce integration burden , minimize costs ; CONS: hard work to fit the actual document centric requirements to the new use-cases.