diff --git a/PixM_Feed_Documentation/README_PixMFeed.md b/PixM_Feed_Documentation/README_PixMFeed.md
deleted file mode 100644
index 76ed509cfe7c3e19692a0f1baa289254a880e459..0000000000000000000000000000000000000000
--- a/PixM_Feed_Documentation/README_PixMFeed.md
+++ /dev/null
@@ -1,572 +0,0 @@
-# PixM Feed
-
-> Version : 1.0.0 <br />
-> Date : 2021-08-26
-
-PixM Feed lets a user to proceed some operations with Cross-Referenced (X-ref) Patient.
-The User can do the following ITI-93 transactions : Create, Update, Delete and Merge Patient (called CUDM operations)
-Each operation will be decribed later.
-
-The PixM Feed has 2 components :
-
-* a PixM Consumer : the Client part, where the User can do CUDM operations through a SOAP UI project uploaded in Gazelle
- Webservice Tester (GWT). The SOAP UI project can perform also all cases covered by the standard and shall send/receive
- all the required requests.
-* a PixM Manager : the Server part, where all the CUDM operations are done in order to feed the Patient database. The
- PixM Manager has 2 parts :
- + PixM Connector: interpret REST FHIR requests and data to transform it into a Gazelle Patient Model for the
- transfert toward Patient Registry.
- + Patient Registry : manage transaction I/O of the Patient Database, CUDM and also X-ref. The access to PatReg has
- to be done with GIT-B webservices.<br />
-
-The communication between PixM Connector and Patient Registry is done by a Java Client in order to translate REST
-operation into SOAP operation done with GIT-B webservices.
-
-
-
-All the transactions between the PixM Client and the PixM Manager are ruled byt ITI-93 transactions.<br />
-https://fhir.ch/ig/ch-epr-mhealth/iti-93.html<br />
-https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_PMIR.pdf
-
-<br />
-
-## ITI-93 transactions
-
-_____________________________________________________________________________________
-ITI-93 transactions are basically Bundle messages exchanged between a Supplier and a Consumer.
-The Supplier sends a Mobile Patient Feed Request to a Consumer. This event is trigerred every time patients are created,
-updated, merged or deleted by the Supplier.
-The Consumer sends back a Mobile Patient feed Response to a Supplier.
-
-
-
-The **Bundle PixMFeed request** has 2 entries (https://fhir.ch/ig/ch-epr-mhealth/Bundle-BundlePIXmFeed.json.html) :
-
-- a Message header
-- a History Bundle, containing the Patient Resource (https://www.hl7.org/fhir/patient.html)
-
-This two entries are mandatory for each transactions.
-We will see further that not every fields are mandatory to proceed operations.
-
-The **Bundle PixMFeed response** has 1 entry (https://fhir.ch/ig/ch-epr-mhealth/Bundle-BundlePIXmResponse.json.html):
-
-- a message response that acknowledge the transaction is done.
-
-For our purpose, the message response will also return in case of :
-
-- CREATE : the uuid of the newly created patient will be returned in the message
-- UPDATE : the whole Patient will be returned
-- MERGE : The uuid of the original Patient is returned
-- DELETE : The DONE or GONE status
-
-<br />
-
-## PIXM Consumer : SOAP UI Project
-
-__________________________________________________________________
-The SOAP UI Project for CHPixM Feed is splitted in 2 parts :
-
-- the one that the user can interact with to do its request to PixM Server, can test nominal and errors requests
-- the MOCK server test implemented methods and mimic the desired comportment from the PixM Server
-
-4 methods are implemented and their related TestSuite & TestCase
-
-- CREATE (C)
-- DELETE (D)
-- UPDATE (U)
-- MERGE (M)
-
-For each TestCase, the user can filled a prefilled body with following fields :
-
-- name.given (CU)
-- name.family (CU)
-- birthDate (CU)
-- gender (CU)
-- resource (CUDM)
-- system (CU)
-- value (CU)
-- uuid (UMD)
-- uuidToRedirect (M)
-
-These fields can be accessed in each TestSuite > TestCase
-then on the bottom-left corner click on the tab "Custom properties"
-
-### CREATE METHOD :
-
-__________________________________________________________________
-
-#### NOMINAL CASE :
-
-Send the following REST Request
-
- POST : {serverAdress}/ch_fhir/Bundle/
-
-With a prefilled body as following :
-
-```json
-{
- "resourceType" : "Bundle",
- "id" : "BundlePIXmFeed",
- "meta" : {
- "profile" : [
- "http://fhir.ch/ig/ch-epr-mhealth/StructureDefinition/ch-pixm-bundle"
- ]
- },
- "type" : "message",
- "entry" : [
- {
- "fullUrl" : "http://example.com/fhir/MessageHeader/1",
- "resource" : {
- "resourceType" : "MessageHeader",
- "id" : "1",
- "text" : {
- "status" : "generated",
- "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative</b></p><p><b>event</b>: <code>urn:ihe:iti:pmir:2019:patient-feed</code></p><h3>Destinations</h3><table class=\"grid\"><tr><td>-</td><td><b>Endpoint</b></td></tr><tr><td>*</td><td><a href=\"http://example.com/patientEndpoint\">http://example.com/patientEndpoint</a></td></tr></table><h3>Sources</h3><table class=\"grid\"><tr><td>-</td><td><b>Endpoint</b></td></tr><tr><td>*</td><td><a href=\"http://example.com/patientSource\">http://example.com/patientSource</a></td></tr></table><p><b>focus</b>: <a href=\"#Bundle_abc\">See above (Bundle/abc)</a></p></div>"
- },
- "eventUri" : "urn:ihe:iti:pmir:2019:patient-feed",
- "destination" : [
- {
- "endpoint" : "http://example.com/patientEndpoint"
- }
- ],
- "source" : {
- "endpoint" : "http://example.com/patientSource"
- },
- "focus" : [
- {
- "reference" : "Bundle/abc"
- }
- ]
- }
- },
- {
- "fullUrl" : "http://example.com/fhir/Bundle/abc",
- "resource" : {
- "resourceType" : "Bundle",
- "id" : "abc",
- "type" : "history",
- "entry" : [
- {
- "fullUrl" : "http://example.com/fhir/Patient/PatientPIXmFeed",
- "resource" : {
- "resourceType" : "Patient",
- "id" : "PatientPIXmFeed",
- "text" : {
- "status" : "generated",
- "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative</b></p><p><b>id</b>: PatientPIXmFeed</p><p><b>meta</b>: </p><p><b>identifier</b>: Medical record number = 8734</p><p><b>name</b>: Franz Muster , Muster </p><p><b>gender</b>: male</p><p><b>birthDate</b>: 1995-01-27</p></div>"
- },
- "contained" : [
- {
- "resourceType" : "Organization",
- "id" : "org1",
- "identifier" : [
- {
- "system" : "${system}",
- "value" : "${value}"
- }
- ],
- "address" : [
- {
- "use" : "work",
- "line" : [
- "Doktorgasse",
- "2"
- ],
- "city" : "Musterhausen",
- "postalCode" : "8888",
- "country" : "CH"
- }
- ]
- }
- ],
- "identifier" : [
- {
- "type" : {
- "coding" : [
- {
- "system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
- "code" : "MR"
- }
- ]
- },
- "system" : "${#system}",
- "value" : "${#value}"
- }
- ],
- "name" : [
- {
- "family" : "${#name.family}",
- "given" : [
- "${#name.given}"
- ]
- },
- {
- "family" : "${#name.family}",
- "_family" : {
- "extension" : [
- {
- "url" : "http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier",
- "valueCode" : "BR"
- }
- ]
- }
- }
- ],
- "gender" : "${#gender}",
- "birthDate" : "${#birthDate}",
- "managingOrganization" : {
- "reference" : "#org1"
- }
- },
- "request" : {
- "method" : "POST",
- "url" : "Patient"
- },
- "response" : {
- "status" : "200"
- }
- }
- ]
- }
- }
- ]
- }
-```
-
-These parameters are mandatory in CREATE method
-
-* name.given
-* name.family
-* birthdate
-* gender
-
-The server then should answer a response bundle like :
-
- ```json
-{
- "resourceType" : "Bundle",
- "id" : "BundlePIXmResponse",
- "meta" : {
- "profile" : [
- "http://fhir.ch/ig/ch-epr-mhealth/StructureDefinition/ch-pixm-bundle-response"
- ]
- },
- "type" : "message",
- "entry" : [
- {
- "fullUrl" : "http://example.com/fhir/MessageHeader/1",
- "resource" : {
- "resourceType" : "MessageHeader",
- "id" : "1",
- "text" : {
- "status" : "generated",
- "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative</b></p><p><b>event</b>: <code>urn:ihe:iti:pmir:2019:patient-feed</code></p><h3>Destinations</h3><table class=\"grid\"><tr><td>-</td><td><b>Endpoint</b></td></tr><tr><td>*</td><td><a href=\"http://example.com/patientEndpoint\">http://example.com/patientEndpoint</a></td></tr></table><h3>Sources</h3><table class=\"grid\"><tr><td>-</td><td><b>Endpoint</b></td></tr><tr><td>*</td><td><a href=\"http://example.com/patientSource\">http://example.com/patientSource</a></td></tr></table><h3>Responses</h3><table class=\"grid\"><tr><td>-</td><td><b>Identifier</b></td><td><b>Code</b></td></tr><tr><td>*</td><td>1</td><td>ok</td></tr></table></div>"
- },
- "eventUri" : "urn:ihe:iti:pmir:2019:patient-feed",
- "destination" : [
- {
- "endpoint" : "http://example.com/patientEndpoint"
- }
- ],
- "source" : {
- "endpoint" : "http://example.com/patientSource"
- },
- "response" : {
- "identifier" : "1",
- "code" : "ok"
- }
- }
- }
- ]
- }
-
-+ The ID of the new patient newly created
-```
-
-The following assertion will be tested when the body is sent :
-
-- if the returned HTTP Status is "200"
-- if the gender is : male OR female OR unknown OR other
-- if the birthDay is an existed date in Calendar AND in the YYYY-MM-DD format AND NOT greater than the Current day
-- if the sourceIdentifier (if given) respect the following regex:
-
-> urn:oid:([0-9]+)(\.[0-9]+)+\|([ -~]+) <br />
-> {start with "urn:oid:"} then {"any number"} then {sequence of "."+"any number"} then a pipe ["|"] then {"any string"}
-
-<br/>
-
-#### TEST CASE (400)
-
-> Resource could not be parsed or failed basic FHIR validation rules | malformed bundle message.<br/>
-
-Same as Nominal Test excepting :
-
-* The Bundle message is intentionally malformed
-
-* The following assertion will be tested when the body is sent :
- - if the returned HTTP Status is "400"
-
-<br/>
-
-#### TEST CASE (404)
-
-> Resource type not supported, or not a FHIR end-point : request URL is not valid
-
-The following assertion will be tested when the body is sent :
-
-- if the returned HTTP Status is "404"
-
-#### TEST CASE (422)
-
-> The proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an
-> OperationOutcome resource providing additional detail.
-
-The request is a right one but the submitted birthdate OR gender OR sourceIdentifier do NOT respect the assertion rules.
-
-The following assertion will be tested when the body is sent :
-
-- if the returned HTTP Status is "422"
-
-### DELETE METHOD
-
-______________________________________________________________________
-
-#### NOMINAL CASE :
-
-Send the following REST Request
-> DELETE : {serverAdress}/{resource}/{id}
-
-
-Same body as a create except :
-
-* request method must be delete at the end :
-
-```json
-
- "request" : {
- "method" : "DELETE",
- "url" : "Patient"
- },
-```
-
-* Mandatory field to fill in case of DELETE method :
- * uuid
-
-In the case of the DELETE method, none of the fields are taking into account, only the UUID is check, and the Server
-shall answer 2 DELETE status :
-
-- DONE if the Patient existed and is now deleted
-- GONE if the Patient to delete does NOT exist in Databse
-
-The following assertion will be tested when the body is sent :
-
-- if the returned HTTP Status is "204"
-
-<br/>
-
-#### TEST CASE (404)
-
-> case where uuid not exist in database
-
-
-Same as NOMINAL except :
-
-The following assertion will be tested when the body is sent :
-
-- if the returned HTTP Status is "404"
-
-### UPDATE METHOD
-
-__________________________________________________________________________________
-
-#### NOMINAL CASE :
-
-Send the following REST Request
-> PUT : {serverAdress}/{resource}/{id}
-
-
-Same body as CREATE method but :
-
-* the request method should be put AND the patient id is replaced by an UUID
-
-```json
- "request" : {
- "method" : "PUT",
- "url" : "Patient"
- },
-
-```
-
-* Mandatory fields : uuid
-
-* The body response shall return the modified Patient.
-
-<br/>
-
-#### TEST CASE (400)
-
-> resource could not be parsed or failed basic FHIR validation rules | malformed bundle message
-
-
-Same as Nominal Test excepting :
-
-The Bundle message is intentionally malformed
-
-The following assertion will be tested when the body is sent :
-
-- if the returned HTTP Status is "400"
-
-#### TEST CASE (422)
-
-> the proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an
-> OperationOutcome resource providing additional detail.
-
-Same as Nominal Test excepting :
-
-The following assertion will be tested when the body is sent :
-
-- if the returned HTTP Status is "422"
-
- <br/>
-
-### MERGE METHOD (should be updated in further version)
-
-____________________________________________________________________________________
-Send the following REST Request :
-> PUT : {serverAdress}/{resource}/{id}
-
-The body is different because the MERGE is a used in the case where the same patient was created 2 times and the user
-would like to redirect the duplicated patient to the original one in the database.
-
-```json
-{
- "resourceType": "Bundle",
- "type": "message",
- "entry": [{
- "fullUrl": "http://qualification.ihe-europe.net/fhir/MessageHeader/1",
- "resource": {
- "resourceType": "MessageHeader",
- "id": "1",
- "eventUri": "urn:ihe:iti:pmir:2019:patient-feed",
- "source": {
- "endpoint": "http://qualification.ihe-europe.net/patientSource"
- },
- "focus": [{
- "reference": "Bundle/abc"
- }],
- "destination": [{
- "endpoint": "http://qualification.ihe-europe.net/patientEndpoint"
- }]
- }
- }, {
- "fullUrl": "http://qualification.ihe-europe.net/fhir/Bundle/abc",
- "resource": {
- "resourceType": "Bundle",
- "id": "abc",
- "type": "history",
- "entry": [{
- "fullUrl": "http://qualification.ihe-europe.net/fhir/Patient/${uuid}",
- "resource": {
- "resourceType": "Patient",
- "id": "${uuid}",
- "active": false,
- "link": [{
- "other": {
- "reference": "http://qualification.ihe-europe.net/fhir/Patient/${uuidToRedirect}"
- },
- "type": "replaced-by"
- }]
- },
- "request": {
- "method": "PUT",
- "url": "Patient/${uuid}"
- },
- "response": {
- "status": "200"
- }
- }]
- }
- }]
-}
-```
-
-* Mandatory fields to fill in MERGE request :
- * uuid
- * uuidToRedirect
-
-* The response should be as Following :
-
- - a Patient Identifier is mandatory [1..*]
- - On the GWT, I can choose a project {projectName} and select the Merge Test Suite and modify : the endpoint, the
- formerSourceIdentifier I want to deprecate, the newSourceIdentifier I want for my Patient.
- - 200 status is returned if the patient is merged
- - 400 status is returned if I provided malformed Bundle Json
- - 404 status is returned if I provided well-formed sourceIdentifier but not exist in PatReg
- - 405 status is returned if I provide a sourceIdentifier for a deactivated patient
- - 422 status is returned if I provide a malformed sourceIdentifier
-
-<br/>
-
-## PIX-M MANAGER
-
-__________________________________________________________________________________
-
-### PixM Connector
-
-PixM Connector is a FHIR application server exposing REST services. It uses the HAPI FHIR Server framework (a fast
-solution to deploy a FHIR Server and implement a specific treatment for the request).
-
-The PixM Connector is a Java Project which receives the SUT Request and transfer it to the Java Client for Patreg.
-It shall manage received CREATE, UPDATE, DELETE, MERGE request from SUT.
-It has also to convert a FHIR Bundle Object from ITI-93 transaction into a manageable Patient Object by Patient
-Registry.
-It has to received response message from Patient Registry to transfer to the SUT.
-
-It has 3 parts :
-
-* **server part** : define the context of the deployed FHIR Server
-* **provider part** : feed the server with the methods that it needs to expose. In our case it defines the treatment of
- parameters that needs to be transferred
-* **call-the-java-client part** : in this part, the module initialize the Java client with de Patient Registry adress.
- It uses the JAVA client to transfer the request and interpret the response and reported errors. It also prepares the
- content of the FHIR reponse and sends back to the SUT.
-
-<br/>
-
-### Java Client (part of PixM Connector)
-
-It acts like a connector to Patient Registry.
-Its role is to initialize the connection with Patient Registry and translate the research parameters into GITB Model.
-It implements the same interface as the service. This connector is embedded in PIXm-Connector to communicate with this
-module.
-
-<br/>
-
-### Patient Registry
-
-Patient Registry is a module that allows you to interact with the database of Patient Manager database.
-This module has no web interface. It is only accessible through its webservices just like PIX-Connector.
-With one exception, the latter uses REST webservices while Patient Registry uses Soap technology with a GITB overlay.
-
-The GITB model is a standardization project initiated by the European Commission.
-The specifications aim at the interoperability of the test tools in a test bucket. It is about
-defining a common interface between the tools and a test bench. This common interface
-defines the data exchanges via the webservices. They use a standardized data type standardized data type that requires a
-correspondence with the gazelle data models.
-It is expected that in the next few years that the GITB standard will migrate to REST webservices.
-
-The Patient Registry Webservice implements the GITB model. It only receives requests in this format. It identifies the
-operation to be performed (here a cross-reference search operation) and
-operation) and establishes the reverse correspondence, from the GITB model to the
-Gazelle model.
-
-The webservice then transmits these parameters to the service application layer which
-returns the result or the exceptions raised during the operation. Again, we perform the
-the results in a report indicating the status and the result of the operation.
-the result of the operation. This report is then translated and interpreted by the Java client.
-
-
-
-
-
-
diff --git a/PixM_Feed_Documentation/pictures/iti_93_interaction_diagram.png b/PixM_Feed_Documentation/pictures/iti_93_interaction_diagram.png
deleted file mode 100644
index d65ca11ee29cda0694cd6f2d5b2d25e81006542e..0000000000000000000000000000000000000000
Binary files a/PixM_Feed_Documentation/pictures/iti_93_interaction_diagram.png and /dev/null differ
diff --git a/PixM_Feed_Documentation/pictures/pixm_connector.png b/PixM_Feed_Documentation/pictures/pixm_connector.png
deleted file mode 100644
index e2eb7b8aeb0b979b5bf7854aabde52452c89a8c8..0000000000000000000000000000000000000000
Binary files a/PixM_Feed_Documentation/pictures/pixm_connector.png and /dev/null differ
diff --git a/PixM_Feed_Documentation/pictures/pixm_scheme_total.png b/PixM_Feed_Documentation/pictures/pixm_scheme_total.png
deleted file mode 100644
index ba1ad2f1ea3f7eb9b9ba0ffa63403eaa850929d9..0000000000000000000000000000000000000000
Binary files a/PixM_Feed_Documentation/pictures/pixm_scheme_total.png and /dev/null differ
diff --git a/README.md b/README.md
index 8993e7747050edadd346600bd80c43cc000d33dd..b713a8743fdbe4ce2412d83890e75747bd8c7eb8 100644
--- a/README.md
+++ b/README.md
@@ -1,17 +1,21 @@
-# Pixm Connector
+# PIXm Connector
---
-### Prerequisites
+## Prerequisites
-- Java 11 with maven.
-- WildFly 18.
+- Java 17 with maven.
+- WildFly 30.0.1 is deployed
+- [Patient Registry](https://gazelle.ihe.net/gazelle-documentation/Patient-Registry/installation.html) is installed.
+- [HTTP Validator](https://gitlab.inria.fr/gazelle/applications/test-execution/validator/http-validator) is installed.
+- [Matchbox](https://www.matchbox.health/) is installed.
---
### Build project locally
-After cloning this repository to your local installation launch
+After cloning this repository to your local installation launch.
+Check that the JAVA_HOME is set correctly to Java 17.
```bash
> mvn clean install
@@ -19,8 +23,7 @@ After cloning this repository to your local installation launch
from the project root directory.
-The artifact pixm_fhir_server.war will be created in target/ directory.
-
+The artifact `pixm-connector.war` will be created in target/ directory.
---
@@ -29,267 +32,226 @@ The artifact pixm_fhir_server.war will be created in target/ directory.
After building the project through Maven, the artifact created just has to be added to your local WildFly installation
in the folder
-```bash
+```http
{$wildfly.home}/standalone/deployments
```
----
+A `deployment.properties` file has to be created in folder `/opt/pixm-connector` with following content:
+
+```properties
+ patientregistry.url = https://{{host}}/patient-registry/PatientProcessingService/patient-processing-service?wsdl
+ xrefpatientregistry.url = https://{{host}}/patient-registry/CrossReferenceService/xref-processing-service?wsdl
+ PROFILE_ID_CREATE_UPDATE_DELETE_ITI_104="IHE_ITI-104-PatientFeed_Query"
+ PROFILE_ID_POST_ITI_83="IHE_ITI-83_POST_PIXm_Query"
+ PROFILE_ID_GET_ITI_83="IHE_ITI-83_GET_PIXm_Query"
+ APP_HTTP_VALIDATOR_SERVER="https://{{host}}/http-validator"
+ APP_IG_FHIR_SERVER="https://{{host}}/matchboxv3/fhir"
+ PIXM_PATIENT_PROFILE="https://profiles.ihe.net/ITI/PIXm/StructureDefinition/IHE.PIXm.Patient"
+ PIXM_PARAMETERS_PROFILE="https://profiles.ihe.net/ITI/PIXm/StructureDefinition/IHE.PIXm.Parameters"%
+```
-### Overview
-Here is a quick overview of the available functionnality from PIXm connector
-| Method | URL to call | Entry parameter | Returned value |
-|--------------------------------|----------------------------------------------|-----------------------------------------------|----------------|
-| Create Patient | ```{FHIR.server.address}/Patient/$create``` | ITI-93 Bundle | Patient Bundle
-| Delete Patient | ```{FHIR.server.address}/Patient/$delete``` | Patient SourceIdentifier | /
-| Read Patient | ```{FHIR.server.address}/Patient``` | Patient SourceIdentifier | Patient Bundle
-| Update Patient | ```{FHIR.server.address}/Patient/$update``` | ITI-93 Bundle with a Patient SourceIdentifier | Patient Bundle
-| Merge Patient | ```{FHIR.server.address}/Patient/$merge``` | 2 Patient SourceIdentifier | Patient Bundle
-| Check Cross Referenced Patient | ```{FHIR.server.address}/Patient/$ihe-pix``` | A Patient sourceIdentifier and a TargetDomain | Patient Bundle
+## Overview
+___
----
+Here is a quick overview of the available functionality from PIXm connector
-### Request a Patient Cross Reference on a specific Target Identifier (ITI-83)
+| Operation | HTTP Methods | URL to call | Entry parameter | Returned value |
+|--------------------------------|--------------|--------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------|------------------------------------------|
+| Create/Update Patient | PUT | ```{FHIR.server.address}/Patient?identifier={{patient.system}}\|{{patient.id}}``` | ITI-104 Patient identifier | ITI-104 FHIR Patient |
+| Delete Patient | DELETE | ```{FHIR.server.address}/Patient/?identifier={{patient.system}}\|{{patient.id}}``` | ITI-104 Patient identifier | / |
+| Merge Patient | PUT | ```{FHIR.server.address}/Patient/?identifier={{patient.system}}\|{{patient.id}}``` | ITI-104 Patient identifier w/ patient.link to Patient to keep | ITI-104 FHIR Patient |
+| Check Cross Referenced Patient | GET | ```{FHIR.server.address}/Patient/$ihe-pix?sourceIdentifier={{patient.system}}\|{{patient.id}}&targetSystem={{targetSystem}}``` | A Patient sourceIdentifier and a TargetDomain | ITI-83 FHIR Parameters with X-ref values |
-Once the project deployed on your WildFly, you can now call it to request a cross Referenced Patient in the Patient
-Registry.
+Capability statement of the application can be found with : <https://example.com/pixm-connector/fhir/metadata>
-Parameters allowed are :
-- The Patient Identifier and the Target System attributed to this identifier
-- The Target System you want the cross reference from.
-- The format returned.
+As described in [HAPI FHIR resources](https://hapifhir.io/hapi-fhir/docs/server_plain/rest_operations_operations.html), some strings are automatically escaped when the FHIR server parses URLs:
-Cardinality for these parameters will be described in each profile since it's the main difference between each.
+- `"|"` → `"%7C"`
+- `"=>="` → `"=%3E%3D"`
+- `"=<="` → `"=%3C%3D"`
+- `"=>"` → `"=%3E"`
+- `"=<"` → `"=%3C"`
-#### IHE Profile
-The URL to call is
+## Validation process
+___
-```http
- {wildfly18.address}/pixm_fhir_server/fhir/ihe/Patient/$ihe-pix
-```
+Each operation implies a validation of requests for both ITI-104 and ITI-83 transactions.
+Validation is done by calling:
-| Parameter name | Cardinality | Parameter Type | Description |
-|------------------|-------------|----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| sourceIdentifier | 1..1 | Token | The Patient identifier search parameter that will be used by the Patient Identifier Cross-reference Manager to find cross matching identifiers associated with the Patient Resource
-| targetSystem | 0..* | uri | The target Patient Identifier Assigning Authority from which the returned identifiers should be selected. |
-| _format | 0..1 | mime-type | The requested format of the response. Accepted values : JSON and XML |
+- [HTTP Validator](https://gitlab.inria.fr/gazelle/applications/test-execution/validator/http-validator) for URL and Headers.
+- [Matchbox](https://www.matchbox.health/) for Body with FHIR Resource.
-#### CH Profile
+Both validators allow to perform validation and have high customization if specifications changed for both transactions without refactoring pixm-connector application.
+An error during validation process will result with an OperationOutcome with error `400 Bad Request` with issues describing where it failed.
-The URL to call is
+## Request a Patient Cross Reference on a specific Target Identifier (ITI-83)
+___
-```http
- {wildfly18.address}/pixm_fhir_server/fhir/ch/Patient/$ihe-pix
-```
-
-| Parameter name | Cardinality | Parameter Type | Description |
-|------------------|-------------|----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| sourceIdentifier | 1..1 | Token | The Patient identifier search parameter that will be used by the Patient Identifier Cross-reference Manager to find cross matching identifiers associated with the Patient Resource
-| targetSystem | 1..2 | uri | The target Patient Identifier Assigning Authority from which the returned identifiers should be selected. |
-| _format | 0..1 | mime-type | The requested format of the response. Accepted values : JSON and XML |
-
-For example :
-Given the Patient with the ID 69420 in the Target System 1.3.6.1.4.1.21367.13.20.3000
-And you want the cross referenced patient in the target system 1.3.6.1.4.1.21367.13.20.1000
+- [IHE Specifications](https://profiles.ihe.net/ITI/PIXm/ITI-83.html)
-The corresponding url will be :
+Request a cross-referenced Patient is possible thanks to the `$ihe-pixm`.
-```http
- {wildfly18.address}/pixm_fhir_server/fhir/ihe/Patient/$ihe-pix?sourceIdentifier=urn:oid:1.3.6.1.4.1.21367.13.20.3000|69420&targetSystem=urn:oid:1.3.6.1.4.1.21367.13.20.1000
-```
-
----
-
-#### Error returned
-
-Malformed requests can cause different types of error, here is a quick overview of how to troubleshoot them :
-
-
-An error 400 Bad Request is returned when the source domain given within the source identifier parameter is not
-recognized by the Patient Registry as an asigning authority.
-In the case of our request above, the value "urn:oid:1.3.6.1.4.1.21367.13.20.3000" is not a valid source domain able to
-register Patients
+Parameters allowed are :
-Common mistakes with the source domain include :
+- The Patient Identifier and the Target System attributed to this identifier as `sourceIdentfier`
+- The Target System you want the cross-reference from as `targetSystem`.
+- The format returned as `_format`. `xml` AND `json` are the only values.
-- Forgetting the namespace in front of the adress (urn:oid:)
-- Malformed source domain.
- The source domain can have the form of an url
+The URL to call is:
```http
-sourceIdentifier=https://your.domain|id
+ GET {wildfly18.address}/pixm-connector/fhir/Patient/$ihe-pix
```
-or of an adress, which must follows the pattern x.x.x.x.x.x.x.x.x.x
+For example :
+Given the Patient with the `id=69420` with the `system=urn:oid:1.3.6.1.4.1.21367.13.20.3000` as `sourceIdentifer=system|id`
+And you want the cross-referenced patient in the `targetSystem=1.3.6.1.4.1.21367.13.20.1000`
+And you want the returned response as a `json`.
-```http
-sourceIdentifier=urn:oid:x.x.x.x.x.x.x.x.x.x|id
+The corresponding url will be :
+
+```http
+ {wildfly18.address}/pixm-connector/fhir/Patient/$ihe-pix?sourceIdentifier=urn:oid:1.3.6.1.4.1.21367.13.20.3000|69420&targetSystem=urn:oid:1.3.6.1.4.1.21367.13.20.1000&_format=json
```
---
-
-
-An error 403 Forbidden is returned when a target domain given in the target system parameter is not recognized by the
-Patient Registry.
-In the case of our request above, the value "urn:oid:1.3.6.1.4.1.21367.13.20.1000" is not recognized as a valid target
-domain containing Patients.
-Common mistakes with the target system are the same as the aformentioned error 400 since the target system and the
-source domain have the same representation.
+## Requests on Patient resources (ITI-104)
----
-
+___
-An error 404 Not Found is returned when the patient identifier given within the source identifier parameter is not
-recognized by the Patient registry.
-In the case of our request above, the value "69420" is not a valid Identifier linked to an existing Patient.
+- [IHE Specifications](https://profiles.ihe.net/ITI/PIXm/ITI-104.html)
---
-### Requests on Patient resources (ITI-93)
-
-PIXm connector implements query for ITI-93
+### Create/Update
-Many of those requests will take an ITI-93 Bundle as a Pramaeter
-
----
-
-#### Create
+Link: <https://profiles.ihe.net/ITI/PIXm/ITI-104.html#2310441-add-or-revise-patient>
PIXm connector accepts the creation of a Patient in the Patient Manager.
Although a Patient could be created without any information in the HL7 model, PIXm connector will only allow a Patient
-to be created with minimum information to permits cross referenciation.
-
-The request takes only one argument, a bundle with three required components :
-
-- A Message header.
-- A Bundle of type history, describing the Patient resource to be created.
-
-The "required" fields in the Patient are :
-
-- A name (either Family, or Given, or both).
-- A Country.
-- A Gender.
-- An Identifier. (?)
-
-A MessageHeader shall contains
-|Componant Name|cardinality|example or description|
-|-|-|-|
-|eventUri|[1..1]|urn:ihe:iti:pmir:2019:patient-feed|
-|focus|[1..1]|shall reference the url of Bundle|
-|sourceEndpoint|[1..1]|Actual message source address or id|
-|destination|[1..*]|The destination(s) of this feed|
-
-A history type bundle shall contains
-|Componant Name|cardinality|example or description|
-|-|-|-|
-|type|[1..1]|should be History
-|entry|[1..*]|the same Patient Resource shall not appear twice in this Bundle
-|entry.request.method|[1..1]|POST PUT DELETE
-|entry.request.url|[1..1]|The URL for this entry, relative to the root (the address to which the request is posted).
-|entry.response.status|[1..1]|The response status shall be an HTTP response status of 200
-
-If the Creation is succesful, an http response 200 will be returned, with a Bundle containing the Patient information,
-and an Endpoint to view the Patient in browser.
+to be created with minimum and/or mandatory information to permits cross-reference thanks to validation with Matchbox.
-If it's not the case, a myriad of error can be returned to help you pinpoint why your request cannot be interpreted.
-
----
-
-The Resource could not be parsed or failed basic FHIR validation rules. In the case of an error 400 being returned,
+The Resource could not be parsed or failed basic FHIR validation rules.
+In the case of an error `400 Bad Request` or `422 Unprocessable Entity` being returned,
please check the following guidelines to verify your query.
-- The Bundle does not countain minimum information needed for creation verify if the following arguments are given in
- the Patient and have the corresponding types and size.
- - A name (either Family, or Given, or both).
- - A Country.
- - A Gender.
- - An Identifier. (?)
-
-The Bundle might be malformed, and does not countain one of the main component
-
-- A Message header.
-- A Bundle of type history, describing the Patient resource to be created.
-
----
-
-Two main event can cause an 404 response.
-
-- The endpoint provided for the request might be wrong, check the validity of the url on your endpoint.
- Usually, your endpoint should look like
+Create/Update request is done through a FHIR conditional update mechanism ([cond-update](http://hl7.org/fhir/http.html#cond-update)) where the patient identifier has to be given as following.
```http
- {wildfly18.address}/pixm_fhir_server/fhir/ihe/Patient/$create?{Bundle}
+ PUT {wildfly18.address}/pixm-connector/fhir/Patient/identifier=urn:oid:1.3.6.1.4.1.21367.13.20.1000|IHERED-m94
```
-Check your wildfly18 address then, by opening it in a web browser you should get a 403 Forbidden error thrown out,
-indicating you're indeed pointing at the right server.
-
-- The other common reason causing this error is the Resource type asked not being supported by PIXm. This means the
- part "/Patient" in the url is not right, either because you choosed another Resource type (like an Observation or a
- Bundle instead of Patient) which does not support the operation create, or because you mistyped it.
-
----
-
-This error is complementary to the 400 Bad Request error. Whereas the 400 happens when the bundle is "syntactically"
-malformed. For example, a required element is not present in the bundle. The inside value of the parameter might be
-completly abnormal. In the case of an error 422, the Bundle object sent is **SEMANTICALLY** erroneous.
-
-In this case, check the core of your request, maybe the Message Header Value is incoherent. Maybe one of the value in
-the Patient does not have any endpoint.
-
-In this case the best way to solve this error is by checking the Payload sent to the server, maybe a Value is erroneous.
-This error case sends an Operation Outcome REsource with it, you should check it as it contains additional information
-about where the error shoud come from exactly.
+With body :
+
+```json
+
+{
+ "resourceType" : "Patient",
+ "id" : "Patient-MaidenAlice-Red",
+ "meta" : {
+ "profile" : [
+ "https://profiles.ihe.net/ITI/PIXm/StructureDefinition/IHE.PIXm.Patient"
+ ]
+ },
+ "text" : {
+ "status" : "generated",
+ "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p style=\"border: 1px #661aff solid; background-color: #e6e6ff; padding: 10px;\"><b>ALICE MOHR </b> female, DoB: 1958-01-30 ( id:\u00a0IHERED-m94)</p><hr/><table class=\"grid\"><tr><td style=\"background-color: #f3f5da\" title=\"Record is active\">Active:</td><td colspan=\"3\">true</td></tr></table></div>"
+ },
+ "identifier" : [
+ {
+ "system" : "urn:oid:1.3.6.1.4.1.21367.13.20.1000",
+ "value" : "IHERED-m94"
+ }
+ ],
+ "active" : true,
+ "name" : [
+ {
+ "family" : "MOHR",
+ "given" : [
+ "ALICE"
+ ]
+ }
+ ],
+ "gender" : "female",
+ "birthDate" : "1958-01-30"
+}
+```
----
-
-This error is surely none of your doing. If one of this occurs, send a Ticket to the corresponding authority providing
-you the service.
+If the patient exists then it is updated otherwise it is created.
+The response will return the updated/created patient.
---
+### Merge for resolving duplicated patient
-#### Update
+Link : <https://profiles.ihe.net/ITI/PIXm/ITI-104.html#2310442-resolve-duplicate-patient>
-The Update method allows the user to update a Patient in the Patient Registry through PIXm. The Request sent is the same
-as the create method, The endpoint is the only difference between the two, since it encapsulates the method used. It
-also needs the sourceIdentifier from the Patient to modify, if you're not sure about it, you can always use the @Read
-Method described under.
+The merge method allows the user to merge two patients together if two registered patients represent the same people.
+This action is **irreversible** as it deactivates a resource making it only readable and immutable.
-You can then follow the create operation explanation above for in-detail details about the parameters needed.
+The request is a PUT method with the Patient to deactivate with a `activate: false` attribute and a `link` field with identifier for the kept patient resource.
-The returned value is the Updated Patient.
-Error values returned contain the same as the Create operation and even more.
-We will not go through the errors already explained in the [Create section](#create) but will add information on the
-errors :
-
----
-
-Is returned when the token for authentication is not valid to perform this method.
+```http
+PUT http://example.org/fhir/Patient?identifier=urn:oid:1.3.6.1.4.1.21367.13.20.1000|IHERED-m94 HTTP/1.1
+Accept: application/fhir+json
+Content-Type: application/fhir+json
+```
+```json
+{
+ "resourceType": "Patient",
+ "identifier": [
+ {
+ "system": "urn:oid:1.3.6.1.4.1.21367.13.20.1000",
+ "value": "IHERED-m94"
+ }
+ ],
+ "active": false,
+ "name": [
+ {
+ "family": "MOHR",
+ "given": [
+ "MAIDEN"
+ ]
+ }
+ ],
+ "gender": "female",
+ "birthDate": "1958-01-30",
+ "link": [
+ {
+ "other": {
+ "identifier": {
+ "system": "urn:oid:1.3.6.1.4.1.21367.13.20.1000",
+ "value": "IHERED-994"
+ }
+ },
+ "type": "replaced-by"
+ }
+ ]
+}
+```
----
-
-When the resource pointed is not found
+### Delete one or more patient(s).
----
-
-When the resource sended is not of the same version as the resource stored in patient registry
+Link: <https://profiles.ihe.net/ITI/PIXm/ITI-104.html#2310443-remove-patient>
----
+The delete operation allows suppression of the patient with its identifier thanks to a conditional deletion.
+This application allows multiple deletion if the identifier returned more than one Patient.
-#### Merge
-The merge method allows the user to merge two patients together if it is deemed reasonable to think those two registered
-patients represent the same people
+````http
+DELETE http://example.org/fhir/Patient?identifier=urn:oid:1.3.6.1.4.1.21367.13.20.1000|IHERED-994 HTTP/1.1
+Accept: application/fhir+json
+````
----
+if the delete is successful the application returns a `200 OK` response otherwise it would be a `204 No Content`.
-#### Delete
+## Errors returned
---
-#### Read
-
+Malformed requests can cause different types of error, for now `422 Unprocessable Entity` is mostly returned.
+Future features will allow a better granularity for code returned.