Posts by jheleniak

    We moved cloud server to faster storage and haven't had the errors since. The disks were performing horribly under high load and I think when it couldn't handle it, it started to cause dicom communication errors and even a few SQL save issues. Hopefully it's gone. It's weird how the setting to 0 did help the issue at the time though.

    I am using JK on both forwarders. I've never seen this on a forwarder with multiple threads with UN either. It is basically two dual core conquest servers forwarding from 2 remote sites to a cloud conquest server. it kind of went away now that i turned release to 0 but occurred frequently before changing. No other errors like command failed FFFF either except the one and only time. I use the JK because it seems to be the highest ratio and didn't conflict with proprietary tags even though it takes a little longer to compress.


    using both rc6 and final latest build with 5.1 and 5.5 mysql. It seemed to happen when say the cloud box was receiving either multiple studies simultaneously from the same forwarder or from 2 forwarders at the same time. I think i was able reproduce by performing 2 cmoves to the forwarder and it started to happen. Could always have been a problem on receiving end with keeping up but I will try to collect for info.

    I haven't seen any failed on sending side and multiplex on receiving side since making this change.


    I also came up with a new idea. If CRCs are pretty much random sort of speak. There is not really any consistency to how many of 10 images are going to go to each thread. I thought that since all images have an Instance Number (at least should have right) that using this way, you always distribute images evenly across 10 threads. Do you see any downside to this algorithm (last number in Instance Number string) or any case when an image would be left out and if so can I create a catch all thread for an image without a Instance Number NOT BETWEEN *0-*9?


    ForwardAssociationLevel = SERIES
    ForwardAssociationCloseDelay = 15
    ForwardAssociationRefreshDelay = 3600
    ForwardAssociationRelease = 0


    ExportConverters = 10
    ExportConverter0 = ifmatch "%V0020,0013", "*0"; forward compressed as jk to CONQUEST2
    ExportConverter1 = ifmatch "%V0020,0013", "*1"; forward compressed as jk to CONQUEST2
    ExportConverter2 = ifmatch "%V0020,0013", "*2"; forward compressed as jk to CONQUEST2
    ExportConverter3 = ifmatch "%V0020,0013", "*3"; forward compressed as jk to CONQUEST2
    ExportConverter4 = ifmatch "%V0020,0013", "*4"; forward compressed as jk to CONQUEST2
    ExportConverter5 = ifmatch "%V0020,0013", "*5"; forward compressed as jk to CONQUEST2
    ExportConverter6 = ifmatch "%V0020,0013", "*6"; forward compressed as jk to CONQUEST2
    ExportConverter7 = ifmatch "%V0020,0013", "*7"; forward compressed as jk to CONQUEST2
    ExportConverter8 = ifmatch "%V0020,0013", "*8"; forward compressed as jk to CONQUEST2
    ExportConverter9 = ifmatch "%V0020,0013", "*9"; forward compressed as jk to CONQUEST2

    Besides being a transfer syntax issue, what else actually can cause this? It happens time to time when I open up a lot of associations concurrently to another conquest server. After the tcp/ip timeout is reached it seems to starts accept more connections again but never really stops accepting connections. On the sending side it always just says


    20110414 10:27:42 *** ExportConverter9.1: Forward failed to connect to host SERVER
    20110414 10:27:42 *** Queue: holding processing of file C:\dicomserver1416rc6\Data\12345\1.2.840.113704.7.1.1.37086.dcm


    which isnt true because the server is accessible because it continues to receive on other threads. And once it tries again it goes through fine after the timoeut. It's just really weird...it only happens when it's sending a ton of images at the same time. Happens on LAN and WAN connections when using



    ForwardAssociationLevel = SERIES
    ForwardAssociationCloseDelay = 15
    ForwardAssociationRefreshDelay = 3600
    ForwardAssociationRelease = 1


    ExportConverters = 10
    ExportConverter0 = ifnumequal "%A0008,0018[0,0]", "0"; forward compressed as jk to SERVER
    ExportConverter1 = ifnumequal "%A0008,0018[0,0]", "1"; forward compressed as jk to SERVER
    ExportConverter2 = ifnumequal "%A0008,0018[0,0]", "2"; forward compressed as jk to SERVER
    ExportConverter3 = ifnumequal "%A0008,0018[0,0]", "3"; forward compressed as jk to SERVER
    ExportConverter4 = ifnumequal "%A0008,0018[0,0]", "4"; forward compressed as jk to SERVER
    ExportConverter5 = ifnumequal "%A0008,0018[0,0]", "5"; forward compressed as jk to SERVER
    ExportConverter6 = ifnumequal "%A0008,0018[0,0]", "6"; forward compressed as jk to SERVER
    ExportConverter7 = ifnumequal "%A0008,0018[0,0]", "7"; forward compressed as jk to SERVER
    ExportConverter8 = ifnumequal "%A0008,0018[0,0]", "8"; forward compressed as jk to SERVER
    ExportConverter9 = ifnumequal "%A0008,0018[0,0]", "9"; forward compressed as jk to SERVER

    I think I figured it out. I had to add apostrophes to the exporter code. I'm not sure if using ifnumequal makes any difference from using ifequal but i'm leaving it alone as it works. It is slinging images out very quick though over wan because it is usually threading 8-10 at a time. For anyone that wants to forward images and saturate a wan link. This is definitely the best speed I've been able to get so far from exporters and traversing higher latency links. Thanks so much Marcel.


    ExportConverters = 10
    ExportConverter0 = ifnumequal "%A0008,0018[0,0]", "0"; forward compressed as j1 to NRADSTORE
    ExportConverter1 = ifnumequal "%A0008,0018[0,0]", "1"; forward compressed as j1 to NRADSTORE
    ExportConverter2 = ifnumequal "%A0008,0018[0,0]", "2"; forward compressed as j1 to NRADSTORE
    ExportConverter3 = ifnumequal "%A0008,0018[0,0]", "3"; forward compressed as j1 to NRADSTORE
    ExportConverter4 = ifnumequal "%A0008,0018[0,0]", "4"; forward compressed as j1 to NRADSTORE
    ExportConverter5 = ifnumequal "%A0008,0018[0,0]", "5"; forward compressed as j1 to NRADSTORE
    ExportConverter6 = ifnumequal "%A0008,0018[0,0]", "6"; forward compressed as j1 to NRADSTORE
    ExportConverter7 = ifnumequal "%A0008,0018[0,0]", "7"; forward compressed as j1 to NRADSTORE
    ExportConverter8 = ifnumequal "%A0008,0018[0,0]", "8"; forward compressed as j1 to NRADSTORE
    ExportConverter9 = ifnumequal "%A0008,0018[0,0]", "9"; forward compressed as j1 to NRADSTORE

    Good to know for others too I guess. I will try to exporter and see what happens. On the forwarder.....it does it really really fast however it seems to be sending the same images over and over frequently?! Could this be? Do you have to be running mysql or can you use built-in database for this exporter to properly work? Can you do a ends with type logic to split it up or even a series number ends in X to split the threads out.

    I've tried both forward STUDY and forward to. Here are my configs. I'm actually forwarding a few times. From a client site with CT to a cloud conquest server back to another hospital conquest server...a few links have 50ms. I'm forwarding by image on the second forward because it seems to keep up with the first forward real-time. It works great but the bandwidth is not being pushed to the limits at all. it could easily handle 2-3 threads of forwarding but I'm not sure if that's possible or you would have to open up additional series associations and thread by series because image associations would probably kill the idea. Also images from a Philps Brilliance 16 doesn't compress all images with NKI but did with JPEG Lossless for some reason ( only half the study's images compresses). j2 definitely helps forwarding times but not sure why NKI couldn't compress all images like JPEG Lossless.



    CT(uncompressed) ---> CONQUEST1 (store j2)-----------forward STUDY compressed as j2----CONQUEST2(store j2)---------forward compressed as j2----> CONQUEST3 (store j2)



    Configuration of forwarding and/or converter programs to export DICOM slices
    ForwardAssociationLevel = SERIES
    ForwardAssociationCloseDelay = 15
    ForwardAssociationRefreshDelay = 3600
    ForwardAssociationRelease = 1


    ExportConverters = 1
    ExportCalledAE0 = CONQUEST1
    ExportConverter0 = forward STUDY compressed as j2 to CONQUEST2


    ForwardCollectDelay = 180
    MaximumExportRetries = 0
    MaximumDelayedFetchForwardRetries = 0



    # Configuration of forwarding and/or converter programs to export DICOM slices
    ForwardAssociationLevel = SERIES
    ForwardAssociationCloseDelay = 15
    ForwardAssociationRefreshDelay = 3600
    ForwardAssociationRelease = 1


    ExportConverters = 1
    ExportCalledAE0 = CONQUEST2
    ExportConverter0 = forward compressed as j2 to CONQUEST3


    MaximumExportRetries = 0
    MaximumDelayedFetchForwardRetries = 0

    I've been testing forwarding performance over WAN links that contain a rather normal latency (ie. 50-60ms), it becomes very hard to saturate a single tcp session/DICOM association.


    Since DICOM has many handshakes and is very chatty during negotiation/transmission is there any possibility of creating two or three simultaneous threads to maximize throughput? It seems to me that if it was possible, forwarding speeds could possibly be doubled or tripled if a single thread isn't saturating the entire bandwidth. Playing with tcp window sizes only goes so far when trying to push data over connections with latency. This becomes particularly applicable when talking about smaller files such as mri/ct etc where there are many starts/stops. What are your thoughts?


    John

    I just wanted to follow up on this. I was never able to get Siemens CT Syngo 2009E to successfully take worklist rsp from Conquest. It only asks for the 0032,1064 and 0040,0008 but expects the SCP to return at least the 0008,0100 and 0008,0102 sub items for these two sequences without defining it in its request. I had to use an alternative SCP to make it work. It is unfortunate I could not use the Conquest. I guess it would take some hard coding to make it work.


    { 0x0032, 0x1064, "ReqProcCodeSequence", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0008, 0x0100, "CodeValue", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0008, 0x0102, "CodeSchDesignator", 16, SQL_C_CHAR, DT_STR, "---" },
    expected but not asked for


    0040,0008 0 SQ ScheduledProcedureSt Sequence Item
    { 0x0008, 0x0100, "CodeValue", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0008, 0x0102, "CodeSchDesignator", 16, SQL_C_CHAR, DT_STR, "---" },
    expected but not asked for

    Here's a response to a query from my philips iu22 ultrasound...weird how conquest puts in the sequences but not for ct?


    First record of cleaned response:
    0008,0005 10 CS SpecificCharacterSet "ISO IR_100"
    0008,0050 14 SH AccessionNumber "20091117246368"
    0008,0090 8 PN ReferringPhysicianNa "SIEVERS "
    0008,1110 0 SQ ReferencedStudySeque Sequence Item
    0008,1120 0 SQ ReferencedPatientSeq Sequence Item
    0010,0010 16 PN PatientName "LAST^FIRST^J"
    0010,0020 6 LO PatientID "55558"
    0010,0030 8 DA PatientBirthDate "19400706"
    0010,0040 2 CS PatientSex "F "
    0010,1030 0 DS PatientWeight ""
    0010,2000 8 LO MedicalAlerts "UNKNOWN "
    0010,21c0 0 US PregnancyStatus "UNKNOWN "
    0020,000d 0 UI StudyInstanceUID ""
    0032,1032 8 PN RequestingPhysician "SIEVERS "
    0032,1060 10 LO RequestedProcedureDe "US THYROID"
    0032,1064 0 SQ RequestedProcedureCo Sequence Item
    >0008,0100 8 SH CodeValue "UNKNOWN "
    >0008,0102 8 SH CodingSchemeDesignat "UNKNOWN "
    >0008,0103 8 UN "UNKNOWN "
    >0008,0104 8 LO CodeMeaning "UNKNOWN "

    0038,0300 8 LO CurrentPatientLocati "UNKNOWN "
    0040,0100 0 SQ ScheduledProcedureSt Sequence Item
    >0008,0060 2 CS Modality "US"
    >0032,1070 0 LO RequestedContrastAge ""
    >0040,0001 0 AE ScheduledStationAETi ""
    >0040,0002 8 DA ScheduledProcedureSt "20091117"
    >0040,0003 4 TM ScheduledProcedureSt "1030"
    >0040,0006 8 PN ScheduledPerformingP "SIEVERS "
    >0040,0007 10 LO ScheduledProcedureSt "US THYROID"
    >0040,0008 0 SQ ScheduledProcedureSt Sequence Item
    >>0008,0100 8 SH CodeValue "UNKNOWN "
    >>0008,0102 8 SH CodingSchemeDesignat "UNKNOWN "
    >>0008,0103 8 UN "UNKNOWN "
    >>0008,0104 8 LO CodeMeaning "UNKNOWN "

    >0040,0009 0 SH ScheduledProcedureSt ""
    >0040,0010 0 SH ScheduledStationName ""
    >0040,0011 0 SH ScheduledProcedureSt ""
    >0040,0012 0 LO ScheduledPreOrderOfM ""
    >0040,0400 0 LT CommentsOnScheduledP ""
    0040,1001 0 SH RequestedProcedureID ""

    The siemens guys tell me that it works with all of the his/ris and worklists they usually attach to at other sites. They tell me they cannot turn off these fields as they are type 1.


    Why does conquest not reply something like this?


    0032,1064 0 SQ RequestedProcedureCo "CT ABDOMEN NO CONTRAST"
    >0008, 0100 2 CodeValue "UNKNOWN"
    >0008, 0102 2 CodeSchDesignator "UNKNOWN"
    >0008, 0103 2 CodeSchVersion "UNKNOWN"
    >0008, 0104 2 CodeMeaning "UNKNOWN"

    based on the following in the dicom.sql and data in the database. Is it something to do with the startsequence and end sequence that i am missing? why only start and stop sequence for the 0040,0100 sequence and no others?


    { 0x0032, 0x1064, "ReqProcCodeSequence", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0008, 0x0100, "CodeValue", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0008, 0x0102, "CodeSchDesignator", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0008, 0x0103, "CodeSchVersion", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0008, 0x0104, "CodeMeaning", 16, SQL_C_CHAR, DT_STR, "---" },

    Here is siemens scu c-find and my response. it appears to build the sequence for the 0040,0100 just fine just not the other two i need. it's weird because on a query from an ultrasound it seems to build them but it must be a siemens issue for the order of the results.


    Edited for brevity by mvh:
    Query:
    0008,0005 0 CS SpecificCharacterSet (empty)
    0008,0050 0 SH AccessionNumber (empty)
    0008,0080 0 LO InstitutionName (empty)
    0008,0081 0 ST InstitutionAddress (empty)
    0008,0082 0 SQ InstitutionCodeSeque Sequence Item
    0008,0090 0 PN ReferringPhysicianNa (empty)
    0008,1080 0 LO AdmittingDiagnosisDe (empty)
    0008,1110 0 SQ ReferencedStudySeque Sequence Item
    0008,1120 0 SQ ReferencedPatientSeq Sequence Item
    0008,1125 0 SQ ReferencedVisitSeque Sequence Item
    0010,0010 0 PN PatientName (empty)
    0010,0020 0 LO PatientID (empty)
    0010,0021 0 LO IssuerOfPatientID (empty)
    0010,0030 0 DA PatientBirthDate (empty)
    0010,0032 0 TM PatientBirthTime (empty)
    0010,0040 0 CS PatientSex (empty)
    0010,0050 0 SQ PatientInsurancePlan Sequence Item
    0010,1000 0 LO OtherPatientID (empty)
    0010,1001 0 PN OtherPatientName (empty)
    0010,1005 0 PN PatientBirthName (empty)
    0010,1010 0 AS PatientAge (empty)
    0010,1020 0 DS PatientSize (empty)
    0010,1030 0 DS PatientWeight (empty)
    0010,1040 0 LO PatientAddress (empty)
    0010,1060 0 PN PatientMotherBirthNa (empty)
    0010,1080 0 LO MilitaryRank (empty)
    0010,1081 0 LO BranchOfService (empty)
    0010,1090 0 LO MedicalRecordLocator (empty)
    0010,2000 0 LO MedicalAlerts (empty)
    0010,2110 0 LO ContrastAllergies (empty)
    0010,2150 0 LO CountryOfResidence (empty)
    0010,2152 0 LO RegionOfResidence (empty)
    0010,2154 0 SH PatientTelephoneNumb (empty)
    0010,2160 0 SH EthnicGroup (empty)
    0010,2180 0 SH Occupation (empty)
    0010,21a0 0 CS SmokingStatus (empty)
    0010,21b0 0 LT AdditionalPatientHis (empty)
    0010,21c0 0 US PregnancyStatus (empty)
    0010,21d0 0 DA LastMenstrualDate (empty)
    0010,21f0 0 LO PatientReligiousPref (empty)
    0010,4000 0 LT PatientComments (empty)
    0020,000d 0 UI StudyInstanceUID (empty)
    0032,1032 0 PN RequestingPhysician (empty)
    0032,1033 0 LO RequestingService (empty)
    0032,1060 0 LO RequestedProcedureDe (empty)
    0032,1064 0 SQ RequestedProcedureCo Sequence Item
    0038,0004 0 SQ ReferencedPatientAli Sequence Item
    0038,0008 0 CS VisitStatusID (empty)
    0038,0010 0 LO AdmissionID (empty)
    0038,0011 0 LO IssuerOfAdmissionID (empty)
    0038,0050 0 LO SpecialNeeds (empty)
    0038,0300 0 LO CurrentPatientLocati (empty)
    0038,0400 0 LO PatientInstitutionRe (empty)
    0038,0500 0 LO PatientState (empty)
    0038,4000 0 LT VisitComments (empty)
    0040,0100 0 SQ ScheduledProcedureSt Sequence Item
    >0008,0060 2 CS Modality "CT"
    >0032,1070 0 LO RequestedContrastAge (empty)
    >0040,0001 0 AE ScheduledStationAETi (empty)
    >0040,0002 8 DA ScheduledProcedureSt "20091117"
    >0040,0003 14 TM ScheduledProcedureSt "000000-235959 "
    >0040,0004 0 DA ScheduledProcedureSt (empty)
    >0040,0005 0 TM ScheduledProcedureSt (empty)
    >0040,0006 0 PN ScheduledPerformingP (empty)
    >0040,0007 0 LO ScheduledProcedureSt (empty)
    >0040,0008 0 SQ ScheduledProcedureSt Sequence Item
    >0040,0009 0 SH ScheduledProcedureSt (empty)
    >0040,0010 0 SH ScheduledStationName (empty)
    >0040,0011 0 SH ScheduledProcedureSt (empty)
    >0040,0012 0 LO ScheduledPreOrderOfM (empty)
    >0040,0020 0 UN (empty)
    >0040,0400 0 LT CommentsOnScheduledP (empty)
    0040,1001 0 SH RequestedProcedureID (empty)
    0040,1002 0 LO ReasonForRequestedPr (empty)
    0040,1003 0 SH RequestedProcedurePr (empty)
    0040,1004 0 LO PatientTransportArra (empty)
    0040,1005 0 LO RequestedProcedureLo (empty)
    0040,1008 0 LO ConfidentialityCode (empty)
    0040,1009 0 UN (empty)
    0040,1010 0 UN (empty)
    0040,1400 0 LT RequestedProcedureCo (empty)
    0040,2004 0 DA IssueDateOfImagingSe (empty)
    0040,2005 0 TM IssueTimeOfImagingSe (empty)
    0040,2008 0 PN OrderEnteredBy (empty)
    0040,2009 0 SH OrderEntererLocation (empty)
    0040,2010 0 SH OrderCallbackPhoneNu (empty)
    0040,2016 0 UN (empty)
    0040,2017 0 UN (empty)
    0040,2400 0 LT ImagingServiceReques (empty)
    0040,3001 0 LT ConfidentialityConst (empty)
    Query On Modality WorkList
    Records = 3
    First record of cleaned response:
    0008,0005 10 CS SpecificCharacterSet "ISO IR_100"
    0008,0050 14 SH AccessionNumber "20091117250881"
    0008,0090 6 PN ReferringPhysicianNa "WILSON"
    0008,1110 0 SQ ReferencedStudySeque Sequence Item
    0008,1120 0 SQ ReferencedPatientSeq Sequence Item
    0010,0010 14 PN PatientName "LAST^FIRST^F"
    0010,0020 6 LO PatientID "245436"
    0010,0030 8 DA PatientBirthDate "19391228"
    0010,0040 2 CS PatientSex "M "
    0010,1030 0 DS PatientWeight ""
    0010,2000 8 LO MedicalAlerts "UNKNOWN "
    0010,2110 8 LO ContrastAllergies "UNKNOWN "
    0010,21c0 0 US PregnancyStatus "UNKNOWN "
    0020,000d 14 UI StudyInstanceUID "20091117250881"
    0032,1032 6 PN RequestingPhysician "WILSON"
    0032,1060 22 LO RequestedProcedureDe "CT ABDOMEN NO CONTRAST"
    0032,1064 0 SQ RequestedProcedureCo "CT ABDOMEN NO CONTRAST"
    0038,0010 14 LO AdmissionID "20091117250881"
    0038,0050 4 LO SpecialNeeds "NONE"
    0038,0300 8 LO CurrentPatientLocati "UNKNOWN "
    0038,0500 0 LO PatientState ""
    0040,0100 0 SQ ScheduledProcedureSt Sequence Item
    >0008,0060 2 CS Modality "CT"
    >0032,1070 0 LO RequestedContrastAge ""
    >0040,0001 8 AE ScheduledStationAETi "AN_MEDPC"
    >0040,0002 8 DA ScheduledProcedureSt "20091117"
    >0040,0003 6 TM ScheduledProcedureSt "130000"
    >0040,0006 6 PN ScheduledPerformingP "WILSON"
    >0040,0007 22 LO ScheduledProcedureSt "CT ABDOMEN NO CONTRAST"
    >0040,0008 0 SQ ScheduledProcedureSt "CT ABDOMEN NO CONTRAST"
    >0040,0009 14 SH ScheduledProcedureSt "20091117250881"
    >0040,0010 0 SH ScheduledStationName ""
    >0040,0011 0 SH ScheduledProcedureSt ""
    >0040,0012 0 LO ScheduledPreOrderOfM ""
    >0040,0400 0 LT CommentsOnScheduledP ""
    0040,1001 14 SH RequestedProcedureID "20091117250881"
    0040,1003 0 SH RequestedProcedurePr ""
    0040,1004 0 LO PatientTransportArra ""
    0040,3001 0 LT ConfidentialityConst ""
    C-Find (Modality Work List) located 3 records

    I have been trying very hard to get a Siemens Syngo Emotion 16 slice CT to pull the worklist from my linux 1.4.14 worklist server. any bugs in .14? I have no problem adding individual dicom attributes to the dicom.sql and database such as pregnancy status etc. The problem occurs when I try to get into the area of sequences. One of the sequences actually is two deep being inside of the 0040,0100 sequence that comes with conquest by default. Two specific attributes that Siemens Persists on having that i cannot get to work for the life of me are Type 1 0040,0008 SchedProtocolSequence and 0032,1064 ReqProcCodeSequence.


    From my research, these contain some Code attributes. I cannot get these to feed properly using a combination of start and end sequences or just adding the attributes and seeing if the order of results just provides the fields to the SCU. I'm thinking it should act similar to the sequence scheduled performed procedure sequence. Does anyone have any working examples or some elaborate or comprehensive dicom.sql files to share? Any help is greatly appreciated. I would like to type a blog up if i can get it working for others to understand with step by step instructions. I'm thinking its possible.


    *WorkList*
    {
    { 0x0008, 0x0050, "AccessionNumber", 16, SQL_C_CHAR, DT_STR, "OBR.3" },
    { 0x0008, 0x0090, "ReferringPhysiciansName", 64, SQL_C_CHAR, DT_STR, "OBR.16" },
    { 0x0010, 0x0020, "PatientID", 64, SQL_C_CHAR, DT_STR, "PID.4" },
    { 0x0010, 0x0010, "PatientName", 64, SQL_C_CHAR, DT_STR, "PID.5" },
    { 0x0010, 0x0030, "PatientBirthDate", 8, SQL_C_DATE, DT_DATE, "PID.7" },
    { 0x0010, 0x0040, "PatientSex", 16, SQL_C_CHAR, DT_STR, "PID.8" },
    { 0x0010, 0x1030, "PatientsWeight", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0010, 0x2000, "MedicalAlerts", 64, SQL_C_CHAR, DT_STR, "---" },
    { 0x0010, 0x2110, "ContrastAllergies", 64, SQL_C_CHAR, DT_STR, "---" },
    { 0x0010, 0x21c0, "PregnancyStatus", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0020, 0x000d, "StudyInstanceUID", 64, SQL_C_CHAR, DT_UI, "---" },
    { 0x0032, 0x1032, "ReqPhysician", 64, SQL_C_CHAR, DT_STR, "OBR.16" },
    { 0x0032, 0x1060, "ReqProcDescription", 16, SQL_C_CHAR, DT_STR, "OBR.4.1" },


    { 0x0032, 0x1064, "--------", 0, SQL_C_CHAR, DT_STARTSEQUENCE, "---" },
    { 0x0032, 0x1064, "ReqProcCodeSequence", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0008, 0x0100, "CodeValue", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0008, 0x0102, "CodeSchDesignator", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0008, 0x0103, "CodeSchVersion", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0008, 0x0104, "CodeMeaning", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0032, 0x1064, "--------", 0, SQL_C_CHAR, DT_ENDSEQUENCE, "---" },


    { 0x0040, 0x1001, "ReqProcID", 16, SQL_C_CHAR, DT_STR, "OBR.4.0" },
    { 0x0040, 0x1003, "ReqProcPriority", 16, SQL_C_CHAR, DT_STR, "OBR.27" },
    { 0x0040, 0x1004, "PatientTransportArrangements", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0040, 0x3001, "ConfidentialityOnPatientDataDescr", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0038, 0x0010, "AdmissionID", 16, SQL_C_CHAR, DT_STR, "OBR.3" },
    { 0x0038, 0x0050, "SpecialNeeds", 64, SQL_C_CHAR, DT_STR, "---" },
    { 0x0038, 0x0300, "CurrentPatientLocation", 64, SQL_C_CHAR, DT_STR, "---" },
    { 0x0038, 0x0500, "PatientState", 16, SQL_C_CHAR, DT_STR, "---" },

    { 0x0040, 0x0100, "--------", 0, SQL_C_CHAR, DT_STARTSEQUENCE, "---" },
    { 0x0008, 0x0060, "Modality", 16, SQL_C_CHAR, DT_STR, "OBR.21" },
    { 0x0032, 0x1070, "ReqContrastAgent", 64, SQL_C_CHAR, DT_STR, "---" },
    { 0x0040, 0x0001, "ScheduledAE", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0040, 0x0002, "StartDate", 8, SQL_C_DATE, DT_DATE, "OBR.7.DATE" },
    { 0x0040, 0x0003, "StartTime", 16, SQL_C_CHAR, DT_TIME, "OBR.7.TIME" },
    { 0x0040, 0x0006, "PerfPhysician", 64, SQL_C_CHAR, DT_STR, "---" },
    { 0x0040, 0x0007, "SchedPSDescription", 64, SQL_C_CHAR, DT_STR, "---" },


    { 0x0040, 0x0008, "--------", 0, SQL_C_CHAR, DT_STARTSEQUENCE, "---" },
    { 0x0040, 0x0008, "SchedProtocolSequence", 64, SQL_C_CHAR, DT_STR, "---" },
    { 0x0008, 0x0100, "CodeValue", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0008, 0x0102, "CodeSchDesignator", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0008, 0x0103, "CodeSchVersion", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0008, 0x0104, "CodeMeaning", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0040, 0x0008, "---------", 0, SQL_C_CHAR, DT_ENDSEQUENCE, "---" },


    { 0x0040, 0x0009, "SchedPSID", 16, SQL_C_CHAR, DT_STR, "OBR.4" },
    { 0x0040, 0x0010, "SchedStationName", 16, SQL_C_CHAR, DT_STR, "OBR.24" },
    { 0x0040, 0x0011, "SchedPSLocation", 16, SQL_C_CHAR, DT_STR, "---" },
    { 0x0040, 0x0012, "PreMedication", 64, SQL_C_CHAR, DT_STR, "---" },
    { 0x0040, 0x0400, "SchedPSComments", 64, SQL_C_CHAR, DT_STR, "---" },
    { 0x0040, 0x0100, "---------", 0, SQL_C_CHAR, DT_ENDSEQUENCE, "---" },

    Does anyone have objection from me ressurecting the code found in the project found below produced by Gavin? The files I found are from an alpha1 zip that I came across. I believe he has opted to pursue creating an adobe flash based system from what I've gathered. Although impressive, I am more interested in the original project code. I have installed the package on a WAMP box and started adding code where he left off. I would like to bring it back to life and make it functional and possibly even get the stratos viewer working like he originally intended. So far I have been working on including user management and the possibility of adding Active Directory/LDAP authentication integration. Another nice feature I had in mind was a user request form that referring physicians could use to request access and require approval through the admin. We could limit physicians to viewing only cases that they referred etc. I like the idea of keeping it apache/php/mysql and possibly some javascript/AJAX too. The windows setup works good but I would like to include cross platform compatibility for unix/linux as an install option. This shouldn't be hard if we keep to open source tools.


    http://pacsworld.blogspot.com/…server-web-interface.html


    Any thoughts or suggestions?


    John