1. Alerts Targeted at Humans @@H – Detailed Proposal Carl Leitner IntraHealth International

2. The Problem Within a health enterprise there are often multiple registries of humans: Client registry Contacts in a facility/organizational registry Health worker registry Multiple actors that wish either to produce alerts/messages targeted at humans or to render alerts/messages to a human There is currently no standard for message brokering with a health enterprise. Having a standardized messaging broker reduces system complexity between the large sets of message publishers and alert consumers and allows better leveraging of existing resources

3. User Stories US1 (Alert Targeted To Explicit List of Health Workers) An alert is targeted to a specific list of health workers concerning a recall notification to three clinicians known to have administered a drug. No subject of care is identified in this message. US2 (Alert Targeted To One Health Worker About A Specific Patient) This example illustrates an alert generated by an ICP workflow host targeted at a specific health worker about a specific subject of care. Variation: the alert is about a subject of care sans targeted recipient (i.e. anyone who sees this patient please do X).

4. User Stories US3 (Alert Targeted To A Health Facility In A Geographic Location ) Alert generated by a CDSS is intended to be sent to all outpatient care facilities in Chapel Hill (which have contact information in a facility/organizational directory). US4 (Cost Reduction Incentives ) A health network (such as a ministry of health) may obtain subsidized rates from a Mobile Network Operator (MNO). The various health services business units utilize SMS based messaging workflows. The health network wishes to reduce cost by allowing various business domains to use the subsidized line from the MNO to reduce costs.

5. User Stories US5 (Alert Targeted At A Patient Cohort) An alert is targeted at all female patients between ages 18-40 in a certain district asking them to begin a survey on the availability and quality of MCH services in their district. US6 (Professional Council Certification) A health professions council sends a SMS reminder to health workers reminding them to renew license/registration

6. Problem Characteristics The messages may or may not contain PHI (e.g. clinical vs. public health/health systems management) At time of publication, the final recipient list may not be known (however search parameters against a human registry are known e.g. ‘all Nurses in district X’) The publisher of an alert should not need to know the business logic behind delivery of the message and multiple means of human interaction (SMS, cell, email, IVR, interaction with point of care system, social media) may be desired

7. Problem Characteristics The message can be rendered by any number of systems but no central way to determine if message has been delivered (e.g. Radiology ) The desired content of a message can vary widely among publishers of message Some messages are intended to be delivered immediately (e.g. emergency response) while others are intended for future consumption at some point during a health worker’s interaction with a point of care system Messages can be delivered either to health workers or subjects of care See also: ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr10-2012- 2013/Technical_cmte/WorkItems/CriticalAndImportantResultsWhitePaper/

8. Proposal Scope: Actors Alert Publisher (AP) Produces alert content to specified humans with contact information or to Query Defined Cohorts (QDC) Human Registry (HR) Registry of either a subject of care or a health worker (WHO definition). Resolves one or more types of QDCs into a list of humans with contact information. Request format/API unrestrained. Response constrained. Alert Broker/Repository(AB) Makes alerts available to AC and resolves (if possible) QDCs Alert Consumer (AC) Renders alert content obtained from AB to specified humans.

9. Workflow AP: Alert Publisher AB: Alert Broker HR: Human Registry AC: Alert Consumer What are allowed AC subscriptions? Can AC request unresolved recipients? (null set of HRs)

10. Proposal Scope: Data Model for Human Recipients

11. Proposal Scope: Human Registries Modeling/defining of search parameters across human registries Available registries should be jurisdiction defined by service contracts of the HIE API (search parameters) for accessing a human registry defined by query type: API In Scope: for discussion urn:ihe:iti:@@h:2015:query-name:csd-provider-search urn:ihe:iti:@@h:2015:query-name:csd-organization-search urn:ihe:iti:@@h:2015:query-name:csd-facility-search urn:ihe:iti:@@h:2015:query-name:hpd-provider-search urn:ihe:iti:@@h:2015:query-name:hpd-organization-search urn:ihe:iti:@@h:2015:query-name:pwp-provider-search urn:ihe:iti:@@h:2015:query-name:fhir:PDQ urn:ihe:iti:@@h:2015:query-name:fhir:PDQm API Out of Scope: can be specified at future point urn:example-hl7:fhir:dstu_version_X:practitioner urn:example-hl7:fhir:dstu_version_X:organization urn:example-hl7:servd:provider-search Proprietary

