MedMij:Vissue-MM-3496/FHIR PDFA - Bewerkingsoverzicht

Luud Slagter: /* Master identifier versus identifier */

2022-12-09T12:46:47Z

Master identifier versus identifier

← Oudere versie		Versie van 9 dec 2022 12:46
Regel 115:		Regel 115:
	Both the DocumentReference and DocumentManifest resources contain the elements {{fhir\|.masterIdentifier}} and {{fhir\|.identifier}}. These identifiers each have different usages.		Both the DocumentReference and DocumentManifest resources contain the elements {{fhir\|.masterIdentifier}} and {{fhir\|.identifier}}. These identifiers each have different usages.
	* The {{fhir\|.masterIdentifier}} is assigned by the source of the document/manifest. There is always exactly one {{fhir\|.masterIdentifier}} present for each DocumentReference/DocumentManifest resource, and this identifier is used to uniquely identify that resource (and is often used in non-FHIR contexts for this purpose as well). In particular this identifier is {{term\|version dependent}}, as each DocumentReference/DocumentManifest resource corresponds to a specific version of a document/manifest. Updating a document/manifest thus results in a new resource with a different {{fhir\|.masterIdentifier}}.		* The {{fhir\|.masterIdentifier}} is assigned by the source of the document/manifest. There is always exactly one {{fhir\|.masterIdentifier}} present for each DocumentReference/DocumentManifest resource, and this identifier is used to uniquely identify that resource (and is often used in non-FHIR contexts for this purpose as well). In particular this identifier is {{term\|version dependent}}, as each DocumentReference/DocumentManifest resource corresponds to a specific version of a document/manifest. Updating a document/manifest thus results in a new resource with a different {{fhir\|.masterIdentifier}}.
	* All other identifiers associated with the document/manifest can be included in the resource as {{fhir\|.identifier}}s, including the {{term\|version independent}} ones. Thus such an identifier could occur in multiple DocumentReference/DocumentManifest resources, where each resource represents a different version of the same document/manifest; in that case it can be ~~used~~ as a bundling mechanism for these different versions. Note that {{fhir\|DocumentManifest.identifier}} is mandatory without justification from the data set; this is a legacy of the IHE MHD specification.		* All other identifiers associated with the document/manifest can be included in the resource as {{fhir\|.identifier}}s, including the {{term\|version independent}} ones. Thus such an identifier could occur in multiple DocumentReference/DocumentManifest resources, where each resource represents a different version of the same document/manifest; in that case it can be seen as a bundling mechanism for these different versions. Note that {{fhir\|DocumentManifest.identifier}} is mandatory without justification from the data set; this is a legacy of the IHE MHD specification.

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

Luud Slagter: /* Master identifier versus identifier */

2022-12-09T12:45:24Z

Master identifier versus identifier

← Oudere versie		Versie van 9 dec 2022 12:45
Regel 115:		Regel 115:
	Both the DocumentReference and DocumentManifest resources contain the elements {{fhir\|.masterIdentifier}} and {{fhir\|.identifier}}. These identifiers each have different usages.		Both the DocumentReference and DocumentManifest resources contain the elements {{fhir\|.masterIdentifier}} and {{fhir\|.identifier}}. These identifiers each have different usages.
	* The {{fhir\|.masterIdentifier}} is assigned by the source of the document/manifest. There is always exactly one {{fhir\|.masterIdentifier}} present for each DocumentReference/DocumentManifest resource, and this identifier is used to uniquely identify that resource (and is often used in non-FHIR contexts for this purpose as well). In particular this identifier is {{term\|version dependent}}, as each DocumentReference/DocumentManifest resource corresponds to a specific version of a document/manifest. Updating a document/manifest thus results in a new resource with a different {{fhir\|.masterIdentifier}}.		* The {{fhir\|.masterIdentifier}} is assigned by the source of the document/manifest. There is always exactly one {{fhir\|.masterIdentifier}} present for each DocumentReference/DocumentManifest resource, and this identifier is used to uniquely identify that resource (and is often used in non-FHIR contexts for this purpose as well). In particular this identifier is {{term\|version dependent}}, as each DocumentReference/DocumentManifest resource corresponds to a specific version of a document/manifest. Updating a document/manifest thus results in a new resource with a different {{fhir\|.masterIdentifier}}.
	* All other identifiers associated with the document/manifest can be included in the resource as {{fhir\|.identifier}}s, including the {{term\|version independent}} ones. Thus such an identifier could occur in multiple DocumentReference/DocumentManifest resources, where each resource represents a different version of the same document/manifest.		* All other identifiers associated with the document/manifest can be included in the resource as {{fhir\|.identifier}}s, including the {{term\|version independent}} ones. Thus such an identifier could occur in multiple DocumentReference/DocumentManifest resources, where each resource represents a different version of the same document/manifest; in that case it can be used as a bundling mechanism for these different versions. Note that {{fhir\|DocumentManifest.identifier}} is mandatory without justification from the data set; this is a legacy of the IHE MHD specification.

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

