Health Cloud: Standards-Based Integrations

Connecting Health Cloud and Your EMR: A Standards-Based Approach

​Kevin Collins, Senior Principal Program Architect, Salesforce

k.collins@salesforce.com, linkedin.com/in/kevincollins-hls
 Forward-Looking Statements
Statement under the Private Securities Litigation Reform Act of 1995
This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the
assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we
make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of product or service availability, subscriber
growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any
statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services.

The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, new
products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in
our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with completed and any possible mergers and acquisitions, the
immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new
releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise
customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the
most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are
available on the SEC Filings section of the Investor Information section of our Web site.

Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may not be
delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available.
Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.
Speaker Background
​Kevin Collins, Senior Principal Program Architect, Salesforce HLS

​Over 30 years experience developing and delivering software products to the global provider
market
• Electronic Medical Records (MU Certified)
• Medical Device Manufacturing (PMA, 501K)
• PACS, RIS
• Revenue Lifecycle Management
• Cardiology Information Systems
• Digital Pathology Solutions
• Health Information Exchanges (HIEs)
• Salesforce Health Cloud
Salesforce Health Cloud Integration Paths
​Health Cloud is a Managed Package on top of Service Cloud

​Data-level Integrations ​Business Process-level ​UI-level Integrations

Integrations

• Web Services (SOAP) • Lightning Connect

• REST Services • Web Services (SOAP) • Canvas
• ETL Tool Bulk Loads/Updates • REST Services • JavaScript messaging between
• Lightning Connect (OData and applications
External Objects) *implemented via custom Apex
Healthcare Integration Standards
​Subtitle placeholder

​de jure Standards, CMS-mandated

• ANSI ASC X12N 837P, 835, 270/271, 276/277

​de facto Standards, Prescribed by IHE (Integrating the Healthcare Enterprise)

• HL7
• CCDA
• DICOM
HL7: Health Level Seven

​HL7 v2:
• Event-based messaging, pipe-and-hat (|^)-delimited messages exchanged over sockets.
• Transaction-oriented.

​CCDA (Consolidated Clinical Document Architecture):

• XML-based documents, exchanged over sockets.
• Often used between EMRs and Health Information Exchanges (HIEs) for transmitting entire
Encounter/Visit data sets or even a full patient chart.

​FHIR (Fast Healthcare Interoperability Resources):

• REST-based query/response mechanism
• Not widely used in production yet, but all major EMR vendors support it.
HL7: FHIR
​Fast Healthcare Interoperability Resources

​FHIR is a developing standard

• Created, in part, because of the failure of the MU program to drive true, ubiquitous integration

​REST-based Query/Response model

• Query: construct a standard URL asking for:
• Specific lab results for a patient
• All clinical notes for a specific encounter or episode of care
• Patient’s allergies
• Response: standard JSON (JavaScript Object Notation) object.

​Truly vendor-neutral:
• Query mechanisms are the same from vendor to vendor
• Responses to the same queries are identical from vendor to vendor
HL7 v2
​The dominant data exchange methodology in healthcare for decades

​Event-based messaging scheme, transaction-oriented

• Patient Admit, Discharge, Demographics (ADT)
• Appointment Scheduling (SIU)
• Order request (medication, lab test, radiology procedure, dietary, etc.) (ORM)
• Observation (lab result, pathology results, radiology reports, patient biometrics, etc.) (ORU)
• Clinical Documentation (MDM)
• Detailed Financial Transactions (DFT)

​Pipe (‘|’) and Hat (‘^’)-delimited messages exchanged over sockets

​Will continue to be used for many, many years, despite the adoption of FHIR
Core Problem

​HL7 v2 is a socket-based text messaging model

​BUT
​The Salesforce Platform doesn’t give us direct access to sockets,
​so we can’t receive and parse standard HL7 messages.
There is a path to Success!
HL7 Integration Engines
​Healthcare- and HL7-specific processing engines

​Most healthcare institutions will already have one or more commercial or open source HL7
Integration Engines
• CorepointHealth
• InterfaceWare Iguana
• Orion Health Rhapsody
• Mirth

​All major HL7 Engines can transform standard HL7 messages into JSON (JavaScript Object
Notation) and pass them on to REST or SOAP endpoints.
​What can consume JSON objects via REST or SOAP endpoints? Health Cloud!
EMR to Salesforce Health Cloud Integration using HL7

Salesforce
HL7 Engine Health
EMR HL7 Message
• Receives HL7 REST API call Cloud
• Transforms into JSON with JSON
ADT, ORM, ORU,
• Calls HC REST API payload
MDM, DFT, etc.
So, this HL7 ADT^A01 (patient admit) message …
​MSH|^~\\&|HNAM_PM|HNA500|AIG||20170828030808||ADT^A01|Q145009810T140865109X782401||2.3||||||8859/1

