Some interesting observations in this article. We always need to consider the right moment to get users (patients, in this case) to engage when rolling out a new program and trying to get adoption. It can be the right application with the right value to the right people, but presented to them at the wrong time.
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.
WSJ.com: The Coming Failure of Accountable Care
The Coming Failure of Accountable Care
Interesting (and perhaps correct) predictions.
While a change to the financial motivations–from reimbursement for procedures (which leads to volume) to funding based on clinical outcomes, quality of care and savings achieved–is admirable, the issue of change management looms. If the systems changes, but those in the system do not, what is accomplished?
Also, one thing I still have to figure out (more reading needed) is how an ACO serving a statistically high elderly or obese or otherwise higher health risk population is compared to one that serves a relatively young and healthy population. Is there some form of “base line” measurement done and the ACO is measured based on improvement from 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.
Don K Dennison 