Simple Interop for Healthcare in the US

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

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

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

4. 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/

5. 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 

6. 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”

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

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

9. 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 Simple Interop:Three Models for Sharing Identifiable Patient Data Routine Care PHR

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

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

12. 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 

13. 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/

14. 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. http://blogs.gartner.com/wes_rishel/2010/01/04/simple-interop-use-cases/

15. 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. http://blogs.gartner.com/wes_rishel/2010/01/04/simple-interop-use-cases/

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

17. 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. http://blogs.gartner.com/wes_rishel/2010/01/04/simple-interop-use-cases/

18. 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 http://blogs.gartner.com/wes_rishel/2010/01/04/simple-interop-use-cases/

19. 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 

20. Simple Interop at Its Simplest

21. Simple Interop Multiple Roles

22. 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 

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

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

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

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

27. 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 

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

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

30. PHR

31. 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 

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

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

34. Reliable Messaging • Four modes to consider EHR Secure Email User Secure Email User EHR

35. 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?

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

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

38. 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 

39. 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 Two Phases of Roll-Out Quick Extensive This slide needs some conceptual work

40. 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 

41. Business Opportunities • Facilitative services, not mandatory • Software • Hardware (Health Internet appliances) • Services • Software services may be open source or proprietary

42. 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., reports_in@familymed.com) 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.

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

44. 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?

45. Revision History 21 Jan 10 original 23 Jan 10 typos 24 Jan 10 added use cases 25 Jan 10 Removed disease registry discussion to avoid complications about discussing consent for aggregation (other than the PHR). Miscellaneous changes based on comments.