​EVN|A01|20170828025400|||SATHEK01^Sathesh Mohanraj^Keerthana^^^^^^^PERSONNEL|20170828025400

​PID|1|35^^^MSH_MRN^MRN|35^^^MSH_MRN^MRN^FROMCERNER~975985^^^MSH_EMPI^CMRN^MTSN|1123690^0^^IID^DO
NOR
ID^UPLOAD~Q35^0^^MSQ_MRN^KMRN|Xtkncnj^Znslgfn^^^^^CURRENT||19140422|F|Xtkncnj^Znslgfn^^^^^MAIDEN|BQ|2253
Third Ave^Apt
#4^Unknown^NY^99999^USA^HOME^^060||9868985986^HOME^CD:13951662||ENGLISH|U|UNK|O50007181^^^MSH_FIN_NB
R^FIN NBR||||20|||0

​PV1|1|I|N09C^9220^P^MSH^^BED(S)^GM|EL|||12391^Btig^Dnssw^A^^MS^^^MSH_DICT_NBR~1508849019^Btig^Dnssw^A^^MS
^^^NPI_POOL|||MED||||F|||12391^Btig^Dnssw^A^^MS^^^MSH_DICT_NBR~1508849019^Btig^Dnssw^A^^MS^^^NPI_POOL|IP|5
0007287^0^^^VISIT ID|HCN|||||||||||||||||||MSH||A|||20170828025400|||||||A

​PV2||PS|^Hand Injury|||||||1|||Self-Referral|||||||||STANDARD|^^589743

​DG1|1|I0|S83.252S^^I0|Bucket-handle tear of lateral meniscus, current injury, left knee, sequela||A|||||||||1|0

GT1|1|35|Xtkncnj^Znslgfn^^^^^CURRENT||2253 Third Ave^Apt #4^Unknown^NY^99999^USA^HOME^^060|(986)898-
5986^HOME||19140422|F|DEFGUAR|Self|||||||||09|||||||||589798

​IN1|1|H03^Cigna POS^^^Cigna POS|589897|Cigna|PO Box 2005^^Farmington^CT^06032^USA^BUSINESS^^099||(800)244-

6224~8006521332~8009557799|||589798||20170828030805|21001231000000||POS|Xtkncnj^Znslgfn^^^^^CURRENT|Self|19140
422|2253 Third Ave^Apt #4^Unknown^NY^99999^USA^HOME^^060|||1|||||||||||||HCN|||||||09|F||P||||123456987b

​IN2|||||||||||||||||||||||||123456987b||||||||||||||||||||||||||||||||||||123456987b||(986)898-5986^HOME|(000)000-0000||||||||Self
… becomes this JSON object

