MedMij:Vprepub-2020.01/FHIR PDFA: verschil tussen versies

Uit informatiestandaarden
Naar navigatie springen Naar zoeken springen
(MM-3500: Added known issue w.r.t. unused profiles)
 
(25 tussenliggende versies door 4 gebruikers niet weergegeven)
Regel 1: Regel 1:
 
__NUMBEREDHEADINGS__
 
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide: PDF/A {{VersieInfo|Vprepub|PDFA}}}}
+
{{DISPLAYTITLE:MedMij FHIR Implementation Guide: PDF/A {{VersieInfo|PDFA}}}}
{{MedMij:Vprepub/Issuebox_FHIR_IG}}
+
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}
  
 
[[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 7: Regel 7:
 
<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/OntwerpPDFA|Functioneel]]                 
+
circle 1013 224 212 [[MedMij:Vprepub-2020.01/OntwerpPDFA|Functioneel]]                 
circle 1787 230 212 [[MedMij:Vprepub/FHIR_IG|Technisch]]                 
+
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]                 
 
desc none                     
 
desc none                     
 
</imagemap>
 
</imagemap>
Regel 15: Regel 15:
  
 
=Introduction=
 
=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub/Ontwerpen |100px|rechts|Functional design|Go to functional design]]
+
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/Ontwerpen |100px|rechts|Functional design|Go to functional design]]
 
MedMij specifies the format [http://www.pdfa.org/publication/pdfa-in-a-nutshell-2-0/ PDF/A] for exchanging unstructured documents containing health information. Forum Standaardisatie is a Dutch governmental organization that aims to stimulate the use of open standards. PDF/A is one of the standards that is recommended by Forum Standaardisatie. More information regarding PDF/A can be found here: https://www.forumstandaardisatie.nl/standaard/pdf-nen-iso.  
 
MedMij specifies the format [http://www.pdfa.org/publication/pdfa-in-a-nutshell-2-0/ PDF/A] for exchanging unstructured documents containing health information. Forum Standaardisatie is a Dutch governmental organization that aims to stimulate the use of open standards. PDF/A is one of the standards that is recommended by Forum Standaardisatie. More information regarding PDF/A can be found here: https://www.forumstandaardisatie.nl/standaard/pdf-nen-iso.  
  
Regel 21: Regel 21:
  
 
When implementing PDF/A, a minimum compliance must be assumed. That is, PDF/A-1 and PDF/A-b is also permitted within this. For more information, see the wiki page on this: https://en.wikipedia.org/wiki/PDF/A#Conformance_levels_and_versions
 
When implementing PDF/A, a minimum compliance must be assumed. That is, PDF/A-1 and PDF/A-b is also permitted within this. For more information, see the wiki page on this: https://en.wikipedia.org/wiki/PDF/A#Conformance_levels_and_versions
 +
 +
'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].
  
 
===IHE MHD specification===
 
===IHE MHD specification===
Regel 57: Regel 59:
 
| PHR
 
| PHR
 
| Personal health record
 
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/pdfa-clientcapabilities|CapabilityStatement: Client}}
+
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/pdfa-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
 
| PDFA FHIR Client requirements  
 
| PDFA FHIR Client requirements  
 
|-
 
|-
Regel 64: Regel 66:
 
| XIS
 
| XIS
 
| Healthcare information system
 
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/pdfa-servercapabilities|CapabilityStatement: Server}}
+
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/pdfa-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
 
| PDFA FHIR Server requirements  
 
| PDFA FHIR Server requirements  
 
|}  
 
|}  
Regel 107: Regel 109:
  
 
=Use case: Find and retrieve existing PDF/A document(s)=
 
=Use case: Find and retrieve existing PDF/A document(s)=
 +
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
 +
{{FHIR-IG-Afsprakenstelsel-Note}}
  
 
==Introduction==
 
==Introduction==
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
 
 
This section summarizes the IHE MHD profile to find and retrieve PDF/A documents in a MedMij context.  
 
This section summarizes the IHE MHD profile to find and retrieve PDF/A documents in a MedMij context.  
 
{{FHIR-IG-Afsprakenstelsel-Note}}
 
  
 
==Actors and transactions involved==
 
==Actors and transactions involved==
Regel 132: Regel 133:
 
| PHR
 
| PHR
 
| Personal health record
 
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/pdfa-clientcapabilities|CapabilityStatement: Client}}
+
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/pdfa-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
 
| PDFA FHIR Client requirements  
 
| PDFA FHIR Client requirements  
 
|-
 
|-
Regel 139: Regel 140:
 
| XIS
 
| XIS
 
| Healthcare information system
 
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/pdfa-servercapabilities|CapabilityStatement: Server}}
+
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/pdfa-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
 
| PDFA FHIR Server requirements  
 
| PDFA FHIR Server requirements  
 
|}  
 
|}  
Regel 150: Regel 151:
 
! style="font-weight: bold; text-align:left;" | MHD Actors
 
