201805 IHE-on-FHIR

IHE-on-FHIR

Focused on testing IHE-MHD profile with support from the IHE Connectathon test tools.

IHE-MHD profile uses HL7 FHIR STU3

Submitting WG/Project/Implementer Group

Driven by IHE International in coordination with IHE-Connectathon

Justification

To support engagement at FHIR Connectathon on the IHE Profiles that leverage FHIR.

Will not duplicate more focused and dedicated tracks. These other tracks are encouraged and every effort will be made to coordinate IHE engagement with them:

• 201805 Care Plan
  • IHE Dynamic Care Planning Profile
• 201801 Medical Device and Implantables Tracking using UDI
  • IHE Point-of-Care Medical Device Tracking Profile
• 201801 Provider Directory
  • IHE Mobile Care Services Discovery (mCSD) Profile
• 201805 Patient Track
  • IHE Patient Demographics for Mobile (PDQm) Profile

Also not intended to be testing non-FHIR based IHE profiles. Testing will leverage IHE-Connectathon tools, but will not be considered as comprehensive as IHE-Connectathon

Previous FHIR Connectathon Track

• • 201801 IHE-on-FHIR

Zulip thread for refinement

https://chat.fhir.org/#narrow/stream/ihe/topic/January.20Connectathon.20-.20IHE-on-FHIR

Proposed Track Lead

See Connectathon_Track_Lead_Responsibilities

1. TBD (EU IHE Connectathon)
2. John Moehrke (JohnMoehrke@gmail.com) -- skype id = johnmoehrke

Roles

This track will be further refined based on the IHE Profiles that leverage FHIR, not including those more dedicated tracks, and the participation. The wiki reference above gives a full list of IHE profiles that leverage FHIR. This is a short list that excludes the tracks already proposed for January, 2018:

Domain	Profile	Name	Description
ITI	MHD	Mobile access to Health Documents	defines one standardized interface to health documents (a.k.a. an Application Programming Interface (API)) for use by mobile devices so that deployment of mobile applications is more consistent and reusable. MHD enables simplified access by mobile devices to an XDS (or a similar) document management environment containing health information.

IHE will provide experienced IHE-Connectathon staff with tooling used at IHE Connectation.

Document Recipient

• The IHE Document Recipient actor receives a set of documents. It is similar to a Document Repository but is only tasked with receiving documents. It will provide documents to other systems through transactions or operations using other interfaces.
• During the Connectathon, the Document Recipient will be expected to accept documents and metadata from a Document Source.

Document Responder

• The IHE Document Responder is a single actor that supports both the Document Registry and Document Repository functionality.
• During the Connectathon, the Document Responder will be expected to support search and retrieve operations from a Document Consumer. The Document Responder can use existing documents or perhaps accept new documents as grouped with a Document Recipient.

Document Source

• The IHE Document Source actor produces and publishes documents. In this context, it publishes documents with metadata by sending data to a Document Recipient.
• During the Connectathon, the Document Source will be required to submit documents for specified patients to a Document Recipient.

Document Consumer

• The IHE Document Consumer actor queries for document metadata meeting certain criteria, and may retrieve selected documents. In this context, it communicates with a Document Responder.

Scenarios

Scenario (MHD) Publication of New Documents

Action: Document Source publishes new documents by sending them to a Document Recipient

Precondition: Actors have agreed on patient identifier domains. A Patient resource exists somewhere that is referenced by the new documents. This Patient resource can live within the Document Source, the Document Recipient or in some other system.

Success Criteria: There are several ways to determine success. If the Document Recipient is coupled with a Document Responder, we have tools that can query the Document Responder and locate the documents. Also, a Document Consumer actor can directly discover and retrieve documents from a Document Responder. If nothing else, we will have to check log entries at the Document Recipient.

Bonus point: Integrate the document workflow with PDQm or PIXm scenarios to manage patient identities and demographics.

Scenario (MHD) Discovery and Retrieval of Existing Documents

Action: Document Consumer discovers documents and retrieves them from a Document Responder.

Precondition: Document Responder has pre-defined documents or is coupled with a Document Recipient and has received documents during the event. We will need to coordinate metadata values.

Success Criteria:

• Document Consumer will have to demonstrate that it was able to retrieve one or more DocumentReference, and retrieve documents for specified patients. This is equivalent to Argonaut DocumentReference use
  • That is a DocumentReference query with only a Patient identified, thus receiving all of the DocumentReference known for that Patient

Bonus point:

• Integrate the document workflow with PDQm or PIXm scenarios to manage patient identities and demographics. Also integrate directly with submission of documents to a Document Recipient.
• Use SMART-on-FHIR or IHE-IUA profile to secure the communication
• Document Consumer uses DocumentReference query parameters: class, setting, and period
• Document Consumer uses DocumentReference further queries defined in MHD
• Document Consumer uses DocumentManifest queries to retrieve metadata about SubmissionSet
• Document Consumer uses List queries to retrieve metadata about Folder

TestScript(s)

Pointer to IHE Connectathon MHD test tooling to be provided

Security and Privacy Considerations

• Authentication/Authorization will be OAuth and HTTPS (e.g. SMART on FHIR (OAuth), IHE IUA (OAuth)
• Privacy Consent management is not part of the expected scenario, but is available through FHIR Consent and/or IHE-BPPC an APPC.
• What Audit Logging is defined in the IHE-MHD profile support through IHE-ATNA includes the ATNA/DICOM schema over syslog, and the FHIR AuditEvent schema using http REST.
• Provenance is not a focus, although the concepts of Provenance are included in the IHE Document Sharing (e.g. XDS) metadata.
  • Note the FHIR Provenance resource is foundational to the IHE-mXDE and IHE-QEDm profiles
• The security-labels use are as defined in MHD and IHE Document Sharing.