HL7 ADT

[Joe Mesterhazy]

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]

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]

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]

Remark 1:
The restfull documentaton is on the website :)

[Alain Mazy]

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

[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]

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 

a...@osimis.io / +32 494 31 67 27

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