! style="font-weight: bold; text-align:left;" | MHD Actors
 
! style="font-weight: bold; text-align:left;" | MHD Transactions
 
! style="font-weight: bold; text-align:left;" | MHD Transactions
 +
! style="font-weight: bold; text-align:left;" | Optionallity
 
|-
 
|-
 
| rowspan="5" | Patient
 
| rowspan="5" | Patient
Regel 157: Regel 159:
 
| rowspan="3" | Document Consumer
 
| rowspan="3" | Document Consumer
 
| Find Document Manifest
 
| Find Document Manifest
 +
| Optional
 
|-
 
|-
 
| Find Document Reference
 
| Find Document Reference
 +
| Required
 
|-
 
|-
 
| Retrieve Document
 
| Retrieve Document
 +
| Required
 
|-
 
|-
 
| rowspan="5" | Healthcare provider
 
| rowspan="5" | Healthcare provider
Regel 168: Regel 173:
 
| rowspan="3" | Document Responder
 
| rowspan="3" | Document Responder
 
| Find Document Manifest
 
| Find Document Manifest
 +
| Optional
 
|-
 
|-
 
| Find Document Reference
 
| Find Document Reference
 +
| Required
 
|-
 
|-
 
| Retrieve Document
 
| Retrieve Document
 +
| Required
 
|}
 
|}
<font size = "1">'''Table 2. MHD actors and transactions in perspective of systems in a MedMij context'''</font>
+
<font size = "1">'''Table 2. MHD actors and transactions in perspective of systems in a MedMij context''' </font>
 
 
===Transactions in scope===
 
 
 
* Find Document Manifests – This transaction is used to issue parameterized queries that result in a list of Document Manifest resources.
 
* Find Document References – This transaction is used to issue parameterized queries that produce a list of Document Reference resources.
 
* Retrieve Document – This transaction is used to get documents.
 
 
 
Document Consumer shall implement at least one transaction: Find Document Manifests, Find Document References, or Retrieve Document. Document Responder shall implement all transactions.
 
  
===Transactions out of scope===
+
Implementation of the 'Find Document Reference' and 'Retrieve Document' transactions are required. The 'Find Document Manifest' transaction is optional for both the Document Consumer and Document Responder.
The MHD profile specifies how to send documents from a Document Source to a Document Receiver using the Provide Document Bundle transaction. However, sending PDF/A documents is currently out of scope for the MedMij context. The 'Afsprakenstelsel' first focuses on pulling data from a XIS to a PHR before considering push transactions. In the future, specifications of sending PDF/A documents from a PHR will be added.
 
  
 
==Find and retrieve existing PDF/A document(s)==
 
==Find and retrieve existing PDF/A document(s)==
Regel 196: Regel 195:
 
'''Search'''
 
'''Search'''
  
