simple interop for healthcare (wes rishel)

Simple Interop for Healthcarein the US

25 January 2009

This work is licensed under the Creative Commons Attribution 3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/us/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

If this work is shared or adapted the original work should be attributed to Wes Rishel of McKinleyville, CA and include a citation to http://blogs.gartner.com/wes_rishel

http://creativecommons.org/licenses/by/3.0/us/

http://blogs.gartner.com/wes_rishel

Topics

• The Problem and Proposition

• The Scope of Simple Interop

• Use Cases

• Simple Interop Defined

• Definitions

• The Personal Health Record

• The Payload

• Two Phases of Roll-Out

• Business Opportunities

Topics

The Problem and Proposition

The Scope of Simple Interop

Use Cases

Simple Interop Defined

Definitions

The Personal Health Record

The Payload

Two Phases of Roll-Out

Business Opportunities

The Facts of Life inHealth Information Technology

• Heath information technology asynchrony

• Interoperability has a compound adoption curve

• Two models for developing standards: incremental and kerplunk- Incremental built the Internet

- No proven success for kerplunk; some glorious failures

• Standards don’t dictate business models- The best standards enable creative users to find business models

http://blogs.gartner.com/wes_rishel/2010/01/02/rant-on-heath-information-technology-asynchrony/



Topics



Use Cases


Definitions


The Payload



Healthcare “Simple Interop” Is

• Easily adopted across a wide range of technologies

• Easily adopted across different levels of technology adoption

• Incremental

- “Quick” rollout can be accomplished to meet the meaningful use interoperability measure minima for Stage 1

- “Extensive” rollout improves scalability, increases breadth of information exchange enough to handle minima for Stage 2

• Avoids organizational and technical complexity associated with trust issues

• Not chained to the roll-out of EHRs, HIEs or large-scale NHIN

• A basic platform for incremental introduction of HIE-like services

• A “pathway” to the large-scale NHIN

• Might be thought of as an important part of “NHIN Light”

The Propositions

“Quick” Simple Interop is sufficient to enable a large number of practices and hospitals to meet Stage 1 interoperability minima.

- Transitions of care

- Structured labs

- 2012 transmission of conformance and quality measures

“Extensive” Simple Interop is sufficient to meet Stage 2 interoperability requirements, as well as we currently understand them

- PHR

- Higher minima for existing interop measures

This slide is incomplete and the propositions must be examined

Fax Simple Interop

Ubiquity Everywhere As good as email and Web

Required Technology Level Easy As easy as email and Web

Memorable Addressing Phone number Email address

Directory Not usually (call and ask) Future consideration

End-point authentication Minimal Better

Secure transmission Switched network Internet encryption

Organizational or personal Trust Ad hoc Ad Hoc

Structured data No Optional

Send to: Person Often Often

Send to: Computer Sometimes Often

Send to: Business function Often Often

The Goal (A Challenge): Start by Doing Slightly Better Than the Fax Machine

Simple Interop:Three Models for Sharing Identifiable Patient Data

• Information sharing about a patient occurs following well-established patterns for the treatment of the patient

- Implicit consent

• Provider organizations know one another or have ways of establishing trust

• No central index of patients or data no required automatic patient ID mapping

• Patient controlled

- Patient uses PHR to aggregate their own data and disburse it as seen fit

- PHR aggregates inputs about the patient from multiple sources

Routine Care PHR

Simplifying Assumptions• The communicating organizations are known to one another by practice patterns or explicit

business agreements

• Organizations trust one another to identify and authenticate users

• Governance is most likely informal (“Fax-machine governance”)

• The organizations determine consent issues off-channel

• There is no need for a module that is dynamically verifying the consent rules or otherwise using technology to enforce governance agreements

• Interoperation does not depend on an intermediary to

- Map patient identity

- Map transaction formats or codes

(The above notwithstanding some EHRs and other clinical systems may rely on third-party products to do mapping before transmitting information)

• There is no need for standard transaction audit-file format or an independent audit logging server

• All routing of transactions is provided by the Internet domain name service; there is no requirement for special healthcare transaction routers.

Scope of Simple Interop

• Three exchange approaches- Person-to-person

- Automated transmission of information from one information system to another

- Computer to person (e.g., sending diagnostic reports to physicians without an EHR)

• All “push” use cases where the policy authorization is covered by HIPAA or other laws

• Limited “pull” cases where the requester of data and the source of data are known to one another or can determine to their satisfaction that the request is valid and covered by policy. - Perhaps pull = push consent and then receive pushed information

• Not designed to support ad hoc lookup of patient data

