1. 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

2. 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).

3. 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.

4. 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.

5. 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.

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

7. Actors & Transactions Create File File Registry File Creator
File Consumer

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

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

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

11. 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

12. 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

13. 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.

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

15. 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

16. 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.