12. Proposal Scope: Data Model for Message plain text for is only one specified

13. Proposal Scope: Content Profiling/defining message content Carrying of message should be content ambivalent. Content types are: In Scope: Define content as the pair ( plain text, URL ) Message content type is “urn:ihe:2015:@@h:message-types:text/link” Handling of rendering (plain text, URL) for human interaction defined on AC actor Out of Scope: domain specific profiles on pairs ( domain specified content, URL) for future specification Radiology : http://wiki.ihe.net/index.php?title=Critical_Results_-_Detailed_Proposal CAP, CDAs, FHIR Alerts, references to XDS Doc Repo, etc.

14. Example: Alert <aah:alert xmlns:aah="urn:openhie.org:alerting”> <aah:target-cohort query-name="urn:ihe:iti:@@h:2015:query-name:csd-provider-search"> <csd:careServicesRequest xmlns:csd="urn:ihe:iti:csd:2013" > Santa Fe <aah:message message-id="2110BC92-F84C-4095-9FAD-CAEF821A4096" published="2006-05-04T18:13:51.0Z" type="urn:ihe:2015:@@h:message-types:text/link" xml:lang='en' link='http://www.cdc.gov/vhf/ebola/'> There has been an outbreak of ebola in your neighborhood. More information can be found from the CDC.

15. Proposal Scope: Actors -Feedback Option Alert Receipt Repository (ARR) Provides feed of reports from AC on the outcome of a human interaction Alert Consumer -Feedback option Publishes to AR response code / URI codifying result of HI Alert Receipt Walker (ARW) Reads feed from ARR of all human interactions/responses to alerts to a specified message Interesting things can happen when AP = ARW or AC = ARW

16. Workflow -Feedback Option AP: Alert Publisher AB: Alert Broker HR: Human Registry AC: Alert Consumer AR: Alert Receipt Recorder Optional transactions

17. Proposal Scope: Rendering –Feedback Option Rendering and delivery of content to a human recipient Methods of rendering of content is not defined by profile In Scope –Feedback Option: AC renders message content for types defined in profile Upon rendering content, AC records basic meta-data about the interaction as an alert receipt Alert receipt includes status defined by codes: urn:ihe:2015:@@h:status-code:attempted-delivery urn:ihe:2015:@@h:status-code:failed-delivery urn:ihe:2015:@@h:status-code:confirmed-delivery urn:ihe:2015:@@h:status-code:cancelled Additional message content type and status code urn:ihe:2015:@@h:message-types:acknowledgableable-text/link urn:ihe:2015:@@h:status-code:acknowledged Optional URL for content created upon human interaction

18. Proposal Scope: Data Model for Receipt –Feedback Option

19. Example: Alert Receipt –Feedback Option (XML -> JSON via JsonML) [ “receipt", { "message-id": "2110BC92-F84C-4095-9FAD-CAEF821A4096", "recipient-id": "8D37B355-EACA-447E-9BD4-746A5B0921AF", "timestamp": "2006-05-04T18:13:51.0Z”, ”latititude”: ”35.9333”, ”longitude”: ”79.0333” }, [ ”status", { "code": "attempted-delivery", "code-scheme": "urn:ihe:2015:@@h:status-code" } ]

20. Alert Consumer: Acknowledge Receipt

21. Resources Authors/Editors: IntraHealth ecGroup Reviewers: ? Early Adopters and important use cases: OpenHIE Community (Rwanda, Zimbabwe, Nigeria, Liberia, Uganda…) Missed appointment / patient follow-up (MCH) Integrated Care Packages http://ohie.org mHero community (Liberia, Sierra Leone, Guinea, Senegal, Uganda…) Lab results Health Worker knowledge assessments / Push out of updated care protocols Availability of supplies and protective gear Contact tracing http://mhero.org

22. Obligatory Cultural Reference