Topics



Use Cases


Definitions


The Payload



Use Cases: Simple Referral PCP to Specialist (no HIE)• Assumptions

- PCP and specialist are known to one another, or

- They participate in an IPA or care management network that

• creates a level of trust sufficient to send patient information

• and makes the health email addresses of the physicians known to one another.

• Workflow

- PCP creates and sends referral

- Specialist receives, identifies or creates patient; sets up appointment

- Specialist prepares and send reports

• Structured data

- If the PCP has an EHR he can include structured data

- If the specialist has an EHR she can upload any structured data the PCP sent

- Same upon return:• If specialist has EHR she can include structured data

• If PCP has EHR he can upload any structured data that was sent

• PCP and specialist do not need to know if the other has an EHR

http://blogs.gartner.com/wes_rishel/2010/01/04/simple-interop-use-cases/


Use Cases: Care Transitions/Routine Care Coordination

• Summary to Physician Across State/HIE Boundaries

- Upon discharge a patient asks that the discharge summary to be sent to her home physician in another state; she has the physician’s health email address in her address book.

• Visit Summary to Unknown Practice

- After an ED visit for breathing difficulties a mom asks that a summary be sent to her son’s pediatrician. She is able to provide the name of the physician and the town where the pediatrician practices, but is not sure of the name of the practice.

- The ED staff is able to find a health Internet address but it is not clear whether the pediatrician has an EHR or not.

• Routine coordination of preop testing; interop challenge

- Upon reading a preop treadmill ultrasound a cardiologist needs to send the report to the surgeon and the primary care provider, and to the patient. The patient and his PCP live in a rural county across a state line a different medical services region than the cardiologist and surgeon.


Use Cases: ED Transitions of Care• Doc Sends Patient to Nearest ED, in a Different Care Delivery Organization

- Doctor A sends a secure email to Doctor B, an attending physician at the local ED, about a complex patient who is rushing over. The email contains patient health information important in managing the patient in the ED

- Docs A and B both have EHRs but there is not yet HIE in their town to connect them or they are signed up with different HIEs.

- Doc A sends the same secure email to Doc B, but Doc B does not have an EHR.

• ED Gets Medical Records for Exceptional Case.

- A patient is brought to the ED with severe cardiovascular symptoms. The patient says he was treated six weeks ago at another hospital. The other hospital is not connected to an HIE.

- The patient gives consent to get the records from the other hospital, so the local ED staff calls the hospital. Over the phone the ED gives the other hospital its healthcare email address.

- The remote hospital chooses to trust the phone call; records are sent from the other hospital’s EHR to the ED which adds the contents to its EHR.

- The transmission includes a structured patient summary and textual reports. The ED EHR imports the structured data in structured form and the textual reports as text reports identified with the appropriate patient and encounter.


Use Cases: Structured Labs and Other Diagnostic Reports

• Hospital Lab to Physicians in Service Area

- Local lab accepts specimens and orders from a variety of practices. Results are sent to fax number or health email address specified on order.

- Payload includes text/PDF and structured file, coded to HITSP standards. Receivers at email address may be physicians without EHRs, which use the text or EHRs which use the structured text.

• Genotype/specialty diagnostic center to national referrers

- National specialty lab accepts specimens and orders from a variety of practices. Results are sent to fax number or health email address specified on order.

- Although such reports may be largely textual due to their nature, if the sender chooses to envelope them with a standard CDA header that identifies patient, signing provider and procedure and the receiver has an EHR, the EHR may provide functionality that enables practice personnel to be more efficient and accurate in accepting results.

Use Cases: Patient Engagement

• Doc to Patient

- A physician sends an email to a patient (at his health Internet address) about the patient’s case

• Patient to Doc with EHR

- A patient, using her PHR sends a secure message to a physician; the message is received and handled through the workflow of the Doc’s EHR.

• Patient to Doc without EHR

- A patient, using her PHR sends a secure message to a physician who does not have an EHR but has agreed to accept e-mail from some patients.

• EHR to PHR

- At the close of each encounter, an EHR automatically sends a summary to the PHR designated by the patient who has requested this service.


Use Case: Pre-standard or non-standard structured formats.

• Non-standard

- Several independent organizations form an agreement to share specific structured data using a format that has not been standardized. They use health email as a convenient and secure way of exchanging the structured data files.

• Pre-standard

- SDOs agree not to standardize formats until they have been in limited production use. Assembling pre-production users is easier because the underlying transports are standard


Topics



Use Cases


Definitions


The Payload



Simple Interop at Its Simplest

Legend

X.509 digital certificate

