Monday, May 21, 2012

The US Privacy Paranoia

Typical Dutch landscape

During my recent DICOM/IHE seminar in the Netherlands, I got the opportunity to hear from the participants about the state of healthcare in that country, a discussion I always try to attend as I find there is much we can learn from other countries.
The differences between the Dutch healthcare system and the U.S. healthcare system are quite large. First of all, in the Netherlands, everyone has healthcare insurance, something we may or may not be getting closer to in the US depending on the Supreme Court ruling on the healthcare act expected later this year. Second, the Dutch do a far better job in managing their healthcare expenses and also rate much higher in quality of care, access and efficiency. As a matter of fact, in a comparison study between seven countries (Australia, Canada, Germany, Netherlands, New Zealand, the UK and the United States), the Dutch came out on top, and, not surprisingly, the USA ranked on the bottom[1].
I am sure that one of the reasons for the difference in ranking is the level of electronic health record implementations. Even though the number of physicians having an EMR in the US is growing steadily, thanks in part to the incentive program as part of the ARRA Hi-Tech act, it is far from the 90 plus percentage in the Netherlands. Interestingly enough though, there is still relatively little sharing among U.S. institutions and the notion of the Health Information Exchanges (HIE), which are rapidly being deployed in the US, is still foreign.
One thing that the Dutch do right is their use of a so-called “BSN” which serves as the universal patient ID. It is not uncommon for European or even some Asian countries to have a unique identifier that is used as a key for matching patient records, but also insurance verification. I always have a hard time explaining the reasons that there is no such thing in the US. I recall the strong opposition from the privacy advocates when the US government tried to introduce this concept as part of the initial HIPAA discussion. I am personally convinced that the privacy concerns are overrated and that the increased risk for mismatching patient records, and the increased cost of creating an infrastructure to reconcile patient identifiers among different domains, far outweigh privacy concerns. Are Europeans in general less concerned about “big brother” than US citizens? I don’t believe so, for example, some of the information that is important to be captured as part of the patient information in the US, in particular the “race” of a patient, is illegal to be captured in many other countries.
Not having a unique patient identifier means that we have to establish an elaborate patient identification cross referencing system as part of the infrastructure to exchange medical information between different domains. Technically, this is not an issue as there are solid standards defined and the IHE has also defined a well-known and implemented profile to do this. However, how can we practically make sure that a John Smith with the same sex, and birthday is actually the same person? The biggest risk I have been told by a developer of master patient indexing software is the match of an identical twin of the same sex, born on the same day, and obviously having the same last name. No wonder these babies immediately get a wristband when they are born in a hospital, but as soon as they leave that institution, they are on their own risk for misidentification.
I believe a much better solution would be to establish a federal patient identification by which the person should have the option to have a unique identifier (“opt-out”). A recent credit rating check based on my social security number showed a list of accounts under 12 different misspelled names. Imagine if I would do the same for my patient records. Without a unique number, the health record my doctor is looking at might be missing the vast majority of my medical history. As a result of what I call the U.S. privacy paranoia and not having a unique identifier, my risk of having an incorrect, or incomplete medical record is greatly increased. Hopefully, some our privacy advocates will start to see this as the greater danger in terms of healthcare.

[1][1] Source: OECD Health data, 2009

Thursday, May 3, 2012

RIS/PACS integration issues when performing multi-modality studies.

A typical multimodality PET/CT study
When using a RIS, PACS and a voice recognition or traditional transcription reporting system from different vendors, many institutions are having integration issues with mapping the orders to the performed studies and resulting reports. These scenarios are well documented as part of the IHE scheduled workflow profiles; however, not every system is fully compliant with the information model, which covers the relationship between the orders, studies and reports. Some institutions use a work-around that is either implemented in software that semi-automatically merges the results, or require a manual merge at a QA station at the PACS or RIS.
Let’s first discuss what the “official” guideline as prescribed in the IHE documentation specifies. An order for a multimodality study such as PET/CT, PET/MR or other combination typically has a single requisition based on an order, and is identified by a placer order number issued by a CPOE (Computerized Physician Order Entry) system, and a filler order number, which is typically issued by a scheduling system such as a RIS. This filler order number is often used as the Accession Number, but a RIS can also create a new Accession Number that is unique for a particular department, in this case radiology. The requisition is referred to in the DICOM and IHE specifications as an Image Service Request or ISR.
Upon querying the modality worklist from a worklist provider, which could reside in the PACS, RIS or a separate broker depending on the system architecture, the modality such as the CT/PET machine will display the information of this order in its worklist. Multiple scheduled procedure steps can be included, such as in the case of a CT/PET, one step for the CT and one for the PET. The information in this step includes scheduled date/time, any procedure codes, etc., which is visible to the technologist. Patient demographics and visit information as well as any pertinent details such as weight, allergies, etc, is visible as well, most of which is reused to fill the corresponding data fields in the header of the DICOM images. Invisible to the user is the study identifier that is also provided in the worklist, i.e. the Study Instance UID, which is used to uniquely identify the study. In the CT/PET scenario, each study, i.e. CT and PET gets its own unique Study Instance UID. There could be multiple steps to be performed for each study, for example, a CT might have a set of images acquired without contrast and one set of images with contrast.
When the studies arrive at the PACS, they will be visible to a radiologist on the workstation worklist. Depending on how the worklist is configured, a radiologist might read both studies, but the two studies also can be reported separately as Nuclear Medicine is a specialty that is often served by a dedicated radiologist.
When multiple reports are created, each one is identified with the same Accession Number just as the multimodality study has a single requisition, and therefore single accession number. These results are sent back to the RIS or report storage and distributor.
There are a couple of areas where discrepancies might occur. First of all, not all modality worklist providers can provide multiple scheduled procedure steps as part of a single requisition, or a modality worklist consumer (i.e. modality) might not be able to display multiple items either. If the two modalities are not integrated, but rather, have two separate worklists, e.g. one for the CT and one for the PET, one needs to make sure that the procedure is not completed until both studies are performed, otherwise it might no longer be visible on the second modality’s worklist. At the back-end, the reporting system needs to be able to select either the combined study or individual studies, depending on how it is being reported. When multiple reports are sent back, the receiver needs to be able to recognize that the second report is part of the requisition and not reject it under an assumption that a single requisition always creates one and only one report.
To resolve these issues requires mapping of the multimodality capability of the RIS, modality, PACS and reporting system. At any discrepancy, one might need to spit and/or merge either one automatically or manually. For example, some institutions issue two separate requisitions, one for each study, and are able to merge the results at the backend. Some can create sub-Accession numbers, each having a child associated with its parent relationship. Whatever the capability, one should work with the RIS, modality and reporting experts to come up with the workflow that is the most effective and efficient. Note that these multi-modality studies will become increasingly popular as new modalities are introduced; therefore, it is wise to come up with a permanent solution instead of manual or semi-automated solutions that require repetitious manual labor.