MedMij:V2020.01/FHIR Images: verschil tussen versies

Uit informatiestandaarden
Ga naar: navigatie, zoeken
k (Tekst vervangen - "{{VersieInfo\|([^\|]+)\|release=Vprepub}}" door "{{VersieInfo|$1}}")
k (Beveiligde "MedMij:V2020.01/FHIR Images": Protect production page from accidental edits ([Bewerken=Alleen beheerders toestaan] (vervalt niet) [Hernoemen=Alleen beheerders toestaan] (vervalt niet)))
 
(23 tussenliggende versies door 4 gebruikers niet weergegeven)
Regel 6: Regel 6:
 
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch   
 
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch   
 
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]                 
 
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]                 
−
circle 1013 224 212 [[MedMij:Vprepub/OntwerpBeelden|Functioneel]]                 
+
circle 1013 224 212 [[MedMij:V2020.01/OntwerpBeelden|Functioneel]]                 
−
circle 1787 230 212 [[MedMij:Vprepub/FHIR_IG|Technisch]]                 
+
circle 1787 230 212 [[MedMij:V2020.01/FHIR_IG|Technisch]]                 
 
desc none                     
 
desc none                     
 
</imagemap>
 
</imagemap>
Regel 14: Regel 14:
  
 
=Introduction=
 
=Introduction=
−
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub/Ontwerpen |100px|rechts|Functional design|Go to functional design]]
+
[[Bestand:Functioneel-02.png|link=MedMij:V2020.01/Ontwerpen |100px|rechts|Functional design|Go to functional design]]
  
 
This page describes the exchange of images within MedMij. Contrary to other MedMij use cases, we have not identified an existing information standard nor any specifically applicable HCIM<sup style="font-weight: bold;" title="Health and Care Information Model or Zorginformatiebouwstenen (zibs)">?</sup> models. To achieve exchange of images, MedMij adopts as much as possible from existing standards, such as the DICOM standard and the [http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD) 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.
 
This page describes the exchange of images within MedMij. Contrary to other MedMij use cases, we have not identified an existing information standard nor any specifically applicable HCIM<sup style="font-weight: bold;" title="Health and Care Information Model or Zorginformatiebouwstenen (zibs)">?</sup> models. To achieve exchange of images, MedMij adopts as much as possible from existing standards, such as the DICOM standard and the [http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD) 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.
Regel 22: Regel 22:
 
The specification currently consists of one use case, that covers sending an image by a patient to a healthcare provider. We anticipate adding a use case to retrieve images by the patient in a future version of this specification. This will most likely will be based on DICOMweb™, which is the DICOM standard for web-based medical imaging based on RESTful services.
 
The specification currently consists of one use case, that covers sending an image by a patient to a healthcare provider. We anticipate adding a use case to retrieve images by the patient in a future version of this specification. This will most likely 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:Vprepub/FHIR_IG MedMij FHIR Implementation Guide] and is a technical representation of its [[MedMij:Vprepub/Ontwerpen|functional design]].
+
'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:V2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].
  
 
=Actors and transactions involved=
 
=Actors and transactions involved=
Regel 95: Regel 95:
 
When the patient (PHR) wants to send one or more images, it issues a send image bundle request message.
 
When the patient (PHR) wants to send one or more images, it issues a send image bundle request message.
  