Secure connection over Internet always protected with TLS.

InternetHealth Internet Node

Health Internet Node

Mutually authenticated TLS connection

Payload is MIME package with unstructured and possible structured data

Simple Interop Multiple Roles

Small Physician Office

EHRHealth Internet Node

Hospital

EHR or Interface Engine


Hospital-defined

Remote HostingVendor


Vendor-defined


Vendor-defined


EHR EHR

HIC

Org Email System

CD

H

E

G

I

F

HISP


Email Client

Legend

X.509 digital certificate Health Internet Client

HIC

Secure connection over Internet always protected with TLS

Secure portal connection, such as an Ajax email client or other app

Topics



Use Cases


Definitions


The Payload



Definition: Health Domain Name

• Health domain name: a regular Internet domain name, propagated through the regular domain name service.

• Healthcare organizations will typically have two domain names a regular domain name and a health domain name.

• Although a convention such as healthinfo.mercyhospital.org might be useful, no information is conveyed in the syntax of the domain name.

Definition: Health Email Address

• Health email address a standard email address in which the domain name is a health domain name. - The user names are managed locally by the organization

associated with the domain name or a third party operating on its behalf.

- A user name has no meaning except in the context of the domain name.

- User names may refer to many things such as• specific staff members

• healthcare consumers

• IT systems, e.g.,

- input queue for an order

- workflow queue for the people processing referral requests.

Definition: Health Internet Node

• A set of servers operated on behalf of one or more health domain names. - Plain-old Internet servers, such as SMTP servers or HTTP servers.)

- Health Internet node security provisions• don’t accept connections from outside its security perimeter that are not mutually

authenticated and encrypted using TLS and digital certificates.

• check that the digital certificate of the connecting client remains valid.

• won’t accept such connections that don’t offer a cipher suite that is sufficiently secure by standards set by ONC

• It will accept such connections using at least one cipher suite that has been established by ONC.

• Health Internet nodes will frequently host numerous healthcare domain names when operating on behalf of multiple healthcare organizations.

Definition: Health Internet Registrar

• Health Internet registrar any organization that has been accredited by the US government to issue organizationally vetted digital certificates associated with health domain names.

Topics



Use Cases


Definitions


The Payload



Personal Health Record: Minimal Functions

• Various systems that may be called personal health records, patient-mediated health IT ecosystems or medical record banks all are assumed to do at least these functions.- Receiving information about the consumer from multiple

healthcare organizations (HCOs) and associating that information with the correct consumer (even though each sending organization has a different ID for the consumer)

- Delivering information to authenticated healthcare organizations as directed by the consumer, identified so that the receiving healthcare organization can file the information properly by patient

• (These do not constitute the full value proposition, just some important common functions)

PHR Approach

• PHR has a health Internet domain for exchanging information with other health Internet domains.

• Assign health consumer emails addresses from their health Internet domain to the subjects of personal health records.

- Allow subjects to have multiple email addresses concurrently while keeping a common record of information collected for the subject via multiple email addresses.

- Allow subjects to discontinue the use of any of their email addresses in the PHR domain upon request.

- Accept incoming email according to the rules for a health Internet node (TLS and only from other healthcare domains) and file the information contained in the mail in the PHR of the subject related to the email address.

• Accept instructions from authenticated PHR users to send selected information about the subject to another health Internet address

PHR


EHRHealth Internet Node

Hospital

EHR or Interface Engine


Hospital-defined

Remote HostingVendor


Vendor-defined


Vendor-defined


EHR EHR

HIC

Org Email System

C

H

E

G

I

F

HISP

Consumer Facing Secure

Mail ConsumerProvider


DPHR

Consumer Facing Secure

Mail

A B

Topics



Use Cases


Definitions


The Payload



Payload: MIME Based Using These Principles

• Standards profiles such as HITSP C32 are supported

• There is no requirement to use structured payload standards when exchanging information among health Internet nodes- PDFs and plain-text allowed and expected

- However meaningful use criteria, trading partner agreements or inter-vendor agreements will no-doubt make certain structures required for specific purposes

• Simple mail clients handle structured data as file attachments

• Experimental or IANA-issued Internet media types per profile

Payload:Upward Compatibility in Structured Formats

• Strongly urge developers of structured formats to offer free, easily installed “readers” (equivalents to Acrobat reader) to enable email recipients to interpret files with structured content

• Entities that define profiles for structured formats are encouraged to achieve reasonable upwards compatibility

• Where upwards compatibility is not achieved transmitters are encouraged to include redundant payload packages.

