Forgive me if this has been asked before, but I’m curious if anyone has implemented an ADT interface for Orthanc? I am looking at using Orthanc as longer-term storage solution, which means patient demographics could change over time, which in our institution means ADT-A08 and ADT-A40 messages. This would necessary to keep Orthanc in-sync with our PACS and RIS.
I could cook something up with MIRTH and the Orthanc REST API but was just curious if anyone else has gone down this path already?
I am personally not aware of such a ADT interface for Orthanc. But maybe some Orthanc user has been working on this topic? Do not hesitate to let us know or to contribute
Forgive me if this has been asked before, but I'm curious if anyone has implemented an ADT interface for Orthanc? I am looking at using Orthanc as longer-term storage solution, which means patient demographics could change over time, which in our institution means ADT-A08 and ADT-A40 messages. This would necessary to keep Orthanc in-sync with our PACS and RIS.
I could cook something up with MIRTH and the Orthanc REST API but was just curious if anyone else has gone down this path already?
Joe
Hi Joe,
I believe you are going in the right direction.
Orthanc does not integrate an HL7 engine that would get:
Therefore, you need to cook something yourself with
Hospital Information System > Mirth
Mirth does HL7 parsing and connect to the REST interface of Orthanc
Mirth might be able to correct stuff in the SQL DB of Orthanc
For example:
ADT A40 or A18 patient merge would go into Mirth
Mirth would convert this into modfication in the Orthanc DB
The probleme beeing:
any Merge request coming from a HIS and applied in RIS, PACS or any other EMR should be tracked in the GUI of the RIS / PACS / EMR
any merge request applied should be easily reversed if it was a mistake
any merge request should be able to be applied automatically or manually depending on criteria
Therefore, you need to cook something yourself with
> Hospital Information System > Mirth
> Mirth does HL7 parsing and connect to the REST interface of Orthanc
> Mirth might be able to correct stuff in the SQL DB of Orthanc
Modifying the SQL DB directly is really not recommended (that's the main
reason why we do not document the schema !).
Would you modify a PatientName in the SQL DB, the Dicom files would not be
affected so your data would be inconsistent.
I strongly recommend to use /patients/{id}/modify REST API routes to
implement the patient merge/modification.
am@osimis.io / +32 494 31 67 27
[image: Osimis]
OSIMIS S.A.
Rue bois Saint-Jean 15/1BE-4102 Seraing
www.osimis.io
Therefore, you need to cook something yourself with
> Hospital Information System > Mirth
> Mirth does HL7 parsing and connect to the REST interface of Orthanc
> Mirth might be able to correct stuff in the SQL DB of Orthanc
Modifying the SQL DB directly is really not recommended (that's the main reason why we do not document the schema !).
Would you modify a PatientName in the SQL DB, the Dicom files would not be affected so your data would be inconsistent.
I strongly recommend to use /patients/{id}/modify REST API routes to implement the patient merge/modification.
a...@osimis.io / +32 494 31 67 27
OSIMIS S.A.
Rue bois Saint-Jean 15/1BE-4102 Seraing
www.osimis.io
Hi Alain,
Your answer perfectly makes perfect sense.
My question would be
a modification through the REST API changes the DB and the DICOM files as well ? Is a trace of the modification stored somewhere ?
in the case of 1 million modifications how is this impacting the DICOM ?
(we might have to deal with patient ID unification / standardisation in France in the next 3 years) files in terms of how many modification per second can be handled ?
How many Patient ID can be stored in the PostreSQL DB ?
if only one, I suggest the DB stores up to 64 or 128 patient IDs
if a request to merge two patient ID arrives, Orthanc should keep track of
- when the request was made
- what was the supposingly wrong patient ID
- what was the supposing good patient ID
- suggest to reverse any modification that was made (un-merge)
If Orthanc has stored an HL7 ORU message it the PostgreSQL DB containing the reports / diagnostic of the study. Is the modification of patient ID beeing propagating to it ? or only propagated to DICOM tags ?
My question would be
> a modification through the REST API changes the DB and the DICOM files
as well ? Is a trace of the modification stored somewhere ?
Yes, through the API, both the DB and the DICOM files are modified. There
is trace recorded in the 'ModifiedFrom' metadata but this would assume that
you keep the original data in the DB too which is not optimal !
> in the case of 1 million modifications how is this impacting the DICOM ?
(we might have to deal with patient ID unification / standardisation in
France in the next 3 years) files in terms of how many modification per
second can be handled ?
I currently do not have these figures. As a rough estimate, a single
Orthanc should be able to modify 30 files per seconds. Note that, you can
create a cluster of Orthanc to speed up such processes so, at some point,
your PostgreSQL DB and your file storage will be the bottleneck, not
Orthanc.
> How many Patient ID can be stored in the PostreSQL DB ?
A single one
> if only one, I suggest the DB stores up to 64 or 128 patient IDs
> if a request to merge two patient ID arrives, Orthanc should keep track
of
- when the request was made
- what was the supposingly wrong patient ID
- what was the supposing good patient ID
- suggest to reverse any modification that was made (un-merge)
If Orthanc has stored an HL7 ORU message it the PostgreSQL DB containing
the reports / diagnostic of the study. Is the modification of patient ID
beeing propagating to it ? or only propagated to DICOM tags ?
We usually consider Orthanc as a microservice to store DICOM files. All
the HL7 interface and, patient ID handling, ... might be implemented by
another microservice that uses Orthanc as a storage. There is actually no
plan in the short-term roadmap to have HL7 interface directly implemented
in Orthanc.
I’m currently in the process of implementing a PIX Manager that needs to interact with various systems within our practice, including Orthanc. To establish a baseline, I’ve chosen to learn from IHE ITI-10, which utilizes ADT^A31.
I am using the REST API, definitely not accessing the DB directly. (However, there’s a minor challenge in that the API employs a dynamic Orthanc ID, generated from the sha1 of the PatientID DICOM tag. Consequently, it changes everytime i need to make a PatientID correction, and I don’t have a static patient ID to work with in my PIX Manager, which adds an extra layer of complexity.)
As Johan mentioned, keeping track of all changes and history is crucial. However it is within the scope of the PIX Manager’s functionality, not Orthanc’s; having an ADT^A31 listener module for Orthanc could greatly enhance our workflow. If I were to consider developing such a module myself, I would greatly appreciate the community’s recommendations and insights on best practices for its implementation.
Your guidance and expertise would be highly valuable in this endeavor. Thank you for any recommendations or suggestions you can provide.
