Suppose we want to send a patient's country and zip code information for someone who lives in Brussels, Belgium:

At the moment, in S2S submissions, in the case of fields containing code list elements, we send the code ID in the body of the message, like so:

"CD_CNTRY_RES": "130349",
"CD_POSTCODE": "4525",

This is not what happens in CSV upload, where we send the code value of the code object. The same will be used now in the new architecture 2.5 for System-To-System submission using the API. So, for the example above, this will be the new way of sending the same values:

"CD_CNTRY_RES": "BE", "CD_POSTCODE": "1000",

The following image shows the relationship between these fields in the database, in the case of the country:

And for the postal code:

The purpose of this change is to stop sending the code IDs in S2S and start sending the code values, as we have today in the CSV upload. More than that, for performance improvements, the service that returns the code value for a given ID is done through a single request per submission to the MDM, thus saving a lot of time in calls to get these values.

Since the code value is not unique, we need to get the codelist ID of an element, given its key, from a given DCD version ID. This could be summarized, in this example, as:

The key CD_CNTRY_RES on DCD version ID 55 (BSACC Police And Public Prosecutor) has the codelist id 347.
The key CD_POSTCODE on DCD version ID 55 (BSACC Police And Public Prosecutor) has the codelist id 12.

Code Lists and Code Values are agreed by IAT and the Researchers. These are sent to DC by IAT via the specifications. A Code ID is the identification of a Code Value in MDM. So how to do the translation?

In the case of sending code IDs, the user should call our services to retrieve the code IDs through requests to our API. In these requests, the user always receives back the complete code object, containing not only the code ID, but also the code value. Let’s see an example for the country code (code list 347):

So here we can see how we were sending the code ID 130349 in System-To-System and how we can send the code value “BE” in architecture 2.5, the same way that was done already using the CSV Uploader.

In terms of code, if we were already calling the services to get the code ID, the only thing that is necessary is changing the returned value from CodeID to CodeValue from the same Code object that is returned.

FROM:

mappedCode = codeFieldService.getFieldCode(field.getFieldId(), codeContent).codeId();

TO: 

mappedCode = codeFieldService.getFieldCode(field.getFieldId(), codeContent).codeValue();

That’s the only change needed in the mapping. All the rest continues exactly the same.

For more information, please check our docs page:
1. End-to-End process to submit DCD registrations | docs.healthdata.be

Architecture 2.0 and Architecture 2.5 proxies

As requested, two proxies were created to make the two current solutions available: Architecture 2.0 and Architecture 2.5

For the TEST environment, this it the configuration:

• Architecure 2.0 at https://hd4dptest.healthdata.be/proxy/
• Architecture 2.5 at https://hd4dptest.healthdata.be/proxy25/

Architecture 2.5 is compatible with Architecture 2.0, it only contains code improvements. To see the differences we can, for instance, call the service to get a project-result in both proxies:

Architecture 2.0
https://hd4dptest.healthdata.be/proxy/api/installation/project-result?organization-id=8429

