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 https://www.rabbitmq.com/resources/specs/amqp0-9-1.pdf	not healthcare domain aware.
XMPP	http://xmpp.org/xmpp-protocols/protocol-namespaces/ http://xmpp.org/rfcs/rfc6122.html	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 http://en.wikipedia.org/wiki/Wireless_Emergency_Alerts	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
	Standards are publicly available for unrestricted implementation Standard adopted by standards body	The standard has a significant market share The standard is implemented by several software vendors Expertise around the implementation and maintenance are offered by many providers Documentation for implementation and maintenance are available and best practices are identified.	Specification evolves in time, with the addition of new features, A schedule of changes is published and users are informed of the content of future releases The standard has the necessary stability and new versions take into account backward compatibility issues.
FHIR DTSU v2	open FHIR license / Creative Commons
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	alert priority	alert type	geo-location of status/response	status/response for alert	content type of alert
FHIR DTSU v2	no	yes (required)	no	maybe: status, but restricted code set	no	category	no	no	plain text string in note
XMPP
WEA
CAP
IPAWS
WS-Notifications
WS-Reliable Messaging
HL7v3 ?
Open Mobile Alliance: RESTful Network API for Notification Channel
PCD ACM
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)
XMPP
WEA
CAP
IPAWS
WS-Notifications
WS-Reliable Messaging
HL7v3 ?
Open Mobile Alliance: RESTful Network API for Notification Channel
PCD ACM	no: Report Alert 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