Alerts Targeted at Humans @@H – Detailed ProposalCarl Leitner

IntraHealth International

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

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).

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.  

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

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  

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/

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.

Workflow

AP: Alert PublisherAB: Alert BrokerHR: Human RegistryAC: Alert Consumer

What are allowed AC subscriptions?

Can AC request unresolved recipients? (null set of HRs)

Proposal Scope: Data Model for Human Recipients

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

Proposal Scope: Data Model for Message

plain text for is only one specified

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.

Example: Alert<?xml version="1.0" encoding="UTF-8"?><aah:alert xmlns:aah="urn:openhie.org:alerting”> <aah:intended-recipients> <aah:target-cohort

query-name="urn:ihe:iti:@@h:2015:query-name:csd-provider-search"> <csd:careServicesRequest

xmlns:csd="urn:ihe:iti:csd:2013" > <csd:function urn="urn:ihe:iti:csd:2014:stored-function:provider-search"> <csd:requestParams> <csd:address> <csd:addressLine component="city">Santa Fe</csd:addressLine>

</csd:address> </csd:requestParams> </csd:function> </csd:careServicesRequest> </aah:target-cohort> </aah:intended-recipients> <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. </aah:message></aah:alert>

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 optionPublishes 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

Workflow -Feedback Option

AP: Alert PublisherAB: Alert BrokerHR: Human RegistryAC: Alert ConsumerAR: Alert Receipt Recorder

Optional transactions

Proposal Scope: Rendering –Feedback Option

• Rendering and delivery of content to a human recipientMethods 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

Proposal Scope: Data Model for Receipt –Feedback Option

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"

}

]

]

Alert Consumer: Acknowledge Receipt

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

Obligatory Cultural Reference