[{"projectId":4,"dcdId":9,"dcdVersionId":9,"version":1,"formioName":"hdbp0231ZephyrZephyrPrimImplt1"}, {"projectId":4,"dcdId":10,"dcdVersionId":10,"version":1,"formioName":"hdbp0231ZephyrZephyrReplac1"}, {"projectId":4,"dcdId":11,"dcdVersionId":11,"version":1,"formioName":"hdbp0231ZephyrZephyrFllwup1"}, {"projectId":5,"dcdId":12,"dcdVersionId":12,"version":3,"formioName":"hdbp0062BelPstSpineTangoIntake1"}, {"projectId":5,"dcdId":13,"dcdVersionId":13,"version":3,"formioName":"hdbp0062BelPstSpineTangoConservativeTherapy1"}, {"projectId":5,"dcdId":14,"dcdVersionId":14,"version":3,"formioName":"hdbp0062BelPstSpineTangoPatientQuestionnaire1"}, {"projectId":5,"dcdId":15,"dcdVersionId":15,"version":3,"formioName":"hdbp0062BelPstSpineTangoSurgery1"}, {"projectId":6,"dcdId":16,"dcdVersionId":16,"version":1,"formioName":"hdbp0000TestTestDcd011"}, {"projectId":6,"dcdId":17,"dcdVersionId":17,"version":1,"formioName":"hdbp0000TestTestDcd021"}, {"projectId":7,"dcdId":18,"dcdVersionId":18,"version":1,"formioName":"hdbp0386OrthoprideHipOpHipPrimImplt1"}, {"projectId":7,"dcdId":19,"dcdVersionId":19,"version":1,"formioName":"hdbp0386OrthoprideHipOpHipRevis1"}, {"projectId":7,"dcdId":20,"dcdVersionId":20,"version":1,"formioName":"hdbp0386OrthoprideHipOpHipResec1"}, {"projectId":8,"dcdId":21,"dcdVersionId":21,"version":1,"formioName":"hdbp0288OrthoprideKneeOpKneePrimImplt1"}, {"projectId":8,"dcdId":22,"dcdVersionId":22,"version":1,"formioName":"hdbp0288OrthoprideKneeOpKneeRevis1"}, {"projectId":8,"dcdId":23,"dcdVersionId":23,"version":1,"formioName":"hdbp0288OrthoprideKneeOpKneeResec1"}, {"projectId":9,"dcdId":24,"dcdVersionId":24,"version":1,"formioName":"hdbp0048OrthoprideMegaOpMpPrimImplt1"}, {"projectId":9,"dcdId":25,"dcdVersionId":25,"version":1,"formioName":"hdbp0048OrthoprideMegaOpMpRevis1"}, {"projectId":9,"dcdId":26,"dcdVersionId":26,"version":1,"formioName":"hdbp0048OrthoprideMegaOpMpResec1"}, {"projectId":1,"dcdId":1,"dcdVersionId":30,"version":3,"formioName":"hdbp0025HhNsihHhPre3"}, {"projectId":1,"dcdId":2,"dcdVersionId":31,"version":3,"formioName":"hdbp0025HhNsihHhIo3"}, {"projectId":1,"dcdId":3,"dcdVersionId":32,"version":3,"formioName":"hdbp0025HhNsihHhPost3"}, {"projectId":10,"dcdId":27,"dcdVersionId":33,"version":1,"formioName":"hdbp0245TaviTaviImplt1"}, {"projectId":10,"dcdId":28,"dcdVersionId":34,"version":1,"formioName":"hdbp0245TaviTaviFllwup1"}, {"projectId":11,"dcdId":29,"dcdVersionId":35,"version":1,"formioName":"hdbp0000CorrectionForm1"}, {"projectId":13,"dcdId":34,"dcdVersionId":40,"version":2,"formioName":"hdbp0016PacemakerQermidPacemakerPrimoImplantation2"}, {"projectId":13,"dcdId":35,"dcdVersionId":41,"version":2,"formioName":"hdbp0016PacemakerQermidPacemakerAjoutRemplacementElectrode2"}, {"projectId":13,"dcdId":36,"dcdVersionId":42,"version":2,"formioName":"hdbp0016PacemakerQermidPacemakerRemplacement2"}, {"projectId":13,"dcdId":37,"dcdVersionId":43,"version":2,"formioName":"hdbp0016PacemakerQermidPacemakerExplantation2"}, {"projectId":13,"dcdId":38,"dcdVersionId":44,"version":2,"formioName":"hdbp0016PacemakerQermidPacemakerSuivi2"}, {"projectId":14,"dcdId":39,"dcdVersionId":45,"version":3,"formioName":"hdbp0019Bewsd3"}, {"projectId":15,"dcdId":40,"dcdVersionId":46,"version":2,"formioName":"hdbp0012AngioHospitalisatie2"}, {"projectId":15,"dcdId":41,"dcdVersionId":47,"version":2,"formioName":"hdbp0012AngioHospitalisatieMetPci2"}, {"projectId":15,"dcdId":42,"dcdVersionId":48,"version":2,"formioName":"hdbp0012AngioHospitalisatieMetFfr2"}, {"projectId":15,"dcdId":43,"dcdVersionId":49,"version":2,"formioName":"hdbp0012AngioHospitalisatieMetFfrEnPci2"}, {"projectId":15,"dcdId":44,"dcdVersionId":50,"version":2,"formioName":"hdbp0012AngioFollowUpNaPci2"}, {"projectId":16,"dcdId":45,"dcdVersionId":51,"version":1,"formioName":"hdbp0240Spine1"}, {"projectId":17,"dcdId":46,"dcdVersionId":52,"version":4,"formioName":"hdbp0008Crrd4"}, {"projectId":19,"dcdId":48,"dcdVersionId":54,"version":1,"formioName":"hdbp0242BsaccMeBsaccReprt1"}, {"projectId":19,"dcdId":49,"dcdVersionId":55,"version":1,"formioName":"hdbp0242BsaccMeBsaccFuPolce1"}, {"projectId":19,"dcdId":50,"dcdVersionId":56,"version":1,"formioName":"hdbp0242BsaccMeBsaccFuCont1"}, {"projectId":19,"dcdId":51,"dcdVersionId":57,"version":1,"formioName":"hdbp0242BsaccMeBsaccFuReferral1"}, {"projectId":19,"dcdId":52,"dcdVersionId":58,"version":1,"formioName":"hdbp0242BsaccMeBsaccFuMed1"}, {"projectId":19,"dcdId":53,"dcdVersionId":59,"version":1,"formioName":"hdbp0242BsaccMeBsaccFuPsychc1"}, {"projectId":20,"dcdId":54,"dcdVersionId":60,"version":9,"formioName":"hdbp0001Bcfr9"}, {"projectId":21,"dcdId":55,"dcdVersionId":61,"version":3,"formioName":"hdbp0078Pitter3"}, {"projectId":22,"dcdId":56,"dcdVersionId":62,"version":3,"formioName":"hdbp0051Becpr3"}, {"projectId":23,"dcdId":57,"dcdVersionId":63,"version":1,"formioName":"hdbp0037Epilabo1"}, {"projectId":24,"dcdId":58,"dcdVersionId":64,"version":1,"formioName":"hdbp0244RProfildRprofildTreat1"}, {"projectId":24,"dcdId":59,"dcdVersionId":65,"version":1,"formioName":"hdbp0244RProfildRprofildRenewal1"}, {"projectId":25,"dcdId":60,"dcdVersionId":66,"version":1,"formioName":"hdbp0274HartDefibDefibPrimImplt1"}, {"projectId":26,"dcdId":61,"dcdVersionId":67,"version":1,"formioName":"hdbp0056MvoMvoImp1"}, {"projectId":26,"dcdId":62,"dcdVersionId":68,"version":1,"formioName":"hdbp0056MvoMvoFu1"}, {"projectId":25,"dcdId":63,"dcdVersionId":69,"version":1,"formioName":"hdbp0274HartDefibDefibExpl1"}, {"projectId":25,"dcdId":64,"dcdVersionId":70,"version":1,"formioName":"hdbp0274HartDefibDefibRepl1"}, {"projectId":25,"dcdId":65,"dcdVersionId":71,"version":1,"formioName":"hdbp0274HartDefibDefibElect1"}, {"projectId":27,"dcdId":67,"dcdVersionId":72,"version":1,"formioName":"hdbp0000DvrForm1"}]