{
“msh” : { “msh_3” : ”HNAM_PM”, “msh_4” : “HNA500”, “msh_7” : “20170828030808”,
“msh_9” : “ADT^A01”},
“evn” : { “evn_1”: “A01”, “evn_2” : “20170828025400” … },
“pid” : { “pid_2” : { ”cx_1” : “35”, “cx_4” : “MSH_MRN”, “cx_5” : “MRN” ... }, “nk1” : {... },
”pv1” : { “pv1_2” : “I”, “pv1_3” : “N09C^9220^P^MSH^^BED(S)^GM”, ... }
“in1” : { ... }
}
HL7 ADT^A01 Components
​How does an HL7 message align with Health Cloud data objects?
​PID: Patient Information (Account, Contact, EhrPatient)
​NK1: Next of Kin / Associated Parties (Contact, Account-Contact Relationships)
​PV1: Visit Info (EhrEncounter, EhrEncounterParticipant, EhrPractitioner)
​OBX: Observation/Result (EhrObservations, EhrImmunizationReaction)
​AL1: Patient Allergies (EhrAllergyIntolerances)
​DG1: Diagnosis (EhrCondition)
​PR1: Procedures (EhrProcedure, EhrProcedurePerformer, EhrImmunization)
​IN1: Insurance (currently requires custom objects)
​GT1: Guarantor Info (Contact, Account-Contact Relationships)
Solution: 2 Approaches
​Make the HL7 engine or ESB do all the work
• Extract the patient information, transform it into JSON, and call the SOAP API for the Contact object
• Do the same for EhrPatient
• Call the Case API to build a Care Plan, call the APIs for all of the clinical and encounter data.

​Do the work in Apex

• HL7 Engine does minimal work, simply transforming the message into JSON
• Call a single custom Apex REST API, passing the JSON as payload.
• Apex class parses the data and inserts it directly into Health Cloud objects.
Solution: 2 Approaches (Considerations)
​Make the HL7 engine or ESB do all the work
• If the organization already has a significant investment in an ESB (already licensed, has their own
center of expertise or SI available), this may be an attractive option.
• Bulk of the processing is performed on customer servers, or Heroku.
• Each individual HL7 message may result in a dozen or more API calls.

​Do the work in Apex

• Once developed, maintenance may be easier using declarative aspects of our platform
• Significantly reduced volume of inbound API calls over option #1.
• Requires developer(s) with Apex and HL7 background.
• May be deliverable with no additional technology licenses (just Salesforce and an HL7 Engine)
Results?
​By using an inbound feed of HL7 messages you can achieve near real-time updates to Health
Cloud as events occur.
​Use Cases:
• Initial Load of Patients
• Keep clinical data up-to-date in near real time
• Care Coordinators notified as soon as patients are discharged.
• Because HL7 messages are generated by Triggering Events in the source system (typically when
information is added or changed), this approach significantly reduces (or eliminates) the difficulties
around Change Data Capture inherent with using Bulk APIs to insert/update/upsert data.
• Utilizing existing data and work flows with standards-based integrations.
Appendix
​Design for an Apex-based HL7 Processor
HL7 Processing in Apex: A High-Level Design
​Consuming industry-standard HL7 transformations with Health Cloud

​Ingredients:
• HL7 Engine capable of transforming HL7 messages into specific JSON formats and calling REST-based
API in Salesforce
• Custom Apex class to accept JSON from HL7 Engine
• Custom Apex classes that are specific to each Message Type.
• The job of a Message Type parser would be to decide which segments to process and which segment parsers to
invoke for that processing.
• Custom Apex classes that are specific to each Message Segment
• The job of a Message Segment parser is to extract the data from the Apex class and insert it into the appropriate
storage location in the Health Cloud data model.
HL7 Processing in Apex: A High-Level Design
​Consuming industry-standard HL7 transformations with Health Cloud

​JSON Transformation:
• Develop a straightforward JSON structure for each Message Type that the HL7 Engine can reliably
create.
{ “msh” : { “msh_1” : …, “msh_2” : ..., “msh_3” : ...}, “evn” : { “evn_1” : ..., “evn_2” : ... }, ... }
• Create an Apex class named “msh” so that the JSON can be de-serialized to the matching class
structure.
• Use the class structure to examine the 9th sequence of the MSH segment. This contains the Message
Type.
• Use the message type to instantiate the appropriate handler/parser class specific to that message
type.
HL7 Processing in Apex: A High-Level Design
​Consuming industry-standard HL7 transformations with Health Cloud
​Msh Class:
Public class Msh {
Public String msh_3; // Sending Application
Public String msh_4; // Sending Facility
Public string msh_9; // Message Type
}
De-serialize:
Msh msgMsh= (Msh) JSON.deserialize(jsonString, Msh.class);

De-serializing the JSON into this class will give you the 3 items you need to choose which
Message Type parser to invoke:
• Sending Application à Msh.msh_3
• Sending Facility à Msh.msh_4
• Message Type à Msh.msh_9
HL7 Processing in Apex: A High-Level Design
​Consuming industry-standard HL7 transformations with Health Cloud

​Message Processing:
• The HL7 standard outlines each of the Message Segments (PID, PV1, etc.) that can be associated in
each Message Type.
• Develop Apex classes specific to parsing each kind of Message Segment.
• Use the Message Type handler/parser to invoke each of the segment-specific parsers.
• Segment-specific parsers will contain the details of mapping individual fields from the HL7 message to
specific objects and fields in the Health Cloud data model.
HL7 Processing in Apex: A High-Level Design
​Consuming industry-standard HL7 transformations with Health Cloud
HL7 Processing in Apex: A High-Level Design
​Consuming industry-standard HL7 transformations with Health Cloud

​Flexibility and Configurability:

• To make this design extra flexible and configurable, it makes sense to store parser class names as
metadata and invoke them dynamically given the context of each message.
• Create an Interface to define the method signatures.
• Implement the Interface in a class, (e.g., “PID_Processor”)
• Invoke dynamically using Apex’s Type class.
• Since each sending application (and, potentially, from each facility) may have slightly different HL7
implementations, it makes sense to select the appropriate Message Type parser and the individual
Message Segment parsers based not only on Message Type (MSH.9), but also Sending Application
(MSH.3) and Sending Facility (MSH.4).
• Individual field mappings for each parser should also be encoded as metadata so that non-
programmer users can make adjustments as needed. For example, one EMR might store the patient’s
MRN in PID.2, while another EMR might store its MRN in PID.3. Users should be able to make these
simple changes without having to dig into Apex.
Blaze Your Trail: Connect and Learn at Dreamforce

MON, NOV 6
INTERCONTINENTAL 4TH FLOOR
10:30am, 12:00pm Enterprise Architect Bar

TUES, NOV 7
INTERCONTINENTAL 4TH FLOOR
Network and See Live Demos 10:30am Health Cloud on FHIR: Leveraging Explore the UCSF Experience
the New Interoperability Standard
11:00am, 2:00pm Enterprise Architect Bar
MARRIOTT MARQUIS
1:00pm Keynote: Healthcare & Life Sciences
2:30pm Health Cloud for Healthcare