MACM Volume2 Standards Assessment
Standards
| Standard | Reference | notes |
|---|---|---|
| FHIR DTSU v2 | http://www.hl7.org/implement/standards/fhir/alert.html | would likely need to define an extension or a new "x-alert" resource
(x-alert = cross enterprise alert) |
| AMQP | https://www.amqp.org/resources/specifications | not healthcare domain aware.
0.9.1 had message broker model (for AM to AC). 1.0 drops this |
| XMPP | http://xmpp.org/xmpp-protocols/protocol-namespaces/ | not healthcare domain aware.
messages routed to single user would not make use of "presence" as that is AM to AC |
| WEA | https://law.resource.org/pub/us/cfr/ibr/001/atis.j-std-102.2011.pdf | US centric (FCC/FEMA) and narrow scope:
Alerts from WEA cover only critical emergency situations. Consumers will receive only three types of alerts: 1. Alerts issued by the President; 2. Alerts involving imminent threats to safety or life; 3. Amber Alerts. Participating carriers may allow subscribers to block all but Presidential alerts. Broadcast transaction specification for CAP (no response) |
| CAP | http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html | no transactions specified |
| IPAWS | https://www.fema.gov/integrated-public-alert-warning-system | no transactions specified |
| WS-Notifications | http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.htm | not healthcare domain aware.
"Notification Producer" is relevant actor |
| WS-Reliable Messaging | http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdf | not healthcare domain aware
not relevant |
| HL7v3 ? | ||
| Open Mobile Alliance:
RESTful Network API for Notification Channel |
http://technical.openmobilealliance.org/Technical/technical-information/release-program/release-program-copyright-notice?rp=2549&r_type=technical&fp=Technical%2FRelease_Program%2Fdocs%2FNotifChanREST%2FV1_0-20130730-C%2FOMA-TS-REST_NetAPI_NotificationChannel-V1_0-20130730-C.pdf | transactions which could be used from AR to AM not specified (it is more from AM to AC) |
| PCD ACM | http://wiki.ihe.net/index.php?title=PCD_Technical_Framework | |
| IEEE 10101a | http://standards.ieee.org/develop/project/11073-10101a.html | codesets only |
| Bespoke Solution for mACM |
Availability and Maturity of Standard for Use
| Standard | Openness of Standard | Market Penetration / Availability of Implementations | Potential for evolution of the standard |
|---|---|---|---|
|
|
| |
| FHIR DTSU v2 | open FHIR license / Creative Commons | ||
| AMQP | AMQP 1.0 freely available (OASIS) | AMQP 0.9.1 has many implementations/libraries. AMQP 1.0 is much less | Quoting: "AMQP/0.9.1 is legally and technically dead. The old spec is copyrighted by the AMQP Working Group and not remixable. There are no mechanisms for extensions, patches, fixes, anything."
AMQP 1.0 is from OASIS |
| XMPP | Subject to: See http://trustee.ietf.org/copyright-faq.html
World wide royalty free distribution. Yes. Anyone can publish and translate unmodified IETF Documents and Contributions for any purpose, even outside the IETF Standards Process. In addition, Code Components included in IETF Documents can be used for any purpose pursuant to an open source license (see Topic 3 and especially Question 3.1 for license details). |
See http://en.wikipedia.org/wiki/Comparison_of_XMPP_server_software | open standard as part of IETF - XMPP working group |
| WEA | produced by Alliance for Telecommunications Industry Solutions Not redistributable w/o prior consent | US wireless networks | |
| CAP | Open (OASIS) | used in multiple countries | OASIS believes widespread adoption can only be achieved when all those affected by a standard participate in its creation. We offer a range of membership levels to support an inclusive, international, and balanced member base. We seek input from non-members as well--achives of OASIS Committee documents and mailing lists are publicly accessible, and regular public reviews of specifications are required by our TC Process. |
| IPAWS | Open (OASIS) | US centric sub-specification of CAP | OASIS believes widespread adoption can only be achieved when all those affected by a standard participate in its creation. We offer a range of membership levels to support an inclusive, international, and balanced member base. We seek input from non-members as well--achives of OASIS Committee documents and mailing lists are publicly accessible, and regular public reviews of specifications are required by our TC Process. |
| WS-Notifications | Open (OASIS) | several implementations found | OASIS believes widespread adoption can only be achieved when all those affected by a standard participate in its creation. We offer a range of membership levels to support an inclusive, international, and balanced member base. We seek input from non-members as well--achives of OASIS Committee documents and mailing lists are publicly accessible, and regular public reviews of specifications are required by our TC Process. |
| WS-Reliable Messaging | Open (OASIS) | OASIS believes widespread adoption can only be achieved when all those affected by a standard participate in its creation. We offer a range of membership levels to support an inclusive, international, and balanced member base. We seek input from non-members as well--achives of OASIS Committee documents and mailing lists are publicly accessible, and regular public reviews of specifications are required by our TC Process. | |
| HL7v3 ? | |||
| Open Mobile Alliance:
RESTful Network API for Notification Channel |
non-exclusive royalty free licence to download, reproduce and use the Documents subject to these terms and conditions.
http://openmobilealliance.org/about-oma/policies-and-terms-of-use/ http://openmobilealliance.org/about-oma/policies-and-terms-of-use/openness-policy/ |
? | membership to OMA requires $
need to be member to participate in working groups |
| PCD ACM | public | Alert Reporters and Alert Managers | |
| IEEE 10101a | Response on use: "Regarding the use of the Reference ID and numeric code identifiers, there is no restriction regarding your inclusion of that information in any documentation published by the IHE or, for that matter, by vendors in their documentation.
However, there may be copyright restrictions if IHE were to include the formal IEEE Descriptions/Definitions or Systematic Names documentation available on the IHE Wiki or ftp sites in an unrestricted manner. You/we would need to contact [the program manager] That said, there are alternative methods that you could use. First, anyone who purchases a copy of IEEE Std 11073-10103-2012 standard is granted royalty-free access to the XML files on the IEEE website that contain the Description/Definitions. Also, the same information is available on the NIST RTMMS site (and if it isn’t already there, it should be shortly). This would allow users to look up the Description/Definition and other information, given a REFID or numeric code identifier. Whether or not the IHE can include the Descriptions/Definitions or Systematic Names in HIMSS/IHE publications is somewhat in a grey zone. For example, NIST has a MoU with the IEEE to make all the IEEE 11073 nomenclature content available on the NIST RTMMS, so anyone can go there to view the material, including the formal definitions, and to a large extent, most of it can be downloaded as well." |
? | need to be a part of IEEE |
| Bespoke Solution for mACM | would be public | none | yes |
mACM Specific Data Fields
| Standard | timestamp | subject of care identifier | recipient identifier | alert status/reponse | alert priority | alert type | geo-location of status/response | content type of alert | originator of alert | notes |
|---|---|---|---|---|---|---|---|---|---|---|
| FHIR DTSU v2 | no | yes (required) | no | maybe: status, but restricted code set | no | category | no | plain text string in note | yes (author) | would need either an extension of new resource "x-alert" |
| WS-Notifications | no | no (wsnt:Topic?) | no (wsnt:Topic?) | no | no | wsnt:Topic ? | no | wsnt:Topic ? | wsnt:ProducerReference | can specify needed fields by specifying what is in wsnt:Message
in this case WS:Notifications is effectively only transport of message |
| PCD ACM | yes | yes (not required)
also includes location information of s.o.c |
no (but likely able to change with a CP) | no (but in PCD-07) | no (but potentially in PCD-07) | plain text | no? | This row is for PCD-04 only. | ||
| HL7v3 ? | ||||||||||
| Bespoke Solution | ||||||||||
| ||||||||||
mACM Specific Transactions
| Standard | Mobile Report Alert | Query for Alert Status |
|---|---|---|
| FHIR DTSU v2 | yes: PUT | no (can either augment alert resource to include status, or create a new resource) |
| WS-Notifications | via Notify message | perhaps if created a district topic for responses and used Notify message |
| HL7v3 ? | ||
| PCD ACM | PCD-04 (Report Alert) transaction. However transaction is not mobile friendly. HL7v2 message is semantically invalid when a subject of care is identified in alert | no: there was a related PCD-05 that was excised from the TF, but it was initiated by AM not AR |
| Bespoke Solution |
mACM Technical Considerations
| Standard | Message Representation
(JSON, XML,..) |
Transport | Mitigates exposure of PI |
|---|---|---|---|
| FHIR DTSU v2 | JSON + XML | HTTP | yes (s.o.c. is identified) |
| WS-Notifications | SOAP specified | no (unless care was taken with perhaps wsnt:Topic) | |
| HL7v3 ? | |||
| PCD ACM | HL7 v2 | MLP | yes |
| Bespoke Solution |