Architecture 2.5
https://hd4dptest.healthdata.be/proxy25/api/installation/project-result?organization-id=8429&dcd-id=49

[{"projectId":19,"dcdId":49,"dcdVersionId":55,"version":1,"formioName":"hdbp0242BsaccMeBsaccFuPolce1"}]

As we can see, using proxy (Architecture 2.0) we have all projects from organization 8429, while proxy25 (Architecture 2.5) returns only one element in its response. This is because the DCD filter in proxy25 is done in the database (more efficient) while in the proxy the same filter is done in the code after the service call. So the filter is not used in the first call and if Architecture 2.0 calls the same service in Architecture 2.5 without the filter (https://hd4dptest.healthdata.be/proxy25/api/installation/project-result?organization-id=8429) it will get exactly the same result.

Architecture 2.0 and Architecture 2.5 proxies tests

CSV Uploader

For the CSV Upload, nothing has changed. So the same inputs are valid for both architectures. Here are the example of some successful tests:

System-To-System

For S2S, as already mentioned, the only difference is that Architecture 2.0 sends Code IDs while Architecture 2.5 sends Code Values. Here are the same tests in both architectures:

Proxy (Architecture 2.0):

Proxy25 (Architecture 2.5):

As we can see, we have the same request, where the first sends Code IDs and the second sends Code Values; both return a successful response.

Front-end

In the front-end (GUI) everything is received normally as the same request was sent twice, because in both cases, S2S will always send the same request with Code IDs to FormIO.

Data Warehouse

Once again, all the information arrived seamlessly, and it should be because the FormIO validation already happened in the previous step:

First call (Architecture 2.0):

Second call (Architecture 2.5):