Luud Slagter: /* Master identifier versus identifier */

2022-12-09T11:38:45Z

Master identifier versus identifier

← Oudere versie		Versie van 9 dec 2022 11:38
Regel 115:		Regel 115:
	Both the DocumentReference and DocumentManifest resources contain the elements {{fhir\|.masterIdentifier}} and {{fhir\|.identifier}}. These identifiers each have different usages.		Both the DocumentReference and DocumentManifest resources contain the elements {{fhir\|.masterIdentifier}} and {{fhir\|.identifier}}. These identifiers each have different usages.
	* The {{fhir\|.masterIdentifier}} is assigned by the source of the document/manifest. There is always exactly one {{fhir\|.masterIdentifier}} present for each DocumentReference/DocumentManifest resource, and this identifier is used to uniquely identify that resource (and is often used in non-FHIR contexts for this purpose as well). In particular this identifier is {{term\|version dependent}}, as each DocumentReference/DocumentManifest resource corresponds to a specific version of a document/manifest. Updating a document/manifest thus results in a new resource with a different {{fhir\|.masterIdentifier}}.		* The {{fhir\|.masterIdentifier}} is assigned by the source of the document/manifest. There is always exactly one {{fhir\|.masterIdentifier}} present for each DocumentReference/DocumentManifest resource, and this identifier is used to uniquely identify that resource (and is often used in non-FHIR contexts for this purpose as well). In particular this identifier is {{term\|version dependent}}, as each DocumentReference/DocumentManifest resource corresponds to a specific version of a document/manifest. Updating a document/manifest thus results in a new resource with a different {{fhir\|.masterIdentifier}}.
	* All other identifiers associated with the document/manifest can be ~~put~~ in {{fhir\|.identifier}}, including the {{term\|version independent}} ones. Thus such an identifier could occur in multiple DocumentReference/DocumentManifest resources, where each resource represents a different version of the same document/manifest.		* All other identifiers associated with the document/manifest can be included in the resource as {{fhir\|.identifier}}s, including the {{term\|version independent}} ones. Thus such an identifier could occur in multiple DocumentReference/DocumentManifest resources, where each resource represents a different version of the same document/manifest.

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

Luud Slagter: /* Master identifier versus identifier */

2022-12-09T11:36:32Z

Master identifier versus identifier

← Oudere versie		Versie van 9 dec 2022 11:36
Regel 114:		Regel 114:
	==Master identifier versus identifier==		==Master identifier versus identifier==
	Both the DocumentReference and DocumentManifest resources contain the elements {{fhir\|.masterIdentifier}} and {{fhir\|.identifier}}. These identifiers each have different usages.		Both the DocumentReference and DocumentManifest resources contain the elements {{fhir\|.masterIdentifier}} and {{fhir\|.identifier}}. These identifiers each have different usages.
	* The {{fhir\|.masterIdentifier}} is assigned by the source of the document/manifest. There is always exactly one {{fhir\|.masterIdentifier}} present for each DocumentReference/DocumentManifest resource, and this identifier is used to uniquely identify that resource (and is often used in non-FHIR contexts as well). In particular this identifier is {{term\|version dependent}}, as each DocumentReference/DocumentManifest resource corresponds to a specific version of a document/manifest. Updating a document/manifest thus results in a new resource with a different {{fhir\|.masterIdentifier}}.		* The {{fhir\|.masterIdentifier}} is assigned by the source of the document/manifest. There is always exactly one {{fhir\|.masterIdentifier}} present for each DocumentReference/DocumentManifest resource, and this identifier is used to uniquely identify that resource (and is often used in non-FHIR contexts for this purpose as well). In particular this identifier is {{term\|version dependent}}, as each DocumentReference/DocumentManifest resource corresponds to a specific version of a document/manifest. Updating a document/manifest thus results in a new resource with a different {{fhir\|.masterIdentifier}}.
	* All other identifiers associated with the document/manifest can be put in {{fhir\|.identifier}}, including the {{term\|version independent}} ones. Thus such an identifier could occur in multiple DocumentReference/DocumentManifest resources, where each resource represents a different version of the same document/manifest.		* All other identifiers associated with the document/manifest can be put in {{fhir\|.identifier}}, including the {{term\|version independent}} ones. Thus such an identifier could occur in multiple DocumentReference/DocumentManifest resources, where each resource represents a different version of the same document/manifest.

Luud Slagter: /* Master identifier versus identifier */

2022-12-09T11:14:46Z

Master identifier versus identifier