−
The PHR initiates a FHIR transaction using a create action by sending an HTTP POST request composed of a FHIR Bundle Resource containing one List resource, one or more FHIR Media resources, one or more Binary resources, one Patient resource, and zero or one Practitioner 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 initiates a [https://www.hl7.org/fhir/stu3/http.html#transaction FHIR transaction] by sending an HTTP POST request composed of a FHIR Bundle Resource containing one List resource, one or more FHIR Media resources, one or more Binary resources, one Patient resource, and zero or one Practitioner resource to the XIS recipient.
  
 
The PHR executes an HTTP POST against the XIS's base endpoint as shown below.
 
The PHR executes an HTTP POST against the XIS's base endpoint as shown below.
  
 
<pre>
 
<pre>
−
POST [base] {?_format=[mime-type]}
+
POST [base]
 
</pre>
 
</pre>
  
−
The PHR shall guarantee consistency of all FHIR resource elements with the requirements specified in the StructureDefinitions for List, Media, Patient, Practitioner, PractitionerRole and Organization resources. References to these StructureDefinitions are provided in [[#List_of_StructureDefinitions|list of StructureDefinitions]].
+
The PHR shall guarantee consistency of all FHIR resource elements with the requirements specified in the profiles for List, Media, Patient, Practitioner, PractitionerRole and Organization resources. References to these profiles are provided in [[#List_of_StructureDefinitions|list of StructureDefinitions]].
  
 
==== Textual Requirements ====
 
==== Textual Requirements ====
Regel 111: Regel 111:
 
* The Bundle contains one List resource that has one to three references to a Media resource.
 
* The Bundle contains one List resource that has one to three references to a Media resource.
  
−
* The Media.content.attachment.url points at the image content, which shall be included 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:Vprepub/FHIR_IG#Use_of_the_reference_datatype MedMij Use case overarching principles].
+
* The Media.content.attachment.url points at the image content, which shall be included 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 [[MedMij:V2020.01/FHIR_IG#Use_of_the_reference_datatype|MedMij Use case overarching principles]].
  
 
* The Media has one version specific identifier. This identifier is discriminated from potential other identifiers by a fixed 'official' value at identifier.use.  
 
* The Media has one version specific identifier. This identifier is discriminated from potential other identifiers by a fixed 'official' value at identifier.use.  
Regel 118: Regel 118:
  
 
* Accompanying text from the patient for the image and/or collection of images shall be placed in the Media.note and List.note respectively.
 
* 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 ===
 
−
{{Sjabloon:Voorbeelden}}
 
  
 
=== Server - XIS response ===
 
=== Server - XIS response ===
Regel 129: Regel 126:
  
 
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.
 
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.
−
 
−
==== Handling errors ====
 
−
A client may use the returned Bundle to track the outcomes of processing the entries, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entries - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.
 
−
 
−
When the resource syntax or data is incorrect or invalid, and cannot be used to create a new resource, the server returns a 400 Bad Request HTTP status code. When the server rejects the content of the resource because of business rules, the server returns a 422 Unprocessable Entity error HTTP status code. In either case, the server SHOULD include a response body containing an OperationOutcome with detailed error messages describing the reason for the error.
 
−
 
−
Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues):
 
−
 
−
* 400 Bad Request - resource could not be parsed or failed basic FHIR validation rules.
 
−
* 404 Not Found - resource type not supported, or not a FHIR end-point.
 
−
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an OperationOutcome resource providing additional detail.
 
−
 
−
Read more:
 
−
[http://hl7.org/fhir/STU3/http.html#create create]
 
−
[http://hl7.org/fhir/STU3/http.html#transaction transaction]
 
  
 
=== Server - XIS & XDS ===
 
=== Server - XIS & XDS ===
 
{{NoteBox|This non-normative section provides advice for receiving XIS actors that want to persist images in an XDS network. MedMij information standards concern the exchange of healthcare information between PHR and XIS systems that act within the MedMij network. The possible backend of those systems is out of scope for the normative section of the information standard.}}
 
{{NoteBox|This non-normative section provides advice for receiving XIS actors that want to persist images in an XDS network. MedMij information standards concern the exchange of healthcare information between PHR and XIS systems that act within the MedMij network. The possible backend of those systems is out of scope for the normative section of the information standard.}}
  
−
If the receiving XIS is part of a XDS network, it may 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 provides the minimally required metadata. A mapping is shown below to assist in creating 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 and List StructureDefinition, provided in the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub/FHIR_Images#List_of_StructureDefinitions list of StructureDefinitions], contain mappings to a XDS DocumentEntry and XDS Folder Metadata Attributes respectively. Some FHIR elements do not translate to XDS concepts; the handling of these elements is left to the implementer of the XIS.
+
If the receiving XIS is part of a XDS network, it may 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 provides the minimally required metadata. A mapping is shown below to assist in creating 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 and List profiles, provided in the [[#List_of_StructureDefinitions|list of StructureDefinitions]], contain mappings to a XDS DocumentEntry and XDS Folder Metadata Attributes respectively. 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.
 
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.
Regel 219: Regel 201:
  
 
====IHE MHD StructureDefinitions====
 
====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 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
+
However, due to errors encountered, that IHE did not intend to fix in STU3, Nictiz has fixed the errors and re-published the IHE.MHD profiles in the Nictiz namespace. Note that IHE originally created two profiles, one for Query DocumentReference and one for Provide DocumentReference which are identical to each other. For usability purposes, these two profiles have been merged.
−
** Canonical URL: {{Simplifier|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
+
* {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Minimal.ProvideDocumentBundle|nictiz.fhir.nl.stu3.zib2017}}
−
** Canonical URL: {{Simplifier| http://ihe.net/fhir/StructureDefinition/IHE.MHD.Provide.Comprehensive.DocumentReference}}
+
* {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.List|nictiz.fhir.nl.stu3.zib2017}}  
−
 
+
* {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest|nictiz.fhir.nl.stu3.zib2017}}
−
==Interactions, operations, search parameters==
+
* {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Minimal.DocumentReference|nictiz.fhir.nl.stu3.zib2017|nictiz.fhir.nl.stu3.zib2017}})
−
 
 
−
===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==
 
==List of StructureDefinitions==
−
{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:Vprepub/FHIR_IG}}
+
{{MedMij:V2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.images|v1Min=1.0.0|p2=nictiz.fhir.nl.stu3.zib2017|v2Min=2.0.0}}
  
 
{| class="wikitable" width="1400px"
 
{| class="wikitable" width="1400px"
Regel 277: Regel 247:
 
|-
 
|-
 
|}
 
|}
−
{{Sjabloon:Voorbeelden}}
 
  
 
=Release notes=
 
=Release notes=
−
Release notes can be found on the [[MedMij:Vprepub/OntwerpBeelden#Release_notes|functional design page]].
+
Release notes can be found on the [[MedMij:V2020.01/OntwerpBeelden#Release_notes|functional design page]].
 +
 
 +
{{MedMij:Sjabloon_Support}}

Huidige versie van 19 nov 2024 om 16:20


Naar medmij.nl
media
AfsprakenstelselFunctioneelTechnischAfspraken-Functioneel-Technisch

1 Introduction

Go to functional design

This page describes the exchange of images within MedMij. Contrary to other MedMij use cases, we have not identified an existing information standard nor any specifically applicable HCIM? models. 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.

Em.png

This specification builds off IHE MHD which usually serves as an IHE XDS compatible frontend. However having an XDS network on either sending or receiving side is not a requirement per this specification.

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

Note: This implementation guide builds on the general guidelines described in the use case overarching principles.

2 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 in conformance with 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

3 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 main deviation of these use-case specifications is the use of the FHIR Media resource instead of the DocumentReference resource. Although the DocumentReference is in line with the requirements of persisting content in an XDS network and the DocumentReference can handle images, the Media resource is more appropriate and specific for the exchange of images. The Media resource has additional, relevant, (medical related) elements compared to the DocumentReference. These are the Media elements 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. MedMij information standards have the primary objective to enable standardized communication between the parties that act within MedMij. As a secondary objective, exchange with parties that are part of a XDS networks are 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 produce a successful DocumentEntry for an image.

4 Use case: send image from a PHR to a XIS

Go to Afsprakenstelsel

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.

4.1 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 creates, downloads or receives an image and uploads it to his PHR.
  2. The PHR sends the image to the chosen XIS system.
    • 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 in bullet 2.

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

4.3 Invocations

4.3.1 Client - PHR request

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

The PHR initiates a FHIR transaction by sending an HTTP POST request composed of a FHIR Bundle Resource containing one List resource, one or more FHIR Media resources, one or more Binary resources, one Patient resource, and zero or one Practitioner resource to the XIS recipient.

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

POST [base]

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

4.3.1.1 Textual Requirements

  • The Bundle.type shall be 'transaction'.
  • The Bundle contains one List resource that has one to three references to a Media resource.
  • The Media has one version specific identifier. This identifier is discriminated from potential other identifiers by a fixed 'official' value at identifier.use.
  • Referenced Resources (for example Patient, Practitioner and PractitionerRole) shall be included in the Bundle.
  • Accompanying text from the patient for the image and/or collection of images shall be placed in the Media.note and List.note respectively.

4.3.2 Server - XIS response

The XIS shall process the bundle atomically.

4.3.2.1 Response message

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) and accompanying resources are received and completely processed and persisted as appropriate to the XIS configuration. The XIS returns an HTTP Status code appropriate to the processing outcome, conforming to the transaction specification requirements as specified in the FHIR specification.

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.

4.3.3 Server - XIS & XDS

Em.png

This non-normative section provides advice for receiving XIS actors that want to persist images in an XDS network. MedMij information standards concern the exchange of healthcare information between PHR and XIS systems that act within the MedMij network. The possible backend of those systems is out of scope for the normative section of the information standard.

If the receiving XIS is part of a XDS network, it may 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 provides the minimally required metadata. A mapping is shown below to assist in creating 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 and List profiles, provided in the list of StructureDefinitions, contain mappings to a XDS DocumentEntry and XDS Folder Metadata Attributes respectively. 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.

4.3.3.1 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 and identifier.use = 'official'
DocumentReference.status Fixed value "current".
DocumentReference.type Media.type Fixed LOINC code: 72170-4 Photographic image Unspecified body region Document.
DocumentReference.class Fixed SNOMED code: 9491000146107 - Imaging documentation (record artifact).
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, class, security (if no value is given in the Media.meta.security element) and format.

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

However, due to errors encountered, that IHE did not intend to fix in STU3, Nictiz has fixed the errors and re-published the IHE.MHD profiles in the Nictiz namespace. Note that IHE originally created two profiles, one for Query DocumentReference and one for Provide DocumentReference which are identical to each other. For usability purposes, these two profiles have been merged.

4.4 List of StructureDefinitions

Em.png

MedMij uses the FHIR Packaging mechanism. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:

Note: packages use Semantic Versioning. Other versions can be used at will as long as they have the same major.minor number or a minor number higher than the stated version.

HCIM NL / Concept HCIM EN / Concept 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
PractitionerRole http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole
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

5 Release notes

Release notes can be found on the functional design page.


6 Support

For questions and change requests regarding the information on this page, please create a ticket in Servicedesk Portal.

Overgenomen van "https://informatiestandaarden.nictiz.nl/index.php?title=MedMij:V2020.01/FHIR_Images&oldid=234309"