MedMij:V2018.06 FHIR Images: verschil tussen versies

Uit informatiestandaarden
Naar navigatie springen Naar zoeken springen
Regel 1: Regel 1:
−
{{#customtitle:MedMij FHIR use case Images}}
+
{{#customtitle:MedMij FHIR Implementation Guide: Images 1.0.0}}
 +
{{MedMij:V2018.06_Issuebox_FHIR_IG}}
 +
 
 +
{{IssueBox|These specifications are for public consultation from '''10th of January to 21th of February'''. Open issues and questions are signaled with issue boxes like this one.
 +
 
 +
If you have any feedback, please submit it at https://bits.nictiz.nl/projects/MSIOC/}}
  
 
[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
 
[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
Regel 12: Regel 17:
 
__TOC__
 
__TOC__
  
−
Content will follow shortly.
+
=Introduction=
 +
[[Bestand:Functioneel-02.png|link=MedMij:V2018.06_Ontwerpen |100px|rechts|Functional design|Go to functional design]]
 +
 
 +
This page describes the exchange of images within MedMij. In contrary to other described use cases for MedMij no existing information standard fits nor are there specific ZIB models applicable. To achieve exchange of images, MedMij adopts as much as possible from existing standards, such as the DICOM standard and the Mobile access to Health Documents (MHD) profile from Integrating the Healthcare Enterprise (IHE) that defines a RESTful/HTTP interface to an [http://wiki.ihe.net/index.php/Cross-Enterprise_Document_Sharing XDS] environment using HL7 FHIR STU3 resources.
 +
 
 +
The specification currently consists of one use case, that covers sending an image by a patient to a healthcare provider. Based on future research, a use case to retrieve images by the patient will be added. Most likely, this will be based on DICOMweb™, which is the DICOM standard for web-based medical imaging based on RESTful services.
 +
 
 +
'''Note''': this page is part of the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2018.06_FHIR_IG MedMij FHIR Implementation Guide] and is a technical representation of the functional design published on this [[MedMij:V2018.06_Ontwerpen| wiki page]].
 +
 
 +
==IHE MHD specification==
 +
Mobile access to Health Documents (MHD) profile defines a simple HTTP interface to an XDS like environment. The four described transactions leverage the document content and format agnostic metadata concepts from XDS but simplify them for access by constrained environments such as mobile devices, or other resource-constrained systems. The MHD profile does not replace XDS. It can be used to allow mobile devices, or other resource-constrained systems, access to an XDS health information exchange.[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)]
 +
 
 +
'''Wiki:'''
 +
[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD) Mobile acces to Health Document (MHD)]
 +
 
 +
'''Document:'''
 +
[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD.pdf MHD Supplement] (Rev 2.3 July 24, 2017)
 +
 
 +
'''Additional Supplement:'''
 +
[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_Appx-Z.pdf Appendix Z on HL7 FHIR]
 +
 
 +
=Actors and transactions involved=
 +
Table 1 shows the relevant actors, systems and FHIR capability statements in a MedMij context. The capability statements demonstrate the minimum requirements to be conformant to the described use cases.
 +
 
 +
{| class="wikitable"
 +
! colspan="2" style="text-align:left;" | Persons
 +
! colspan="2" style="text-align:left;" | Systems
 +
! colspan="2" style="text-align:left;" | FHIR Capability Statements
 +
|-
 +
! style="text-align:left;" |Name
 +
! style="text-align:left;" |Description
 +
! style="text-align:left;" |Name
 +
! style="text-align:left;" |Description
 +
! style="text-align:left;" |Name
 +
! style="text-align:left;" |Description
 +
|-
 +
| Patient
 +
| The user of a personal healthcare environment.
 +
| PHR
 +
| Personal health record
 +
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/NictizSTU3-Zib2017/image-clientcapabilities CapabilityStatement: Client]
 +
| Image FHIR Client requirements
 +
|-
 +
| Healthcare Provider
 +
| The user of a XIS
 +
| XIS
 +
| Healthcare information system
 +
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/NictizSTU3-Zib2017/image-servercapabilities CapabilityStatement: Server]
 +
| Image FHIR Server requirements
 +
|}
 +
<font size = "1">'''Table 1. Actors, systems and FHIR capability statements'''</font>
 +
 
 +
Table 2 shows the MHD actors and transactions in perspective of the systems used in a MedMij context.
 +
{| class="wikitable"
 +
! style="font-weight: bold; text-align:left;" | Person
 +
! style="font-weight: bold; text-align:left;" | System
 +
! style="font-weight: bold; text-align:left;" | Role
 +
! style="font-weight: bold; text-align:left;" | MHD Actors - for XDS
 +
! style="font-weight: bold; text-align:left;" | MHD Transactions - for XDS
 +
|-
 +
| Patient
 +
| PHR
 +
| Sends image to the XIS
 +
| Document Source
 +
| rowspan="2" |Provide Document Bundle
 +
|-
 +
| Healthcare provider
 +
| XIS
 +
| Receives image from the PHR
 +
| Document Recipient
 +
|}
 +
<font size = "1">'''Table 2. MHD actors and transactions in perspective of systems in a MedMij context'''</font>
 +
 
 +
=Boundaries and Relationships=
 +
The use case where an image is sent from a PHR to a XIS is influenced by the IHE MHD profile with regards to the PHR message semantics and mandatory elements. The specifications for this use case mainly deviates in the use of the FHIR Media resource instead of the DocumentReference resource. Although the DocumentResource is in line with the requirements of persisting content in a XDS network and the resource can handle images, the Media resource is more appropriate and specific for the exchange of images. The Media resource has additional, more specific, (medical related) elements compared to the DocumentReference. These are the Media's view, reasonCode, bodySite, device and to a lesser extent the height and width elements. In addition, the Media resource has a reference coming from the DiagnosticReport that may be of value for further development of the MedMij information standard for images.
 +
 
 +
A XIS can possibly act within a XDS network. The information standards in use by MedMij have the primary objective to enable standardized communication based on FHIR STU3. As a secondary objective, enabling exchange with XDS networks is taken into account. For this objective, the PHR will need to provide additional meta information to the Media resource. The additional meta information allows XIS actors to index an image properly within a XDS network. The XIS is responsible for converting the PHR message into a XDS DocumentEntry. A mapping from the Media resource to the mandatory metadata elements of the IHE MHD DocumentReference resource is provided. The IHE MHD and general IHE XDS profiles will provide the information needed to perform a successful DocumentEntry of an image.
 +
 
 +
=Use case: send image from a PHR to a XIS=
 +
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
 +
 
 +
== Introduction ==
 +
This use case describes the minimal required technical functionalities in order to exchange an image made by the patient to a healthcare provider. Typical process flow would be:
 +
# Patients makes, downloads or receives an image and uploads it to his PHR.
 +
# The PHR sends the image to the chosen XIS system.
 +
## Potentially the patient needs to provide sufficient metadata concerning the image.
 +
# A healthcare provider views the image in his XIS.
 +
This use case presumes made agreements between the patient and healthcare provider. Besides a technical answer by the XIS of the healthcare provider, no answer to the patient is expected.
 +
 
 +
The following technical specifications will concern the process mentioned at point 2.
 +
 
 +
==Actors==
 +
{| class="wikitable" "cellpadding="10"
 +
! style="text-align:left;"| '''Transaction group'''
 +
! style="text-align:left;"| '''Transaction'''
 +
! style="text-align:left;"| '''Actor'''
 +
! style="text-align:left;"| '''Role'''
 +
|-
 +
|style="background-color: white;vertical-align:top;" rowspan="2"|Send Image Bundle (PUSH)
 +
|style="background-color: white;vertical-align:top;"|Send image bundle request
 +
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
 +
|style="background-color: white;vertical-align:top;"|Sends image to the XIS
 +
|-
 +
|style="background-color: white;vertical-align:top;"|Receive image bundle response
 +
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
 +
|style="background-color: white;vertical-align:top;"|Receives image from PHR
 +
|}
 +
 
 +
== Invocations ==
 +
{{FHIR-IG-Afsprakenstelsel-Note}}
 +
 
 +
=== Client - PHR request===
 +
When the patient (PHR) wants to send one or more images, it issues a send image bundle request message.
 +
 
 +
The PHR initiate a FHIR transaction using a create action by sending an HTTP POST request composed of a FHIR Bundle Resource containing one or more FHIR Media resources, zero or more Binary resources and one patient resource to the XIS Recipient. References to the FHIR specification for the required transaction and POST requests are given in the [[#Interactions.2C_operations.2C_search_parameters | interactions, operations and search parameters]] section below.
 +
 
 +
The PHR executes an HTTP POST against the XIS's base endpoint as shown below.
 +
 
 +
<pre>
 +
POST [base] {?_format=[mime-type]}
 +
</pre>
 +
 
 +
The PHR shall assure all FHIR resource elements are consistent with the requirements specified in the StructureDefinitions for List, Media, Device, Patient, Practitioner and Organization resources. References to these StructureDefinitions are provided in [[#List_of_StructureDefinitions | list of StructureDefinitions]].
 +
 
 +
==== Textual Requirements ====
 +
 
 +
* The Bundle.type shall be transaction.
 +
 
 +
* The Media.content.attachment.url points at the image content, which shall be in the Bundle as a Binary resource. See FHIR Resolving references in Bundles at the [http://hl7.org/fhir/STU3/bundle.html#references FHIR specification] and use within MedMij at the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2018.06_FHIR_IG#Use_of_the_reference_datatype MedMij Use case overarching principles].
 +
 
 +
* All Media.subject values shall be References to Patient resources and shall be included in the Bundle.
 +
 
 +
* A List resource shall be used to group the images if a collection of images are sent.
 +
 
 +
* Accompanying text from the patient for the image and/or collection of images shall be placed in the Media.note and List.note respectively.
 +
 
 +
=== Examples ===
 +
'''Message components'''
 +
* [https://simplifier.net/nictizstu3-zib2017/media-example-eczema-comprehensive-data Media comprehensive data]
 +
* [https://simplifier.net/nictizstu3-zib2017/media-example-eczema-minimum-data  Media minimum data]
 +
* [https://simplifier.net/nictizstu3-zib2017/binary-example Binary of image]
 +
* [https://simplifier.net/nictizstu3-zib2017/images-list-media List of Media resources]
 +
'''Transaction Bundle'''
 +
* [https://simplifier.net/nictizstu3-zib2017/image-transaction-bundle Transaction Bundle containing one image]
 +
* [https://simplifier.net/nictizstu3-zib2017/images-bundle-transaction-multiple-images Transaction Bundle containing multiple images]
 +
* [http://hl7.org/fhir/bundle-response.xml.html Transaction Bundle response - example from the FHIR spec]
 +
 
 +
=== Server - XIS response ===
 +
The XIS shall process the bundle atomically. If necessary for processing, the XIS shall retrieve resources referenced by absolute URLs in the FHIR Bundle Resource.
 +
 
 +
The XIS returns an HTTP Status code appropriate to the processing outcome, conforming to the transaction specification requirements as specified in the FHIR specification.
 +
 
 +
The XIS response message shall be sent when a success or error condition needs to be communicated. Success is only indicated once the image(s) is/are received and completely processed and persisted as appropriate to the XIS configuration.
 +
 
 +
To enable the PHR to know the outcome of processing the transaction, and the identities assigned to the resources by the XIS, the XIS shall return a Bundle, with type set to transaction-response, that contains one entry for each entry in the request, in the same order as received, with the Bundle.entry.response.outcome indicating the results of processing the entry. The XIS shall comply with FHIR [http://hl7.org/fhir/STU3/bundle.html#transaction-response Bundle transaction-response] and [http://hl7.org/fhir/STU3/http.html#transaction-response the HTTP transaction-response] specifications.
 +
 
 +
=== Server - XIS & XDS ===
 +
If the receiving XIS is part of a XDS network, it will need to convert the PHR request message into a proper message for the IHE "Provide and Register Document Set-b [ITI-41]" transaction. The XIS shall create appropriate metadata from the resources in the FHIR Bundle. The PHR shall provide the minimally required metadata. A mapping is shown below to assist in the XDS entry. The FHIR Media resource is mapped to the mandatory elements in the IHE MHD Profile on "DocumentReference with Comprehensive (aka XDS-on-FHIR) Metadata". IHE MHD defined these elements as a minimum for a XDS DocumentEntry. The [https://simplifier.net/NictizSTU3-Zib2017/ImagesMedia/~mappings Media StructureDefinition] contains a mapping to this profile and to XDS DocumentEntry, the [https://simplifier.net/NictizSTU3-Zib2017/images-List/~mappings List StructureDefinition] contatins a mapping to the XDS 'Folder Metadata Attributes'. Some FHIR elements do not translate to XDS concepts; the handling of these elements is left to the implementer of the XIS.
 +
 
 +
Upon successful conversion of the FHIR Bundle to XDS metadata, the XIS shall execute the Provide and Register Document Set-b [ITI-41] transaction. The transaction result and any error or warning messages, shall be reported to the PHR. The XIS is responsible for translating the XDS response to the appropriate HTTP Status Code and FHIR OperationOutcome Resource in the Send Image Bundle Response Message.
 +
 
 +
==== Mapping Media to mandatory IHE MHD DocumentReference elements needed for XDS DocumentEntry ====
 +
 
 +
{| class="wikitable"
 +
! style="font-weight:bold;" | IHE MHD Profile on DocumentReference with Comprehensive (aka XDS-on-FHIR) Metadata
 +
! style="font-weight:bold;" | Media for images, used by the PHR
 +
! style="font-weight:bold;" | Implementation notes for XIS & XDS
 +
|-
 +
| DocumentReference.masterIdentifier
 +
| Media.identifier
 +
|
 +
|-
 +
| DocumentReference.status
 +
|
 +
| Fixed value "current".
 +
|-
 +
| DocumentReference.type
 +
| Media.type
 +
| Fixed LOINC code: 72170-4 Photographic image Unspecified body region Document.
 +
|-
 +
| DocumentReference.class
 +
| Media.reasonCode
 +
| If no reasonCode is present, a fixed LOINC code 72170-4 Photographic image Unspecified body region Document can be used.
 +
|-
 +
| DocumentReference.subject
 +
| Media.subject
 +
|
 +
|-
 +
| DocumentReference.indexed
 +
| Media.occurrenceDateTime
 +
|
 +
|-
 +
| DocumentReference.securityLabel
 +
| Media.meta.security
 +
| If no value is present 'normal' should be used as default.
 +
|-
 +
| DocumentReference.content
 +
| Media.content
 +
|
 +
|-
 +
| DocumentReference.content.attachment
 +
| Media.content.attachment
 +
|
 +
|-
 +
| DocumentReference.content.attachment.contentType
 +
| Media.content.attachment.contentType
 +
| Possible media content types: JPEG, PNG, GIF, JP2.
 +
|-
 +
| DocumentReference.content.attachment.url
 +
| Media.content.attachment.url
 +
|
 +
|-
 +
| DocumentReference.content.attachment.size
 +
| Media.content.attachment.size
 +
|
 +
|-
 +
| DocumentReference.content.attachment.hash
 +
| Media.content.attachment.hash
 +
|
 +
|-
 +
| DocumentReference.content.format
 +
|
 +
| Fixed value "mimeType Sufficient".
 +
|}
 +
 
 +
A number of fixed values can be used in indexing to a XDS network based on an image sent by a patient. These are status, type, security (if no value is given in the Media.meta.security element) and format. Below the technical representation of these fixed values is shown.
 +
 
 +
<pre>
 +
<DocumentReference>
 +
  ....
 +
    <status value="current" />
 +
  ....
 +
    <type>
 +
        <coding>
 +
            <system value="http://loinc.org/" />
 +
            <code value="72170-4" />
 +
            <display value="Photographic image Unspecified body region Document" />
 +
        </coding>   
 +
    </type>
 +
  ....
 +
    <securityLabel>
 +
        <coding>
 +
            <system value="http://hl7.org/fhir/v3/Confidentiality" />
 +
            <code value="N" />
 +
            <display value="normal" />
 +
        </coding>
 +
    </securityLabel>
 +
  ....
 +
    <format>
 +
        <system value="urn:oid:1.3.6.1.4.1.19376.1.2.3"/>
 +
        <code value="urn:ihe:iti:xds:2017:mimeTypeSufficient"/>
 +
        <display value="mimeType Sufficient"/>
 +
    </format>
 +
  ....
 +
</DocumentReference>
 +
</pre>
 +
 
 +
{{IssueBox|'''Images.1''' Currently we mandate the PHR to provide identifiers for the Media and List, which should conform to the requirements of an identifier needed for a DocumentEntry. Should this be mandatory? Isn't this an element that a XIS should generate?}}
 +
{{IssueBox|'''Images.2''' Media Status. A DocumentReference has a status while Media does not in STU3. Within IHE MHD only the status values 'current' and 'superseded' are used. This in combination with a relatesTo element to indicate which document is superseded. This use case does not specify how to handle superseded images. Current scope is to exchange images witouth a status indicator. Could this be a problem for XDS networks?}}
 +
{{IssueBox|'''Images.3''' Is a 'normal' security code possible as default when no information is given by the patient?}}
 +
{{IssueBox|'''Images.4''' Does Media.reasonCode map to DocumentReference.class / XDS classCode? Do we need the patient to mandatory provide information for this concept? Does the fixed code suggestion fits if the patient does not provide information?}}
 +
{{IssueBox|'''Images.5''' The mapping table above only maps the mandatory elements from the DocumentReference profile. The StructureDefinitions Media en List contain all the mappings and is referenced above as well. However, should we expand this table here with additional and optional elements?}}
 +
 
 +
==Interactions, operations, search parameters==
 +
 
 +
===Interactions===
 +
The following logical interactions are needed for this use case:
 +
* [http://hl7.org/fhir/STU3/http.html#create Create]
 +
* [http://hl7.org/fhir/STU3/http.html#transaction Transaction]
 +
 
 +
===Operations===
 +
There are no defined operations for this use case.
 +
 
 +
===Search parameters===
 +
There are no search parameters needed for this use case.
 +
 
 +
==List of StructureDefinitions==
 +
===MedMij StructureDefinitions===
 +
 
 +
{| class="wikitable" width="1400px"
 +
|-style="background-color: #1F497D; color: white; font-weight: bold; "
 +
|Name NL||Name EN||FHIR Resource||URL profile
 +
|-style="vertical-align:top; background-color: #E3E3E3;
 +
|-
 +
| Patient
 +
| #ZIB Patient|Patient
 +
| Patient
 +
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-patient  http://fhir.nl/fhir/StructureDefinition/nl-core-patient]
 +
|-
 +
| Zorgverlener
 +
| HealthProfessional
 +
| Practitioner
 +
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-practitioner http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner]
 +
|-
 +
| Zorgaanbieder
 +
| HealthcareProvider
 +
| Organization
 +
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization]
 +
|-
 +
| Beeld
 +
| Image
 +
| Media
 +
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/structuredefinition/images-media http://nictiz.nl/fhir/StructureDefinition/images-Media]
 +
|-
 +
| CollectieBeelden
 +
| CollectionImages
 +
| List
 +
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/StructureDefinition/images-List http://nictiz.nl/fhir/StructureDefinition/images-List]
 +
|-
 +
| MedischHulpmiddel.Product
 +
| MedicalDevice.Product
 +
| Device
 +
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct]
 +
|}
 +
 
 +
===IHE MHD StructureDefinitions===
 +
IHE has defined StructureDefinitions and other Conformance resources applicable to this use case. The FHIR Implementation Guide on the '''[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#FHIR_Implementation_Guide  IHE MHD wiki]''' lists these StructureDefinitions.
 +
 
 +
* IHE MHD profile on Provide Document Bundle (ITI-65) transaction with Comprehensive Metadata
 +
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Comprehensive http://ihe.net/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Comprehensive]
 +
 
 +
* IHE MHD Profile on DocumentReference (DocumentEntry) when used in the Provide Transaction with Comprehensive (aka XDS-on-FHIR) Metadata
 +
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.Provide.Comprehensive.DocumentReference  http://ihe.net/fhir/StructureDefinition/IHE.MHD.Provide.Comprehensive.DocumentReference]
 +
 
 +
* IHE MHD Profile on List (Folder)
 +
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.List http://ihe.net/fhir/StructureDefinition/IHE.MHD.List]
 +
 
 +
{{IssueBox|'''IHE.1''' Currently, we don't use or specify a profile that concerns the transaction request. (A profile like "IHE MHD profile on Provide Document Bundle (ITI-65) transaction with Comprehensive Metadata") Is such a profile nescessary? We don't use it in other MedMij use cases and the transaction bundle is described by the FHIR specification and textual in this use case.}}
 +
{{IssueBox|'''IHE.2''' The main reason the "IHE MHD Profile on List (Folder)" is not used, is because it mandates the use of .title and .code which likely contains information a patient needs to enter manually. As we would like to keep the burden on patients as low as possible a custom profile of list is used without these mandatory elements. Additionally, one of the benefits is that we can use references to our own profiles. }}
 +
{{IssueBox|'''IHE.3''' The IHE StructureDefinitions contain a number of errors, mentioned in this [https://chat.fhir.org/#narrow/stream/100-IHE-FHIR.20profiles/topic/IHE.20MHD.20profiles Zulip chat]. These issues will be solved in the R4 release of IHE MHD. We will likely make a pull request to address these issues for the STU3 release. .}}
 +
{{IssueBox|'''IHE.4''' The IHE StructureDefinitions restrict the use of the .created element. This is a known issue and will be addressed in the R4 release of the profiles. This issue (CP-ITI-1100) can be found on the [http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#FHIR_Implementation_Guide  IHE MHD wiki]. Therefore the indexed element is used to capture creation time.}}
 +
 
 +
=Annex: Document history=
 +
 
 +
==Release notes==
 +
Release notes can be found on the [[MedMij:V2018.06_Ontwerpen#Release_Notes| functional design main page]] of the MedMij information standards.
 +
 
 +
==History==
 +
{| class="wikitable" "cellpadding="10"
 +
!style="text-align:left;"|Version
 +
!style="text-align:left;"|Date
 +
!style="text-align:left;"|Description
 +
|-
 +
| style="background-color: white;"| 0.1.0
 +
| style="background-color: white;"| 10-12-2018
 +
| style="background-color: white;"|
 +
* Added concept version.
 +
|-
 +
| style="background-color: white;"| 0.2.0
 +
| style="background-color: white;"| 11-12-2018
 +
| style="background-color: white;"|
 +
* Added introduction text.
 +
|-
 +
| style="background-color: white;"| 0.3.0
 +
| style="background-color: white;"| 12-12-2018
 +
| style="background-color: white;"|
 +
* Added Boundaries and Relationships.
 +
* Added Client - PHR request.
 +
* Added Server - XIS response.
 +
* Added Server - XIS & XDS.
 +
|-
 +
| style="background-color: white;"| 0.4.0
 +
| style="background-color: white;"| 13-12-2018
 +
| style="background-color: white;"|
 +
* Added Media - DocumentReference mapping.
 +
|-
 +
| style="background-color: white;"| 0.5.0
 +
| style="background-color: white;"| 19-12-2018
 +
| style="background-color: white;"|
 +
* Added FHIR examples and StructureDefinitions.
 +
* Textual improvements.
 +
|-
 +
| style="background-color: white;"| 0.6.0
 +
| style="background-color: white;"| 28-12-2018
 +
| style="background-color: white;"|
 +
* Added FHIR examples and StructureDefinitions (Transaction Bundle and List profile).
 +
* Textual improvements.
 +
* Added and improved open issues with issue boxes.
 +
* Added an open public consultation issue box at the top of the page.
 +
* Moved releas notes to the functional design main page.
 +
|}

Versie van 7 jan 2019 13:35

{{#customtitle:MedMij FHIR Implementation Guide: Images 1.0.0}}

Issue icon.png

This version is obsolete - See current publication here.

Issue icon.png

These specifications are for public consultation from 10th of January to 21th of February. Open issues and questions are signaled with issue boxes like this one.

If you have any feedback, please submit it at https://bits.nictiz.nl/projects/MSIOC/

Naar medmij.nl
media
AfsprakenstelselFunctioneelTechnischAfspraken-Functioneel-Technisch

Introduction

Go to functional design

This page describes the exchange of images within MedMij. In contrary to other described use cases for MedMij no existing information standard fits nor are there specific ZIB models applicable. To achieve exchange of images, MedMij adopts as much as possible from existing standards, such as the DICOM standard and the Mobile access to Health Documents (MHD) profile from Integrating the Healthcare Enterprise (IHE) that defines a RESTful/HTTP interface to an XDS environment using HL7 FHIR STU3 resources.

The specification currently consists of one use case, that covers sending an image by a patient to a healthcare provider. Based on future research, a use case to retrieve images by the patient will be added. Most likely, this will be based on DICOMweb™, which is the DICOM standard for web-based medical imaging based on RESTful services.

Note: this page is part of the MedMij FHIR Implementation Guide and is a technical representation of the functional design published on this wiki page.

IHE MHD specification

Mobile access to Health Documents (MHD) profile defines a simple HTTP interface to an XDS like environment. The four described transactions leverage the document content and format agnostic metadata concepts from XDS but simplify them for access by constrained environments such as mobile devices, or other resource-constrained systems. The MHD profile does not replace XDS. It can be used to allow mobile devices, or other resource-constrained systems, access to an XDS health information exchange.[1]

Wiki: Mobile acces to Health Document (MHD)

Document: MHD Supplement (Rev 2.3 July 24, 2017)

Additional Supplement: Appendix Z on HL7 FHIR

Actors and transactions involved

Table 1 shows the relevant actors, systems and FHIR capability statements in a MedMij context. The capability statements demonstrate the minimum requirements to be conformant to the described use cases.

Persons Systems FHIR Capability Statements
Name Description Name Description Name Description
Patient The user of a personal healthcare environment. PHR Personal health record Verwijzing.png CapabilityStatement: Client Image FHIR Client requirements
Healthcare Provider The user of a XIS XIS Healthcare information system Verwijzing.png CapabilityStatement: Server Image FHIR Server requirements

Table 1. Actors, systems and FHIR capability statements

Table 2 shows the MHD actors and transactions in perspective of the systems used in a MedMij context.

Person System Role MHD Actors - for XDS MHD Transactions - for XDS
Patient PHR Sends image to the XIS Document Source Provide Document Bundle
Healthcare provider XIS Receives image from the PHR Document Recipient

Table 2. MHD actors and transactions in perspective of systems in a MedMij context

Boundaries and Relationships

The use case where an image is sent from a PHR to a XIS is influenced by the IHE MHD profile with regards to the PHR message semantics and mandatory elements. The specifications for this use case mainly deviates in the use of the FHIR Media resource instead of the DocumentReference resource. Although the DocumentResource is in line with the requirements of persisting content in a XDS network and the resource can handle images, the Media resource is more appropriate and specific for the exchange of images. The Media resource has additional, more specific, (medical related) elements compared to the DocumentReference. These are the Media's view, reasonCode, bodySite, device and to a lesser extent the height and width elements. In addition, the Media resource has a reference coming from the DiagnosticReport that may be of value for further development of the MedMij information standard for images.

A XIS can possibly act within a XDS network. The information standards in use by MedMij have the primary objective to enable standardized communication based on FHIR STU3. As a secondary objective, enabling exchange with XDS networks is taken into account. For this objective, the PHR will need to provide additional meta information to the Media resource. The additional meta information allows XIS actors to index an image properly within a XDS network. The XIS is responsible for converting the PHR message into a XDS DocumentEntry. A mapping from the Media resource to the mandatory metadata elements of the IHE MHD DocumentReference resource is provided. The IHE MHD and general IHE XDS profiles will provide the information needed to perform a successful DocumentEntry of an image.

Use case: send image from a PHR to a XIS

Go to Afsprakenstelsel

Introduction

This use case describes the minimal required technical functionalities in order to exchange an image made by the patient to a healthcare provider. Typical process flow would be:

  1. Patients makes, downloads or receives an image and uploads it to his PHR.
  2. The PHR sends the image to the chosen XIS system.
    1. Potentially the patient needs to provide sufficient metadata concerning the image.
  3. A healthcare provider views the image in his XIS.

This use case presumes made agreements between the patient and healthcare provider. Besides a technical answer by the XIS of the healthcare provider, no answer to the patient is expected.

The following technical specifications will concern the process mentioned at point 2.

Actors

Transaction group Transaction Actor Role
Send Image Bundle (PUSH) Send image bundle request Patient (using a PHR) Sends image to the XIS
Receive image bundle response Healthcare professional (using a XIS) Receives image from PHR

Invocations

This FHIR implementation guide assumes that the PHR system is able to make a connection to the right XIS that contains the patient's information. It does not provide information on finding the right XIS nor does it provide information about security. Moreover, each transaction is performed in the context of a specific authenticated patient, for whose context (token) has been established using the authentication mechanisms described in the 'Afsprakenstelsel'. Each XIS Gateway is required to perform filtering based on the patient associated with the context for the request, so only the records associated with the authenticated patient are returned. For this reason, search parameters should not be included for patient identification.

Client - PHR request

When the patient (PHR) wants to send one or more images, it issues a send image bundle request message.

The PHR initiate a FHIR transaction using a create action by sending an HTTP POST request composed of a FHIR Bundle Resource containing one or more FHIR Media resources, zero or more Binary resources and one patient resource to the XIS Recipient. References to the FHIR specification for the required transaction and POST requests are given in the interactions, operations and search parameters section below.

The PHR executes an HTTP POST against the XIS's base endpoint as shown below. 

POST [base] {?_format=[mime-type]}

The PHR shall assure all FHIR resource elements are consistent with the requirements specified in the StructureDefinitions for List, Media, Device, Patient, Practitioner and Organization resources. References to these StructureDefinitions are provided in list of StructureDefinitions.

Textual Requirements

  • The Bundle.type shall be transaction.
  • All Media.subject values shall be References to Patient resources and shall be included in the Bundle.
  • A List resource shall be used to group the images if a collection of images are sent.
  • Accompanying text from the patient for the image and/or collection of images shall be placed in the Media.note and List.note respectively.

Examples

Message components

Transaction Bundle

Server - XIS response

The XIS shall process the bundle atomically. If necessary for processing, the XIS shall retrieve resources referenced by absolute URLs in the FHIR Bundle Resource.

The XIS returns an HTTP Status code appropriate to the processing outcome, conforming to the transaction specification requirements as specified in the FHIR specification.

The XIS response message shall be sent when a success or error condition needs to be communicated. Success is only indicated once the image(s) is/are received and completely processed and persisted as appropriate to the XIS configuration.

To enable the PHR to know the outcome of processing the transaction, and the identities assigned to the resources by the XIS, the XIS shall return a Bundle, with type set to transaction-response, that contains one entry for each entry in the request, in the same order as received, with the Bundle.entry.response.outcome indicating the results of processing the entry. The XIS shall comply with FHIR Bundle transaction-response and the HTTP transaction-response specifications.

Server - XIS & XDS

If the receiving XIS is part of a XDS network, it will need to convert the PHR request message into a proper message for the IHE "Provide and Register Document Set-b [ITI-41]" transaction. The XIS shall create appropriate metadata from the resources in the FHIR Bundle. The PHR shall provide the minimally required metadata. A mapping is shown below to assist in the XDS entry. The FHIR Media resource is mapped to the mandatory elements in the IHE MHD Profile on "DocumentReference with Comprehensive (aka XDS-on-FHIR) Metadata". IHE MHD defined these elements as a minimum for a XDS DocumentEntry. The Media StructureDefinition contains a mapping to this profile and to XDS DocumentEntry, the List StructureDefinition contatins a mapping to the XDS 'Folder Metadata Attributes'. Some FHIR elements do not translate to XDS concepts; the handling of these elements is left to the implementer of the XIS.

Upon successful conversion of the FHIR Bundle to XDS metadata, the XIS shall execute the Provide and Register Document Set-b [ITI-41] transaction. The transaction result and any error or warning messages, shall be reported to the PHR. The XIS is responsible for translating the XDS response to the appropriate HTTP Status Code and FHIR OperationOutcome Resource in the Send Image Bundle Response Message.

Mapping Media to mandatory IHE MHD DocumentReference elements needed for XDS DocumentEntry

IHE MHD Profile on DocumentReference with Comprehensive (aka XDS-on-FHIR) Metadata Media for images, used by the PHR Implementation notes for XIS & XDS
DocumentReference.masterIdentifier Media.identifier
DocumentReference.status Fixed value "current".
DocumentReference.type Media.type Fixed LOINC code: 72170-4 Photographic image Unspecified body region Document.
DocumentReference.class Media.reasonCode If no reasonCode is present, a fixed LOINC code 72170-4 Photographic image Unspecified body region Document can be used.
DocumentReference.subject Media.subject
DocumentReference.indexed Media.occurrenceDateTime
DocumentReference.securityLabel Media.meta.security If no value is present 'normal' should be used as default.
DocumentReference.content Media.content
DocumentReference.content.attachment Media.content.attachment
DocumentReference.content.attachment.contentType Media.content.attachment.contentType Possible media content types: JPEG, PNG, GIF, JP2.
DocumentReference.content.attachment.url Media.content.attachment.url
DocumentReference.content.attachment.size Media.content.attachment.size
DocumentReference.content.attachment.hash Media.content.attachment.hash
DocumentReference.content.format Fixed value "mimeType Sufficient".

A number of fixed values can be used in indexing to a XDS network based on an image sent by a patient. These are status, type, security (if no value is given in the Media.meta.security element) and format. Below the technical representation of these fixed values is shown. 

<DocumentReference>
  ....
    <status value="current" />
  ....
    <type>
        <coding>
            <system value="http://loinc.org/" />
            <code value="72170-4" />
            <display value="Photographic image Unspecified body region Document" />
        </coding>     	
    </type>
  ....
    <securityLabel>
        <coding>
            <system value="http://hl7.org/fhir/v3/Confidentiality" />
            <code value="N" />
            <display value="normal" />
        </coding>
    </securityLabel>
  ....
    <format>
        <system value="urn:oid:1.3.6.1.4.1.19376.1.2.3"/>
        <code value="urn:ihe:iti:xds:2017:mimeTypeSufficient"/>
        <display value="mimeType Sufficient"/>
    </format>
  ....
</DocumentReference>

Issue icon.png

Images.1 Currently we mandate the PHR to provide identifiers for the Media and List, which should conform to the requirements of an identifier needed for a DocumentEntry. Should this be mandatory? Isn't this an element that a XIS should generate?

Issue icon.png

Images.2 Media Status. A DocumentReference has a status while Media does not in STU3. Within IHE MHD only the status values 'current' and 'superseded' are used. This in combination with a relatesTo element to indicate which document is superseded. This use case does not specify how to handle superseded images. Current scope is to exchange images witouth a status indicator. Could this be a problem for XDS networks?

Issue icon.png

Images.3 Is a 'normal' security code possible as default when no information is given by the patient?

Issue icon.png

Images.4 Does Media.reasonCode map to DocumentReference.class / XDS classCode? Do we need the patient to mandatory provide information for this concept? Does the fixed code suggestion fits if the patient does not provide information?

Issue icon.png

Images.5 The mapping table above only maps the mandatory elements from the DocumentReference profile. The StructureDefinitions Media en List contain all the mappings and is referenced above as well. However, should we expand this table here with additional and optional elements?

Interactions, operations, search parameters

Interactions

The following logical interactions are needed for this use case:

Operations

There are no defined operations for this use case.

Search parameters

There are no search parameters needed for this use case.

List of StructureDefinitions

MedMij StructureDefinitions

Name NL Name EN FHIR Resource URL profile
Patient Patient Patient http://fhir.nl/fhir/StructureDefinition/nl-core-patient
Zorgverlener HealthProfessional Practitioner http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner
Zorgaanbieder HealthcareProvider Organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization
Beeld Image Media http://nictiz.nl/fhir/StructureDefinition/images-Media
CollectieBeelden CollectionImages List http://nictiz.nl/fhir/StructureDefinition/images-List
MedischHulpmiddel.Product MedicalDevice.Product Device http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct

IHE MHD StructureDefinitions

IHE has defined StructureDefinitions and other Conformance resources applicable to this use case. The FHIR Implementation Guide on the IHE MHD wiki lists these StructureDefinitions.

Issue icon.png

IHE.1 Currently, we don't use or specify a profile that concerns the transaction request. (A profile like "IHE MHD profile on Provide Document Bundle (ITI-65) transaction with Comprehensive Metadata") Is such a profile nescessary? We don't use it in other MedMij use cases and the transaction bundle is described by the FHIR specification and textual in this use case.

Issue icon.png

IHE.2 The main reason the "IHE MHD Profile on List (Folder)" is not used, is because it mandates the use of .title and .code which likely contains information a patient needs to enter manually. As we would like to keep the burden on patients as low as possible a custom profile of list is used without these mandatory elements. Additionally, one of the benefits is that we can use references to our own profiles.

Issue icon.png

IHE.3 The IHE StructureDefinitions contain a number of errors, mentioned in this Zulip chat. These issues will be solved in the R4 release of IHE MHD. We will likely make a pull request to address these issues for the STU3 release. .

Issue icon.png

IHE.4 The IHE StructureDefinitions restrict the use of the .created element. This is a known issue and will be addressed in the R4 release of the profiles. This issue (CP-ITI-1100) can be found on the IHE MHD wiki. Therefore the indexed element is used to capture creation time.

Annex: Document history

Release notes

Release notes can be found on the functional design main page of the MedMij information standards.

History

Version Date Description
0.1.0 10-12-2018
  • Added concept version.
0.2.0 11-12-2018
  • Added introduction text.
0.3.0 12-12-2018
  • Added Boundaries and Relationships.
  • Added Client - PHR request.
  • Added Server - XIS response.
  • Added Server - XIS & XDS.
0.4.0 13-12-2018
  • Added Media - DocumentReference mapping.
0.5.0 19-12-2018
  • Added FHIR examples and StructureDefinitions.
  • Textual improvements.
0.6.0 28-12-2018
  • Added FHIR examples and StructureDefinitions (Transaction Bundle and List profile).
  • Textual improvements.
  • Added and improved open issues with issue boxes.
  • Added an open public consultation issue box at the top of the page.
  • Moved releas notes to the functional design main page.
Overgenomen van "https://informatiestandaarden.test-nictiz.nl/index.php?title=MedMij:V2018.06_FHIR_Images&oldid=17243"