Generated fake patient mtb data does not match generated JSON schema for coding

[pcvolkmer]

The generated fake patient mtb data does not match generated JSON schema.

Sources

Schema file and fake data are generated from example DNPM:DIP source:

• Schema: https://dnpm.bwhealthcloud.de/api/mtb/etl/patient-record/schema
• Fake Data: https://dnpm.bwhealthcloud.de/api/mtb/fake/data/patient-record

Comparison

This will compare an example part of Schema with generated mtb data.

Definitions in schema

For example, a Patient is defined as:

"patient": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
...
        "gender": {
          "$ref": "#/definitions/Gender"
        },
        "birthDate": {
          "$ref": "#/definitions/YearMonth"
        },
 ...
    }

Gender is defined as:

    "Gender": {
      "type": "string",
      "enum": [
        "female",
        "male",
        "other",
        "unknown"
      ]
    },

Generated fake patient mtb data

Same part in generated fake patient mtb data does not use a string but an object:

  "patient": {
    "id": "fbd23d0b-f81b-4a2f-b53b-e93871069cfd",
    "gender": {
      "code": "male",
      "display": "Männlich",
      "system": "Gender"
    },
    "birthDate": "1977-01-01",
  ...
  }

Conclusion

The gender (and all other object values using a coding scheme) should use some kind of schema definition containing code, display and system.

[lucienclin]

Thanks for the issue report, but this is just a temporary inconsistency:

The generated MTBPatientRecords conform to the internally used model, already aligned with "MTB Datensatz V2.0". However, the working basis over the last months has been that the ETL API should support MTB data submissions according to the format already established in bwHC, using an internal conversion of such payloads into the internal format.

Thus, the default JSON schema returned by the API represents this previous MTBPatientRecord format ("application/json"), thus leading to the apparent inconsistency between schema and JSON examples. However, you can explicitly request the JSON Schema of the new format "application/json+v2" by passing this content-type as query parameter in the JSON Schema request: GET /api/mtb/etl/patient-record/schema?format=application/json%B2v2

See also: https://github.com/KohlbacherLab/dnpm-dip-api-gateway/blob/50d5d888b70a49513319ee4c08f74c6db33f1892/app/controllers/de/dnpm/dip/rest/api/MTBRouter.scala#L37

About the two formats: The new format aligned to "MTB Datensatz V2.0" already contains most new elements specified, but given that essentially all are optional, they don't represent particular breaking changes. The main differences from the new to the previous bwHC format, and thus breaking changes are:

• Use of a dedicated Reference type for references among objects, in contrast to mere ID strings as previously.
• Consistent use of Coding objects for any attributes coming from CodeSystems/terminology, thus also e.g. for Patient.gender or Patient.vitalStatus, in contrast to previously.

However, in course of finalizing the changes to the MTBPatientRecord to conform to regulations of the model project (MVH), the previous "bwHC format" will not be supported anymore after all, but only the new one, so that JSON Schema and generated JSON examples will eventually be consistent with each other.