← Oudere versie		Versie van 9 dec 2022 11:14
Regel 113:		Regel 113:

	==Master identifier versus identifier==		==Master identifier versus identifier==
	Both the DocumentReference and DocumentManifest resources contain the elements {{fhir\|.masterIdentifier}} and {{fhir\|.identifier}}.		Both the DocumentReference and DocumentManifest resources contain the elements {{fhir\|.masterIdentifier}} and {{fhir\|.identifier}}. These identifiers each have different usages.
	* The {{fhir\|.masterIdentifier}} is assigned by the source of the document/manifest. There is always exactly one {{fhir\|.masterIdentifier}} present for each DocumentReference ~~and~~ DocumentManifest resource, and this identifier is used to uniquely identify that resource (and is often used in non-FHIR contexts as well). In particular this identifier is {{term\|version dependent}}, as each resource corresponds to a specific version of a document/manifest. Updating a document/manifest thus results in a new resource with a ~~fiferent~~ {{fhir\|.masterIdentifier}}.		* The {{fhir\|.masterIdentifier}} is assigned by the source of the document/manifest. There is always exactly one {{fhir\|.masterIdentifier}} present for each DocumentReference/DocumentManifest resource, and this identifier is used to uniquely identify that resource (and is often used in non-FHIR contexts as well). In particular this identifier is {{term\|version dependent}}, as each DocumentReference/DocumentManifest resource corresponds to a specific version of a document/manifest. Updating a document/manifest thus results in a new resource with a different {{fhir\|.masterIdentifier}}.
	* All other identifiers associated with the document/manifest can be put in {{fhir\|.identifier}}, including the {{term\|version independent}} ones. Thus such an identifier could occur in multiple resources, where each resource represents a different version of the same document/manifest.		* All other identifiers associated with the document/manifest can be put in {{fhir\|.identifier}}, including the {{term\|version independent}} ones. Thus such an identifier could occur in multiple DocumentReference/DocumentManifest resources, where each resource represents a different version of the same document/manifest.

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

Luud Slagter: /* Master identifier versus identifier */

2022-12-09T11:11:46Z

Master identifier versus identifier

← Oudere versie		Versie van 9 dec 2022 11:11
Regel 113:		Regel 113:

	==Master identifier versus identifier==		==Master identifier versus identifier==
	Both the DocumentReference and DocumentManifest resources contain the elements {{fhir\|.masterIdentifier}} and {{fhir\|.identifier}}.		Both the DocumentReference and DocumentManifest resources contain the elements {{fhir\|.masterIdentifier}} and {{fhir\|.identifier}}.
			* The {{fhir\|.masterIdentifier}} is assigned by the source of the document/manifest. There is always exactly one {{fhir\|.masterIdentifier}} present for each DocumentReference and DocumentManifest resource, and this identifier is used to uniquely identify that resource (and is often used in non-FHIR contexts as well). In particular this identifier is {{term\|version dependent}}, as each resource corresponds to a specific version of a document/manifest. Updating a document/manifest thus results in a new resource with a fiferent {{fhir\|.masterIdentifier}}.
			* All other identifiers associated with the document/manifest can be put in {{fhir\|.identifier}}, including the {{term\|version independent}} ones. Thus such an identifier could occur in multiple resources, where each resource represents a different version of the same document/manifest.

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

Luud Slagter op 8 dec 2022 om 15:55

2022-12-08T15:55:38Z

