Interoperability
Plug-ins vs. APIs
Without endorsing the product represented (I have not looked at it at), I think this blog post is covering some important points (and is well written, so do have a look).
Some thoughts, though…
Pet peeve of mine: The smartphone app metaphor is a bit overused in enterprise software that manages personal healthcare information. When a physician is making a life-altering decision about my (or my loved ones’) care, I would hope that they are relying on something with a bit more vigilance around it than something that they downloaded along with a Kanye West tune. I want something that is “battled tested” and properly integrated in the enterprise (see ITIL Change and Configuration Management) before being used clinically in the hands of healthcare providers. Call me paranoid.
Look, I get it. Users like downloading and using “apps”. But, the expression of desire for “apps” is properly translated in a desire for more flexibility and responsiveness from their healthcare IT vendor(s)–people like the personal experience of the control that downloading apps provides them and speed of innovation (with a decent platform, apps can be developed with massive parallelism–think Army of Nerds) , but if Angry Birds makes a mistake, no one dies (well, a bird, I suppose–never played the game so I am only guessing).
I may get some flame mail from respected friends for this one: open source applications are also not the (complete) answer. Sure, its fun to be able to change and extend source code (and to become a hero by fixing bugs yourself instead of waiting for a fix from your vendor), but for every “coder” I have met only a small percentage that really understand the full scope of work of professional software development required to produce an application to the quality we need in healthcare. Don’t get me wrong: I love hackers. They break through barriers and solve problems with practical methods. But, their output typically needs a lot more work to make something that is production ready. Great power, great responsibility, and all that.
The reality is: we don’t need a bunch of user-downloadable apps or developer-modifiable source code. We need APIs. Good ones. REST-based Web service APIs. Documented, well-designed and tested. Supported. Unbreakable, secure ones.
When done right, APIs are contracts. Promises. They aren’t some side-door or limited set of functions added as an afterthought. They become the language by which applications speak to each other, even internal parts of an application.
Healthcare standards like DICOM and HL7 standards include APIs, just ones based on older technologies and protocols. The information model is still pretty solid, I would argue, so we don’t need completely new “words”, just some different ways to communicate.
Oh, and products with great APIs are generally higher quality because it is much easier to write automated tests to beat the crap out of them before unleashing them on to the world.
More on this topic later.
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.
Don K Dennison 