The Document Consumer executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTfull] and [http://hl7.org/fhir/search.html search] specification. A search query would have the following format.
+
The Document Consumer executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTful] and [http://hl7.org/fhir/search.html search] specification. A search query would have the following format.
 
   
 
   
 
<pre>
 
<pre>
GET [base]DocumentReference?[parameters]{&_format=[mime-type]}
+
GET [base]/DocumentReference?status=[status]{&[parameters]}
GET [base]DocumentManifest?[parameters]{&_format=[mime-type]}
+
GET [base]/DocumentManifest?status=[status]{&[parameters]}
 
</pre>
 
</pre>
  
Example query to search for DocumentReferences of type Discharge summary with a current status.
+
An example query to search for DocumentReferences which have status "''current''" and which are indexed/created after 01-01-2010:
<pre>GET http://example.org/fhir/DocumentReference?type=http://loinc.org|18842-5&status=current</pre>
+
<pre>GET [base]/DocumentReference?status=current&indexed=ge2010-01-01</pre>
  
 
'''Search Parameters'''
 
'''Search Parameters'''
Regel 220: Regel 219:
 
| style="font-weight: bold;" | Description
 
| style="font-weight: bold;" | Description
 
|-
 
|-
| indexed
+
| <code>indexed</code>
 
| date
 
| date
 
| When this document reference was created
 
| When this document reference was created
| created
+
| <code>created</code>
 
| date
 
| date
 
| When this document manifest created
 
| When this document manifest created
 
|-
 
|-
| status
+
| <code>status</code>
 
| token
 
| token
 
| current / superseded  
 
| current / superseded  
| status
+
| <code>status</code>
 
| token
 
| token
 
| current / superseded
 
| current / superseded
Regel 236: Regel 235:
  
 
====Response message====
 
====Response message====
The Document Responder shall process the query to discover the DocumentReference or DocumentManifest entries that match the search parameters given. The Document Responder returns an HTTP Status code appropriate to the processing as well as a Bundle including the matching DocumentReference or DocumentManifest Resources. When the Document Responder needs to report an error or warning, it shall use HTTP error response codes and should include a FHIR [http://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome] with more details on the failure or warning. If the request message is processed successfully, whether or not any DocumentReference or DocumentManifest Resources are found, the HTTP status code shall be 200.  
+
The Document Responder shall process the query to discover the DocumentReference or DocumentManifest entries that match the search parameters given. The Document Responder returns an HTTP Status code appropriate to the processing as well as a Bundle including the matching DocumentReference or DocumentManifest Resources.  
  
 
* The Document Responder shall place into the ''''DocumentReference.content.attachment.url'''' element a full URL that can be used by the Document Consumer to retrieve the document using Retrieve Document transaction.
 
* The Document Responder shall place into the ''''DocumentReference.content.attachment.url'''' element a full URL that can be used by the Document Consumer to retrieve the document using Retrieve Document transaction.
 
** The Document Responder shall only include references which are resolved through the Document Responder to maintain control over the authentication and authorization. The Document Responder shall only serve DocumentReference or DocumentManifest resources that contain a reference which the Document Consumer may resolve.
 
** The Document Responder shall only include references which are resolved through the Document Responder to maintain control over the authentication and authorization. The Document Responder shall only serve DocumentReference or DocumentManifest resources that contain a reference which the Document Consumer may resolve.
 
* The Document Responder shall return only PDF/A documents and shall place into the ''''DocumentReference.content.attachment.contentType'''' element the value 'application/pdf'.
 
* The Document Responder shall return only PDF/A documents and shall place into the ''''DocumentReference.content.attachment.contentType'''' element the value 'application/pdf'.
 
'''Example of a response message'''
 
 
Example of a Bundle with 11 DocumentReference Resources. Only the first DocumentReference is displayed.
 
 
<pre>
 
<Bundle xmlns="http://hl7.org/fhir">
 
    <id value="c0beb362-efc7-4cb9-b35a-c6cea0742156" />
 
    <meta>
 
        <versionId value="1498fcb4-af9c-404f-b445-e6634619df55" />
 
        <lastUpdated value="2017-10-25T11:25:00.336+00:00" />
 
    </meta>
 
    <type value="searchset" />
 
    <total value="11" />
 
    <link>
 
        <relation value="self" />
 
        <url value="http://vonk.furore.com/DocumentReference?status=current" />
 
    </link>
 
    <entry>
 
        <fullUrl value="http://vonk.furore.com/DocumentReference/c4f22730-bb5a-4f12-b4ef-c7bde0784426" />
 
        <resource>
 
            <DocumentReference xmlns="http://hl7.org/fhir">
 
                <id value="example-pdfa-documentreference2" />
 
                <meta>
 
                    <profile value="http://ihe.net/fhir/StructureDefinition/IHE.MHD.Query.Minimal.DocumentReference"/>
 
                </meta>
 
                <contained>
 
                    <Practitioner>
 
                        <id value="p1"/>
 
                        <name>
 
                            <family value="Kneder"/>
 
                            <given value="B.">
 
                                <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier">
 
                                    <valueCode value="IN"/>
 
                                </extension>
 
                            </given>
 
                        </name>
 
                    </Practitioner>
 
                </contained>
 
                <masterIdentifier>
 
                    <system value="urn:ietf:rfc:3986" />
 
                    <value value="urn:oid:1.2.276.0.7230010.3.1.2.1787205428.3024.1522314975.220899" />
 
                </masterIdentifier>
 
                <identifier>
 
                    <system value="http://example-xis.org/fhir/NamingSystem/DocumentReferenceID"/>
 
                    <value value="963369"/>
 
                </identifier>
 
                <status value="current" />
 
                <type>
 
                    <coding>
 
                        <system value="http://loinc.org/" />
 
                        <code value="34781-5" />
 
                        <display value="Infectious disease Consult note" />
 
                    </coding>
 
                </type>
 
                <class>
 
                    <coding>
 
                        <system value="http://loinc.org/" />
 
                        <code value="11488-4" />
 
                        <display value="Consult Note" />
 
                    </coding>       
 
                </class>
 
                <subject>
 
                    <reference value="Patient/example-pdfa-kwalificatie1" />
 
                </subject>
 
                <indexed value="2017-04-08T15:26:01+01:00" />
 
                <author>
 
                    <reference value="#p1" />
 
                </author>
 
                <description value="Infectious disease Consult note" />
 
                <securityLabel>
 
                    <coding>
 
                        <system value="http://hl7.org/fhir/v3/Confidentiality" />
 
                        <code value="V" />
 
                        <display value="very restricted" />
 
                    </coding>
 
                </securityLabel>
 
                <content>
 
                    <attachment>
 
                        <contentType value="application/pdf" />
 
                        <language value="en" />
 
                        <url value="http://example-test-server.org/fhir/Binary/example-pdfa-binary2" />
 
                        <title value="Example PDF - Infectious disease Consult note"/>
 
                    </attachment>
 
                </content>
 
            </DocumentReference>
 
        </resource>
 
        <search>
 
            <mode value="match" />
 
        </search>
 
    </entry>
 
    .......
 
    </pre>
 
  
 
===Retrieve PDF/A document===
 
===Retrieve PDF/A document===
Regel 349: Regel 255:
 
The Document Responder shall process the request message. The Document Responder returns an HTTP Status code appropriate to the processing as well as the content of the requested PDF/A document in the HTTP message-body.  
 
The Document Responder shall process the request message. The Document Responder returns an HTTP Status code appropriate to the processing as well as the content of the requested PDF/A document in the HTTP message-body.  
  
The document may be placed inside a FHIR [http://hl7.org/fhir/STU3/binary.html Binary] resource if it is useful to handle pure binary content using the same framework as other resources. Binary resources behave slightly differently from all other resources on the RESTful API. Specifically, when a read request is made for the binary resource that doesn't explicitly specify the FHIR content types "application/fhir+xml" or "application/fhir+json", then the content should be returned using the content type stated in the resource. e.g. if the content type in the resource is "application/pdf", then the content should be returned as a PDF directly.[http://hl7.org/fhir/STU3/binary.html#rest]  
+
The document may be placed inside a FHIR [http://hl7.org/fhir/STU3/binary.html Binary] resource if it is useful to handle pure binary content using the same framework as other resources. Binary resources behave slightly differently from all other resources on the RESTful API. Specifically, when a read request is made for the binary resource that doesn't explicitly specify the FHIR content types "application/fhir+xml" or "application/fhir+json", then the content should be returned using the content type stated in the resource. e.g. if the content type in the resource is "application/pdf", then the content should be returned as a PDF directly.[http://hl7.org/fhir/STU3/binary.html#rest]
  
When the Document Responder needs to report an error or warning, it shall use HTTP error response codes and should include a [http://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome] with more details on the failure or warning. If the Retrieve Document message is processed successfully the HTTP status code shall be 200.
+
==List of profiles==
 +
IHE has defined profiles 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 conformance resources.
  
'''Example of a response message'''
+
Due to errors encountered when creating the send use case, 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.
<pre><Binary>
 
  <id value="1e404af3-077f-4bee-b7a6-a9be97e1ce32" />
 
  <meta>
 
    <versionId value="948f3653-c9a3-4831-bae5-f629319c194f" />
 
    <lastUpdated value="2017-09-20T17:55:14.098+00:00" />
 
  </meta>
 
  <contentType value="application/pdf" />
 
  <content value="JVBERi0xLjUNJeLjz9MNCjU1I........"/> 
 
</Binary></pre>
 
  
==Interactions, operations, search parameters==
+
Find and retrieve existing PDF/A document transaction uses the following profiles:
  
===Interactions===
+
* DocumentReference from Query with Minimal Metadata (canonical URL {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Minimal.DocumentReference|nictiz.fhir.nl.stu3.zib2017}})
The following logical interactions are needed for this use case:
+
* DocumentManifest (canonical URL {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest|nictiz.fhir.nl.stu3.zib2017}})
* [http://hl7.org/fhir/STU3/http.html#search Search]
 
* [http://hl7.org/fhir/STU3/http.html#read Read]
 
  
===Operations===
+
{{IssueBox|The IHE profiles 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.}}
There are no defined operations for this use case.
 
  
===Search parameters===
+
The complete set of used profiles for the response message is listed in the table below.
The following search parameter types need to be supported for this use case. No search result parameters need to be supported.
 
  
Search parameter types:
+
{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}
* [http://hl7.org/fhir/STU3/search.html#token token]
 
* [http://hl7.org/fhir/STU3/search.html#reference reference]
 
* [http://hl7.org/fhir/STU3/search.html#date date]
 
* [http://hl7.org/fhir/STU3/search.html#uri uri]
 
 
 
==List of 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.
 
 
 
Find and retrieve existing PDF/A document transaction uses the following StructureDefinitions:
 
 
 
* DocumentReference from Query with Minimal Metadata (canonical URL {{Simplifier|http://ihe.net/fhir/StructureDefinition/IHE.MHD.Query.Minimal.DocumentReference}})
 
* DocumentManifest (canonical URL {{Simplifier|http://ihe.net/fhir/StructureDefinition/IHE.MHD.DocumentManifest}})
 
 
 
* Optionally: DocumentReference from Query with Comprehensive Metadata (canonical URL: {{Simplifier|http://ihe.net/fhir/StructureDefinition/IHE.MHD.Query.Comprehensive.DocumentReference}}). This StructureDefinition has more mandatory field compared to Minimal Metadata and is used for XDS environments.
 
 
 
{{IssueBox|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.}}
 
 
 
Next to the IHE MHD StructureDefinitions, MedMij uses the following HCIM StructureDefinitions for the response message.
 
 
 
{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:Vprepub/FHIR_IG}}
 
  
 
{| class="wikitable" width="1400px"
 
{| class="wikitable" width="1400px"
Regel 407: Regel 281:
 
| #Zib Patient|Patient
 
| #Zib Patient|Patient
 
| Patient
 
| Patient
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient}}
+
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
 
| Zorgverlener
 
| Zorgverlener
 
| HealthProfessional
 
| HealthProfessional
 
| Practitioner
 
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner}}
+
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
 
| Zorgaanbieder
 
| Zorgaanbieder
 
| HealthcareProvider
 
| HealthcareProvider
 
| Organization
 
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization}}
+
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
 
| -
 
| -
 
| -
 
| -
 
| DocumentManifest
 
| DocumentManifest
| {{Simplifier|http://ihe.net/fhir/StructureDefinition/IHE.MHD.DocumentManifest}}
+
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
 
| -
 
| -
 
| -
 
| -
 
| DocumentReference
 
| DocumentReference
| {{Simplifier|http://ihe.net/fhir/StructureDefinition/IHE.MHD.Query.Minimal.DocumentReference}}
+
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Minimal.DocumentReference|nictiz.fhir.nl.stu3.zib2017}}
 
|}
 
|}
{{Sjabloon:Voorbeelden}}
 
  
 
=Use case: Send PDF/A document(s)=
 
=Use case: Send PDF/A document(s)=
Regel 466: Regel 339:
  
 
<pre>
 
<pre>
POST [base] {?_format=[mime-type]}
+
POST [base]
 
</pre>
 
</pre>
  
Regel 472: Regel 345:
 
* [http://hl7.org/fhir/STU3/http.html#transaction transaction]
 
* [http://hl7.org/fhir/STU3/http.html#transaction transaction]
 
* [http://hl7.org/fhir/STU3/http.html#create create]
 
* [http://hl7.org/fhir/STU3/http.html#create create]
 
====Example - Bundle structure====
 
<pre>
 
<?xml version="1.0" encoding="UTF-8"?>
 
<Bundle xmlns="http://hl7.org/fhir">
 
    <type value="transaction"/>
 
    <entry>
 
        <fullUrl value="urn:uuid:96cf0274-9b2c-4bdc-b4c4-cb46f7a07097"/>
 
        <resource>
 
            <Patient xmlns="http://hl7.org/fhir">
 
                <!-- SNIP -->
 
            </Patient>
 
        </resource>
 
        <request>
 
            <method value="POST"/>
 
            <url value="Patient"/>
 
        </request>
 
    </entry>
 
    <entry>
 
        <fullUrl value="urn:uuid:278764fb-06b6-4f4f-8cef-4abaa3682111"/>
 
        <resource>
 
            <DocumentManifest xmlns="http://hl7.org/fhir">
 
                <!-- SNIP -->
 
            </DocumentManifest>
 
        </resource>
 
        <request>
 
            <method value="POST"/>
 
            <url value="DocumentManifest"/>
 
        </request>
 
    </entry>
 
    <entry>
 
        <fullUrl value="urn:uuid:2aa911db-9117-4e4b-97e4-d2f09dd28111"/>
 
        <resource>
 
            <DocumentReference xmlns="http://hl7.org/fhir">
 
                <!-- SNIP -->
 
            </DocumentReference>
 
        </resource>
 
        <request>
 
            <method value="POST"/>
 
            <url value="DocumentReference"/>
 
        </request>
 
    </entry>
 
    <entry>
 
        <fullUrl value="urn:uuid:6d035264-66ac-4df2-8bf8-d9a9bbf46111"/>
 
        <resource>
 
            <Binary xmlns="http://hl7.org/fhir" >
 
                <!-- SNIP -->
 
            </Binary>
 
        </resource>
 
        <request>
 
            <method value="POST"/>
 
            <url value="Binary"/>
 
        </request>
 
    </entry>
 
</Bundle>
 
 
</pre>
 
  
 
===XIS: Response message===
 
===XIS: Response message===
Regel 537: Regel 353:
 
A client may use the returned Bundle to track the outcomes of processing the entry, 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 entry - 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.
 
A client may use the returned Bundle to track the outcomes of processing the entry, 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 entry - 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.
  
====Handling Errors====
+
==List of profiles==
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, and perform a rollback of the creation of any previous entries.
 
 
 
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]
 
 
 
==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===
 
No search parameters are needed for this use case.
 
 
 
==List of StructureDefinitions==
 
  
IHE has defined StructureDefinitions applicable to this use case. Although the IHE MHD Profile text (the published PDF) is Normative these conformance resources are labelled as Informative. Not all IHE MHD profiles are implementable as-is for the send use case because of errors that IHE does not intend to resolve in FHIR STU3, but instead, require updating to FHIR R4. MedMij is not ready upgrading to FHIR R4 for just this use case and has implemented the necessary fixes in the IHE FHIR STU3 profiles to support this use case. The IHE MHD profiles 'IHE.MHD.DocumentManifest' and 'IHE.MHD.ProvideDocumentBundle.Minimal' are therefore copied, adjusted for the known issues and released under Nictiz. The table below shows the IHE MHD profiles used for the Providing Document Bundle transaction and the relevant HCIM profiles.
+
IHE has defined profiles applicable to this use case. Although the IHE MHD Profile text (the published PDF) is Normative these conformance resources are labelled as Informative. Not all IHE MHD profiles are implementable as-is for the send use case because of errors that IHE does not intend to resolve in FHIR STU3, but instead, require updating to FHIR R4. MedMij is not ready upgrading to FHIR R4 for just this use case and has implemented the necessary fixes in the IHE FHIR STU3 profiles to support this use case. The IHE MHD profiles 'IHE.MHD.DocumentManifest' and 'IHE.MHD.Minimal.ProvideDocumentBundle' are therefore copied, adjusted for the known issues and released in the Nictiz namespace. The table below shows the IHE MHD profiles used for the Providing Document Bundle transaction and the relevant HCIM profiles. Note that IHE originally created two profiles on DocumentReference, one for Query DocumentReference and one for Provide DocumentReference which are identical to each other. For usability purposes, these two profiles have been merged.  
  
{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:Vprepub/FHIR_IG}}
+
{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}
 
{| class="wikitable" width="1400px"
 
{| class="wikitable" width="1400px"
 
|-style="background-color: #1F497D; color: white; font-weight: bold; "
 
|-style="background-color: #1F497D; color: white; font-weight: bold; "
Regel 579: Regel 369:
 
| #Zib Patient|Patient
 
| #Zib Patient|Patient
 
| style="background-color: white;"| Patient
 
| style="background-color: white;"| Patient
| style="background-color: white;"| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient}}
+
| style="background-color: white;"| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
 
| rowspan="2" style="background-color: white;" | [https://zibs.nl/wiki/Zorgverlener-v3.2(2017NL) Zorgverlener]
 
| rowspan="2" style="background-color: white;" | [https://zibs.nl/wiki/Zorgverlener-v3.2(2017NL) Zorgverlener]
 
| rowspan="2" style="background-color: white;" | [https://zibs.nl/wiki/HealthProfessional-v3.2(2017EN) HealthProfessional]
 
| rowspan="2" style="background-color: white;" | [https://zibs.nl/wiki/HealthProfessional-v3.2(2017EN) HealthProfessional]
 
| style="background-color: white;"| Practitioner
 
| style="background-color: white;"| Practitioner
| style="background-color: white;"| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner}}
+
| style="background-color: white;"| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
 
| style="background-color: white;"| PractitionerRole
 
| style="background-color: white;"| PractitionerRole
| style="background-color: white;"| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole}}
+
| style="background-color: white;"| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
 
| style="background-color: white;"| Zorgaanbieder
 
| style="background-color: white;"| Zorgaanbieder
 
| style="background-color: white;"| HealthcareProvider
 
| style="background-color: white;"| HealthcareProvider
 
| style="background-color: white;"| Organization
 
| style="background-color: white;"| Organization
| style="background-color: white;"| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization}}
+
| style="background-color: white;"| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
 
| style="background-color: white;"| -
 
| style="background-color: white;"| -
 
| style="background-color: white;"| -
 
| style="background-color: white;"| -
| style="background-color: white;"| Bundle *
+
| style="background-color: white;"| Bundle
| style="background-color: white;"| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Minimal}}
+
| style="background-color: white;"| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Minimal.ProvideDocumentBundle|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
 
| style="background-color: white;"| -
 
| style="background-color: white;"| -
 
| style="background-color: white;"| -
 
| style="background-color: white;"| -
| style="background-color: white;"| DocumentManifest *
+
| style="background-color: white;"| DocumentManifest
| style="background-color: white;"| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest}}
+
| style="background-color: white;"| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
 
| style="background-color: white;"| -
 
| style="background-color: white;"| -
 
| style="background-color: white;"| -
 
| style="background-color: white;"| -
 
| style="background-color: white;"| DocumentReference
 
| style="background-color: white;"| DocumentReference
| style="background-color: white;"| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Provide.Minimal.DocumentReference}}
+
| style="background-color: white;"| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Minimal.DocumentReference|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
 
| style="background-color: white;"| -
 
| style="background-color: white;"| -
 
| style="background-color: white;"| -
 
| style="background-color: white;"| -
 
| style="background-color: white;"| List
 
| style="background-color: white;"| List
| style="background-color: white;"| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.List}}
+
| style="background-color: white;"| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.List|nictiz.fhir.nl.stu3.zib2017}}
 
|}
 
|}
'* Adjusted version of IHE MHD profiles by Nictiz.
 
  
{{Sjabloon:Voorbeelden}}
+
{{IssueBox|Even though the table above contains all profiles based on IHE MHD applicable to this use case, both the Bundle and List profiles aren't explicitly used within the PDF/A information standard, and are merely listed for completeness purposes.}}
  
 
=Release notes=
 
=Release notes=
Release notes can be found on the [[MedMij:Vprepub/OntwerpPDFA#Release_notes| functional design page]].
+
Release notes can be found on the [[MedMij:Vprepub-2020.01/OntwerpPDFA#Release_notes| functional design page]].

Huidige versie van 20 sep 2022 om 08:34


Naar medmij.nl
PDF/A
AfsprakenstelselFunctioneelTechnischAfspraken-Functioneel-Technisch

1 Introduction

Go to functional design

MedMij specifies the format PDF/A for exchanging unstructured documents containing health information. Forum Standaardisatie is a Dutch governmental organization that aims to stimulate the use of open standards. PDF/A is one of the standards that is recommended by Forum Standaardisatie. More information regarding PDF/A can be found here: https://www.forumstandaardisatie.nl/standaard/pdf-nen-iso.

To achieve exchange of PDF/A files, MedMij adopts as much as possible from 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 MHD profile is written to be content agnostic and as such is suitable for much more than PDF/A. For this use case, we have limited the scope to PDF/A. The next section summarizes MHD and contains references to IHE MHD specification. The following sections provides an adaptation of the MHD profile to specify exchange of PDF/A documents in a MedMij context.

When implementing PDF/A, a minimum compliance must be assumed. That is, PDF/A-1 and PDF/A-b is also permitted within this. For more information, see the wiki page on this: https://en.wikipedia.org/wiki/PDF/A#Conformance_levels_and_versions

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

1.1 IHE MHD specification

Mobile access to Health Documents (MHD) profile defines a simple HTTP RESTful interface to an XDS like environment, based on HL7 FHIR. It describes four transactions:

  1. submit submission sets, folders, new documents, and document metadata from the mobile device to a document receiver (Provide Document Bundle),
  2. find submission sets matching query parameters (Find Document Manifest),
  3. find document entries containing metadata based on query parameters (Find Document Reference),
  4. retrieve a copy of a specific document (Retrieve Document).

These 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.4 July 24, 2018)

Additional Supplement: Appendix Z on HL7 FHIR (Rev 1.2 July 21, 2017)

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 conformant to the full MHD specifications.

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 PDFA FHIR Client requirements
Healthcare Provider The user of a XIS XIS Healthcare information system Verwijzing.png CapabilityStatement: Server PDFA 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 MHD Actors MHD Transactions
Patient
PHR
Document Consumer Find Document Manifests [ITI-66]
Find Document References [ITI-67]
Retrieve Document [ITI-68]
Document Source Provide Document Bundle [ITI-65]
Healthcare provider
XIS
Document Responder Find Document Manifests [ITI-66]
Find Document References [ITI-67]
Retrieve Document [ITI-68]
Document Recipient Provide Document Bundle [ITI-65]

3 Use case: Find and retrieve existing PDF/A document(s)

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.

3.1 Introduction

This section summarizes the IHE MHD profile to find and retrieve PDF/A documents in a MedMij context.

3.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 conformant to the full MHD specifications.

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 PDFA FHIR Client requirements
Healthcare Provider The user of a XIS XIS Healthcare information system Verwijzing.png CapabilityStatement: Server PDFA 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 MHD Actors MHD Transactions Optionallity
Patient
PHR
Document Consumer Find Document Manifest Optional
Find Document Reference Required
Retrieve Document Required
Healthcare provider
XIS
Document Responder Find Document Manifest Optional
Find Document Reference Required
Retrieve Document Required

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

Implementation of the 'Find Document Reference' and 'Retrieve Document' transactions are required. The 'Find Document Manifest' transaction is optional for both the Document Consumer and Document Responder.

3.3 Find and retrieve existing PDF/A document(s)

3.3.1 Find PDF/A or PDF/A collection

Discovery of PDF/A documents is done with the MHD defined transaction 'Find Document Reference' or 'Find Document Manifest.' The Find Document Reference retrieves FHIR DocumentReference Resources that represents a single reference to document per resource, for example, one PDF/A file. The Find Document Manifest retrieves FHIR DocumentManifest Resources. A DocumentManifest Resource gathers a set of DocumentReference Resources into a single package together with metadata that applies to the collection.

The Document Consumer requests DocumentReference or DocumentManifest Resources, matching a set of criteria, from the Document Responder. The Document Responder returns DocumentReference or DocumentManifest Resources that match the search criteria provided by the Document Consumer.

3.3.1.1 Request message

Search

The Document Consumer executes an HTTP GET conform to the FHIR RESTful and search specification. A search query would have the following format.

GET [base]/DocumentReference?status=[status]{&[parameters]}
GET [base]/DocumentManifest?status=[status]{&[parameters]}

An example query to search for DocumentReferences which have status "current" and which are indexed/created after 01-01-2010:

GET [base]/DocumentReference?status=current&indexed=ge2010-01-01

Search Parameters The Document Consumer shall include search parameter status. The Document Consumer may supply, and the Document Responder shall be capable of processing, all search parameters listed below. These search parameters are a selection of the defined search parameters by the IHE MHD profile. The IHE MHD profile contains more search parameters that were deemed to pose a disproportionate implemenation burden for Document Responders. The following subselection still allow Document Consumers with server-side filter capabilities while making this use case more implementable for Document Responders.

DocumentReference DocumentManifest
Name Type Description Name Type Description
indexed date When this document reference was created created date When this document manifest created
status token current / superseded status token current / superseded

3.3.1.2 Response message

The Document Responder shall process the query to discover the DocumentReference or DocumentManifest entries that match the search parameters given. The Document Responder returns an HTTP Status code appropriate to the processing as well as a Bundle including the matching DocumentReference or DocumentManifest Resources.

  • The Document Responder shall place into the 'DocumentReference.content.attachment.url' element a full URL that can be used by the Document Consumer to retrieve the document using Retrieve Document transaction.
    • The Document Responder shall only include references which are resolved through the Document Responder to maintain control over the authentication and authorization. The Document Responder shall only serve DocumentReference or DocumentManifest resources that contain a reference which the Document Consumer may resolve.
  • The Document Responder shall return only PDF/A documents and shall place into the 'DocumentReference.content.attachment.contentType' element the value 'application/pdf'.

3.3.2 Retrieve PDF/A document

After obtaining the location of the PDF/A document in the DocumentReference.content.attachment.url, the Document Consumer requests the document from the Document Responder. The Document Responder sequentially serves the PDF/A document to the Document Consumer. The context that was established in the initial request shall also apply when retrieving/serving the document contents.

3.3.2.1 Request Message

This message is an HTTP GET request to retrieve the document. See an example below.

GET http://example:9556/svc/fhir/Binary/1e404af3-077f-4bee-b7a6-a9be97e1ce32

The Document Consumer may provide an HTTP Accept header, according to the semantics of the HTTP protocols (see RFC2616, Section 14.1). The only MIME type assured to be returned is the MIME type indicated in the 'DocumentReference.content.attachment.contentType'. Within MedMij this is set to 'application/pdf'. The HTTP If-Unmodified-Since header shall not be included in the GET request

3.3.2.2 Response Message

The Document Responder shall process the request message. The Document Responder returns an HTTP Status code appropriate to the processing as well as the content of the requested PDF/A document in the HTTP message-body.

The document may be placed inside a FHIR Binary resource if it is useful to handle pure binary content using the same framework as other resources. Binary resources behave slightly differently from all other resources on the RESTful API. Specifically, when a read request is made for the binary resource that doesn't explicitly specify the FHIR content types "application/fhir+xml" or "application/fhir+json", then the content should be returned using the content type stated in the resource. e.g. if the content type in the resource is "application/pdf", then the content should be returned as a PDF directly.[2]

3.4 List of profiles

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

Due to errors encountered when creating the send use case, 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.

Find and retrieve existing PDF/A document transaction uses the following profiles:

The complete set of used profiles for the response message is listed in the table below.


Zib name NL Zib name EN FHIR Resource
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
- - DocumentManifest http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest
- - DocumentReference http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Minimal.DocumentReference

4 Use case: Send PDF/A document(s)

4.1 Introduction

Go to Afsprakenstelsel

This section summarizes the IHE MHD profile to Send PDF/A document(s) in a MedMij context.

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

Person System MHD Actors MHD Transactions
Patient PHR Document Source Provide Document Bundle [ITI-65]
Healthcare provider XIS Document Recipient Provide Document Bundle [ITI-65]

4.3 Send PDFA

4.3.1 PHR: Request message

When the patient (PHR) wants to send one or more PDF/A documents, it issues a send PDFA 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 DocumentManifest resource, one or more DocumentReference resources, one or more Binary resources, one Patient resource, and zero or more Practitioner resources 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]

Read more:

4.3.2 XIS: Response message

The target XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type transaction-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

The target 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, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, 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 entry - 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.

4.4 List of profiles

IHE has defined profiles applicable to this use case. Although the IHE MHD Profile text (the published PDF) is Normative these conformance resources are labelled as Informative. Not all IHE MHD profiles are implementable as-is for the send use case because of errors that IHE does not intend to resolve in FHIR STU3, but instead, require updating to FHIR R4. MedMij is not ready upgrading to FHIR R4 for just this use case and has implemented the necessary fixes in the IHE FHIR STU3 profiles to support this use case. The IHE MHD profiles 'IHE.MHD.DocumentManifest' and 'IHE.MHD.Minimal.ProvideDocumentBundle' are therefore copied, adjusted for the known issues and released in the Nictiz namespace. The table below shows the IHE MHD profiles used for the Providing Document Bundle transaction and the relevant HCIM profiles. Note that IHE originally created two profiles on DocumentReference, one for Query DocumentReference and one for Provide DocumentReference which are identical to each other. For usability purposes, these two profiles have been merged.


Zib name NL Zib 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
PractitionerRole http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole
Zorgaanbieder HealthcareProvider Organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization
- - Bundle http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Minimal.ProvideDocumentBundle
- - DocumentManifest http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest
- - DocumentReference http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Minimal.DocumentReference
- - List http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.List

5 Release notes

Release notes can be found on the functional design page.