← Oudere versie		Versie van 8 dec 2022 15:55
Regel 243:		Regel 243:

	====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.		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 {{fhir\|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 {{fhir\|DocumentReference.content.attachment.url}} element a full URL that can be used by the Document Consumer to retrieve the document using Retrieve Document transaction.
Regel 261:		Regel 261:

	====Response Message====		====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 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 {{term\|application/fhir+xml}} or {{term\|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 {{term\|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 {{term\|application/fhir+xml}} or {{term\|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 {{term\|application/pdf}}, then the content should be returned as a PDF directly.[http://hl7.org/fhir/STU3/binary.html#rest]
Regel 355:		Regel 355:

	===XIS: Response message===		===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 returns an HTTP status code appropriate to the processing outcome and returns a Bundle, of type {{term\|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.		The target XIS SHALL return a Bundle with type set to {{term\|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.		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.

Luud Slagter op 8 dec 2022 om 15:52

2022-12-08T15:52:13Z

← Oudere versie		Versie van 8 dec 2022 15:52
Regel 213:		Regel 213:

	'''Search Parameters'''		'''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 implementation 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.
			The Document Consumer shall include search parameter {{fhir\|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 implementation 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.

	{\| class="wikitable"		{\| class="wikitable"
Regel 226:		Regel 227:
	\| style="font-weight: bold;" \| Description		\| style="font-weight: bold;" \| Description
	\|-		\|-
	\| ~~<code>~~indexed~~</code>~~		\| {{fhir\|indexed}}
	\| date		\| date
	\| When this document reference was created		\| When this document reference was created
	\| ~~<code>~~created~~</code>~~		\| {{fhir\|created}}
	\| date		\| date
	\| When this document manifest created		\| When this document manifest created
	\|-		\|-
	\| ~~<code>~~status~~</code>~~		\| {{fhir\|status}}
	\| token		\| token
	\| current / superseded		\| {{term\|current}} / {{term\|superseded}}
	\| ~~<code>~~status~~</code>~~		\| {{fhir\|status}}
	\| token		\| token
	\| current / superseded		\| {{term\|current}} / {{term\|superseded}}
	\|}		\|}

Regel 260:		Regel 261:

	====Response Message====		====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 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 {{term\|application/fhir+xml}} or {{term\|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 {{term\|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 {{term\|application/fhir+xml}} or {{term\|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 {{term\|application/pdf}}, then the content should be returned as a PDF directly.[http://hl7.org/fhir/STU3/binary.html#rest]

Luud Slagter op 8 dec 2022 om 15:42

2022-12-08T15:42:39Z

← Oudere versie		Versie van 8 dec 2022 15:42
Regel 22:		Regel 22:
	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 [http://wiki.ihe.net/index.php/Cross-Enterprise_Document_Sharing 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.		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 [http://wiki.ihe.net/index.php/Cross-Enterprise_Document_Sharing 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		When implementing PDF/A, a minimum compliance must be assumed. That is, PDF/A-1 and PDF/A-b are 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]].		'''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]].
Regel 58:		Regel 58:
	\|-		\|-
	\| Patient		\| Patient
	\| The user of a personal healthcare environment.		\| The user of a personal healthcare environment
	\| PHR		\| PHR
	\| Personal health record		\| Personal health record
	\|[[Bestand: Verwijzing.png\| 20px]] {{Simplifier\|http://nictiz.nl/fhir/CapabilityStatement/pdfa-clientcapabilities\|nictiz.fhir.nl.stu3.zib2017\|title=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		\| PDF/A FHIR Client requirements
	\|-		\|-
	\| Healthcare Provider		\| Healthcare Provider
Regel 69:		Regel 69:
	\| Healthcare information system		\| Healthcare information system
	\|[[Bestand: Verwijzing.png\| 20px]] {{Simplifier\|http://nictiz.nl/fhir/CapabilityStatement/pdfa-servercapabilities\|nictiz.fhir.nl.stu3.zib2017\|title=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		\| PDF/A FHIR Server requirements
	\|}		\|}
	<font size = "1">'''Table 1. Actors, systems and FHIR capability statements'''</font>		<font size = "1">'''Table 1. Actors, systems and FHIR capability statements'''</font>
Regel 137:		Regel 137:
	\|-		\|-
	\| Patient		\| Patient
	\| The user of a personal healthcare environment.		\| The user of a personal healthcare environment
	\| PHR		\| PHR
	\| Personal health record		\| Personal health record
	\|[[Bestand: Verwijzing.png\| 20px]] {{Simplifier\|http://nictiz.nl/fhir/CapabilityStatement/pdfa-clientcapabilities\|nictiz.fhir.nl.stu3.zib2017\|title=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		\| PDF/A FHIR Client requirements
	\|-		\|-
	\| Healthcare Provider		\| Healthcare Provider
Regel 148:		Regel 148:
	\| Healthcare information system		\| Healthcare information system
	\|[[Bestand: Verwijzing.png\| 20px]] {{Simplifier\|http://nictiz.nl/fhir/CapabilityStatement/pdfa-servercapabilities\|nictiz.fhir.nl.stu3.zib2017\|title=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		\| PDF/A FHIR Server requirements
	\|}		\|}
	<font size = "1">'''Table 1. Actors, systems and FHIR capability statements'''</font>		<font size = "1">'''Table 1. Actors, systems and FHIR capability statements'''</font>
Regel 337:		Regel 337:
	\|}		\|}

	==Send ~~PDFA~~==		==Send PDF/A==
	===PHR: Request message===		===PHR: Request message===
	When the patient (PHR) wants to send one or more PDF/A documents, it issues a send ~~PDFA~~ request message.		When the patient (PHR) wants to send one or more PDF/A documents, it issues a send PDF/A 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 below.		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 below.

Luud Slagter op 14 okt 2022 om 14:54

2022-10-14T14:54:35Z

← Oudere versie		Versie van 14 okt 2022 14:54
Regel 109:		Regel 109:
	\| Provide Document Bundle [ITI-65]		\| Provide Document Bundle [ITI-65]
	\|}		\|}

			=Boundaries and Relationships=

			==Master identifier versus identifier==
			Both the DocumentReference and DocumentManifest resources contain the elements {{fhir\|.masterIdentifier}} and {{fhir\|.identifier}}.

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