HL7 ADT

232 views
Skip to first unread message

Joe Mesterhazy

unread,
Dec 5, 2016, 2:51:04 PM12/5/16
to Orthanc Users
Hi all, 

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


Sébastien Jodogne

unread,
Dec 5, 2016, 3:22:24 PM12/5/16
to Orthanc Users
Hi Joe,

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 :)

Cheers,
Sébastien-

johan.z...@gmail.com

unread,
Jul 2, 2017, 6:34:16 PM7/2/17
to Orthanc Users
Hi Joe,

I believe you are going in the right direction.

Orthanc does not integrate an HL7 engine that would get:
> Patient admission
> patient merge
> patient modification
etc

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


The main question beeing:
> where is the full documentation of the RESTFull implementation of Orthanc ? :)

> Is the DB scheme and access right provided by default ?





johan.z...@gmail.com

unread,
Jul 2, 2017, 6:39:04 PM7/2/17
to Orthanc Users, johan.z...@gmail.com
Remark 1:
The restfull documentaton is on the website :)

Alain Mazy

unread,
Jul 3, 2017, 3:53:31 AM7/3/17
to johan.z...@gmail.com, Orthanc Users

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

OSIMIS S.A. 
Rue bois Saint-Jean 15/1BE-4102 Seraing 
www.osimis.io

Twitter LinkedIn


johan.z...@gmail.com

unread,
Jul 3, 2017, 6:18:06 AM7/3/17
to Orthanc Users, johan.z...@gmail.com
Le lundi 3 juillet 2017 09:53:31 UTC+2, Alain Mazy a écrit :
> 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 ?

Cheers

Johan














Alain Mazy

unread,
Jul 4, 2017, 3:38:18 AM7/4/17
to Johan Zoli, Orthanc Users

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.

Br,

Alain
 
Cheers

Johan

















--

Alain Mazy / CTO 

Osimis

OSIMIS S.A. 
Rue bois Saint-Jean 15/1BE-4102 Seraing 
www.osimis.io

Twitter LinkedIn


Reply all
Reply to author
Forward
0 new messages