The discussion got heated because there is interest in getting a very targeted notification. As elaborated there is indeed no specific IHE profile capability to do this notification. There is however many ways that the functionality can be implemented. No single functionality is universal, there are really good reasons for each method.
The XDS notification functionality methods are:
Poll: An individual (system) can poll XDS. That is to use Queries one for each patient that system has individuals that are interested in. How often should it poll is left as a configurable parameter as there are good reasons to have this configurable. ** Note this is very much what e-mail uses at the technical level with POP. Clearly as users we are not polling, nor do we know our machines (cellular phones) are polling. This is the most basic, and most robust mechanism. But this is also cumbersome and causes unnecessary traffic and query processing. *** Note that doing date specific queries are not easy to do, but can be done; and there is a Change Proposal to enhance the query.
Notification: The Notification of Document Availability (NAV) Profile is a little known supplement. It defines a simple XML encoded manifest of document references, and indicates to send this in an e-mail message. This is just a list of document ID values, so it is not exposing patient privacy in any direct way. This e-mail could surely be sent using encrypted email if you have that capability. The drawback is that it does require that someone knows that you need to be notified, and that you would like to be notified in this way. *Note that the profile does have a specification of how to encode this on paper as well. ** Note a degenerate form is simply an e-mail with no information, just a ‘ping’ that you might recognize, however this isn’t interoperability. *** Of course you could also just pick up the phone as well.
PUSH: That is to Push the content using XDR or XDM. This could be a copy of the documents, because they are globally uniquely identified there is no problem that they get duplicated. ** Clearly again the publisher must know who to next notify *** Because this is full content one must secure the communications.
Subscription: There is the Document Subscription (DSUB) profile that allows a system to ‘subscribe’ to be notified. This subscription contains a filter criteria that would constrain why a notification would happen. Although this is a rather technically easy profile, it is not implemented often. It is not clear how big does a notification system need to be to satisfy a growing population of systems that want notification. This profile is also tied to SOAP webservices, and really only works within a single XDS domain.
Atom Feed: This is really a polling query, but the results often is seen as a form of notification. The Atom feed is a part of the Mobile Health Documents (MHD) profile.Is there a pattern that we don’t have? I know of some creative ways to use TCP sessions that are left in a closing state, where the one that knows who to notify closes the connection when there is something useful to pull, thus causing the system to poll only when this session close event happens. This is a very low overhead, but does require the systems handle many failure-modes robustly. This is what happens in some mobile APIs to help limit the polling traffic.
Specific to workflows, in the Cross-Enterprise Document Workflow (XDW) profile we did document that a workflow does need to have a system watching to make sure workflows do progress normally. This system could notice a workflow document that seems to have stalled, and give notice via a mechanism like NAV.
It seems we have plenty of ways to achieve the functionality. This technical solution should not be confused with what the user sees or feels.
Document Management (Health Information Exchange - HIE)
- Healthcare Metadata
- Minimal Metadata
- What is the benefit of an HIE
- Karen's Cross or just Minimal Metadata
- HIE using IHE
- Texas HIE Consent Management System Design
- The French Health Information Systems Interoperability Framework -- Now available in English
- One Metadata Model - Many Deployment Architectures
- Critical aspects of Documents vs Messages or Elements
- Using both Document Encryption and Document Signature
- Document Encryption
- XDS/XCA testing of Vocabulary Enforcement
- Where in the World is CDA and XDS?
- Universal Health ID -- Enable Privacy
- HIE/HIO Governance, Policies, and Consents
- IHE - Privacy and Security Profiles - Document Encryption
No comments:
Post a Comment