Healthcare IT
Too Many, Too Few …Just Right
One thing I have noticed (and was commented on by an esteemed panelist at the SIIM Regional meeting) is the wide disparity of the number of IT and Admin staff working on medical imaging systems among similarly sized facilities. One hospital has 10 FTE, while a peer has 2 FTE. I can’t imagine that there are productivity differences to account for such a variation. I have to think that one is simply doing more work (quality control, systems integration, user support and training, etc.).
This begs the question: how many FTE is the right amount?
I have not seen anyone come up with a ratio of the number of FTE per exam volume amount, modalities, etc.
PACS Challenges – A Perspective from the SIIM Regional Meeting
“PACS” is used well beyond radiology; how can they still own it? It is being decomposed into discrete services, but it still has to come together and be fast and reliable (software is only valuable if it is available and responsive when needed).
Integrating patient records (different patient ID domains, order schema, different procedure codes, etc.) is critical to a patient’s imaging record interoperability, whether it is to consolidate records to a shared system (e.g. imaging studies in a VNA), or at access time (on demand cross indexing when viewing studies from different patient ID domains).
For all the pages of must have features that fill a PACS RFP, most people I talk to would trade most of them for a fast PACS that never crashes.
SIIM Regional Meeting in Philly
I am attending the SIIM regional meeting in Philadelphia. Keeping the sword sharp by listening to experts talk about challenges in radiology and informatics. Good turnout. Great to see some friends.
Noted some increasingly commonly reported trends…
- Funds for PACS expansion, upgrades, and replacements are threatened by the focus on EMR adoption.
- Enterprise imaging is becoming a focus for informatics professionals; a VNA is the most common place sought to store these images.
- In addition to the VNA taking the “A” out of PACS, it seems most people are looking to PACS add-ons (“PACS Apps?”) to solve problems over looking for a solution engineered into their PACS. I wonder if this is because of the focus that a smaller vendor can apply to the problem space, or that PACS vendor resources are consumed with managing the installed base, or that they are strategically reducing R&D investment as the PACS market become saturated and radiology revenues decline.
Article from HIMSS: PACS will not remain a self-contained data silo
Have a read (may need an account).
Some thoughts…
- The shift of the “archive” out of PACS has been well-discussed and is occurring today with the maturation of the VNA market; though these primarily serve PACS.
- I believe that the next evolution will be a significant advancement in the ease at which a medical imaging record may be discovered and accessed. And these records will be dynamically transformed and provided to the wishes of the consumer (user or application). This will come through new REST-based Web protocols, such as those being defined in DICOM WG-27 and the HL7 FHIR initiative; as well as modern full text search methods.
- With these new methods the lines between records in DICOM, document, or structured data formats will be blurred and the content much easier to cross-index and normalize.
- The same evolution (easy to find, access, use) will occur to resources, such modalities and clinical specialists. The freedom I have to find and reserve a flight among dozens of providers within seconds compared to the ability to book an appointment for a CT exam would be laughable, were it not depressing.
Article: Healthcare Imaging Strategies Not Exactly a Snap
An article on enterprise imaging and image sharing that is worth a read.
Some thoughts…
- Informatics at the time of capture is (very) important, but this doesn’t mean we are back to typing data in–most of what is needed can easily be discovered on demand by a Web service
- VNA’s are still being considered a component distinct from PACS and the EMR–they should be considered an EMR component, enabling the management of imaging records within the EMR
- You can question the ROI of including images in the EMR or assess the clinical relevance (both noble goals), but one thing I have learned: EMR users want them there (and you should want to make them happy)
- People still think we need to move a full copy of the DICOM images around to share; when I share a video on YouTube, I share just a link. The state-of-the-art of medical imaging is at the same level. Only make a copy of the full data if you need to incorporate it into your systems as a new record.
- Something I have recently observed: regardless of whether including images in an EMR is an optional menu or required core item in MU, if the people interpreting these rules believe they need image access display for referring physicians inside and outside the hospital, they are going expect to be able to put them there.
5 CIOs imagine health IT in 10 years
via Healthcare IT News.
Patterns…
- Interoperable (HIE) and integrated (EMR) patient records
- Sensors/monitors (bedside, mobile, home) integrated with health records
- Shift of risk from payers to providers (providers funded based on outcomes, quality measurements, savings realized–not volume of procedures)
The Future of Image Sharing
I have been keeping tabs on some of the work in standards groups; most notably HL7’s FHIR and DICOM WG-27’s DICOMweb™ APIs: WADO-RS, QIDO-RS and STOW-RS. I think the ‘awakening’ to REST based Web APIs and the willingness to accept the use of data in new forms (e.g. metadata in JSON vs. traditional DICOM C-FIND RSP), marks a watershed moment in the healthcare IT industry. I spent some time looking at a project focused on image sharing and tried to see what impact these changes might have on how it manages data. Check it out.
The Power of REST in Healthcare IT
The beauty and power of REST is in its conceptual and syntax simplicity, ease of use for consumers, and freely available technology stack.
For example, if I have a URL that says…
https://server_name/patient/?patientName=DENNISON
…you can probably guess what will be returned without reading any documentation (answer: info on patients with the Dennison in the name). Another example…
https://server_name/study/?patientId=123&accessionNumber=456&view=epr
…would return a specific study with some form of defined application setting called “epr”.
REST is always stateless, can use any accepted authentication method used with URLs (e.g. Kerberos, OAuth, OpenID, etc.), and perhaps most importantly can be used by Web browsers (and any other consumer) without any added client technology. Other Web service methods, like SOAP, are effective for machine to machine communication (which is why they are popular in large-scale enterprises for transactions), but are not possible to consumer from a Web browser without some for of added download. IHE went heavy into SOAP due to the influence of the preferences of the large companies involved–and, to be fair, most of the integration profiles were dealing with machine to machine transactions, and SOAP was more defined/accepted than REST, at the time. Now they are rapidly turning to REST as innovators, eager to unlock the power of REST proven by companies like Google, Facebook, and Twitter, are involved in the integration profiles.
