[{"content":"","date":"9 November 2026","externalUrl":null,"permalink":"/tags/c-find/","section":"Tags","summary":"","title":"C-Find","type":"tags"},{"content":"","date":"9 November 2026","externalUrl":null,"permalink":"/tags/dicom/","section":"Tags","summary":"","title":"Dicom","type":"tags"},{"content":"","date":"9 November 2026","externalUrl":null,"permalink":"/tags/methods/","section":"Tags","summary":"","title":"Methods","type":"tags"},{"content":"","date":"9 November 2026","externalUrl":null,"permalink":"/tags/migration/","section":"Tags","summary":"","title":"Migration","type":"tags"},{"content":"","date":"9 November 2026","externalUrl":null,"permalink":"/tags/pacs/","section":"Tags","summary":"","title":"Pacs","type":"tags"},{"content":"","date":"9 November 2026","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"9 November 2026","externalUrl":null,"permalink":"/","section":"Premier Imaging Informatics","summary":"","title":"Premier Imaging Informatics","type":"page"},{"content":"","date":"9 November 2026","externalUrl":null,"permalink":"/tags/query-retrieve/","section":"Tags","summary":"","title":"Query-Retrieve","type":"tags"},{"content":"","date":"9 November 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"9 November 2026","externalUrl":null,"permalink":"/tags/vna/","section":"Tags","summary":"","title":"Vna","type":"tags"},{"content":"Every migration, every archive assessment, and every \u0026ldquo;how big is this thing, really?\u0026rdquo; conversation I\u0026rsquo;ve been part of runs into the same wall early: the organization needs to know what\u0026rsquo;s in the archive, and the only access anyone will grant is a DICOM port.\nNo database login. No vendor report anyone trusts. Sometimes not even a conformance statement that matches the installed version. Just an AE title, an IP address, and permission to query.\nThat makes C-FIND the instrument. It\u0026rsquo;s a good one, but it was designed to find a patient\u0026rsquo;s studies for a reading workstation, not to inventory a petabyte. If you use it for the second job, you need to know exactly where the standard stops guaranteeing answers and starts leaving them to the vendor. This is a walk along that boundary, with the standard open beside me.\nThe model you are querying # DICOM Query/Retrieve is defined in PS3.4, Annex C. An archive that supports it exposes one or more information models. The two that matter in practice are Patient Root and Study Root, and both are hierarchies of the same four levels:\nflowchart TD P[\"PATIENT\nPatient ID (0010,0020)\"] ST[\"STUDY\nStudy Instance UID (0020,000D)\"] SE[\"SERIES\nSeries Instance UID (0020,000E)\"] IM[\"IMAGE\nSOP Instance UID (0008,0018)\"] P --\u003e ST --\u003e SE --\u003e IM classDef lvl fill:#1e293b,stroke:#64748b,color:#e2e8f0; class P,ST,SE,IM lvl; Each level has a unique key (shown above), a short list of required keys the archive must be able to match on and return, and a longer list of optional keys it may or may not support. The standard spells these out in Section C.6. Study Root starts the hierarchy at STUDY and folds the patient attributes into that level, which is why most tools default to it. Patient Root is common on older archives; the method below works the same there, with one more level to walk and Patient ID as the key for it.\nThe word hierarchical is doing real work. A baseline query asks about one level at a time, and to go deeper you must supply the unique keys for every level above. To learn anything about the series in a study, you first have to have found the study. The standard defines relational queries that let you skip levels, but they\u0026rsquo;re an optional extension negotiated at association time; assume you don\u0026rsquo;t have them until the conformance statement and a live test both say you do.\nHow a query actually proceeds # Here is the shape of one STUDY-level query. Everything in it is the standard\u0026rsquo;s behavior, not a vendor\u0026rsquo;s.\nsequenceDiagram participant SCU as Your tool (SCU) participant SCP as Archive (SCP) SCU-\u003e\u003eSCP: A-ASSOCIATE-RQ (Study Root FIND SOP Class) SCP--\u003e\u003eSCU: A-ASSOCIATE-AC SCU-\u003e\u003eSCP: C-FIND-RQ\nLevel=STUDY, StudyDate=20240301-20240331,\nModalitiesInStudy=\"\", NumberOfStudyRelatedInstances=\"\" loop one response per matching study SCP--\u003e\u003eSCU: C-FIND-RSP, status Pending (FF00 or FF01)\n+ identifier with return keys filled in end SCP--\u003e\u003eSCU: C-FIND-RSP, status Success (0000) SCU-\u003e\u003eSCP: A-RELEASE-RQ SCP--\u003e\u003eSCU: A-RELEASE-RP Two details in that exchange decide whether your inventory is trustworthy.\nFirst, the identifier you send is both the question and the answer template. An attribute with a value is a matching key (\u0026ldquo;only studies in March 2024\u0026rdquo;). An attribute sent with zero length is a return key (\u0026ldquo;and tell me the modalities and instance count for each\u0026rdquo;). You get back only what you asked for, so an inventory tool has to know in advance every attribute it wants.\nSecond, the status on each pending response carries information most tools throw away. FF00 means \u0026ldquo;here\u0026rsquo;s a match.\u0026rdquo; FF01 means \u0026ldquo;here\u0026rsquo;s a match, but one or more of the optional keys you asked for are not supported\u0026rdquo; (PS3.4, Table C.4-1). An archive that returns FF01 is telling you, on every response, that part of your question went unanswered. The reverse is not true: plenty of archives return FF00 and simply leave unsupported attributes empty, so an empty return attribute on a FF00 response is ambiguous. Record the status anyway. FF01 is a gift when you get it, and its absence is not a clean bill of health.\nWhat the standard guarantees # At the STUDY level in Study Root, the required keys are short, and they are the reason C-FIND is useful for this at all. Every conformant archive will match and return:\nAttribute Tag What it buys you Study Date (0008,0020) Range matching, so you can walk the archive by day, month, or year Study Time (0008,0030) Range matching within a day Accession Number (0008,0050) Reconciliation against the RIS or EHR Patient\u0026rsquo;s Name (0010,0010) Wildcard matching Patient ID (0010,0020) The key you\u0026rsquo;ll join on Study ID (0020,0010) Rarely useful; often blank or duplicated Study Instance UID (0020,000D) The unique key, and the only durable identity a study has Range matching on dates is what makes enumeration possible. Query StudyDate = 20240301-20240331, collect the UIDs, move to April. Slow, deterministic, and it works against any archive that claims Q/R conformance.\nWhat the standard leaves optional # Now the part that matters for sizing. The attributes you actually want for an inventory are all optional at the STUDY level:\nAttribute Tag Why you want it Why you can\u0026rsquo;t count on it Modalities in Study (0008,0061) Mix of CT, MR, CR, US Optional; some archives populate it only for studies ingested after the feature was enabled Number of Study Related Series (0020,1206) Study shape Optional; often computed at ingest and never recomputed Number of Study Related Instances (0020,1208) The number everyone wants Optional; same problem, and it drifts Study Description (0008,1030) Human-readable context Optional, and free text \u0026ldquo;Optional\u0026rdquo; in DICOM means the archive may support it, and if it does, the conformance statement says so. It does not mean \u0026ldquo;usually works.\u0026rdquo; The pattern I see most often with the counts is that they\u0026rsquo;re derived values populated when the study arrived, and nothing re-derives them after a series is deleted, a study is split, or a migration lands only part of the images. The count you get back is the count the archive believed at some point in the past, and after a messy history it can be off by a large fraction.\nThen there\u0026rsquo;s the list of things no C-FIND attribute exists for at all. You cannot ask an archive:\nHow many bytes a study occupies. There is no size attribute at any level. Rows, Columns, Bits Allocated, and Number of Frames let you compute it, but they\u0026rsquo;re IMAGE-level attributes that the standard doesn\u0026rsquo;t list among the IMAGE-level query keys; an archive may support them as additional optional keys, and the conformance statement is where you find out. When it received the study. Study Date is the clinical date, set by the modality. The archive\u0026rsquo;s ingest timestamp isn\u0026rsquo;t a query key. A study performed in 2009 and migrated in 2023 queries as 2009. Where it is stored. Online, nearline, tape, cloud tier, deleted-but-indexed: invisible. What you didn\u0026rsquo;t get. C-FIND returns matches. It never returns \u0026ldquo;and here are the studies I didn\u0026rsquo;t return because I cap results.\u0026rdquo; Caps are real and often undocumented. The first sign is usually that every window of your enumeration returns exactly the same round number. Sizing an archive anyway # Knowing the limits, here\u0026rsquo;s the method I use when C-FIND is all I have: three passes, each stepping down a level only where the one above left a gap.\nflowchart LR A[\"Pass 1\nSTUDY level\nby date range\"] --\u003e B{\"Counts and\nmodalities\nreturned?\"} B -- \"yes\" --\u003e D[\"Record study row\"] B -- \"no, FF01, or blank\" --\u003e C[\"Pass 2\nSERIES level\nper study UID\"] C --\u003e E{\"Instance count\nper series\nreturned?\"} E -- yes --\u003e D E -- no --\u003e F[\"Pass 3\nIMAGE level\nper series UID\"] F --\u003e D D --\u003e G[\"Size estimate\nfrom counts × typical\nobject size per modality\"] classDef pass fill:#1e293b,stroke:#64748b,color:#e2e8f0; class A,C,F pass; Pass 1 walks the calendar at STUDY level in windows small enough to stay under any cap (I start at one day and widen if the archive is thin), asking for the required keys plus the optional counts and Modalities in Study, and recording the status on every response. Pass 2 queries SERIES for every study where the counts came back blank or the status was FF01; Modality (0008,0060) is required at this level, so the modality mix becomes trustworthy here even when Modalities in Study wasn\u0026rsquo;t. Pass 3 enumerates instances only where Pass 2 still left counts unknown. It\u0026rsquo;s expensive, so it\u0026rsquo;s the exception.\nThen estimate: instances times a typical object size per modality lands within a usable tolerance of total storage, with the error dominated by the handful of large multi-frame and tomosynthesis objects, which you can go measure individually. Present it as what it is: an estimate derived from counts, with the per-modality assumptions written next to it.\nA few habits make this robust. Log every response status. Log the association parameters; the accepted presentation contexts are a conformance statement you can actually trust. Re-run one early window at the end to see whether the archive changed under you. Treat any window that returns a suspiciously round count as a cap, not a fact.\nWhat\u0026rsquo;s missing from this post # A worked run. I\u0026rsquo;ve described the method but not shown it with numbers: window sizes, response counts, how far the estimate landed from the truth. That\u0026rsquo;s deliberate; the archives I\u0026rsquo;ve run it against belong to clients, and the right way to show it is against an archive I own. That\u0026rsquo;s the next post, with the queries and the results in it.\nIf you\u0026rsquo;ve hit limits in C-FIND I haven\u0026rsquo;t mentioned, I\u0026rsquo;d like to hear about them: jsole@pii.services.\nSources # DICOM PS3.4, Annex C, Query/Retrieve Service Class: https://dicom.nema.org/medical/dicom/current/output/chtml/part04/chapter_C.html. Information models and hierarchical versus relational queries in C.2 and C.3; attribute matching in C.2.2.2; required and optional keys per level in C.6; status codes in Table C.4-1. DICOM PS3.6, Data Dictionary, for the attribute names and tags used above: https://dicom.nema.org/medical/dicom/current/output/chtml/part06/PS3.6.html. Everything about result caps, stale counts, and what archives actually do is from my own work and is stated as experience, not standard. ","date":"9 November 2026","externalUrl":null,"permalink":"/posts/what-c-find-can-and-cant-tell-you-about-an-archive/","section":"Posts","summary":"","title":"What C-FIND Can and Can't Tell You About an Archive","type":"posts"},{"content":"","date":"9 November 2026","externalUrl":null,"permalink":"/tags/meta/","section":"Tags","summary":"","title":"Meta","type":"tags"},{"content":"","date":"9 November 2026","externalUrl":null,"permalink":"/tags/site/","section":"Tags","summary":"","title":"Site","type":"tags"},{"content":"Welcome. This is the website of Premier Imaging Informatics, which is to say it\u0026rsquo;s mine. I\u0026rsquo;m John Sole, and I\u0026rsquo;ve spent the last thirty years in medical imaging: first behind a CT scanner, then running PACS inside hospitals, then on the vendor side, working out how an enterprise archive fits into everything a hospital already runs, and since 2018 as an independent consultant working with health systems on their imaging infrastructure.\nI\u0026rsquo;ve built this site for one reason: to write.\nMost of what I know, I learned by being the person who had to make something work when the documentation didn\u0026rsquo;t match the wire, or when two systems that were both \u0026ldquo;standards compliant\u0026rdquo; refused to talk to each other. That knowledge mostly lives in engagement notes and in my head, where it does nobody else any good. Writing it down is the fix.\nWhat to expect here\nA new piece roughly once a month, on topics like these:\nWhat the DICOM and HL7 standards actually say, as opposed to what vendors and folklore say they say, and how to find out for yourself. Methods for migrations, verifications, and archive analysis that don\u0026rsquo;t depend on a particular vendor\u0026rsquo;s tools. Field notes from production problems, written at the level of the protocol and the query, with the names filed off. I hold myself to a simple rule: where a claim would be challenged by someone who knows this field, I cite the standard or the paper. Where numbers appear, the method behind them is shown. The rest is experience, and I\u0026rsquo;ll say so when it is.\nThe Archives\nIf you want to see where this started, The Archives hold the articles I wrote from 2008 to 2010 on a site called JS PACS, when I was a working PACS administrator. Dated, lightly cleaned up, otherwise as they were. Nearly twenty years on, the problems have changed less than you\u0026rsquo;d think.\nThe first real piece is already up: What C-FIND Can and Can\u0026rsquo;t Tell You About an Archive. If you work with imaging systems and want to know when something new is posted, the RSS feed is the simplest way. I\u0026rsquo;m also at jsole@pii.services.\n","date":"9 November 2026","externalUrl":null,"permalink":"/posts/welcome/","section":"Posts","summary":"","title":"Welcome to pii.services","type":"posts"},{"content":"Originally published on JS PACS, August 31, 2010.\nIt is that time again for hi-res monitor replacement discussions between two highly competitive vendors. After a week of use with each of the monitors, and competitive pricing from both, I am looking to the JS PACS community for other experiences with either vendor. I am hoping to hear the good, the bad, and the ugly.\nI personally like both monitors, and each offers the latest array of fleet management along with remote calibration and reporting tools.\nAs with anything, it is hard to gauge what a device will actually do until you have stressed it for a year or more, so I am hoping to hear from those of you who have.\n","date":"31 August 2010","externalUrl":null,"permalink":"/archive/2010-08-31-hi-res-monitors-barco-and-image-systems/","section":"The Archives","summary":"","title":"Hi-Resolution Monitors: Barco and Image Systems","type":"archive"},{"content":"","date":"31 August 2010","externalUrl":null,"permalink":"/tags/monitors/","section":"Tags","summary":"","title":"Monitors","type":"tags"},{"content":"","date":"31 August 2010","externalUrl":null,"permalink":"/tags/reviews/","section":"Tags","summary":"","title":"Reviews","type":"tags"},{"content":"Take a walk through the archives. JS PACS was a site I ran from 2008 to 2010, when I was in the trenches as a PACS administrator, as a way of sharing what I was working on at the time. There may be a gem or two in here for new PACS admins, or a refresher for experienced ones, but mainly I\u0026rsquo;ve kept these for historical reasons.\nThey are republished as written and dated as they were. Dictation errors and typos have been cleaned up; the opinions, and the 2009 facts, have not.\n","date":"31 August 2010","externalUrl":null,"permalink":"/archive/","section":"The Archives","summary":"","title":"The Archives","type":"archive"},{"content":"","date":"31 August 2010","externalUrl":null,"permalink":"/tags/vendors/","section":"Tags","summary":"","title":"Vendors","type":"tags"},{"content":"","date":"21 April 2010","externalUrl":null,"permalink":"/tags/mobile/","section":"Tags","summary":"","title":"Mobile","type":"tags"},{"content":"Originally published on JS PACS, April 21, 2010.\niPads and imaging, what an exciting platform that will be when it develops. How many of you out there have your iPad yet? I have mine and I am eagerly awaiting some quality PACS applications for this new platform. OsiriX has the iPhone app, but as of today they haven\u0026rsquo;t written it to take advantage of the iPad\u0026rsquo;s great screen, and the iPhone app enlarged on the iPad just doesn\u0026rsquo;t cut it. I haven\u0026rsquo;t tried the Merge application on the iPad yet. I do have it on the iPhone and wasn\u0026rsquo;t overly impressed with its proprietary nature, and I won\u0026rsquo;t even consider trying it on the iPad until Merge puts out an iPad-specific application.\nIf you have your PACS viewers available on Citrix, you are already a good portion of the way there. We don\u0026rsquo;t support remote viewing over Citrix, so I can\u0026rsquo;t view images that way, but it is amusing to see a Windows application running on the iPad through Citrix. It is also nice to have access to the EMR through the iPad. We are a MediTech shop and it runs very nicely over the iPad Citrix receiver.\nThe iPad makes VPN configuration a simple process, and I think many organizations can expect to see an increasing number of requests to hook iPads into the system. We are preparing for it and are even considering offering some limited level of support for the OS X platform now that this new tool has come out.\nAnother way I am looking to use the iPad is for dashboards. How great would it be to walk the halls with all of your imaging systems\u0026rsquo; data right in the palm of your hand? Many web-based dashboard viewers are already primed to be viewed on the iPad, but remember that the iPad runs Apple\u0026rsquo;s Safari browser and some systems just don\u0026rsquo;t run right on it (I don\u0026rsquo;t blame that on Safari, though).\nThere are numerous ways to use the iPad in healthcare, especially in imaging. How are you using, or how would you use, the iPad in your daily activities?\n","date":"21 April 2010","externalUrl":null,"permalink":"/archive/2010-04-21-the-ipad-and-pacs/","section":"The Archives","summary":"","title":"The iPad and PACS","type":"archive"},{"content":"","date":"21 April 2010","externalUrl":null,"permalink":"/tags/viewers/","section":"Tags","summary":"","title":"Viewers","type":"tags"},{"content":"Originally published on JS PACS, December 31, 2009.\nWhat a busy year. The organization I am currently supporting has undergone some major changes.\nWe had a major upgrade to the MediTech HIS/RIS (Client Server), we\u0026rsquo;ve implemented digital mammography and voice-recognition dictation, and we just signed the order for our second-generation cardiology PACS. Oh yeah, another PACS merger as well. Because of all the projects, this was the first time I\u0026rsquo;ve missed the SIIM conference, but I will be returning next year up in Minneapolis and hope to provide live updates like I did from the 2008 conference in Seattle.\nBecause of the high volume of work, I have been lax in spending the needed time creating content to stimulate discussion on the JS PACS website. However, with the new year upon us, I am renewing my commitment to push this page forward and make it useful for the community.\nOur membership has grown from 75 in mid-2009 to 125 registered members today. With that many people, we should have enough to generate some interesting conversation, and I offer each of you the opportunity to post in our discussion forum or share a story that can be published on the front page of the site.\nSome topics I plan on writing about in the first few months of 2010 include:\nLessons learned from the voice-recognition dictation implementation. Review of the Hologic mammography project. Updates on the cardiology project we are about to embark on. Review of what happened to Emageon this past year. Discussion of the new hi-res color monitors on the market. Using Macs for PACS. Topics based on suggestions or contributions from other members. I hope this last post of 2009 finds your systems running well, you in good health, and facing good projections for 2010.\nHappy New Year!\nJohn\n","date":"31 December 2009","externalUrl":null,"permalink":"/archive/2009-12-31-happy-new-year-final-post-for-2009/","section":"The Archives","summary":"","title":"Happy New Year: Final Post for 2009","type":"archive"},{"content":"","date":"31 December 2009","externalUrl":null,"permalink":"/tags/year-in-review/","section":"Tags","summary":"","title":"Year-in-Review","type":"tags"},{"content":"","date":"7 August 2009","externalUrl":null,"permalink":"/tags/cad/","section":"Tags","summary":"","title":"Cad","type":"tags"},{"content":"","date":"7 August 2009","externalUrl":null,"permalink":"/tags/mammography/","section":"Tags","summary":"","title":"Mammography","type":"tags"},{"content":"Originally published on JS PACS, August 7, 2009.\nAs we progress through our digital mammography implementation, new questions are being raised every day. We are often provided answers by the vendor; however, I feel some vendors are quick to provide answers that steer us toward the path of least resistance for them.\nThe specific instance this time is the question of what to do with mammography CAD data. What is the standard of care in the mammography world regarding the use of CAD in digital mammography?\nAs we begin implementing a digital mammography department, we are faced with the decision of how to handle CAD markings on digital images. We are being told that nobody stores CAD markings, because of the liability: if CAD identifies a spot on an image, the spot is not worked up by the radiologist, and it proves to be positive, the radiologist can be held liable.\nNow, I am of the school of thought that if you make mention of a spot identified by CAD and the CAD overlay is not stored, we can also be held liable, since we cannot reproduce the image that identified the area of interest.\nWe have had this discussion with the risk management group in our organization, and it was stated that we have to identify the standard of care by evaluating what others who have been using such CAD systems are doing.\nSo I am interested in hearing how everybody is handling CAD overlays in their digital mammography environment.\n","date":"7 August 2009","externalUrl":null,"permalink":"/archive/2009-08-07-mammography-cad-standard-of-care/","section":"The Archives","summary":"","title":"Mammography CAD: Standard of Care","type":"archive"},{"content":"","date":"7 August 2009","externalUrl":null,"permalink":"/tags/policy/","section":"Tags","summary":"","title":"Policy","type":"tags"},{"content":"","date":"23 June 2009","externalUrl":null,"permalink":"/tags/dictation/","section":"Tags","summary":"","title":"Dictation","type":"tags"},{"content":"","date":"23 June 2009","externalUrl":null,"permalink":"/tags/implementation/","section":"Tags","summary":"","title":"Implementation","type":"tags"},{"content":"Originally published on JS PACS, June 23, 2009.\nI\u0026rsquo;m about to embark on an implementation of the MedQuist SpeechQ voice-recognition dictation product, and I\u0026rsquo;m interested in hearing how others who use the same system felt their implementation went.\n","date":"23 June 2009","externalUrl":null,"permalink":"/archive/2009-06-23-medquist-speechq-an-implementation-begins/","section":"The Archives","summary":"","title":"MedQuist SpeechQ: An Implementation Begins","type":"archive"},{"content":"","date":"12 June 2009","externalUrl":null,"permalink":"/tags/career/","section":"Tags","summary":"","title":"Career","type":"tags"},{"content":"","date":"12 June 2009","externalUrl":null,"permalink":"/tags/certification/","section":"Tags","summary":"","title":"Certification","type":"tags"},{"content":"","date":"12 June 2009","externalUrl":null,"permalink":"/tags/opinion/","section":"Tags","summary":"","title":"Opinion","type":"tags"},{"content":"Originally published on JS PACS, June 12, 2009.\nThere is an interesting discussion about the legitimacy of the PACS certification and recertification process on another PACS discussion board. Some see it as unnecessary for our profession. The following is my response to those who say it is not necessary or not worth it.\nIt is interesting to find that PACS administrators themselves don\u0026rsquo;t see the value of certification. Comments such as \u0026ldquo;money grab\u0026rdquo; and \u0026ldquo;not enough value to the cert to maintain it\u0026rdquo; all seem self-serving to me.\nI have started to notice more and more that when people complain about something, there is often an underlying reason it doesn\u0026rsquo;t serve them well, regardless of the overall benefit to the community.\nThe purpose of a certification, and the PACS certification in particular, is to demonstrate a basic aptitude in the PACS environment. Take a look at how far PACS administration has come. It used to be the individual from radiology who was \u0026ldquo;good with computers\u0026rdquo; who was put in charge of an internal system that served nobody but the radiology department. We have now grown to enterprise imaging, where the systems we manage encompass anything deemed a medical image. We have graduated from radiology to \u0026ldquo;-ology,\u0026rdquo; and we need to keep our knowledge up with the impressive evolution we face every day.\nHowever much our systems evolve and move into alignment with standardized healthcare IT, there is still something that separates imaging informatics from HIS, RIS, ED, pharmacy, and other clinical systems, and it is that distinction I think we all thrive on.\nThe certification process should be seen as a method by which we demonstrate that we can provide that extra level of expertise to a healthcare organization.\nSure, day-to-day activities such as server reboots, DICOM data editing for QA, and workstation management are all skills that can be assessed in an interview. But understanding why a particular device needs to be configured a certain way to successfully query a modality worklist, or knowing what to ask a vendor from both a clinical and a technical standpoint, is what certification helps represent.\nAs an organizational leader, wouldn\u0026rsquo;t you rather know that the individual you are hiring to implement your $2.5 million PACS knows the ins and outs of radiology, imaging, and IT before hiring him or her? Or would you rather wait until you are in the middle of RFP discussions to find that the individual you are expecting so much of can\u0026rsquo;t read a DICOM conformance statement to determine whether the DICOM objects created by your new high-tech equipment can even be sent into the PACS?\nTo the comment that \u0026ldquo;certification is not necessarily correlated with ability,\u0026rdquo; it can also be said that you can have all the skill in the world, but if you don\u0026rsquo;t have the degree or certification to demonstrate it, you won\u0026rsquo;t be considered.\nBetween ABII and PARCA, PACS certification isn\u0026rsquo;t even ten years old. Ten years from now, when an organization will not interview you without an imaging informatics certification, don\u0026rsquo;t find yourself unable to compete. Remember, this isn\u0026rsquo;t about you as an individual; it\u0026rsquo;s about supporting our profession and propelling us into an environment where we can demonstrate our knowledge.\n","date":"12 June 2009","externalUrl":null,"permalink":"/archive/2009-06-12-value-of-pacs-certification/","section":"The Archives","summary":"","title":"Value of PACS Certification and Recertification","type":"archive"},{"content":"Originally published on JS PACS, May 27, 2009.\nThe government recently released open-source software designed to allow federal agencies and private organizations to transfer healthcare information between their systems.\nI am a fan of open source, but I have some initial concerns about the government running various aspects of our proposed national healthcare record on open-source software.\nIf the software is open source, I fear it will be more difficult to protect the healthcare information transferred through it. More people would have access to the software, or be able to create hooks into it for various purposes. Additionally, could the resources needed to manage an open-source project like this become more expensive than privately developed software built under a government contract? Remember, open-source software has hidden costs in the specialized people needed to manage it.\nOn the other hand, open source certainly offers flexibility and ingenuity, as there can be many people working on various aspects of the system, designing robust and customized solutions for almost any scenario.\nAgain, I am a fan of open-source software, but without all the details yet, it is hard to know whether open source is really the right choice for the government. Regardless, it will be interesting to see how this develops in the next year or two.\n","date":"27 May 2009","externalUrl":null,"permalink":"/archive/2009-05-27-government-open-source-and-healthcare-it/","section":"The Archives","summary":"","title":"Government, Open Source, and Healthcare IT: Is It a Good Fit?","type":"archive"},{"content":"","date":"27 May 2009","externalUrl":null,"permalink":"/tags/healthcare-it/","section":"Tags","summary":"","title":"Healthcare-It","type":"tags"},{"content":"","date":"27 May 2009","externalUrl":null,"permalink":"/tags/open-source/","section":"Tags","summary":"","title":"Open-Source","type":"tags"},{"content":"Originally published on JS PACS, May 22, 2009.\nI typically don\u0026rsquo;t like to discuss vendor-specific problems in front-page articles, but I\u0026rsquo;m going to break that rule today. I\u0026rsquo;m hoping this article reaches many people, but specifically cardiology PACS administrators who manage the Agfa HeartLab cardiology PACS. I\u0026rsquo;m currently managing this C-PACS and find some recurring behaviors that are not only problematic but result in significant manual work to keep the system in a usable state.\nWhat has been occurring in my implementation is routine loss of the DICOM services. If you\u0026rsquo;re familiar with Agfa as a cardiology solution, you\u0026rsquo;ll know that they run objects called DICOM Labs. Each DICOM Lab is responsible for image transfer from one particular imaging device. We have customized HeartLab in that we don\u0026rsquo;t store directly to the cardiology PACS; we store to the radiology PACS (which contains our enterprise archive) and forward a copy to the cardiology PACS for viewing. Since we only have one device sending to the cardiology PACS, we only have one DICOM Lab, and one would think that without the typical 10 or 15 DICOM Labs running simultaneously we would see high levels of performance. We do not.\nThe most frustrating problem I have with this system is that every so often (20 to 24 hours) the DICOM services hang on the server. There is really no indication that the services have hung, other than that an occasional spot check of our archive\u0026rsquo;s auto-router shows anywhere from 1,500 to 2,000 images pending transfer to HeartLab. Usually, logging on to the server and performing a stop and start of the DICOM services kicks all the processes back into motion. Sometimes, however, a complete reboot of the C-PACS server is necessary. While the resolution is manual, it is not overly lengthy; but the fact that it has to occur every day is unacceptable. Between the time the PACS administrator spends fixing the problem and the time lost by cardiologists waiting for image transfers, this cardiology solution significantly slows down workflow throughout the day.\nI\u0026rsquo;m curious to know whether other cardiology PACS administrators experience similar issues, specifically with the Agfa solution, and what types of resolutions you\u0026rsquo;ve developed.\n","date":"22 May 2009","externalUrl":null,"permalink":"/archive/2009-05-22-agfa-heartlab-performance-issues/","section":"The Archives","summary":"","title":"Agfa HeartLab: Performance Issues or Normal Behavior?","type":"archive"},{"content":"","date":"22 May 2009","externalUrl":null,"permalink":"/tags/cardiology-pacs/","section":"Tags","summary":"","title":"Cardiology-Pacs","type":"tags"},{"content":"","date":"22 May 2009","externalUrl":null,"permalink":"/tags/troubleshooting/","section":"Tags","summary":"","title":"Troubleshooting","type":"tags"},{"content":"Originally published on JS PACS, May 13, 2009.\nThe day of the vendor-provided workstation is coming to an end. For so long we have heard that we have to purchase our PACS workstations pre-built and pre-configured. Well, I think the time is upon us to take control of our workstations. Your organization can gain a lot by moving PACS workstation development in house. You can save money, standardize the workstation build, and use your organization\u0026rsquo;s own software, such as anti-virus and patch management.\nI am currently in the process of building a Centricity 1000 workstation from scratch, and I want to say that it is not the mysterious process the vendors would have you believe. We simply purchased a license, obtained the software, and bought the recommended hardware. In fact, we purchased a workstation well over the minimum specifications, so we know we\u0026rsquo;ll get great performance out of it.\nThe most arduous part of building this workstation so far consisted of two issues. The first was getting XP installed on the HP workstation (see the article on installing Windows XP on the HP xw series), and the other was getting the license. The license acquisition wasn\u0026rsquo;t difficult; it just took some time to get an account on the GE licensing system and register the Centricity serial number I had received in order to generate the license.\nWith the workstation up and running and the license file in hand, it was rather trivial to install the cardiology software. I have it all installed and configured, but I haven\u0026rsquo;t given it the true test of sending DICOM images to the workstation. I am not that worried about that portion of the testing, however, because from this point it is just a matter of tweaking settings.\nThe most important aspect of this process for me was a reaffirmation that an organization really can be successful building its own workstations, and that software-only solutions can be a viable part of the strategy for maintaining workstations and keeping them refreshed. The biggest advantages to purchasing, building, and maintaining your own workstations are that you can shop for the best prices, standardize your hardware, and align the software with your organization\u0026rsquo;s overall strategy (virus protection and so on).\n","date":"13 May 2009","externalUrl":null,"permalink":"/archive/2009-05-13-build-your-own-workstations/","section":"The Archives","summary":"","title":"Workstation Management: Build Your Own Workstations","type":"archive"},{"content":"","date":"13 May 2009","externalUrl":null,"permalink":"/tags/workstations/","section":"Tags","summary":"","title":"Workstations","type":"tags"},{"content":"Originally published on JS PACS, May 8, 2009.\nThis troubleshooting tip relates to rebuilding PACS workstations on the HP xw series platform. A lot of PACS workstations these days run on this platform, many of them the HP xw4300 or xw8600. There are many models in the series, but their price and performance have been very attractive, and they are one of our preferred platforms.\nThis issue doesn\u0026rsquo;t occur all the time, but some of these workstations hit you with the dreaded BSOD (Blue Screen of Death, with an error of 0x0000007B, which is a device-inaccessible error) when trying to install Windows XP Pro from the install disc.\nThe issue is related to the onboard RAID controller that some of these devices come with, or the lack of LSI drivers for the hard drive controller. Either will cause the Windows install to fail, but here are some steps to get through it.\nFirst, if you get the BSOD on the Windows install, check the BIOS, and under Storage Options disable the RAID controller, setting it to IDE Independent. This will allow the Windows installer to see the boot sector of the drive and prevent the install from failing.\nIf you still get the error, you may need to add the LSI drivers during the Windows install. There are two ways to do this. First, download the correct LSI drivers for your model from the HP website and extract them onto a workstation you have access to. You can then put them on a floppy, and during the Windows install there is a point where you will see \u0026ldquo;Press F6 to install third party SCSI drivers\u0026rdquo; at the bottom of the screen. Press F6 and you will be presented with a section that allows you to load those drivers into the install process. Given that not many workstations ship with floppy drives these days, the second method might be the better solution.\nThat second solution involves creating a new install disc that contains the LSI drivers. There is a great free product called nLite that will let you do this. There is good documentation on the nLite site, so I won\u0026rsquo;t go into the details of using the software, but suffice it to say that this tool lets you rebuild your install disc and include the drivers you need (such as the LSI drivers). As a side note, there are a lot of other things you can add to the install disc, such as service packs, additional programs, and registry edits, that will all be included in the install.\nOnce you have the disc built, pop it in the CD drive, fire up the workstation, and the install should go smoothly.\n","date":"8 May 2009","externalUrl":null,"permalink":"/archive/2009-05-08-installing-windows-xp-on-hp-xw-workstations/","section":"The Archives","summary":"","title":"PACS Troubleshooting Tips: Installing Windows XP on the HP xw Series Workstations","type":"archive"},{"content":"","date":"8 May 2009","externalUrl":null,"permalink":"/tags/windows/","section":"Tags","summary":"","title":"Windows","type":"tags"},{"content":"Originally published on JS PACS, May 5, 2009.\nOn April Fool\u0026rsquo;s Day, the world was set to absorb the wrath of the Conficker worm. After April 1 came and went, many thought the scope of the virus was a hoax, but in yesterday\u0026rsquo;s edition of Health Imaging \u0026amp; IT, an article reported that Conficker was beginning to make its presence known on medical imaging devices. The article started out making it sound like an MRI scanner was infected, then clarified by saying that engineers monitoring the internet had seen \u0026ldquo;an imaging machine used to review high-resolution images\u0026rdquo; reaching out over the internet for instructions, presumably from the programmers who created Conficker. That machine sounds like nothing more than the average 3D workstation that comes with many scanners these days, and that brings me to the point of this discussion: how do you handle virus protection and patch management on your PACS equipment and imaging devices?\nOften, actually almost always, vendors of medical imaging equipment don\u0026rsquo;t let you touch their products when it comes to putting your own software on them. This puts the organization in a precarious position. After some time, the trial anti-virus software installed on the workstation expires, leaving the device unprotected. Even when it is protected, the AV software isn\u0026rsquo;t regularly updated, so the virus definitions aren\u0026rsquo;t current. I think it is time for vendors to start allowing us to put our organizational anti-virus software on these devices.\nPatch management is also a problem. Microsoft released a security patch for the Conficker worm, but vendors often don\u0026rsquo;t supply users with such patches in a package that can be easily installed on their devices. As system administrators, we can go install them ourselves, but then we are faced with the vendor potentially withdrawing support because we installed unapproved software on the device.\nSo, is it the responsibility of the vendor to develop better methods of applying anti-virus protection and patch management, or do we, as system administrators, take it upon ourselves to deploy these protective measures on our equipment?\nReference: \u0026ldquo;Conficker computer virus snakes its way into medical devices,\u0026rdquo; HealthImaging.com, May 2009.\n","date":"5 May 2009","externalUrl":null,"permalink":"/archive/2009-05-05-patch-management-and-anti-virus-on-pacs-equipment/","section":"The Archives","summary":"","title":"PACS Equipment: Patch Management and Anti-Virus Software","type":"archive"},{"content":"","date":"5 May 2009","externalUrl":null,"permalink":"/tags/security/","section":"Tags","summary":"","title":"Security","type":"tags"},{"content":"Originally published on JS PACS, April 23, 2009.\nBe sure to develop a policy regarding the installation and maintenance of imaging devices and peripheral PACS equipment. Sometimes the line between organizational PCs and medical imaging equipment becomes blurred, and questions arise about who supports what. Consider anything attached to imaging equipment to be your domain, and take the stance that no equipment related to PACS can be worked on without your knowledge. I am not suggesting that you keep your organization\u0026rsquo;s technical services group from working on PCs around imaging equipment, just that they verify with the PACS team any work they are about to perform, to ensure it won\u0026rsquo;t impact workflow. Nobody wants to run a dictatorship over PACS, but having information pass through you will prevent issues from happening in your organization\u0026rsquo;s imaging informatics flow without your knowledge.\nScenario: an oncology PC used for treatment planning was having some issues, and the technical services team inadvertently altered its IP address, breaking DICOM communication. It took a day for the IS team to figure out that the IP address had to be reset to its original setting. Because of that, an entire day of work in the oncology department was lost, and some patients had to wait longer than normal since the department was down to one treatment planning device. Considering that this was a DICOM device, the PACS team was distressed to learn that oncology had been unnecessarily impacted for an entire day. The details of what required the modification of the device\u0026rsquo;s IP, and how it was done without the knowledge of the PACS team, are still being uncovered.\nWith an incident like this, it is clearly time to review policies and procedures with all parties involved, to ensure that the organization\u0026rsquo;s DICOM devices and medical imaging equipment are worked on by, or with oversight from, the PACS team.\nBe sure your organization has policies and procedures in place for the management of PACS-related equipment. Also be sure the policy is communicated to the organization (clinical department managers, IS, administration, and so on), as you never know where an issue with imaging informatics may surface. Whether it is a new imaging device, maintenance on an existing device, or a PC that interfaces with imaging devices, you need to know about it.\n","date":"23 April 2009","externalUrl":null,"permalink":"/archive/2009-04-23-pacs-asset-management/","section":"The Archives","summary":"","title":"PACS Policies and Procedures: PACS Asset Management","type":"archive"},{"content":"","date":"22 April 2009","externalUrl":null,"permalink":"/tags/cd-import/","section":"Tags","summary":"","title":"Cd-Import","type":"tags"},{"content":"Originally published on JS PACS, April 22, 2009.\nToday I had the opportunity to demo the Codonics Integrity CD importing device. If you haven\u0026rsquo;t seen it, there is information on it at the vendor\u0026rsquo;s site.\nIt is a device that looks similar to a Mac Mini, if you are familiar with that Apple product. There is no keyboard, mouse, or monitor. The operating system and the system and DICOM configuration files are kept on a thumb drive that plugs into the back of the Integrity. The box itself is nothing more than a CD/DVD reader and an 80 GB hard drive.\nThe beauty of this system is that it can be put anywhere, and all a user has to do is stick a DICOM CD or DVD in the drive. After it reads the disc and stores the images locally, it spits the disc back out for the user to return to the patient. The file-room staff can then navigate to the device in a web browser, reconcile the imported studies to the modality worklist or make manual patient edits as needed, and push the studies to PACS.\nThe device works wonderfully from a clinical perspective, offering ease of use and speed. It is in some of the IT aspects that I feel it falls short.\nThe device does allow you to configure it for DHCP, a nice change in the DICOM world of static TCP/IP configurations, and you can join it to your organization\u0026rsquo;s domain and use DNS to browse to it. Where I feel it comes up short is the user database. Some may think this is trivial, but given that it is a fairly advanced device, Active Directory authentication would certainly be a beneficial feature. Maintaining disparate user databases on DICOM equipment is time-consuming and tedious, so Codonics should consider developing that in a future release.\nI will close by saying this is a review and nothing more. I have not purchased this product, and I am not encouraging or discouraging others from purchasing it; I just wanted to share my thoughts after being able to demo the device today.\n","date":"22 April 2009","externalUrl":null,"permalink":"/archive/2009-04-22-codonics-integrity-a-review/","section":"The Archives","summary":"","title":"Codonics Integrity: A Review","type":"archive"},{"content":"","date":"23 March 2009","externalUrl":null,"permalink":"/tags/c-move/","section":"Tags","summary":"","title":"C-Move","type":"tags"},{"content":"Originally published on JS PACS, March 23, 2009.\nI was recently working on a PACSGear CD burner. The software was PACSGear MediaWriter version 1.0.2.25990, and when retrieving a study from PACS to burn to a CD I was constantly getting an error. The error from the MediaWriter logs was:\nThread MoveManager::Start-\u0026gt;An exception occurred while C-MOVE with AE C001.\nThis made me think there was a device somewhere with an AE title of C001. After looking for that AE in the configuration files, I started searching online and found that C001 was one of five error codes for C-MOVE operations.\nI found this information in a discussion about the Conquest DICOM server. The error codes are as follows:\nCode Meaning C001 No destination AE specified C002 Empty destination AE specified C003 Destination not found or allowed C004 Search error C005 Destination not available I am curious whether anybody else has encountered C-MOVE errors with the PACSGear MediaWriter similar to mine.\n","date":"23 March 2009","externalUrl":null,"permalink":"/archive/2009-03-23-dicom-troubleshooting-pacsgear-mediawriter/","section":"The Archives","summary":"","title":"DICOM Troubleshooting: PACSGear MediaWriter","type":"archive"},{"content":"","date":"7 March 2009","externalUrl":null,"permalink":"/tags/document-scanning/","section":"Tags","summary":"","title":"Document-Scanning","type":"tags"},{"content":"Originally published on JS PACS, March 7, 2009. Part of the Radiology Workflow series. The two diagrams from the original post, a pros-and-cons table and a workflow chart, did not survive the archive.\nOne of the lesser-used functions of many PACS systems is a paperless radiology workflow. This page discusses some of the things you should consider when developing a paperless workflow for your radiology department. Paperless workflow can shave time off report turnaround, a very important metric for measuring quality in any radiology department.\nAn analysis of the documentation that travels through the radiology department turns up quite a few documents. The most common include:\nPatient questionnaires for MRI Contrast reaction forms for CT Consent forms Ultrasound worksheets Procedure requisitions All of these documents become part of the patient\u0026rsquo;s record or get turned in to the radiologist so that the study can be read. A radiologist who must wait to have documents in hand before reading a study loses time, which comes from the time it takes a technologist to get the documents to the radiologist.\nWhen a paperless solution is deployed, the radiologist has those same documents in PACS when they open a study to read, and a quicker report turnaround can be achieved.\nHow document scanning is deployed is a big decision in itself, since you gain certain benefits and pay certain prices with either an integrated or a third-party solution. Each has advantages and disadvantages.\nOnce you have figured out the type of document scanning you need, select it and then focus on the workflow.\nIt is up to the radiology department as a team to develop the best workflow around the paperless solution. It is up to you as the PACS administrator to make sure that everyone making the decision knows the pros and cons of each choice. Sometimes the choice is driven by the functionality of the PACS, other times by cost, and other times by radiology need. Think about the choices wisely and pick the scanning solution that best fits your needs, but do pick one. Your department cannot afford to be paper-driven.\n","date":"7 March 2009","externalUrl":null,"permalink":"/archive/2009-03-07-paperless-radiology-workflow/","section":"The Archives","summary":"","title":"Paperless Radiology Workflow: Considerations for the PACS Administrator","type":"archive"},{"content":"","date":"7 March 2009","externalUrl":null,"permalink":"/tags/workflow/","section":"Tags","summary":"","title":"Workflow","type":"tags"},{"content":"","date":"7 March 2009","externalUrl":null,"permalink":"/tags/hl7/","section":"Tags","summary":"","title":"Hl7","type":"tags"},{"content":"","date":"7 March 2009","externalUrl":null,"permalink":"/tags/prefetch/","section":"Tags","summary":"","title":"Prefetch","type":"tags"},{"content":"Originally published on JS PACS, March 7, 2009. Part of the Radiology Workflow series.\nA common question I hear new PACS administrators ask is, \u0026ldquo;What is meant by prefetching?\u0026rdquo;\nIn the PACS environment, a prefetch is when studies are retrieved from the permanent archive and restored to the local cache. This typically happens when an order for a particular patient is entered into the RIS. When that order comes through to the PACS via an HL7 message, the system goes and retrieves the appropriate prior studies on that same patient. These are typically of the same modality and body part as the current order. Advanced prefetching can be based on a combination of factors, such as modality and body part.\nAn example would be a chest x-ray. If a patient is having a chest x-ray today and in the past had some chest CT scans as well as chest x-rays, you would only want to prefetch the previous chest x-rays. Conversely, if that same patient was coming in for a chest CT, you would want to pull back from the archive all prior chest x-rays and chest CTs.\nSpending some time with your radiologists discussing which studies are considered relevant priors is important. If the time is not spent in advance, it will be lost at interpretation time. When a radiologist opens a study to read and the most relevant prior is not available, it has to be manually retrieved right then. That takes additional resources and slows down report turnaround time, which is an important radiology workflow metric. Another area affected by poorly planned retrieval is hanging protocols. If hanging protocols are built to include specific prior studies and those studies are not correctly retrieved from the archive, the hanging protocols will not work as well.\nAgain, spending time with the radiologists and having a thorough discussion of which relevant priors are needed for reading is imperative. Areas where extra time should be spent are the common multi-modality body parts such as the abdomen, pelvis, and chest.\n","date":"7 March 2009","externalUrl":null,"permalink":"/archive/2009-03-07-understanding-the-pacs-prefetching-process/","section":"The Archives","summary":"","title":"Understanding the PACS Prefetching Process","type":"archive"},{"content":"Originally published on JS PACS, March 7, 2009. Part of the Radiology Workflow series.\nWhen planning a radiology image QA program, you must make sure to provide the imaging technologists with the appropriate tools to do the work. This means installing video cards and monitors that can be calibrated and measured to the DICOM grayscale standard. Two-megapixel monitors at 21 inches are sufficient to show diagnostic-quality images for MRI, CT, ultrasound, and other modalities, with the exception of general x-ray and mammography. Monitors such as the Planar PX212 are sufficient and affordable enough to purchase and sprinkle throughout each area.\nFor general x-ray, you will want to purchase at least one three-megapixel monitor and place it in a central location for image evaluation. For mammography, the FDA requires a five-megapixel monitor for diagnostic viewing; there are numerous additional QA requirements in mammography that are outside the scope of this discussion.\nAs a PACS administrator, recommend to your leadership team that an image QA program be set up so that all technologists see images in a way similar to how the radiologist will see them. This helps ensure that by the time the images are available for the radiologist to read, they have already been viewed as they will appear to the radiologist. Also mention to your leadership team that there are various solutions available that allow you to build a quality program, which ultimately helps reduce turnaround time.\n","date":"7 March 2009","externalUrl":null,"permalink":"/archive/2009-03-07-basics-of-a-radiology-image-qa-program/","section":"The Archives","summary":"","title":"Basics of a Radiology Image QA Program","type":"archive"},{"content":"","date":"7 March 2009","externalUrl":null,"permalink":"/tags/qa/","section":"Tags","summary":"","title":"Qa","type":"tags"},{"content":"Originally published on JS PACS, March 7, 2009. This introduced the Radiology Workflow series; the QA, paperless, and prefetching pieces that followed are also in the archive.\nRadiology workflow! It is where the money is in the PACS world. Even the most technically superior PACS will not deliver the expected ROI if a department can\u0026rsquo;t get its electronic processes right.\nAs a PACS administrator, understanding the processes within the department helps you know where to look when specific incidents occur. A solid understanding of how information travels through the department will also let you analyze your PACS and make improvements when you are not getting the performance you expected. Installing a new PACS? This information will be instrumental in preparing for it.\nAs you progress through this section, you will find information about how a typical imaging department operates from the time an order is entered until the final report is signed.\nIf you are the IT-born PACS administrator, this section is critical for you. For the rad-tech-born PACS administrator, some of it will be review, but some of it will also help you understand what is happening behind the scenes in the HIS/RIS and PACS.\nTopics in the Radiology Workflow series include order entry specifics, modality worklist selection, image acquisition, study reading, and report generation.\n","date":"7 March 2009","externalUrl":null,"permalink":"/archive/2009-03-07-radiology-workflow-for-the-pacs-administrator/","section":"The Archives","summary":"","title":"Radiology Workflow for the PACS Administrator","type":"archive"},{"content":"","date":"5 March 2009","externalUrl":null,"permalink":"/tags/it-skills/","section":"Tags","summary":"","title":"It-Skills","type":"tags"},{"content":"","date":"5 March 2009","externalUrl":null,"permalink":"/tags/networking/","section":"Tags","summary":"","title":"Networking","type":"tags"},{"content":"Originally published on JS PACS, March 5, 2009. Part of the PACS IT Skills series. The diagram from the original post did not survive the archive.\nThe IP address, or Internet Protocol address, is an address assigned to a computer so that it can talk to other computers on a network. An address needs to be unique to the network segment it is on, but that same address can exist on another network. A few addresses are designated to be unique to the world and exist only once.\nWhen troubleshooting network issues, such as an image that won\u0026rsquo;t send to the PACS server, you can use the ping utility, which uses the IP address. It simply sends a small packet of information to another computer, and if the other computer receives that ping, meaning it is on the network and working, it sends a response back telling you it is alive.\nIf it helps to visualize, the address of a device can be compared to your street address, which is unique to your town but not unique to your state or country. There may be many 1035 Union Street addresses in the country; consider each town its own network segment.\nThis protocol is found on the third layer of the OSI model.\nAn IP address is built from four octets (eight binary digits each), each octet being one byte in length. An entire address is therefore four bytes long.\nIn an upcoming article, we\u0026rsquo;ll review the various classes of networks and how they work into subnets.\n","date":"5 March 2009","externalUrl":null,"permalink":"/archive/2009-03-05-the-ip-address-defined/","section":"The Archives","summary":"","title":"The IP Address Defined","type":"archive"},{"content":"Originally published on JS PACS, March 5, 2009. Part of the PACS IT Skills series.\nOperating systems, also known by the acronym OS, are the next topic in the IT Skills section.\nMost people are familiar with the Microsoft Windows platform; however, not all PACS systems run on Windows. This is why, as a PACS administrator, you will need to understand the different systems.\nThe OS is the software on which any workstation, server, laptop, PDA, or other computing device runs. The OS is responsible for sharing and coordinating all of the hardware resources on the device and allowing them to talk to each other.\nThere are three major OSs in use today: Windows, Unix/Linux, and Macintosh OS X.\nEach has its advantages. Windows is the most widely used OS; Unix/Linux is open source, so you can use it for free; and Mac OS X is very stable and has outstanding graphics capabilities.\nEach also has distinct disadvantages. Windows crashes fairly easily and has many security vulnerabilities; Unix/Linux is not a mainstream system and is therefore more difficult to adapt to widespread use in an organization; and Mac OS X runs on proprietary hardware from Apple, meaning you can\u0026rsquo;t put OS X on any hardware you would like.\nSome lesser-known systems include Solaris, BSD, QNX, and VxWorks. To my knowledge, there are no PACS systems running on any of these.\nAs a PACS administrator, I would recommend focusing on the Microsoft Server, XP, and Vista platforms, and learning Unix and Linux when you have the opportunity. Learning to operate in the Unix/Linux environment is a great way to build text-based computing skills. Anybody working as a PACS administrator at an Emageon PACS site can attest to that.\n","date":"5 March 2009","externalUrl":null,"permalink":"/archive/2009-03-05-operating-systems/","section":"The Archives","summary":"","title":"Operating Systems","type":"archive"},{"content":"","date":"5 March 2009","externalUrl":null,"permalink":"/tags/operating-systems/","section":"Tags","summary":"","title":"Operating-Systems","type":"tags"},{"content":"Originally published on JS PACS, March 5, 2009. This was the introduction to a series; the Operating Systems and IP Address pieces that followed are also in the archive.\nWhat PACS IT skills do you need?\nThere is a laundry list of IT skills that every PACS administrator must have. This site will cover all of those skills, but initially the focus will be on what you need to get through your day.\nSome very basic IT concepts you will need to understand include: Networking 101, Workstation Management, Server Management, and Storage Management.\n","date":"5 March 2009","externalUrl":null,"permalink":"/archive/2009-03-05-pacs-it-skills/","section":"The Archives","summary":"","title":"PACS IT Skills: The Essential IT Skills Every PACS Admin Should Know","type":"archive"},{"content":"Originally published on JS PACS, March 5, 2009. A reprint of my article from rt-image, vol. 21, no. 35, September 2008.\nPACS is ubiquitous. At one time or another, whether attending the Society for Imaging Informatics in Medicine (SIIM) conference, researching the latest technologies in imaging informatics, or evaluating PACS vendors, we have all heard statements to that effect.\nThat means a second round of PACS implementation, consisting of ripping out the old and putting in the new, is underway. There can be many reasons an organization may have lost faith in its initial PACS vendor: not providing adequate support, annual costs that are too high, or not improving the software in the direction that is needed.\nOr maybe a vendor\u0026rsquo;s product does not fit into an organization\u0026rsquo;s workflow. That is a surprising reason, but it is happening to some users. During early implementations of PACS, the goal was to get images stored into PACS without much thought given to the other work that occurred in obtaining the images.\nFor your next PACS implementation, be sure to fix your workflow woes by making sure you understand how to better integrate PACS into your imaging department\u0026rsquo;s workflow.\nLooking at Workflow Nuances\nBefore discussing the integration of PACS and radiology workflow, a review of imaging workflow basics is necessary. In its simplest form, the workflow consists of: order entry; receiving the patient; imaging; evaluating the images; releasing the patient; submitting the images for interpretation; interpreting the images (dictation); transcription of the report; and, finally, signing the report.\nThese steps seem pretty unremarkable until you analyze the nuances that occur at the transitions between each phase. It is at those transition points that imaging informatics can really improve the overall workflow.\nIn the interpretation process, technology can make enormous improvements both during the transitions and in the interpretation itself. Extra effort should go into completely documenting existing workflows from the very beginning of the imaging process (order entry) through the signing of the final report. Only then should the project to go from analog to digital workflow begin.\nEarly Oversights\nOne of the primary things PACS vendors failed to provide in the early versions of their systems was functionality for integrating the radiology workflow nuances into the PACS workflow. In its standard form, a PACS allowed studies to be in one of two statuses: unread and read.\nThe basic PACS workflow was to image a patient, send the studies to PACS in an unread status, and have the radiologist interpret the study, changing it to read. All the other workflow that occurred in radiology never changed.\nOrders were provided via written scripts and entered into a hospital information system/radiology information system (HIS/RIS). This generated a printed paper requisition that served as a transportation slip, patient identifier, a tickler indicating a study needed to be performed, and, ultimately, a document handed to the radiologist stating that a study was ready to be read.\nProperly Integrated PACS\nNow, with a fresh picture of how radiology workflow used to occur (or still does, for those who didn\u0026rsquo;t integrate it properly), and an understanding of the stages a study passes through in its lifespan, taking the paper out of the workflow and moving into the digital era should become clearer.\nHere is a scenario with a properly integrated PACS:\nThe study is ordered and the patient is processed into the department. After arrival is completed electronically, the technologist, viewing a RIS-based worklist, sees the order appear on screen. The technologist can optionally print a small card for transporting an inpatient to the study. If the patient is an emergency department patient or an outpatient, the technologist simply calls the patient back to the imaging room. The technologist finds the study on the imaging device\u0026rsquo;s modality worklist, selects the correct patient, and begins the exam. In a completely integrated system, initiating the study on the imaging device changes the order\u0026rsquo;s status in the RIS to \u0026ldquo;begin procedure\u0026rdquo; or \u0026ldquo;start procedure.\u0026rdquo; Images from the study are sent to PACS. Once they arrive, they are in a \u0026ldquo;performed\u0026rdquo; status. The technologist moves to a PACS workstation, finds the study on a worklist set to display only studies not yet marked reviewed, and opens it. The technologist reviews each image, ensuring it is in the proper sequence, at an appropriate window/level, and of overall diagnostic quality. While the study is open, the technologist scans any paper documents generated during the study (contrast questionnaires, etc.) and provides the radiologist with pertinent patient history through a \u0026ldquo;study notes\u0026rdquo; type of tool. After confirming the study is diagnostic, scanning in documents, and adding study notes, the technologist changes the study from \u0026ldquo;performed\u0026rdquo; to \u0026ldquo;reviewed.\u0026rdquo; This is the equivalent of handing the radiologist a piece of paper saying the study is ready for interpretation. The study disappears from the technologist\u0026rsquo;s worklist (set to show only performed studies) and appears on the radiologist\u0026rsquo;s worklist (set to show only reviewed studies). The radiologist opens the study for interpretation and, through properly deployed hanging protocols, sees not only the images but is automatically presented with the patient history and any scanned documents. Using voice recognition, the radiologist begins a dictation session from within the open study. After interpretation, the radiologist either reviews and signs the report immediately (placing the study in a \u0026ldquo;reported\u0026rdquo; status) or sends it to transcription for verification (placing it in a \u0026ldquo;dictated\u0026rdquo; status). Within a short period the review is completed and the report is sent back to the radiologist for signing, at which point the study moves to \u0026ldquo;reported.\u0026rdquo; Easier Said Than Done\nWhile it is easy to document such a system on paper, correct implementation is a completely different matter. There are multiple components that need to be in place to allow such tight integration. Migration to a workflow like the one above cannot happen solely upon the purchase of a PACS.\nAn appropriately functioning HIS/RIS, voice-recognition dictation, and a document scanning solution all must be part of the implementation. If members of your project team balk at the higher prices that come with this functionality, explain to them why it is needed to improve overall workflow.\nAfter reviewing the ten steps above, I hope it is easier to see that simply allowing a study to be marked read or unread does not fit the bill anymore. Vendors have to work toward providing a PACS that fits the needs of the radiology department.\nSince the first generation of mainstream PACS ten years ago, some vendors have realized the need for a multiple-step process for radiology studies. However, whenever I visit SIIM or RSNA and ask a new vendor whether they provide multiple statuses for radiology studies, they still respond, with a curious look on their face, \u0026ldquo;Well, of course we do. Look here. See? Read and unread.\u0026rdquo;\nI try to explain why I look for more than two statuses; but if, after the first iteration of what I just described, I still get a blank stare, you can bet the conversation is pretty much over.\nPoints to Ponder\nThrough this article, I hope to have accomplished two things. First, I hope I have put into print what many PACS administrators have been trying to convey to vendors over the past two years: \u0026ldquo;Please build us a system that can adapt to what we do.\u0026rdquo;\nSecond, I hope I have conveyed to PACS administrators, radiology managers, and IT directors how important it is to find a vendor whose system provides these finer points of functionality. It is definitely worth the extra money to purchase this up front.\nIt will save you time, effort, and even more money when you see a return on investment more quickly, and it prevents you from having to rework your PACS and radiology workflow two years after the initial purchase. If you don\u0026rsquo;t properly integrate your workflow up front, I will put my money on the fact that you will be reevaluating PACS vendors within three years.\n","date":"5 March 2009","externalUrl":null,"permalink":"/archive/2009-03-05-pacs-enhancing-radiology-workflow/","section":"The Archives","summary":"","title":"PACS: Enhancing Radiology Workflow — Integrating PACS Is Key","type":"archive"},{"content":"","date":"5 March 2009","externalUrl":null,"permalink":"/tags/ris/","section":"Tags","summary":"","title":"Ris","type":"tags"},{"content":"Originally published on JS PACS, August 9, 2008. First appeared in Health Imaging \u0026amp; IT.\nMany healthcare career paths are built on successive education, and there are different ways of indicating ascension into higher levels of your profession. An obvious method is the degrees you obtain. Another common method is obtaining certification along a logical progression of tasks or skill sets.\nAs the PACS administrator profession grows, so have the opportunities to obtain certification. Two organizations currently provide certification for PACS administrators: the American Board of Imaging Informatics (ABII) and the PACS Administrators Registry and Certification Association (PARCA). ABII offers the Certified Imaging Informatics Professional (CIIP) exam, and PARCA offers a track of exams that culminates in the Certified PACS System Manager. I have had the opportunity to obtain both the CIIP from ABII and the CPSA level of certification through PARCA. A comparison of these two methods of certification is an ongoing hot topic among PACS administrators in the field. Regardless of which side you take or which certification you prefer, there are unique aspects of each that warrant consideration.\nABII\nThe American Board of Imaging Informatics and the CIIP exam were introduced during the 2007 SIIM conference. This exam has many myths associated with it. One myth is that it is associated with the American Registry of Radiologic Technologists (ARRT). This is not true. Yes, the CIIP exam has undergone psychometric development similar to that of the ARRT exams, but it is in no way associated with the ARRT. The fact that the ARRT served as a model for building the exam should be a comfort to those who take it, in that it follows the many years of tradition the ARRT exam has developed. No one can deny that the ARRT is the obvious benchmark for testing in the medical imaging profession.\nAnother myth I hear debated among PACS administrators is that there is no way to prepare for the CIIP exam. This also is not true. The ABII website provides the test content outline, which is a clear definition of the subject matter that can be found on the exam. Understanding each of these topics will help a CIIP candidate prepare. There are multiple ways to prepare for the CIIP exam. The best way to study is to simply be a PACS administrator for a year or two, especially during an implementation, upgrade, or replacement of a major system such as PACS, voice recognition, or your HIS/RIS. Understanding and gaining experience in both clinical workflows and information system components is critical to being ready for this exam. Networking and attending seminars are also beneficial for gaining critical knowledge for your profession and for the exam.\nPARCA\nPARCA and the series of exams that make up the various levels of PARCA certification started a few years prior to the CIIP exam. This certification consists of a three-tiered exam system. The entry-level exam, Certified PACS Associate (CPAS), is made up of two tests. The first evaluates a PACS administrator on technical knowledge. The second evaluates clinical knowledge. These two tests can be taken in any order, but both are required to progress to level 2.\nUpon reaching level 2, an individual can take the Certified PACS Interface Analyst (CPIA) exam. The CPIA tests an individual\u0026rsquo;s understanding of DICOM and HL7, including troubleshooting in both areas. The second level 2 test is the Certified PACS Systems Analyst (CPSA), which tests an individual\u0026rsquo;s understanding of the various components of a PACS and of system administration. Again, both of these tests are required to pass to the level 3 exam.\nThe Certified PACS System Manager (CPSM) is the final and encompassing exam. Holding this certification demonstrates that an individual has an advanced understanding of all imaging informatics topics, including image quality, advanced DICOM and HL7, security, and systems integration.\nAs with the CIIP exam, there are myths associated with PARCA certification. The primary one I hear is that you must study with materials from a specific organization in order to pass. I can assure you this is not true; I have never purchased any study materials from that organization. All my preparation for the PARCA exams was based on my own experience and learning.\nConclusion\nBefore giving my personal opinions of both certifying organizations, I feel compelled to offer a disclosure. I am a member of the CIIP item review committee as well as a CIIP item writer. I\u0026rsquo;ll also reiterate that I hold both the CIIP and the CPSA certifications.\nBoth of these organizations offer positive things for PACS administrators. Primarily, both offer recognition that the individual has obtained a certain level of knowledge and understanding of the components and complexities of imaging informatics in today\u0026rsquo;s healthcare environment. Additionally, both offer an increased level of professionalism in the rapidly evolving PACS administrator career. I will say that I feel there are distinct aspects to each exam.\nI feel the CIIP demonstrates concrete knowledge of PACS and the various components that interface with it. Additionally, I think the individual who holds a CIIP certification assures an employer or organization of a higher level of survivability during the crisis moments that imaging informatics can sometimes bring. It does this by assuring an understanding of all aspects of PACS encountered in day-to-day operations.\nI feel the PARCA exam series also demonstrates concrete knowledge of PACS and all of the components involved. PARCA certification likewise assures an employer that an individual is qualified to operate autonomously in the imaging informatics field. Additionally, I would offer that the PARCA exams evaluate an individual on their understanding of all the aspects of imaging informatics a PACS administrator may encounter throughout a career.\nUltimately, both certifying organizations hold critical places in the PACS administrator profession. Perhaps as PACS administrators we should stop comparing and contrasting the two exams and work to obtain all the levels of certification that we can.\nABII and SIIM are registered trademarks of their respective organizations.\n","date":"9 August 2008","externalUrl":null,"permalink":"/archive/2008-08-09-pacs-certification-two-valid-options/","section":"The Archives","summary":"","title":"PACS Certification: Two Valid Options","type":"archive"},{"content":"I\u0026rsquo;m John Sole. Premier Imaging Informatics is my consulting practice, and it\u0026rsquo;s just me.\nI started in the scanner room. The Army trained me as a radiologic technologist in 1994; I spent the next decade doing x-ray, trauma imaging, and CT, and moved to the IT side in 2004 as a PACS analyst. For the next eight years I ran imaging systems inside hospitals: PACS, cardiology PACS, a RIS, speech recognition, and an early vendor-neutral archive. Then I crossed to the vendor side, spending six years as a solutions architect for the Acuo VNA (later Lexmark Healthcare) and Vital Images, working out how those systems fit into what health systems across the country already had running. In 2018 I went independent.\nThat path is the point. I\u0026rsquo;ve been the person who gets paged at 2 a.m. when the archive stops accepting studies, and I\u0026rsquo;ve been the person who drew the architecture that was supposed to prevent it. I understand what the radiologist needs, what the modality actually sends, and what the database is doing underneath.\nToday I work with health systems on enterprise medical imaging: implementing new PACS and archive systems, migrating data between them, and connecting imaging to everything around it, from modalities to the EHR. Most of that lives in the standards, DICOM, HL7 and IHE, and in the databases and interfaces beneath them. When a production problem needs someone to trace it to the protocol or the query, that\u0026rsquo;s the work I like most.\nMy clients are academic medical centers, cancer centers, and children\u0026rsquo;s hospitals. I take engagements through healthcare advisory firms rather than selling directly.\nI sat the first CIIP exam in 2007 and later wrote exam items and served on the exam committee for ABII. I hold an MBA from Rockford College. I write SQL and Python when the problem calls for it.\nWriting # I publish here on imaging informatics: methods, standards, and things I\u0026rsquo;ve seen go wrong. Where a claim would be challenged by someone who knows the field, I cite the standard or the paper. Where numbers appear, the method behind them is shown. The rest is experience, stated as such.\nContact # jsole@pii.services\n","externalUrl":null,"permalink":"/about/","section":"Premier Imaging Informatics","summary":"","title":"About","type":"page"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"}]