• A strong preference that every emailed MIME package contains at least one human-readable part (think about the transition from plain-text to HTML email)

Reliable Messaging

• Four modes to consider

EHR

EHR

Secure Email User

Secure Email User

Delivery Reliability Concerns: What If …

• The message is never delivered to the recipient?

• The message is delivered but cannot be processed?

• The message is delivered but some of the attachments cannot be processed?

• A recipient later claims it never got a message and cannot be liable for not having acted on it?

• A sender later claims that it never sent a certain message, so it cannot be liable for erroneous contents?

• A sender and a receiver disagree on when the message was transferred between organizations?

How to Deal With Message Reliability Concerns

• Ignore them – not simple interop

• Create a specification for email servers in health Internet nodes that handle all receipting and other needs

• Enable and specify Web services, time sync and ATNA between health Internet nodes

• Find a simple specification based on the assumption of TLS, and some approach to HTTP-based transactions- Whatever complexity is needed should be limited to the health

Internet node

- Look for “good enough” with a path to better if this is shown to be necessary

A Possible “Simple Interop” Approach to Reliable Messaging Using SMTP

• The simple interop mechanism only assures delivery from one organization to another. Each organization that accepts a transmission is responsible for delivering it internally or initiating an error response.

• SMTP error messages are adequate unless a health Internet node can accept a message and later determine it is undeliverable.

• Protocol features implemented to “prove” delivery at a specific time are not required for simple interop. Each organization that provides health Internet node services must do a risk analysis and - Certainly will keep a time-stamped log of all messages

- May chose to use products or techniques to forensically demonstrate the integrity of their logs.

Topics



Use Cases


Definitions


The Payload




• Self-signed certificates

• Out of band distribution and revocation of certificates

• Health Internet nodes white-list one another

• Can support large numbers of connected organizations if

- EHR vendors choose to operate health Internet nodes on behalf of their clients

- Large CDOs choose to operate health Internet nodes on behalf of practices

• Conceptually the same as “Quick”

- Organizational trust

- Consent determined “out of band”

• Added facilities to accommodate larger scale

- PKI to support issuance and revocation of X.509 certificates associated with domain names

- “Health Internet registrar” issues certificates

- Health Internet nodes accept communication with all servers offering certs on this PKI

Quick Extensive

This slide needs some conceptual work

Topics



Use Cases


Definitions


The Payload




• Facilitative services, not mandatory- Software

- Hardware (Health Internet appliances)

- Services

• Software services may be open source or proprietary

Health Internet Node Add-on Services (Not Mandatory – Business Opportunities)

• Directory: assistance in identifying the “health Internet address” of healthcare organizations that are not known to the sender

- Senders may consider the availability a health Internet domain name in determining whether to trust the receiving organization, but it is not conclusive

• Person directory: assistance in identifying the “health Internet address” of healthcare providers that are not known to the sender; note that many providers have more than one health Internet address.

• Patient Lookup: community-based master-patient index

• Information Lookup: assistance to their users in finding the sources of information about patients in a way that is consistent with local and national policy

• Interface lookup: health Internet addresses associated with specific functions (e.g., [email protected]) including “can-can’t” info for specific structured formats.

• Mapping of transactions and codes

A health Internet node could “grow up” to be an HIE.

Health Internet Other Business Opportunity:Interface Appliance• Assists organizations in exchanging structured data to recipients that have health

Internet addresses

- Sender’s appliance: assists in sending structured data from a non-compliant lab or other clinical system

- Receiver’s appliance: assists in receiving over the health Internet and mapping to non-compliant EHRs or other clinical systems, in effect making them compliant

• Disclosure Auditing

• Format translation for standard formats

• Code translation for standard codes (e.g., LOINC)

• “New code trapping”

- Detect outgoing transactions with unmapped codes

- Suspend transactions until code is resolved

• Related business service opportunity

- Setting up code translation tables

- Remote support for operations and code trapping

Some services once thought of as requiring an HIEcould be provided without an HIE

Recent Considerations

• Is a heath domain name actually needed?

- X.509 certificates can have extended validation for vetted identity

• Is a health Internet registrar necessary to get started?

• Is accreditation of a health Internet node needed? When?

• Is a separate structured patient demographics standard needed? Helpful?

• Is this leverageable for RESTful interfaces, such as for Ajax clients. Is it useful?

Revision History

21 Jan 10 original23 Jan 10 typos24 Jan 10 added use cases25 Jan 10 Removed disease registry discussion to avoid

complications about discussing consent for aggregation (other than the PHR).Miscellaneous changes based on comments.

simple interop for healthcare (wes rishel)

Health & Medicine