0.2.0 - ci-build
ONCOnnectTumorboardIG - Local Development build (v0.2.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
To register a patient for one of the available tumorboards through our API, you need to create a FHIR Bundle containing all relevant resources.
The Bundle must be of type transaction. For a new registration all entries must have a request element with a POST method.
You can orientate yourself on the provided example Bundle, which combines all the example resources from all our profiles.
If you're looking for info on how to add files to a registration, take a look at the file attachments documentation.
The ServiceRequest is the core of every registration. Each available tumorboard has its own profile derived from this base profile, which can modify the requirements.
| Tumorboard | Profile | Changes from base profile | API endpoint |
|---|---|---|---|
| MTB WTZ Essen | onconnect-pr-tb-registration-wtz-mtb | None | https://tumorboards.staging.test.ccc-onconnect.de/api/fhir/wtz-mtb/register |
| Sarkomboard WTZ Essen | In progress | / | / |
| MTB Charité Berlin | In progress | / | / |
Properties:
intent: required by the base profile, but not actually used. Using plan is suggested.category: Use a code from the provided ValueSet.subject: Reference the patient (see below).requester: Reference the role of the requester (see below). Don't link directly to the requester.note: Include at least one note with text containing the written request for the tumorboard. Additional notes will be displayed as comments in the UI, so make sure to include an author and date with them.supportingInfo: Every other resource included in the bundle must be referenced here. This includes the patient and the requester even though they are already referenced above. The profile lists the minimum required resources, but even if some are not directly listed there (e.g. FamilyMemberHistory entries from a family history), you must still include them here. You will get an error if the length of the list doesn't match the number of other resources in your bundle.
status: Automatically set to active server-side when the registration is created.meta.profile: Automatically set server-side based on the selected tumorboard.meta.tag: Automatically set to the current version of the tumorboard profile server-side.The patient profile is based on the MII Patient. Additionally you need to provide a Versicherungsnummer (KVNR) and a PID, an ID to identify the patient within your own system and the patient's name and birth date are also required fields.
The primary diagnosis profile is based on the MII Onkologie Diagnose. It represents the main tumor diagnosis for which the patient is being registered for the tumorboard.
Properties:
clinicalStatus: Use a code from the provided ValueSet. Most of the time this will be either active or recurrence.verificationStatus: Use a code from the provided ValueSet.code: A diagnosis code from ICD-10-GM is required. An additional code from OncoTree and/or the ICD-O morphology should be provided if available.bodySite: Optionally provide the ICD-O topography code for the tumor location if available.subject: Reference the patient (see above).recordedDate and extension.Feststellungsdatum: Both are required by the MII profile. We think it's very likely that they will be the same date in most cases. Let us know if you have a use case, where they should be handled differently.stage: To make it easier to differentiate between different staging systems, please include the system of the staging in the type field of the stage, even though this will likely duplicate information from the code field of the Observation.
ECOG Profile / Karnofsky Profile
The general condition of the patient can be represented either by an ECOG or Karnofsky score. Neither is required, but if you have this information available, please include it. Make sure to set the effectiveDateTime since the patient's condition can change over time.
The oncological history profile is a List containing a variety of other resources representing the patient's oncological history. For simplicity only the note field is required for all entries. Since MII profiles would have additional required fields, the profile only requires the base resource types. The MII profiles are nevertheless recommended since they provide a more structured representation of the data.
The TNM staging is part of the oncological history and based on the MII Onkologie TNM Staging. It consist out of one main wrapping Observation resource with the UICC staging and multiple component Observations for the individual T, N and M values (or others, see the MII profiles) using hasMember references.
It is possible to include multiple TNM stagings in the oncological history, e.g. if the patient was restaged at a later date, so make sure to set the effectiveDateTime correctly.
The comorbidities profile is a List containing MII Diagnose Conditions.
You can use the note field of the List to provide additional information about comorbidities that aren't captured in a structured way.
List Profile / Family Member History Profile
The family history profile is a List containing FamilyMemberHistory resources. Track the relationship, conditions and deceased fields if you can. You can use the text field if capturing this information in a structured way is not possible. If you don't have any family history information available, you can also include an empty List with a valid emptyReason. This is to differentiate between the case where no family history was taken and the case where there is simply no relevant family history.