Connect Architecture Overview


Uploaded by USGOVHHS on 06.08.2009

Transcript:
Copyright Metrics Spec
EVERYBODY'S GOT THEIR AFTERNOON DOSE OF CAFFEINE
TO MAKE THE LAST HAUL HERE.
ALL RIGHT, WE'LL GO AHEAD AND GET STARTED
ON THE NEXT SESSION.
OUR NEXT SESSION, WHICH I TRIED TO HAVE EARLIER,
BUT CRAIG WOULDN'T DO IT--
I HAD INTRODUCED CRAIG
AS GOING TO COVER THE CONNECT ARCHITECTURE OVERVIEW,
AND INSTEAD HE COVERED THE NHIN ARCHITECTURE OVERVIEW,
WHICH WE NEEDED TO DO TO SET CONTEXT
FOR WHAT WE'RE GONNA TALK ABOUT NOW.
SO, THE CONNECT PROJECT,
AS I MENTIONED IN THE INTRODUCTION--
I DON'T KNOW, WHAT, 2 HOURS AGO NOW?--
IT WAS A PROJECT DESIGNED
TO IMPLEMENT THE SERVICES FOR THE NHIN,
WHICH WE'VE JUST SPENT SOME TIME
GOING OVER THOSE SERVICES IN DETAIL.
SO NOW WHAT WE'D LIKE TO DO IS TO INTRODUCE
A COUPLE OF THE TECHNICAL FOLKS HERE.
RIM IS SUPPORTING THE PROGRAM OFFICE
IN TERMS OF ARCHITECTURAL SUPPORT.
HE WORKS WITH CRAIG,
AND IS A PART OF THE PROGRAM MANAGEMENT TEAM FOR CONNECT.
AND LES WESTBERG IS THE DEVELOPMENT LEAD
FOR THE PRIME CONTRACTOR
FOR THE DEVELOPMENT OF THE CONNECT SOLUTION,
SO BETWEEN THE TWO OF THEM, WE SHOULD BE ABLE TO GET
ALL OF THE QUESTIONS THAT YOU HAVE
ABOUT THE CONNECT IMPLEMENTATION ANSWERED,
OR CERTAINLY WE CAN TAKE NOTES
AND GO BACK AND SEE IF WE CAN FIGURE OUT THE ANSWER
IF WE CAN'T ANSWER IT HERE TODAY.
SO WHAT I'D LIKE TO DO IS TO INTRODUCE--
I GUESS YOU'RE UP FIRST, RIM, RIGHT?
SO, RIM COTHREN, WHO, AS I SAID,
IS PART OF OUR ARCHITECTURAL STAFF
FOR THE CONNECT PROGRAM MANAGEMENT. RIM?
[APPLAUSE]
THANK YOU, DAVE.
AS DAVE SAID, WE'RE GONNA SHIFT A LITTLE BIT
IN THIS AFTERNOON'S SESSION
AND MOVE FROM TALKING ABOUT LOCAL, REGIONAL
AND NATIONWIDE HEALTH INFORMATION NETWORKS,
THE STANDARDS, THE CONVENTIONS THAT MAKE THEM UP,
AND START TALKING ABOUT CONNECT,
WHICH IS AN OPEN SOURCE IMPLEMENTATION OF A GATEWAY
THAT INSTANTIATES THOSE STANDARDS
AND HELPS ORGANIZATIONS JOIN THE HEALTH WIDE--
NATIONWIDE HEALTH INFORMATION NETWORK.
SO MY JOB, AS PART OF THIS DISCUSSION TODAY,
IS REALLY TO INTRODUCE YOU TO CONNECT,
TALK A LITTLE BIT ABOUT WHAT IT IS,
AND TRY TO MAKE THE BRIDGE BETWEEN THE STANDARDS
THAT YOU HEARD ABOUT EARLIER THIS AFTERNOON
AND WHAT CONNECT ACTUALLY DOES.
I STAND BETWEEN YOU AND THE INTERESTING STUFF
THAT LES IS GONNA TALK ABOUT IN A FEW MINUTES,
WHICH IS REALLY STARTING TO GET DOWN IN THE NITTY-GRITTY,
TALKING ABOUT THE BIG-PICTURE ARCHITECTURE FOR CONNECT
AND THE COMPONENT DETAILS,
AND THEN JUST A LITTLE INTRODUCTION
OF WHAT'S COMING NEXT FOR CONNECT.
SO WE'LL START OFF WITH WHAT IS CONNECT?
WELL, CONNECT STARTED OUT AS PART OF THE INITIATIVE
THAT DAVE TALKED ABOUT EARLIER THIS AFTERNOON
FOR TRIAL IMPLEMENTATIONS FOR NHIN,
AND IT WAS AND STILL IS AN INITIATIVE
OF THE FEDERAL HEALTH ARCHITECTURE
TO ENABLE FEDERAL AGENCIES TO JOIN THE NHIN.
NOW, SINCE THAT TIME,
IT HAS EMERGED TO BE MORE THAN THAT.
IT IS NOW A PLATFORM FOR PARTICIPATION
AND A PLATFORM FOR INNOVATION
FOR PARTNERS BEYOND JUST FEDERAL AGENCIES
AS IT WAS RELEASED INTO THE OPEN SOURCE COMMUNITY
IN MARCH OF THIS YEAR.
THE CONNECT ARCHITECTURE AND SOLUTION
IS A JOINT EFFORT
AMONG A NUMBER OF DIFFERENT PARTICIPANTS.
I'M A REPRESENTATIVE
OF THE CONNECT PROGRAM MANAGEMENT OFFICE,
PART OF FHA.
LES COMES FROM THE CONNECT DEVELOPMENT TEAM
AND LEADS THE TEAM THERE
IN DEVELOPING THE IMPLEMENTATION OF CONNECT
THAT WAS RELEASED BACK IN MARCH AND CONTINUES TO BE AVAILABLE.
AND THEN, IMPORTANT TO THIS PARTNERSHIP
ARE THE FEDERAL PARTNERS
THAT MAKE UP THE FEDERAL CONSORTIUM,
OVER 20 AGENCIES THAT HAVE A SIGNIFICANT INVESTMENT
IN HEALTH INFORMATION TECHNOLOGY
AND ARE INTERESTED IN BECOMING PARTICIPANTS IN NHIN.
THIS SLIDE GIVES YOU A PICTURE OF THE NUMBER OF ORGANIZATIONS
THAT PARTICIPATED IN THE TRIAL IMPLEMENTATION
AND ARE MOVING FORWARD TO PARTICIPATE IN NHIN DURING 2009.
AND INTERESTINGLY IN THIS
IS NOT ONLY ARE THERE A LOT OF DIFFERENT ORGANIZATIONS
THAT ARE PARTICIPATING--
7 AGENCIES THAT ARE LISTED HERE,
15 PRIVATE SECTOR ORGANIZATIONS
AND 3 STATE-LEVEL ORGANIZATIONS--
BUT A LARGE NUMBER OF THEM,
THE ONES THAT ARE MARKED WITH 2 RED ASTERISKS,
ARE ACTUALLY USING THE CONNECT SOLUTION
AS PART OF THEIR IMPLEMENTATION.
IN PARTICULAR, WANT TO POINT OUT THE COLLABORATION
BETWEEN THE SOCIAL SECURITY ADMINISTRATION AND MEDVIRGINIA,
BOTH USING THE CONNECT GATEWAY
TO CONNECT AS PART OF THE LIMITED PRODUCTION
OF THE NHIN THAT'S ONGOING NOW,
ACTUALLY EXCHANGING INFORMATION IN A PRODUCTION MODE.
CONNECT HAS A SET OF VERY IMPORTANT GOALS
AS PART OF IT.
YOU HEARD ABOUT THEM ALREADY FROM DAVE EARLIER TODAY.
THE SOLUTION IMPLEMENTS THE NHIN CONVENTIONS AND STANDARDS
TO PROVIDE AN OPEN SOURCE AND FLEXIBLE IMPLEMENTATION
THAT CAN BE USED BY A NUMBER OF DIFFERENT ORGANIZATIONS,
BOTH FEDERAL AGENCIES AND NON-FEDERAL ORGANIZATIONS,
STATE GOVERNMENTS, ORGANIZATIONS WITHIN THE STATES,
HIEs, PRIVATE SECTOR ORGANIZATIONS, IDNs, ET CETERA.
SO WE SEE CONNECT BEING THE SOLUTION
THAT MIGHT PROVIDE AN ON-RAMP TO THE NHIN
FOR A LARGE NUMBER OF ORGANIZATIONS.
THE DRIVING REQUIREMENTS THAT WERE REALLY BROUGHT TO THE TABLE
BY OUR FEDERAL PARTNERS
INCLUDED THAT IT NEEDED TO BE AN OPEN PLATFORM.
LES WILL TALK A LITTLE BIT
ABOUT THE COMPONENTS THAT MAKE THAT UP.
THERE NEEDS TO BE SUPPORT FOR MULTIPLE OPERATING SYSTEMS.
THE RELEASE BACK IN MARCH WAS RELEASED FOR WINDOWS.
IT'S NOW AVAILABLE FOR SOLARIS. LINUX IS COMING SOON.
WE'LL CONTINUE TO SUPPORT MULTIPLE OPERATING SYSTEMS.
MUST BE READILY EXTENSIBLE
WITH THE CAPABILITY OF ADDING FUNCTIONALITY AND COMPONENTS
TO THE ARCHITECTURE AS WE MOVE FORWARD.
IN FACT, ONE OF THE MAJOR DIFFERENCES
BETWEEN THE RELEASE 2.0 IN MARCH
AND THE 2.1 IMPLEMENTATION THAT'LL BE RELEASED NEXT MONTH
THAT LES WILL BE TALKING A LITTLE BIT ABOUT
IS ADDING ADDITIONAL CAPABILITIES
TO THE CONNECT ARCHITECTURE
IN THE FORM OF ENTERPRISE SERVICE COMPONENTS.
THERE MUST BE COMMERCIAL SUPPORT AVAILABLE,
EVEN THOUGH IT IS AN OPEN SOURCE IMPLEMENTATION,
FOR THOSE ORGANIZATIONS THAT WANT COMMERCIAL SUPPORT
OF THE ARCHITECTURE BEHIND IT.
IT MUST BE FULLY FUNCTIONAL AS IT COMES OUT OF THE BOX.
WHEN IT REACHES YOUR HAND,
IT NEEDS TO PROVIDE ALL OF THE FUNCTIONS
THAT ARE NECESSARY TO GET YOU ONTO NHIN.
AT THE SAME TIME, IT MUST BE CUSTOMIZABLE,
IT MUST HAVE REPLACEABLE COMPONENTS SO THAT YOU CAN MAKE USE
OF THE INVESTMENTS THAT YOU ALREADY HAVE IN PLACE,
OR FOR THOSE COMPONENTS
WHERE YOU WANT SOME OTHER IMPLEMENTATION
THAN WHAT IS PROVIDED,
YOU MUST BE ABLE TO MAKE THOSE CHANGES TO THE ARCHITECTURE.
SO LET'S TALK A LITTLE BIT ABOUT THE BRIDGE
BETWEEN WHAT YOU'VE BEEN HEARING ABOUT EARLIER TODAY--
THE NHIN SERVICES
AND THE SPECIFICATIONS FOR THEM,
AND THE CONNECT ARCHITECTURE AS IT IMPLEMENTS THOSE.
FIRST, WE THINK ABOUT CONNECT
AS REALLY HAVING 3 DIFFERENT LAYERS TO THE ARCHITECTURE.
FIRST, AND WHAT YOU'RE GONNA HEAR MOST ABOUT TODAY,
IS THE GATEWAY,
AND THE GATEWAY IMPLEMENTS THE CORE NHIN SERVICES
THAT ALLOWS AN ORGANIZATION
TO PARTICIPATE IN THE NHIN.
THE SECOND IS ENTERPRISE SERVICE COMPONENTS,
AND IN PARTICULAR, THE ENTERPRISE SERVICE COMPONENTS ARE ADDED
IN THE 2.1 RELEASE THAT LES WILL TALK ABOUT,
BUT THESE REPRESENT OPEN SOURCE, ENTERPRISE-CLASS
IMPLEMENTATIONS OF SOME CORE SERVICES
THAT MAY BE NECESSARY FOR ORGANIZATIONS
TO BECOME FULLY FLEDGED PARTICIPANTS.
THEY INCLUDE THINGS LIKE MPIs,
DOCUMENT REGISTRIES AND REPOSITORIES
THAT CONFORM TO THE XDS.b IMPLEMENTATION,
A POLICY ENGINE THAT IS RESPONSIBLE FOR MAKING DECISIONS
ABOUT WHETHER INFORMATION SHOULD BE RELEASED,
AND AN IMPLEMENTATION OF AN AUDIT REPOSITORY
TO MAINTAIN INFORMATION,
A HISTORY OF DISCLOSURES OF HEALTH INFORMATION.
AND THEN FINALLY IS THE UNIVERSAL CLIENT
THAT PROVIDES A PLATFORM
FOR THE DEVELOPMENT OF OTHER COMPONENTS
THAT WILL BE THE INCREASED FOCUS IN CONNECT
AS WE MOVE FORWARD.
THE ARCHITECTURAL PRINCIPLES THAT WE FOLLOWED
WERE THE USE OF FLEXIBLE AND EXTENSIBLE ARCHITECTURE
BUILT ON JAVA, GLASSFISH AND OpenESB
AS THE PRIMARY PLATFORM COMPONENTS.
FULLY IMPLEMENTS ALL OF THE CLIENT
AND SUPPLIER INTERFACES FOR EXISTING NHIN SERVICES,
AND WE'LL TALK A LITTLE BIT MORE ABOUT THAT IN A SECOND.
ALL OF THE COMPONENTS USE WEB SERVICES
TO IMPLEMENT THAT BASED ON THE STANDARDS
THAT WE JUST GOT DONE HEARING ABOUT.
THE ARCHITECTURE IS DIVIDED INTO A GATEWAY AND AN ADAPTER,
AND THE ADAPTER IS CONSTRUCTED IN SUCH A WAY
THAT IT CAN WRAP ITSELF AROUND ANY EXISTING HEALTH SYSTEM
TO MAKE THAT HEALTH SYSTEM NHIN-COMPLIANT.
AND WE TALKED A LITTLE BIT
ABOUT ENTERPRISE SERVICE COMPONENTS ALREADY.
THOSE ARE REPLACEABLE COMPONENTS,
AND ANY DEVELOPER CAN CHOOSE WHETHER TO USE THE MPI,
THE DOCUMENT REPOSITORY, ET CETERA,
THAT COMES WITH CONNECT AS OPEN SOURCE IMPLEMENTATIONS,
OR WHETHER THEY WANT TO REPLACE THEM
WITH THE EXISTING MPI, DOCUMENT REPOSITORY, ET CETERA,
THAT MAY ALREADY BE WITHIN THEIR HEALTH SYSTEM.
THIS DIAGRAM IS MEANT TO START GIVING YOU A PICTURE
OF HOW WE WALK BETWEEN THE NHIN SERVICES
AND THE ARCHITECTURE FOR THAT
AND THE CONNECT GATEWAY AND ADAPTER ARCHITECTURE.
AS I SAID BEFORE, CONNECT REALLY CAN BE THOUGHT OF
AS IMPLEMENTING BOTH A GATEWAY AND AN ADAPTER.
THE SERVICES ASSOCIATED WITH THE GATEWAY
ARE IMPLEMENTED BY INDIVIDUAL COMPONENTS.
IF YOU TAKE A LOOK, THE NHIN SERVICES,
THE INFORMATION SERVICES
AND INFORMATION EXCHANGE SERVICES
THAT WE HEARD ABOUT THE SPECIFICATIONS EARLIER
MAP INTO PARTICULAR COMPONENTS WITHIN THE GATEWAY
THAT ARE RESPONSIBLE FOR EXPOSING THE INTERFACES
ASSOCIATED WITH THEM.
THE NHIN PROFILES, THEN, CURRENTLY RIDE
ON TOP OF THE HEALTH INFORMATION EVENT MESSAGING SYSTEM,
OR THE HIEM, WHICH, AGAIN, ARE IMPLEMENTED
AS PUBLISH AND SUBSCRIBE SERVICES,
AND A SUBSCRIPTION REPOSITORY WITHIN THE GATEWAY ITSELF.
IF WE THINK ABOUT THIS IN TERMS OF AN API
THAT IS EXPOSED BY THE GATEWAY,
WE CAN EASILY THINK OF THE NHIN SERVICES
AS THAT API EXPOSED BY THE GATEWAY EXTERNALLY
TO OTHER NHIN PARTICIPANTS,
SO THAT INCLUDES A SERVICE TO LOCATE PATIENTS...
WE HEARD A LITTLE BIT ABOUT PATIENT DISCOVERY
THAT IS BASED ON PIX/PDQ.
...TO LOCATE HEALTH DOCUMENTS AND RETRIEVE HEALTH DOCUMENTS.
THAT'S QUERY FOR DOCUMENTS AND RETRIEVE DOCUMENT SERVICES
THAT ARE BASED ON THE XCA SPECIFICATION FROM IHE.
...PUBLISH AND SUBSCRIBE TO DATA FEEDS.
THAT'S THE HIEM SERVICES
THAT ARE BASED ON WS-BASENOTIFICATION.
...RETRIEVE DISCLOSURE HISTORY
OR THE QUERY AUDIT LOG NHIN SERVICE
THAT'S BASED ON ATNA.
...EXCHANGE PATIENT PRIVACY PREFERENCES--
ONE OF THE SPECIFIC PROFILES BASED ON HIEM--
AND LOCATE HEALTH SYSTEMS AND SERVICES.
WE TALKED A LITTLE BIT ABOUT UDDI ALREADY.
THEN, INTERNALLY THE CONNECT GATEWAY
EXPOSES AN API AS WELL,
SIMILAR TO THAT OF NHIN BUT DIFFERENT,
AND THAT IS USED TO INTERFACE
AN EXISTING HEALTH INFORMATION SYSTEM
TO THE GATEWAY
AND THEREFORE MAKE IT COMPATIBLE WITH NHIN.
WHAT'S IMPORTANT IS THAT CONNECT,
IN AND OF ITSELF, DOES NOT PROVIDE AN HIE.
IT IS A GATEWAY TO AN EXISTING SYSTEM,
WHETHER THAT BE AN HIE SYSTEM, AN EHR, ANY OTHER SYSTEM,
TO MAKE IT COMPATIBLE WITH NHIN.
HOWEVER, BY EXPOSING A CONSISTENT API,
YOU CAN IMAGINE OTHER USES WHERE IT MIGHT BE COMPATIBLE
WITH FRAMEWORK THAT MIGHT CREATE AN HIE.
LAST THING I WANTED TO TALK ABOUT JUST VERY QUICKLY
IS THAT THE ARCHITECTURE IS DOCUMENTED,
AND AN EARLY RELEASE OF THE ARCHITECTURE DOCUMENTATION
WAS PROVIDED WITH THE 2.0 RELEASE IN MARCH.
IT IS LIMITED IN DESCRIBING THE MOST IMPORTANT
OF THE INFORMATION EXCHANGE SERVICES.
THAT'S SUBJECT DISCOVERY, QUERY FOR DOCUMENTS
AND RETRIEVE DOCUMENTS,
AND THAT WAS JUST AS AN EARLY RELEASE OF THE ARCHITECTURE.
WITH THE RELEASE OF 2.1 OF CONNECT
HERE DUE OUT NEXT WEEK,
THERE WILL BE A MORE COMPLETE VERSION
OF THE ARCHITECTURE DOCUMENTATION
THAT'S RELEASED THEN.
IT DESCRIBES ALL 6 OF THE SERVICES ASSOCIATED--
THE CORE SERVICES-- WITH NHIN--
SUBJECT DISCOVERY, QUERY FOR DOCUMENTS,
RETRIEVE DOCUMENTS, AUTHORIZED CASE FOLLOW-UP,
HIEM AND AUDIT LOG QUERY--
AS WELL AS THE 4 ENTERPRISE SERVICE COMPONENTS--
THE MPI, DOCUMENT REGISTRY AND REPOSITORY,
POLICY ENGINE AND AUDIT REPOSITORY--
THAT ARE PART OF THE 2.1 RELEASE AS WELL.
SO THAT GIVES YOU A BRIEF INTRODUCTION AT A VERY HIGH LEVEL
TO THE CONNECT ARCHITECTURE.
NOW LES WILL GIVE YOU A DEEPER DIVE
INTO THE COMPONENTS.
[APPLAUSE]
OK. LET ME JUST ADD A COUPLE OF COMMENTS TO WHAT RIM SAID.
OUR CHARTER WAS TO MAKE SURE THIS WAS CUSTOMIZABLE.
IT WAS TO MAKE SURE THAT INITIALLY,
AT THE FEDERAL AGENCIES,
THAT EACH ONE OF THE FEDERAL AGENCIES
COULD TAKE THIS CONNECT PROJECT,
INSTALL IT IN THEIR OWN ENVIRONMENT
AND CUSTOMIZE IT FOR THEIR OWN NEEDS.
WE HAD ALSO THE NEED
THAT MANY OF THEM WERE GOING TO HAVE TO BUY
THESE COMMERCIAL SUPPORT AGREEMENTS,
AND SO THAT DICTATED A LOT OF OUR CHOICE ON PLATFORMS,
OUR CHOICE OF SERVICES, OF TOOLS,
AND SO THAT'S WHAT CAME INTO PLAY
WHEN WE BUILT CONNECT.
WE WENT THROUGH THE EFFORT--
A YEAR AGO, WE STARTED WITH THE DEMONSTRATIONS,
AND WHAT WE FOUND WITH THE DEMONSTRATIONS,
AS MOST OF YOU ARE AWARE WITH DEVELOPMENT,
YOU LEARN A LOT OF THINGS OVER THAT FIRST YEAR OF DEVELOPMENT
ON ANYTHING NEW LIKE THIS, AND DEFINITELY WITH THIS PROJECT,
WHERE THE REQUIREMENTS WERE NOT WELL DEFINED UP FRONT,
AND THEY WERE BEING WORKED OUT AS WE BUILT THE SOFTWARE.
THERE WERE A LOT OF LESSONS LEARNED,
SO WHAT HAPPENED AT THE END OF THE DEMONSTRATIONS IN DECEMBER
IS WE WENT BACK TO THE DRAWING BOARD
AND WERE GIVEN THE OPPORTUNITY TO RE-ARCHITECT THE SOLUTION,
WHICH IS WHAT YOU SEE WITH 2.0 AND MOVING FORWARD WITH 2.1.
SO WHAT YOU SEE NOW
IS A SOLUTION THAT'S QUITE A BIT DIFFERENT IN ARCHITECTURE
THAN WHAT WE BUILT FOR THE DEMONSTRATIONS
AND MORE FOCUSED ON THE LESSONS WE LEARNED FROM THE DEMONSTRATIONS
ON WHAT NEEDED TO BE CONFIGURED,
WHAT WE BELIEVED NEEDED TO BE REPLACEABLE,
AND HOW WE COULD CUSTOMIZE IT FOR EACH INDIVIDUAL AGENCY
AND NOW FOR ANY ORGANIZATION, WHETHER IT BE AN AGENCY OR NOT.
SO LET'S GO AHEAD AND START WITH THE DEEP DIVE NOW.
THERE ARE 2 ARCHITECTURE DIAGRAMS
THAT YOU'LL SEE ON THE WEBSITE FOR 2.0,
AND THEY DON'T CHANGE FOR 2.1.
THAT WAS ONE OF THE REASONS
WHY WE DID THE RE-ARCHITECTURE WITH 2.0 IS TO MAKE SURE
WE REALLY ESTABLISH A SOLID UNDERLYING ARCHITECTURE.
WE WANTED IT BASED ON SERVICE-ORIENTED ARCHITECTURE PRINCIPLES.
WE WANTED IT TO BE CONFIGURABLE,
THAT YOU COULD SWAP OUT COMPONENTS.
WE WANTED TO BE ABLE TO MAKE SURE
THAT, AS RIM DESCRIBED,
THAT ONCE IT WENT OUT THE DOOR,
YOU COULD USE IT RIGHT OUT OF THE BOX
BUT THEN YOU COULD CUSTOMIZE IT AS NECESSARY.
WE IDENTIFIED CERTAIN KEY THINGS ABOUT THE ARCHITECTURE
THAT HAD TO BE IN PLACE AND THAT REALLY WERE COMMON
ACROSS ALL GATEWAY INSTALLATIONS
AND MOST LIKELY WOULD NOT REALLY CHANGE.
AND THEN WE IDENTIFIED THOSE THAT WOULD CHANGE,
AND WE TRIED TO MAKE A VERY CLEAR SEPARATION
BETWEEN THOSE TWO TO MAKE IT CUSTOMIZABLE.
SO THIS FIRST DIAGRAM HERE TALKS ABOUT THE ARCHITECTURE
OF MESSAGES COMING IN FROM THE NHIN,
SO THESE ARE MESSAGES THAT ARE PROCESSED BY CONNECT
AND THEN PASSED DOWNWARD.
THE NEXT DIAGRAM WE'LL TALK ABOUT
WILL BE THE REVERSE DIRECTION OF MESSAGES GOING OUT.
YOU'LL SEE MULTIPLE LAYERS IN THE SOLUTION.
LET ME USE THE...
NO. THERE WE GO. I GOT THAT.
I'VE GOT A POINTER, BUT IN ORDER FOR BOTH SIDES TO SEE IT,
I'LL USE THIS MOUSE HERE.
ACROSS THE TOP HERE ARE LOLLIPOPS
THAT MOST OF YOU WILL SEE AS INTERFACES.
THESE ARE THE INTERFACES THAT HAVE BEEN DEFINED BY NHIN.
THIS IS THE ENTRY INTO CONNECT.
WHEN A MESSAGE IS PASSED FROM NHIN,
THEY GO THROUGH THIS SET OF INTERFACES.
WE DID NOT DEFINE THOSE. WE ARE IMPLEMENTERS OF THOSE.
AS THE NHIN TEAM--
AS THE SPEC FACTORY CREATES NEW SPECIFICATIONS THIS YEAR,
THOSE WILL ROLL TO US, AND WE WILL IMPLEMENT THOSE
AS NEW SPECIFICATIONS OR CHANGES TO THE SPECIFICATIONS.
THIS IS THE LAYER THAT WE'VE DEFINED SAML TO BE.
THAT'S BEEN DEFINED BY NHIN.
NOW, ONE OF THE THINGS THAT YOU'LL SEE DOWN LOWER
AT THE SECOND LAYER
IS RIGHT NOW DEFINED AS A NON-SAML LAYER.
OUR INITIAL PLAN FOR THIS IS THAT EVERYTHING
FROM THE NHIN LAYER DOWN WOULD BE BEHIND YOUR FIREWALL,
AND THEREFORE WE DID NOT NEED SAML DOWN THERE.
NOW, I KNOW THERE'S GOING TO BE SOME OUT THERE
THAT SAY, "YEAH, WE DO," AND YOU'RE RIGHT.
THOSE ARE SOME OF THE CHANGES COMING OUT AS WE MOVE FORWARD.
ONE THING THAT I WANT TO BE VERY CLEAR ON--
WE KNOW THAT THIS IS NOT A PERFECT SYSTEM.
FOR ANYBODY TO ASSUME THAT WE HAVE A PERFECT SYSTEM
AT THIS EARLY STAGE OF THE GAME WOULD BE INCORRECT.
AND THE WHOLE IDEA HERE OF THE OPEN SOURCE,
OF GETTING A GROUP TOGETHER TO START REALLY MOVING FORWARD
IS THAT AS THIS PLAYS OUT, IT'S GOING TO EVOLVE.
THERE ARE GOING TO BE THINGS JUST LIKE THIS ONE,
WHERE WE MADE A DECISION EARLY THAT WE DIDN'T NEED SAML THERE
AND CAME UP WITH ARGUMENTS THAT WE NEED TO PUT IT THERE.
SO THAT DICTATES THE NEXT RELEASE CYCLE.
OUR CURRENT RELEASE CYCLE ON CONNECT IS EVERY 3 MONTHS,
SO QUARTERLY RELEASE CYCLES,
AND AT EACH OF THOSE QUARTERLY RELEASE CYCLES,
AT LEAST FOR WHAT WE'VE BEEN DOING AT THIS POINT,
WE CAN INTERJECT CHANGES IN WHAT THE PRIORITY LIST OF ITEMS ARE
THAT WE'RE WORKING ON.
WE USE AN AGILE PROCESS,
SO, FROM A DEVELOPMENT PERSPECTIVE,
AT ANY SPRINT, ANY RELEASE CYCLE,
WE CAN INJECT AND REORDER THE PRIORITIES OF WHAT WE'RE BUILDING,
SO WE'RE ABLE TO EASILY NAVIGATE AND EASILY ADAPT TO CHANGES.
OK, SO WE HAVE THAT FIRST LAYER, WHICH IS THE NHIN CONNECT,
OR THE NHIN INTERFACE COMING IN.
AS WE DROP TO THE NEXT LAYER,
THESE ARE ORCHESTRATION COMPONENTS.
THESE ARE THE MESSAGE PROXY.
THEY TAKE CARE OF ORCHESTRATING
AND BASICALLY MOVING THE MESSAGES
THROUGH THE GATEWAY.
ONE OF THE THINGS THAT YOU'LL SEE
ON THIS FAR RIGHT-HAND SIDE HERE
IS AN INTERFACE THAT'S CALLED PASS-THROUGH MODE.
DID WE...? OH, WE SWITCHED DIAGRAMS HERE.
BACK UP.
THESE MESSAGE ORCHESTRATION COMPONENTS RIGHT HERE,
THESE ARE THE COMPONENTS THAT TAKE THE MESSAGE,
THEY PROCESS IT.
IF IT'S A SUBJECT DISCOVERY MESSAGE, FOR EXAMPLE,
IT WILL TAKE THE MESSAGE, PULL IT IN.
IT'LL DO THE AUDITING, LOG THE MESSAGE.
IT'LL DETERMINE IF THIS PATIENT HAS ALREADY BEEN CORRELATED
BY LOOKING IT UP IN THE CORRELATION TABLES.
IF IT HAS NOT BEEN CORRELATED,
IT WILL DO A CALL TO THE MPI TO LOOK UP THE PATIENT,
AND IT DOES ALL THIS WORK OF ORCHESTRATING.
ONE OF THE THINGS THAT WE FOUND IN RELEASE 1.0
THAT WE ADDED IN FOR 2.0 IS THE IDEA OF A PASS-THROUGH.
THERE ARE TIMES WE WANT TO ABLE TO BYPASS THE ORCHESTRATION
AND SO PART OF THE ARCHITECTURE THAT WE IMPLEMENTED HERE
IN BOTH DIRECTIONS, BOTH TO AND FROM THE NHIN,
IS THE ABILITY TO SELECTIVELY, SERVICE BY SERVICE,
TURN IT INTO PASS-THROUGH MODE AND TURN OFF ORCHESTRATION.
AND SO THAT'S BUILT IN TO THIS AS WELL,
AND YOU CAN DO THAT SERVICE BY SERVICE.
SO WE HAVE THAT FIRST LAYER WHERE WE ORCHESTRATE.
THE SECOND LAYER IN THIS DIAGRAM IS THE CONNECT CORE COMPONENTS.
THESE ARE COMPONENTS THAT, SOME OF THEM, WE BELIEVE
WILL NEVER REALLY BE TOUCHED OR MODIFIED.
THEY COULD BE, BECAUSE IT'S OPEN SOURCE,
BUT WE DON'T BELIEVE THERE WILL BE A NEED TO.
AND SOME OF THEM WE BELIEVE THERE'S A SMALL POSSIBILITY
THAT SOME ORGANIZATIONS WILL WANT TO CUSTOMIZE THOSE.
THOSE ARE THE ONES THAT ARE IN PURPLE,
OR A DARK BLUE, DEPENDING ON THE SCREEN.
THOSE ITEMS, LIKE, FOR EXAMPLE, PATIENT CORRELATION.
IN VERSION 1.0, WE HAD MPI AND PATIENT CORRELATION
AS THE SAME ENTITY.
AND WHAT WE REALIZED,
THAT ALTHOUGH MANY ORGANIZATIONS ALREADY HAVE AN MPI,
MOST OF THOSE ORGANIZATIONS
DON'T HAVE CORRELATION ENGINES BUILT INTO THEIR MPI
THAT WOULD DEAL WITH CORRELATION ACROSS THE NHIN.
AND SO TO US THERE WAS A CLEAR SEPARATION
OF WANTING TO ALLOW ORGANIZATIONS TO USE THEIR OWN MPI
AND DEALING WITH THE CORRELATION ISSUES
THAT WERE REALLY A GATEWAY-RELATED ISSUE.
NOW, WE DO KNOW OF SOME CASES WHERE THEY HAVE BOTH AN MPI
AND A CORRELATION ENGINE, AND IN THOSE CASES,
THEY WOULD TAKE AND SWAP OUT THE WEB SERVICE
THAT WE'VE DEFINED FOR PATIENT CORRELATION
AND REPLACE IT WITH THEIR OWN
IF THEY WANT TO DO THEIR OWN PATIENT CORRELATION.
BUT THEY WOULDN'T BE REQUIRED TO.
SO, THE PURPLE-COLORED ITEMS
ARE ITEMS THAT COULD BE REPLACED, COULD BE SWAPPED OUT--
WE PLANNED FOR THEM AND DEALT WITH THEM ACCORDINGLY--
BUT THEY DON'T HAVE TO BE.
NEXT, WE DROP-- AND THAT SET OF ITEMS
COVERS BASICALLY THE CORE GATEWAY ITSELF.
ONCE YOU LEAVE THAT AREA,
THEN YOU DROP DOWN TO THE ADAPTER.
NOW, THE ADAPTER ARE ALL IN RED.
THE MAIN PARTS OF THE ADAPTER ARE IN RED ON THE BOTTOM.
THIS IS THE AREA WE BELIEVE ARE HIGHLY CUSTOMIZABLE.
THIS IS THE AREA WE BELIEVE MOST LIKELY WOULD BE REPLACED.
NOW, IN ORDER TO MEET DIRECTIVES FROM ONC,
THESE ARE ALSO AREAS WHERE OPEN SOURCE
ENTERPRISE-CLASS COMPONENTS ARE BEING PROVIDED
AS PART OF THE 2.1 RELEASE
THAT WILL BE HAPPENING IN JULY--JULY 7th,
BUT YOU DON'T NEED TO USE THOSE ENTERPRISE-CLASS SERVICES.
YOU COULD PLUG IN YOUR OWN MPI.
YOU CAN PLUG IN YOUR OWN POLICY ENGINE, ET CETERA.
AND THIS LAYER RIGHT HERE,
WHICH IS CALLED THE ADAPTER SERVICE BUS--
LET ME GET THIS MOUSE HERE--
THIS IS THE LAYER THAT WE'VE CUSTOMIZED TO PLUG THOSE IN.
NOW, AT EACH ONE OF THESE LAYERS,
WE ADOPT OR USE AS MANY OF THE STANDARDS
THAT ARE ALREADY DEFINED AS POSSIBLE.
SO THE ADAPTER LAYER, ALL OF THE SERVICES RUNNING
THE LOLLIPOPS RIGHT ABOVE THE ADAPTER,
THOSE INTERFACES ARE DEFINED TO BE IDENTICAL
TO THE NHIN INTERFACES WITH ONE EXCEPTION, AND THAT IS,
THE INFORMATION THAT WOULD HAVE BEEN PASSED IN SAML,
SINCE WE DON'T HAVE SAML AT THAT LAYER,
WE ADDED A PARAMETER TO HOLD THAT INFORMATION
SO THAT WE COULD PASS THAT ON TO THE ADAPTER,
AND SO YOU HAVE AN EXTRA PARAMETER IN EACH OF THOSE.
OTHER THAN THAT, THE INTERFACES ARE DEFINED TO BE THE SAME.
NOW, AS WE MOVE TOWARDS A SAML-ALL-THE-WAY-THROUGH IMPLEMENTATION,
THAT EXTRA PARAMETER WILL PROBABLY GO AWAY,
ALTHOUGH WE HAVEN'T DONE THE DESIGN OF THAT PIECE YET.
BUT THAT'S THE EXCEPTION.
NOW, AS WE DROP ONE LEVEL LOWER,
WHICH IS THE ADAPTER LEVEL AT THAT ADAPTER SERVICE BUS,
THE INTERFACES AREN'T DEFINED AT THAT LAYER BY NHIN,
AND SO WE WENT OUT, AND AS WE LOOKED AT A COMPONENT,
IF THERE WERE STANDARDS THAT WERE ALREADY DEFINED FOR THAT COMPONENT,
WE TRIED TO ADOPT THOSE AS MUCH AS POSSIBLE.
FOR EXAMPLE, WITH THE DOCUMENT REPOSITORY AND DOCUMENT REGISTRY,
WE USE XDS.b, SINCE IT'S ALREADY BEEN DEFINED.
SO THE IDEA HERE--
AND WE'VE PROVED IT IN VERSION 2.1 THAT THE IDEA WORKS--
AND THAT IS, WE IMPLEMENT TO XDS.b,
AND WE CAN TAKE AND SWAP IN
ANOTHER IMPLEMENTATION OF XDS.b RIGHT AT THAT LAYER
BY SIMPLY CHANGING THE URL THAT WE HAD TALKED TO.
AND SO IT'S REALLY A TRUE SERVICE-ORIENTED ARCHITECTURE APPROACH,
WHERE JUST BY CHANGING THE ADDRESS OF THE SERVICE,
BECAUSE THE INTERFACE IS THE SAME,
WE AUTOMATICALLY SWITCHED TO A DIFFERENT IMPLEMENTATION.
SO, IN 2.1 WHAT YOU'LL HAVE
IS 2 IMPLEMENTATIONS OF A REPOSITORY--
OUR LITTLE MINI ONE THAT WE BUILT
FOR THE DEMONSTRATIONS LAST YEAR
PLUS A NIST-BASED REPOSITORY--
THAT BOTH IMPLEMENT XDS.b, AND THEY'RE INTERCHANGEABLE
BY SWITCHING THE URL FOR WHICH ONE YOU'RE TALKING TO.
WHEN WE WENT TO MPI,
WE REALLY COULDN'T FIND A CLEAR, DEFINED WINNER FOR MPI,
SO WE CHOSE THE FIND CANDIDATES
THAT'S ALREADY BEEN DEFINED UNDER HL7,
SO WE BASICALLY WENT TO AS CLOSE TO A STANDARD AS WE COULD
IF THERE WAS ONE DEFINED.
WHEN WE GO TO POLICY ENGINE,
POLICY ENGINE, WE USED THE XACML, THE X-A-C-M-L.
WE ALSO USED THE--
AS WE MOVED WITH 2.1, THE XSPA PROFILE ON XACML,
WHICH WAS DEFINED BY DAVE RILEY AND CRAIG MILLER
AS THEY TALKED EARLIER,
AND AS YOU LOOK AT SOME OF THE SPECIFICATIONS
FOR THE POLICY ENGINE,
THERE'S A SPECIFICATION DEFINED BY HITSP, WHICH IS TP30,
AND THEN IT DEFINES SOMETHING CALLED BPPC--
I ALWAYS GET THE CCs AND THE P's MIXED UP--
THE BPPC, WHICH IS THE BASIC PATIENT PROFILE CONSENT STANDARD.
AND SO, IN VERSION 2.1, WE USE THAT
TO STORE THE DOCUMENT FOR PATIENT CONSENT.
AS MUCH AS POSSIBLE, OUR IDEA IS NOT TO REINVENT THE WORLD.
OUR IDEA IS TO USE STANDARDS THAT HAVE ALREADY BEEN THERE
AND MAKE THEM INTEROPERATE, AND SO THAT'S THE POLICY ENGINE.
THE SUBSCRIPTION REPOSITORY IS A SINK, BASICALLY,
IN THE 2.0 AND 2.1 IMPLEMENTATION
BY WHICH YOU WOULD PLUG IN
A PLACE FOR YOU TO STORE SUBSCRIPTION INFORMATION.
WE TALKED ABOUT, IN SOME OF THE EARLIER PRESENTATIONS,
ABOUT THE HEALTH INFORMATION EVENT PROCESSING
OR MESSAGING, HIEM.
THIS IS WHERE THE INFORMATION GETS STORED.
IT REALLY IS THE PROCESS OF THE ADAPTER
TO DETERMINE WHEN TO POST STUFF BASED ON A SUBSCRIPTION.
THE GATEWAY CAN MANAGE NOTIFYING ABOUT SUBSCRIPTIONS,
IT CAN MANAGE THE TOPIC.
ONE QUESTION THAT WAS ASKED EARLIER,
IF YOU WERE IN THE PRESENTATION, REGARDING WS-TOPIC...
IN CONNECT, WE'VE ALREADY IMPLEMENTED WS-TOPIC
FOR RELEASE 2.1,
SO NHIN IS STILL WORKING ON SOME OF THE STANDARDS,
BUT IN THAT ONE CASE,
WE HAD A NEED TO GET THAT OUT THE DOOR FAST
FOR SPECIFICALLY THE CDC WORK THAT'S COMING DOWN
FOR WHAT THEY WANTED TO DO WITH THEIR LIMITED LIVE PRODUCTION.
SO WE'VE ALREADY MADE THE CHANGE FOR WS-TOPIC
THAT YOU'LL SEE IN 2.1.
AND SO THE SUBSCRIPTION REPOSITORY IS A WAY FOR US
TO PASS THE MESSAGE DOWN
FOR THE ADAPTER TO BE ABLE TO TAKE IT
AND STORE THAT IT HAPPENED.
RE-IDENTIFICATION--
THERE WERE SOME QUESTIONS EARLIER IN THE PRESENTATION.
THE PRIMARY PART OF--
THEY CALL IT AUTHORIZED CASE FOLLOW-UP
AS AN NHIN SPEC,
AND WHAT THAT BASICALLY IS IS WHEN MESSAGES ARE SENT OUT--
LIKE FOR CDC, FOR BIOSURVEILLANCE--
WHICH HAVE BEEN DE-IDENTIFIED.
A PREVIOUS NAME FOR THIS IS PSEUDONYMIZATION,
WHERE MESSAGES HAVE A PSEUDONYM RATHER THAN THE REAL IDENTIFIER,
AND IF THERE WAS AN ISSUE THAT THE CDC NEEDED TO FOLLOW UP ON,
THEY COULD TAKE, AND WITH THE RIGHT SECURITY,
THEY COULD GET A RE-IDENTIFICATION OF THAT IDENTIFIER,
GET THE REAL PATIENT IDENTIFIER
SO THEY COULD QUERY FOR THAT INFORMATION.
THAT'S WHAT RE-IDENTIFICATION IS,
AND CONNECT HAS A VERY RUDIMENTARY IMPLEMENTATION
ON THE ADAPTER SIDE.
IT'S SIMPLY AN XML FILE,
BUT IT ALLOWS YOU TO IMPLEMENT THE INTERFACE
AND SHOWS YOU WHAT YOU NEED TO DO TO IMPLEMENT THE INTERFACE,
AND THAT'S WHAT RE-IDENTIFICATION IS.
SOME OF THE OTHER COMPONENTS IN THIS ON THE SDK SERVICES,
MANY OF THEM HAVE NOT BEEN IMPLEMENTED YET.
THEY'RE PLACEHOLDERS FOR THINGS TO COME--
TERMINOLOGY SERVICES, FOR EXAMPLE,
AND OTHER SERVICES WHICH ARE NOT DEFINED--
BUT WE NEEDED TO MAKE SURE THEY WERE SHOWN ON THE ARCHITECTURE
AS TO WHERE THEY MIGHT LIVE, AND THAT'S WHAT'S HERE.
THE NEXT SLIDE HERE--
AND I'M USING A LOT OF TIME ON THESE FIRST FEW SLIDES
BECAUSE I THINK IT'S VERY IMPORTANT TO UNDERSTAND
THE LAYERS HERE, AND THEN IT'LL HELP US
IN MOVEMENT THROUGH THE OTHER SLIDES.
THIS DIAGRAM HERE GOES IN THE REVERSE DIRECTION.
ON THE ADAPTER SIDE,
THERE REALLY ISN'T A LOT THAT WE CAN PUT IN HERE
FOR ITEMS THAT WE CAN BUILD RIGHT NOW FROM SCRATCH.
HOWEVER, UNDER 2.2 AND SOME OF THE MOVEMENT GOING FORWARD,
THE IDEA OF THE UNIVERSAL CLIENT THAT RIM TALKED ABOUT,
THE ABILITY TO HAVE A CLIENT, FOR EXAMPLE,
FOR AN EHR OR A DOCTOR'S PRACTICE OFFICE
THAT MIGHT BE SOMEWHERE WHERE THEY DON'T REALLY HAVE A SYSTEM,
THE ABILITY TO TURN ON A CLIENT
SO THAT THEY CAN HAVE ACCESS INTO THE NHIN
AND NOT NECESSARILY BE A PROVIDER IN IT
BUT BE A REVIEWER OF THE DATA OR A RECIPIENT OF IT--
A LOT OF WORK THAT'S GOING TO BE GOING ON
OVER THE NEXT FEW MONTHS
REGARDING THAT UNIVERSAL CLIENT AND HOW THAT MIGHT PLAY OUT
AND BUILDING IT IN SUCH A WAY
THAT ADD-INS COULD BE PLUGGED IN AS WELL,
SO VENDOR...
VALUE TO VENDOR DEVELOPMENT
TO BE ABLE TO PRODUCE ADD-INS TO THAT.
THERE'S BEEN A LOT OF DISCUSSION ALONG THOSE LINES.
MOST OF THE WORK IN THIS CASE HAS HAPPENED IN THE GATEWAY.
IF WE FLIP THE PREVIOUS DIAGRAM ON ITS HEAD
WITH A LITTLE BIT OF VARIATION,
THAT'S WHAT WE GET HERE.
IN THIS CASE, WE'RE SENDING MESSAGES OUT.
THE TRIGGERS OF THOSE MESSAGES ARE REALLY DEPENDENT
ON WHAT THE ADAPTER NEEDS TO DO,
WHAT YOUR AGENCY, YOUR ORGANIZATION WANTS TO DO
OR HOW THE USERS ARE INTERACTING WITH IT,
WHETHER IT'S DOING A QUERY FOR DOCUMENTS OUT TO THE NHIN,
WHETHER IT'S DOING AN ANNOUNCEMENT OF A PATIENT.
YOU MIGHT, FOR EXAMPLE, ON A TRIGGER,
EVERY TIME A PATIENT ARRIVES INTO YOUR ORGANIZATION,
YOU SEND A MESSAGE OUT
TO DO A CORRELATION TO THE NHIN.
YOU MIGHT HAVE IT BASED ON WHEN THE PATIENT ACTUALLY SHOWS UP.
SO THERE'S A NUMBER OF DIFFERENT PLACES
THAT YOU CAN DO THAT.
ONCE YOU'VE TRIGGERED IT,
THEN WE HAVE THE ORCHESTRATION THAT IS IN REVERSE.
NOW, WE'VE CALLED THIS LAYER HERE,
WHICH IS THE BOTTOM SIDE OF THE BLUE BOX,
WE'VE CALLED THAT THE ENTITY LAYER.
WHEREAS THE ADAPTER LAYER
IS WHERE THE GATEWAY TALKS TO AN ADAPTER,
THE ENTITY LAYER IS THE DEFINITION OF INTERFACES
THAT THE ADAPTER TALKS TO THE GATEWAY,
AND THAT'S THIS LAYER.
SO WE HAVE ENTITY ORCHESTRATION.
ONCE WE GET THE MESSAGE IN, WE HAVE TO DO PROCESSING OF IT.
FOR EXAMPLE, IF I'M DOING A SUBJECT DISCOVERY,
I NEED TO FIGURE OUT WHERE I SEND THAT SUBJECT DISCOVERY.
NOW, THERE'S A COUPLE OF OPTIONS THAT MIGHT HAPPEN THERE.
ONE IS THAT I'M TOLD WHERE TO SEND IT BY THE ADAPTER.
THE ADAPTER MAY SAY, "SEND THIS SUBJECT DISCOVERY ANNOUNCEMENT
TO THIS INSTITUTION."
THAT WOULD BE AN EXAMPLE OF THE WAY THAT THE LIMITED PILOT
RIGHT NOW BETWEEN MEDVA AND THE SOCIAL SECURITY ADMINISTRATION.
IT'S VERY TARGETED RIGHT NOW.
THEY'RE NOT DOING A BROADCAST ANNOUNCEMENT.
THEY'RE TARGETED TO THAT ONE INSTITUTION.
OR THE OTHER OPTION WOULD BE
I NEED TO ANNOUNCE THAT I HAVE THIS PATIENT ON THE NHIN,
AND I WANT IT TO GO EVERYWHERE.
SO THE ORCHESTRATION OF THAT WOULD BE GO TO THE UDDI
OR AT LEAST OUR CACHE OF THE UDDI--
AND WE CACHE ALL THAT INFORMATION IN OUR CONNECTION MANAGER--
SO GO TO THE CACHE,
FIND OUT ALL THE INSTITUTIONS THAT WE CAN CONNECT TO,
SEND A MESSAGE OUT TO EACH ONE, GET ALL THE RESPONSES BACK,
AND CORRELATE THAT AND DO ALL THE CORRELATION.
THAT WOULD BE WHAT WOULD BE INVOLVED
IN AN ORCHESTRATION OF SUBJECT DISCOVERY.
NOW, IF I WAS DOING A DOCUMENT QUERY,
THAT ONE GETS A LITTLE MORE COMPLEX, BECAUSE NOW I'VE GOT TARGETS.
I KNOW THAT I'M CORRELATED WITH THESE 3 PLACES,
SO I'M GONNA SEND A MESSAGE TO EACH ONE OF THOSE 3,
THEN I'M GONNA HAVE TO WAIT FOR THE RESPONSE TO COME BACK
FROM EACH ONE OF THOSE 3, CORRELATE THEM ALL UP,
THEN TAKE THAT WHOLE MESSAGE AS ONE MESSAGE AND PASS IT BACK TO THE ADAPTER.
SO I'VE GOTTA AGGREGATE THOSE MESSAGES THAT COME BACK,
AND THE SAME THING WOULD BE TRUE ON A RETRIEVE.
SO ALL OF THAT IS THE ORCHESTRATION WORK THAT THE GATEWAY IS DOING.
THAT FINAL LAYER,
WHICH IS THE NHIN CONNECT MESSAGE PROXY COMPONENT
ON THE TOP,
THAT'S THE COMPONENT THAT REALLY HAS ONE JOB TO DO,
AND THAT IS GET THAT MESSAGE OUT ONTO THE NHIN.
IT TAKES CARE OF THE SAML,
SO IT TAKES CARE OF TAKING ALL THAT INFORMATION
IN THAT EXTRA PARAMETER, PACKAGING IT UP,
MAKING THE SAML MESSAGE AND SENDING IT OUT ON THE NHIN,
AND WAITING FOR RESPONSES TO COME BACK IF THAT'S APPROPRIATE.
THIS IS WHERE THE PASS-THROUGH COMES IN IN THIS DIRECTION.
FROM A TESTING PERSPECTIVE,
WE DIDN'T FIND A WHOLE LOT OF TOOLS
THAT WE COULD TEST THAT HAD SAML ENABLED IN THEM,
BUT WE COULD DO A LOT OF TESTING
IF WE DIDN'T HAVE SAML IN THE PICTURE.
SO ONE OF THE REASONS WHY WE DESIGNED THIS AT THIS LAYER
IS THAT WE COULD WRITE ALL OF OUR TEST TOOLS RIGHT AGAINST THIS LAYER
AND THEN HAVE THE CONNECT DEAL WITH SAML.
SO THAT'S ONE OF THE REASONS.
THE OTHER REASON IS IF YOU JUST WANT TO PUSH SOMETHING OUT,
BYPASS ORCHESTRATION AND JUST PUSH IT OUT,
YOU COULD DO THAT THROUGH THE PASS-THROUGH,
AND EVERY ONE OF THE SERVICES HAVE THAT OPTION.
ALREADY TALKED ABOUT THAT, SO WE'LL SKIP THAT.
THE DEVELOPMENT ENVIRONMENT TOOL SET--SOME BASIC STUFF.
1.6, UPDATE 11, BUILD 3 IS THE JDK.
THE GLASSFISH ESB-- WE HAD A NUMBER OF ISSUES
THAT WE HAD TO GET RESOLVED IN GLASSFISH ESB
WHEN WE WERE DOING THE DEVELOPMENT,
AND A LOT OF THEM DEALT WITH SAML-RELATED ISSUES.
SO WE HAD TO TAKE A SPECIFIC NIGHTLY BUILD
THAT SUN HAD CREATED WHICH FIXED THOSE ISSUES,
SO IT IS VERY SPECIFIC.
IF YOU TRY TO USE A RELEASE THAT'S PREVIOUS TO THAT,
IT WILL NOT WORK. I WILL WARN YOU THAT NOW.
AND WHAT WE DID ALSO FIND IN MANY CASES,
MOVING TO A DIFFERENT VERSION OF GLASSFISH ESB
WAS PROBLEMATIC.
IT WAS VERY DIFFICULT.
IN ONE CASE IT TOOK US A WHOLE MONTH TO MAKE THE JUMP.
IN THE LAST CASE WE DID, IT WASN'T SO PROBLEMATIC,
AND SO I ONLY RAISE THAT
AS DON'T THINK THAT JUST MOVING TO A LATER VERSION
OF GLASSFISH ESB AND YOU'RE OK.
YOU MAY RUN INTO ISSUES,
AND JUST BE AWARE THAT THAT MAY HAPPEN.
WE USE METRO 1.4
AND MySQL 5.0 AND soapUI 2.5.1.
NOW, soapUI HAS BOTH A PROFESSIONAL
AND A FREE VERSION OR OPEN SOURCE VERSION,
AND IT WORKS WITH EITHER ONE.
OK. WHAT TIME IS IT?
4:30.
OK, SO A COUPLE OF DIAGRAMS HERE.
I THINK WHAT I'M GONNA DO
IS TO GO THROUGH ONE OR TWO OF THESE IN DETAIL,
THEN LEAVE THE REST FOR YOU TO REVIEW
SO WE HAVE SOME TIME FOR QUESTIONS.
I THINK THE QUESTIONS ARE GOING TO BE IMPORTANT,
AND I THINK AFTER ONE OR TWO OF THESE,
IF I DON'T PUT YOU TO SLEEP AFTER THE FIRST ONE,
I'M SURE BY THE SECOND ONE, I'LL HAVE ALL OF YOU OUT.
THE FIRST ONE HERE, THIS CONTEXT DIAGRAM,
RIM PUT THESE CONTEXT DIAGRAMS TOGETHER
TO HELP KIND OF SHOW EACH INDIVIDUAL SERVICE
AND HOW THOSE SERVICES RELATE WITH CONNECT
AND HOW THEY PLUG IN.
I THINK THEY'RE VERY VALUABLE IN HELPING YOU UNDERSTAND
WHICH COMPONENTS ARE RELATED TO WHICH SERVICE.
SO IN THE CASE OF SUBJECT DISCOVERY,
IT LOOKS PRETTY SIMPLE,
AND THE NAME "SUBJECT DISCOVERY,"
IN MY OPINION,
IT ACTUALLY SHOULD HAVE BEEN "SUBJECT ANNOUNCE,"
BECAUSE THE WAY THE NHIN SERVICES REALLY ARE ON THIS
IS NOT THAT I'M DOING A QUERY FOR A PATIENT,
I'M ACTUALLY SENDING AN ANNOUNCEMENT THAT I HAVE ONE,
AND I'M WAITING FOR THAT SYSTEM TO SEND AN ANNOUNCEMENT BACK
THAT THEY HAVE A MATCH AND WHAT THAT INFORMATION IS,
SO IT'S REALLY AN ANNOUNCEMENT.
SO WHAT HAPPENS IN THE CASE OF CONNECT FOR THIS
IS A MESSAGE WILL COME IN FROM ANOTHER SYSTEM, FOR EXAMPLE.
THAT SYSTEM WILL DO AN ANNOUNCE TO CONNECT.
CONNECT WILL DO A QUERY ON THE MPI.
IT'LL DETERMINE,
BASED ON THE CRITERIA OF THAT ORGANIZATION,
AND THAT'S WHERE "FIND CANDIDATES" BECOMES IMPORTANT.
THAT'S WHERE YOUR IMPLEMENTATION OF THE ADAPTER BECOMES IMPORTANT
BECAUSE THE DETERMINATION OF WHETHER YOU HAVE A MATCH
IS ALL TIED TO THAT "FIND CANDIDATES" ROUTINE.
IF THAT "FIND CANDIDATES" ON THE ADAPTER
SAYS IT IS A MATCH, THEN WE'RE GOING TO CORRELATE IT
AND STICK THE CORRELATION IN THE CORRELATION TABLE.
IF THAT "FIND CANDIDATE" SAYS IT'S NOT A MATCH,
WE'RE NOT GOING TO CORRELATE AND WE'RE NOT GOING TO ORCHESTRATE THAT,
SO THE "FIND CANDIDATES" BECOMES CRITICAL
IN YOUR ORGANIZATION.
NOW, UNDER PREVIOUS PROJECTS THAT I'VE WORKED,
ONE CALLED CHEDDAR AND ONE CALLED BHIE,
WHAT WAS INTERESTING ABOUT THOSE IS WE FOUND--
AND I SEE TONY OUT HERE WITH A SMILE ON HIS FACE--
WE FOUND THAT IN CORRELATION--
AND THEY DID CORRELATION AS WELL--
THERE ARE REALLY ONLY 4 TRAITS
THAT REALLY MADE A BIG DIFFERENCE,
AND IF YOU TRIED TO GO FARTHER THAN THAT,
IT ACTUALLY GAVE YOU MORE FALSE MATCHES
OR MORE NON-MATCHES THAN YOU WANTED,
AND IN THAT CASE WE FOUND
WAS LAST NAME, FIRST NAME, DATE OF BIRTH AND SEX.
THOSE WERE THE 4.
WHEN WE TRIED TO ADD IN ADDITIONAL CRITERIA,
WE DIDN'T GET WHAT WE WANTED OUT OF IT.
SO THAT'S SOMETHING THAT EACH ORGANIZATION
WILL GET TO PLAY WITH BASED ON THEIR ADAPTER
AND WHAT THEY'RE GOING TO SEND.
NOW, ONCE AN ORGANIZATION-- AND THIS IS AN NHIN SPEC THING--
ONCE AN ORGANIZATION DETERMINES THEY HAVE A MATCH,
THEY CAN CORRELATE, AND THEN THEY SEND AN ANNOUNCEMENT
BACK OUT TO THE ORGANIZATION THAT FIRST SENT IT,
AND THAT ORGANIZATION GETS TO DETERMINE
WHETHER THEY HAVE A MATCH ALSO BASED ON THEIR OWN CRITERIA.
SO YOU MIGHT HAVE ON THE NHIN
ONE SYSTEM THAT THINKS IT'S A MATCH TO PATIENT
AND THE OPPOSITE SYSTEM
NOT COUNTING IT AS A MATCHED PATIENT,
AND THAT'S PART OF THE NHIN SPECIFICATIONS.
IT WAS DESIGNED THAT WAY SO THAT EACH ORGANIZATION
COULD DETERMINE THEIR OWN CRITERIA FOR MATCHING.
AND SO THAT'S THE CASE HERE.
NOW, THIS DIAGRAM--
THE REASON WHY YOU GOT VERY DETAILED PRINTOUTS
IS BECAUSE I KNEW YOU WOULDN'T BE ABLE TO SEE THIS ON THE SCREEN.
SO THIS SHOULD BE THE FIRST DIAGRAM IN YOUR PRINTOUT.
- [MAN, INDISTINCT] - YEAH.
THIS SHOULD BE THE FIRST DIAGRAM AFTER THE SLIDE DECK
IN YOUR PRINTOUT, AND THEY'RE FULL-PAGE DIAGRAMS.
I'M JUST GONNA WALK THROUGH THIS ONE
JUST SO YOU KIND OF GET A PICTURE
OF HOW TO READ THESE DIAGRAMS AND WHAT THEY MEAN.
IF YOU LOOK AT THE VERY TOP,
THE GATEWAY IS THE COMPONENT ON THE FAR SIDE.
THAT'S THE REMOTE GATEWAY.
I TOLD YOU I'D PUT YOU ALL TO SLEEP.
[LAUGHS]
THE REMOTE GATEWAY BASICALLY IS ON THE OTHER SIDE OF THE NHIN,
SO THIS IS A MESSAGE THAT'S COMING IN FROM THE NHIN.
GETS A MESSAGE. THAT'S THE REMOTE GATEWAY.
THE SECOND COMPONENT AFTER THAT
IS OUR ORCHESTRATOR.
I MENTIONED IN THE ARCHITECTURE PICTURE,
THE ORCHESTRATOR.
THAT'S THE ITEM THAT'S GOING TO CATCH THAT MESSAGE,
AND THEN YOU'LL SEE A NUMBER OF OTHER COMPONENTS.
WE HAVE A PATIENT CORRELATION FACADE AND A PATIENT CORRELATION.
ONE OF THE THINGS WE FOUND IS
OFTENTIMES THE SPECIFICATIONS GET TO BE VERY UNRULY
IN NAVIGATING SOME OF THE CONSTRUCTS,
ESPECIALLY SOME OF THE HL7 VERSION 3,
AND SO WHAT WE DID WITH SOME OF THOSE ITEMS
IS WE WRAPPED THEM WITH A FACADE,
A LAYER THAT WOULD SIMPLIFY IT,
SO THAT WE COULD ENCAPSULATE THAT AWAY
AND NOT HAVE TO HAVE EVERYBODY HAVE TO DEAL
WITH THE COMPLEXITIES OF THAT DATA TYPE.
AS WE MOVE DOWN FURTHER, WE HAVE A CONNECTION MANAGER,
AND I'LL GET INTO MORE DETAIL ABOUT THAT TOMORROW
IN SOME OF THE TECHNICAL PRESENTATIONS,
BUT THE CONNECTION MANAGER BASICALLY TAKES THE INFORMATION
FROM UDDI AS WELL AS OTHER CONNECTION INFORMATION,
CACHES IT, AND IT'S USED TO LOOK UP SERVICES.
AND SO ANY OF THOSE COMPONENTS THAT ARE REPLACEABLE COMPONENTS,
WE USE THE CONNECTION MANAGER TO GIVE US THE URL
THAT WE'RE GOING TO USE TO CONNECT UP TO THAT SERVICE,
AND THAT ALLOWS US TO CONFIGURE THOSE
WITHOUT HAVING TO REPLACE SOFTWARE,
AND SO THAT'S WHERE THE CONNECTION MANAGER COMES INTO PLAY.
SO I WILL GO THROUGH A COUPLE OF THE ITEMS ON THIS,
A COUPLE OF THE LINES,
AND THEN I WILL BEAR YOU THE PAIN OF WALKING THROUGH THIS
LIKE WE'VE HAD TO DO FOR A LONG TIME.
THE FIRST ITEM THERE, THE FIRST LINE,
IS THE MESSAGE COMES IN.
THE MESSAGE TYPE IS AN HL7 VERSION 3 MESSAGE TYPE.
IT'S A 201/301 MESSAGE, SO YOU'VE HEARD
A LITTLE BIT OF THAT IN ONE OF THE EARLIER PRESENTATIONS.
IT'S AN I.N. 201/301 MESSAGE.
THAT'S A SPECIFICATION FROM HL7.
WE TAKE IN ONE OF THOSE KINDS OF MESSAGES.
WE LOG IT. THAT'S THE FIRST THING WE DO.
YOU'LL SEE LOGGING COMING IN, LOGGING GOING OUT.
THEN THE NEXT THING YOU'LL SEE
IS WE STORE AN ASSIGNING AUTHORITY.
THIS IS AN AREA OF THE NHIN SPECIFICATIONS
THAT ALSO NEEDS TO BE ADDRESSED AS WE MOVE FORWARD,
BUT WE NEEDED TO HAVE A SOLUTION TO IT.
THERE'S A DIFFERENCE BETWEEN AN ORGANIZATION'S OID
OR AN ORGANIZATION'S I.D.
AND THE ASSIGNING AUTHORITY ASSOCIATED WITH AN IDENTIFIER.
YOU MIGHT HAVE A RHIO OR HEALTH INFORMATION EXCHANGE
THAT HAS MULTIPLE ASSIGNING AUTHORITIES,
BUT THEY ONLY HAVE ONE OID FOR THEIR ORGANIZATION,
SO YOU CAN'T CALL THE HOME COMMUNITY I.D.
THE SAME AS AN ASSIGNING AUTHORITY.
BUT UNFORTUNATELY RIGHT NOW ON NHIN IN THE UDDI REGISTRY,
THEY ONLY TRACK HOME COMMUNITY I.D.s.
THEY ONLY TRACK THE OIDs.
WHAT WE ELECTED TO DO FOR CONNECT
IS AS THE MESSAGES COME IN
AND WE HAVE AN ASSIGNING AUTHORITY--
BECAUSE ONCE YOU GET PAST THE SUBJECT DISCOVERY,
WE DON'T KNOW ONE OF THE PIECES OF THOSE INFORMATION,
I FORGET WHETHER IT WAS HOME COMMUNITY I.D. OR ASSIGNING AUTHORITY.
I THINK IT'S HOME COMMUNITY I.D.
WE LOSE ON DOCUMENT QUERY AND DOCUMENT RETRIEVE.
WE GET AN ASSIGNING AUTHORITY
BUT DON'T KNOW WHAT HOME COMMUNITY IT IS,
SO WE DON'T KNOW WHERE TO SEND THE MESSAGE.
WHAT WE DECIDED TO DO ON SUBJECT DISCOVERY IS
IN OUR ORCHESTRATION OF SUBJECT DISCOVERY,
WHEN WE GET A MESSAGE IN, WE TAKE THAT ASSIGNING AUTHORITY
AND GET BOTH HOME COMMUNITY AND ASSIGNING AUTHORITY ON SUBJECT DISCOVERY.
WE MAKE A MAP OF IT IN A LOCAL DATABASE,
AND AS WE HAVE THAT IN OUR LOCAL DATABASE,
LATER, WHEN WE JUST GET THE ASSIGNING AUTHORITY,
WE CAN LOOK UP THE HOME COMMUNITY I.D.
IN A FUTURE CALL.
SO THAT'S WHAT'S GOING ON THERE,
AND THAT'S A SHORT-TERM IMPLEMENTATION.
WHEN NHIN COMES UP WITH A SOLUTION OF TRACKING ASSIGNING AUTHORITIES,
THEN WE'LL MIGRATE TO THEIRS,
BUT WE HAD TO SOLVE THAT PROBLEM IN ORDER TO MOVE FORWARD.
THERE'S SOME IF-LOGIC IN SOME OF THESE BOXES
I'LL JUST QUICKLY TALK ABOUT.
SOME OF THE ITEMS THERE--
ANOTHER SPECIFICATION THAT WAS NOT REAL CLEAR
ON THE NHIN SIDE THAT WE NEEDED AN IMPLEMENTATION OF
WAS WHETHER, IF YOU'VE ALREADY CORRELATED THIS PATIENT BEFORE,
WHETHER YOU STILL SEND BACK AN ANNOUNCEMENT
IF THEY SENT YOU ONE.
SO, FOR EXAMPLE, THEY'VE SENT US AN ANNOUNCEMENT.
WE CORRELATED THE PATIENT,
WE STUCK AN ENTRY IN THE CORRELATION TABLES,
AND THEY SENT US ANOTHER ANNOUNCEMENT.
DO WE SEND BACK AN ANNOUNCEMENT,
OR DO WE JUST SAY, "YOU ALREADY DID THAT," AND THROW IT AWAY?
THAT WASN'T REAL CLEAR IN THE NHIN SPECIFICATIONS,
SO WE PUT THAT ON A FLAG
WHETHER THE CONNECT DOES-- WHICH ONE IT WILL DO.
YOU CAN CHOOSE.
AND SO THAT'S SOME OF THE IF-LOGIC HERE.
OTHER THAN THAT, I'M MORE THAN WILLING
TO GO THROUGH EACH OF THESE INDIVIDUALLY,
AND AFTER OUR QUESTIONS, IF YOU WANT TO COME UP
AND TALK WITH ME ON ANY ONE OF THEM, IF YOU HAVE QUESTIONS,
I'M MORE THAN HAPPY TO GO THROUGH ANY OF THEM WITH YOU,
BUT I THINK IT WILL BE OVERKILL HERE.
I THINK THIS IS NOT A GOOD FORUM TO GO THROUGH EACH OF THESE.
I'LL SKIP THOSE AND GO TO SOME OF THE OTHER SLIDES THAT I HAVE,
THEN WE'LL COME BACK WITH QUESTIONS,
THEN, INDIVIDUALLY,
I'M MORE THAN HAPPY TO STAY AS LONG AS YOU NEED ME TO.
OK. I DO WANT TO MAKE A COMMENT.
I'M SKIPPING OVER TO SLIDE 30.
I WANT TO MAKE A COMMENT ON DOCUMENT RETRIEVE
AND DYNAMIC DOCUMENTS.
THERE WAS A COMMENT MADE EARLIER
REGARDING DYNAMIC DOCUMENTS.
THIS IS GOING TO BECOME A BIG ISSUE WITH NHIN
AND A BIG ISSUE WITH CONNECT.
THE IDEA THAT EVERY ORGANIZATION ALREADY HAS A CDA DOCUMENT
SITTING THERE ON THE SYSTEM WAITING TO SEND TO THE NHIN
IS NOT REALITY.
EACH OF THE SYSTEMS OUT THERE
HAVE DIFFERENT GRANULARITY OF DATA,
AND THAT DATA IS GOING TO BE COMPILED TOGETHER
INTO A DOCUMENT AND SENT OUT TO THE NHIN
BASED ON ALL SORTS OF CRITERIA,
BASED ON POLICIES AND ALL THOSE ITEMS.
THERE'S A COUPLE OF CRITERIA THAT NHIN HAS ALREADY DEFINED
THAT I'M SURE MAY BE REVISITED
BASED ON WHAT THEY'RE TRYING TO ACCOMPLISH
IN SOME OF THE SPEC WORK THAT'S HAPPENING,
BUT ONE OF THEM IS THAT ONCE YOU'VE TRANSMITTED A DOCUMENT
THAT HAS BEEN DYNAMICALLY CREATED,
IT MUST BE KEPT PERMANENTLY FROM THEN ON.
YOUR SYSTEM HAS TO BE ABLE
TO RESEND THE EXACT SAME DOCUMENT
AS IT EXISTED THE FIRST TIME YOU SENT IT.
THAT'S A PRETTY TALL ORDER
FOR THOSE CONSTRUCTING DYNAMIC DOCUMENTS,
BUT THAT RIGHT NOW IS WHAT THE NHIN SPEC SPECIFIES
FOR DYNAMIC DOCUMENTS.
THE ONLY CAVEAT TO THAT THAT THEY LIST
IS IF SOMEONE DID A QUERY
OR IF A SYSTEM DID A QUERY FOR A DYNAMIC DOCUMENT,
AND YOU SENT OUT THAT YOU HAD THE ABILITY TO GIVE THE DOCUMENT
BUT YOU NEVER ACTUALLY SENT THE DOCUMENT,
THEN YOU CAN TAKE THOSE AND THROW THEM AWAY
AFTER A CERTAIN PERIOD OF TIME. I DON'T REMEMBER WHAT THAT IS.
AS WE MOVE FORWARD WITH THE SPECIFICATIONS
AS THEY COME OUT OF THE SPEC FACTORY,
THIS IS GOING TO BE AN ISSUE.
I KNOW IT'S AN ISSUE FOR ONE SYSTEM
THAT WE'VE BEEN TALKING ABOUT,
AND SO I KNOW IT'S GOING TO BECOME
A BIGGER AND BIGGER DRIVER
AS SYSTEMS COME UP ON THE NHIN,
BUT JUST BE AWARE OF THAT.
OK, SO, 2.1 CHANGES.
THERE ARE 4 ENTERPRISE-CLASS SYSTEMS
THAT WERE PUT IN PLACE FOR 2.1
AT VARYING DEGREES OF-- VARYING LEVELS.
THE MPI-- LET ME GET A DRINK OF WATER.
WE DID SOME SEARCHES TO FIND SOME MPIs THAT WERE OPEN SOURCE,
AND REALLY THE ONLY ONE WE FOUND WAS MURAL.
I'M NOT SAYING IT IS THE ONLY ONE.
IT'S THE ONLY ONE WE FOUND
IN THE TIME WE HAD TO SEARCH FOR THEM.
AND IF THERE ARE OTHERS OUT THERE, BY ALL MEANS,
GET ON THE FORUM, LET US KNOW ON THESE THINGS,
BECAUSE THOSE ARE THE ITEMS THAT DRIVE A LOT OF THE DEVELOPMENT,
AND AS YOU GET ON THE FORUMS AND PUT THIS INFORMATION IN,
CHANGES CAN HAPPEN.
WE FOUND THE MPI TO BE REASONABLE,
BUT WE RAN INTO A LOT OF PROBLEMS
IN TRYING TO PUSH IT IN.
THERE WERE ISSUES WE RAN INTO WITH INCOMPATIBILITY
OF VERSIONS OF SOFTWARE.
AND WE HAD TO DEAL WITH THOSE ISSUES.
WE DID GET PAST THEM, AND WE DID GET THE MPI WORKING.
WE DO NOT HAVE A LOADER FOR THE MPI IN PLACE.
THAT'S GOING TO COME OUT WITH 2.2
WHERE YOU'LL BE ABLE TO DO A MASSIVE LOAD OF AN MPI.
WE RECOGNIZE THAT'S AN IMPORTANT CAPABILITY
THAT NEEDS TO BE THERE IF IT'S GOING TO BE USED.
AND THERE ARE A NUMBER OF ISSUES THAT WE'VE WORKED WITH SUN ON,
AND I HAVE TO PUT MY HAT OFF TO SUN.
THEY'VE BEEN FAIRLY RESPONSIVE TO US IN WORKING WITH US,
AND AT ONE POINT IN TIME, WE ACTUALLY HAD SOME OF THEIR--
A GOOD SIGNIFICANT NUMBER OF THEIR DEVELOPERS
THAT ALL FLEW IN TO D.C. AND WE HAD SOME MEETINGS WITH THEM
TO WORK OUT SOME ISSUES,
AND THE MPI IS AN EXAMPLE OF THEM WORKING WITH US
AND WORKING THROUGH SOME OF THESE ISSUES
TO GET IT TO RUN IN OUR ENVIRONMENT.
WE USED AS A REPOSITORY--
THERE ARE A COUPLE OUT THERE.
WE CHOSE THE NIST ONE, WHICH IS BASED ON OMAR.
IT'S AN OPEN SOURCE REPOSITORY.
WE WERE ABLE TO PLUG THAT IN AND GET THAT TO RUN,
BUT AGAIN, IT HAD SOME ISSUES THAT WE RAN INTO
IN SOME OF THE PLATFORM TOOLS THAT IT RAN ON.
IT RAN ON POSTGRES, IT RAN ON AXIS.
THERE WERE JUST A NUMBER OF ISSUES,
AND SO IT WASN'T CONDUCIVE TO THE STACK WE WERE USING,
BUT WE DID GET IT TO RUN AND PLUG IN,
AND YOU CAN GET IT, PULL IT DOWN AND GET IT TO PLUG IN,
BUT YOU'D HAVE TO RUN IT ON A DIFFERENT PLATFORM.
AND SO THERE ARE SOME ITEMS THERE
THAT WE PLAN TO MOVE FORWARD WITH 2.2
TO MAKE SOME CHANGES ALONG THOSE LINES.
THE POLICY ENGINE-- WE USED 2 POLICY ENGINES,
AND BOTH OF THEM WE'LL HAVE FUNCTIONAL FOR 2.1.
OpenSSO IS A POLICY ENGINE,
AND IN THE OpenSSO RIGHT NOW,
IN ORDER TO PROCESS XACML MESSAGES,
YOU HAVE TO WRITE A JAVA PROCESSOR,
REQUEST HANDLER THAT YOU PLUG INTO OpenSSO.
AND SO, IF YOU GO DOWN THE ROAD OF OpenSSO,
YOU'LL HAVE TO WRITE A REQUEST HANDLER TO PROCESS YOUR POLICY RULES.
IN THE CASE OF JERICHO, BOTH OpenSSO AND JERICHO
DID A DEMONSTRATION AT THE HIMSS CONFERENCE
A COUPLE OF MONTHS AGO OF A POLICY-ENGINE APPROACH
USING CONNECT,
AND JERICHO USES A XACML POLICY RULES ENGINE,
AND SO WE WORKED WITH JERICHO,
AND JUST AS AN ASIDE ON THAT,
IT WAS REALLY SLICK.
WE CODED UP AGAINST OpenSSO, GOT ALL THAT WORKING,
AND IN A MATTER OF A DAY, WE SWITCHED THE URL
TO TALK TO THE JERICHO PDP,
AND THEY HAD ALREADY PUT TOGETHER A RULES--
POLICY RULES THAT MATCHED OUR POLICY,
AND WE WERE ABLE TO COMPLETELY-- IT WAS TRANSPARENT.
WE SWITCHED OVER TO JERICHO OR BACKED OpenSSO TRANSPARENTLY.
AND AS PART OF THE 2.1 RELEASE,
JERICHO HAS DECIDED TO PUT A BINARY FORM OF JERICHO
IN THE PUBLIC DOMAIN, BASICALLY,
AS A DOWNLOAD ON THE CONNECT WEBSITE.
SO YOU'LL BE ABLE TO TAKE YOUR PICK OF WHETHER OpenSSO OR JERICHO.
THE AUDIT REPOSITORY REALLY DIDN'T CHANGE MUCH
BETWEEN 2.0 AND 2.1.
WE ALREADY HAD A DATABASE IMPLEMENTATION OF IT
THAT USED MySQL,
SO THAT IS THE IMPLEMENTATION THAT WE'RE USING IN 2.1.
THE DEVELOPMENT ENVIRONMENT FOR VERSION 2.1--
WE MADE THE MOVE TO GET OFF A NIGHTLY BUILD.
WE REALLY WANTED TO BE ON A MORE STABLE RELEASE
FOR A NUMBER OF REASONS THAT WE RAN INTO,
AND SO WE'VE MOVED TO THE LATEST COPY AT THAT TIME
OF THE JDK, WHICH IS 1.6 UPDATE 13 BUILD 3.
WE WENT TO GLASSFISH ESB VERSION 2.1,
WHICH IS THEIR LATEST STABLE RELEASE,
AND WE'RE USING NETBEANS FROM THAT.
METRO 1-4 STAYED THE SAME.
MySQL AND soapUI STAYED THE SAME.
THE NEXT COUPLE OF SLIDES TALK ABOUT A DIRECTION
THAT WE HAVE STARTED IN VERSION 2.1
THAT WE'RE GOING TO MOVE FORWARD WITH IN 2.2 AS WELL.
ONE OF THE DRIVING FACTORS UNDER 1.0 AND 2.0 THAT WE HAD
WAS A NEED TO USE BPEL
TO ORCHESTRATE OUR WEB SERVICE COMPONENTS.
THERE WERE A NUMBER OF PERCEIVED BENEFITS
THAT WE THOUGHT WE WOULD GET FROM DOING SO.
WE ALSO THOUGHT THAT WAS GOING TO BE THE WAY
THAT AGENCIES WOULD BE ABLE TO CONFIGURE AND CUSTOMIZE.
THAT THEY WOULD SIMPLY TAKE
A BUNCH OF WEB SERVICE COMPONENTS
AND REORGANIZE AND REPACKAGE
AND THAT GAVE CONFIGURABILITY AND CUSTOMIZABILITY.
WHAT WE FOUND, WHEN WE WENT TO 2.0,
A NUMBER OF THINGS REALLY HAPPENED TO US
WHEN WE REALLY LAID OUT THE ARCHITECTURE THE WAY WE REALLY WANTED IT TO BE.
IT BECAME VERY SLOW.
THE MEMORY FOOTPRINT BECAME A MAJOR ISSUE FOR US.
IN FACT, THAT'S WHY IN 2.0 YOU HAD TO HAVE
BOTH A GATEWAY AND ADAPTER RUNNING ON A SEPARATE MACHINE.
BUT PREVIOUS TO THAT, WE HAD THEM ALL RUNNING ON THE SAME MACHINE.
I DON'T NEED--I'M NOT PLANNING TO GO THROUGH ALL THE DETAILS
OF WHAT HAPPENED, BUT WE DETERMINED
THAT THE BENEFITS THAT WE HAD FOR USING AN ENTERPRISE SERVICE BUS
REALLY WEREN'T GIVING US WHAT WE NEEDED.
AND PROBABLY THE BIGGEST ONE THAT WE DID NOT GET OUT OF IT
IS THE NORMALIZED MESSAGE ROUTER.
THAT WAS THE ITEM THAT WAS GOING TO GIVE US
THE MOST PERFORMANCE HIT FOR OUR MONEY
IS THAT BY HAVING THE NORMALIZED MESSAGE ROUTER
AND USING WEB SERVICES THROUGH THERE,
IT WOULD OPTIMIZE THOSE WEB SERVICE CALLS, THOSE soap CALLS
SO THAT WE HAD FAST PERFORMANCE.
THE REALITY WE RAN INTO IS THAT IN ORDER
TO GET EVERYTHING TO RUN THROUGH THE NMR,
WE SACRIFICED DYNAMIC--
THE ABILITY TO DYNAMICALLY CONFIGURE WHICH WEB SERVICES
WE WANTED TO SWAP IN OR SWAP OUT.
AND IT BECAME A VERY BIG PROBLEM TO US.
WE HAD TO DECIDE THOSE AT COMPILE TIME,
WHICH MEANT NOTHING COULD USE THE NMR
BECAUSE AT COMPILE TIME, WE HAD TO BE COMPLETELY CONFIGURABLE.
AND SO WE RAN INTO A NUMBER OF THOSE ISSUES.
SO AS WE WENT FORWARD WITH 2.1
AND WE'VE STARTED THIS PROCESS WITH 2.1,
WE'VE STARTED MOVING EVERYTHING TO A MORE PURE J2EE APPROACH,
A MORE PURE ENTERPRISE JAVA BEAN APPROACH.
WE'VE ADDED SPRING FRAMEWORK TO THE MIX,
AND WHAT THIS DID FOR US-- THIS WAS REALLY COOL FOR US.
WHAT WE WERE ABLE TO DO IS TO GET BACK TO
A PURE DYNAMIC DECISION ON WHETHER I USE A WEB SERVICE
OR WHETHER I USE A STRAIGHT JAVA CALL
AND HAVE IT PURELY DYNAMIC AT RUNTIME,
NOT HAVE TO MAKE THAT DECISION AT ALL AT COMPILE TIME.
BASICALLY, WE CREATED AN IMPLEMENTATION OF A WEB SERVICE,
AN IMPLEMENTATION ON JAVA, AND AT RUNTIME,
WE CAN CONFIGURE THROUGH A CONFIGURATION FILE WHICH ONE WE CALL,
AND SO WE COULD EASILY SWAP IN,
AND WE SAW MAJOR PERFORMANCE IMPROVEMENTS
MOVING THAT DIRECTION.
THE OTHER THING THAT THIS ALLOWED US TO DO--
WE FOUND A NUMBER OF ISSUES WITH BPEL,
COMPLEXITIES OF BPEL.
ONCE WE HIT CERTAIN COMPLEXITY LEVELS,
THE BPEL JUST DIDN'T WORK FOR US.
IT BECAME MORE COMPLEX TO TRY TO DO IT IN BPEL.
AND BY MOVING THEM TO JAVA,
WE GOT ALL OF THAT BACK AND THEN SOME,
AND SO THAT'S OUR APPROACH.
YOU WILL STILL SEE A LOT OF BPELs
IN 2.1 AND 2.0 A LOT THERE,
BUT WE ARE MOVING FORWARD AS WE'RE DEVELOPING NEW SERVICES
WITH THIS COMPONENT PROXY APPROACH.
AND AS WE HAVE OPPORTUNITY TO REWRITE ONE OF THE BPELs,
WE'VE BEEN DOING THAT AS WE GO.
WE HAD HOPE TO GET MOST OF THEM REWRITTEN IN THE LAST RELEASE,
BUT SOME OF THE PROBLEMS WE RAN INTO
WITH THE ENTERPRISE CLASS COMPONENTS SLOWED US WAY DOWN.
TRYING TO SOLVE THOSE PROBLEMS,
WE DIDN'T GET AS MANY OF THEM REDONE AS WE WANTED TO.
BUT THAT'S THE DIRECTION WE'RE HEADING.
AND FINALLY, THIS IS THE LAST SLIDE HERE.
THE CONNECT 2.2 ROAD MAP--
WHAT'S OUR PLAN FOR THE NEXT RELEASE?
AS WE START THAT IN A WEEK, WE'LL FINISH UP OUR 2.1.
THAT'LL BE LAUNCHED.
2.2--THERE ARE SOME SECURITY ENHANCEMENTS WE'RE PLANNING TO DO.
I BELIEVE THAT INCLUDES THE SAML ALL THE WAY THROUGH.
PUSHING SAML--
I'M SEEING THE NOD FROM OUR PROGRAM MANAGER.
SO THE SAML--SO THAT WE CAN IMPLEMENT SAML ALL THE WAY THROUGH.
THE HIEM PROFILE--
AS I MENTIONED, WE'VE ALREADY IMPLEMENTED THE ABILITY
TO SUPPORT WS TOPIC IN THE HIEM SERVICES LAYER.
WE'LL BE ADDING A NEW TOPIC THE CDC GYPSY
SO THAT WE CAN HANDLE THAT.
THE ENTERPRISE SERVICE COMPONENTS--
WE'VE GOT ANOTHER OPTION FOR US, AN ORGANIZATION
THAT HAS TAKEN THE NIST REPOSITORY
AND PUT IT ALREADY ON THE PLATFORM
THAT WE CURRENTLY ARE SET UP WITH WITH GLASSFISH,
AND SO WE'RE GOING TO MAKE A DECISION--
WE'RE GOING TO LOOK AT THAT AND SEE IF WE CAN PLUG THAT ONE IN
AS OUR OPEN SOURCE REPOSITORY
AND GET IT TO ITS--SO THAT IT RUNS ON THIS PLATFORM.
THE MPI--WE'RE GOING TO ADD IN SOME ENHANCEMENTS,
INCLUDING THE MPI LOADER.
A FINE GRAIN POLICY ENGINE--
ONE OF THE THINGS WE WANTED TO DO IN THIS 2.1 RELEASE
IS TO GET TO THE POINT WHERE WE COULD--
AS YOU SAW IN SOME OF THE DISCUSSIONS EARLIER TODAY,
TO GET TO THE POINT WHERE WE COULD ACTUALLY SPECIFY--
MISS WADE TALKED ABOUT THE ISSUE
OF HER HUSBAND'S PSYCHIATRIC RESULTS OF 4 YEARS AGO
NOT REALLY BEING ACCESSIBLE TO AN ORGANIZATION
OR A PERSON THAT DIDN'T REALLY HAVE A NEED TO SEE THOSE.
IT'S THAT LEVEL OF GRANULARITY WE WANT TO GET TO ON POLICY ENGINE,
TO BE ABLE TO SAY, "I'LL LET THESE KINDS OF PEOPLE
"WITH THESE KINDS OF ROLES SEE PHARMACY DATA,
BUT NOT MY LAB WORK OR NOT MY PSYCHIATRIC DATA."
SO TO BE ABLE TO SPECIFY AND TO GET TO A MORE FINE-GRAIN APPROACH.
NOW, THAT IN ITSELF HAS POTENTIAL ISSUES
WHEN YOU'RE DEALING WITH DOCUMENTS,
AND IT HAS ISSUES FOR THE ADAPTER LAYER,
BECAUSE EVEN THOUGH YOU SPECIFY THAT YOU CAN'T SEE IT,
THE ADAPTERS ARE GOING TO HAVE TO BE ABLE TO WORK THOSE ISSUES OUT
AND TAKE THE DATA OUT THAT THEY'RE NOT SUPPOSED TO SEND OUT, ET CETERA.
THERE'S A NUMBER OF ISSUES THAT STILL NEED TO BE WORKED OUT WITH THAT.
AND THEN FINALLY, UNIVERSAL CLIENT.
THE UNIVERSAL CLIENT-- AS WE MOVE FORWARD,
THERE ARE A NUMBER OF ITEMS ON THE UNIVERSAL CLIENT
THAT WE KNOW WE GOT TO DO RIGHT AWAY.
SOME OF THE CONFIGURATIONS--
SIMPLIFY SOME OF THE CONFIGURATIONS,
SOME OF THE PROPERTY FILES THAT NEED TO BE MANAGED
AND BE ABLE TO LAY SOME OF THAT GROUNDWORK
OF CONFIGURATION AND SET-UP,
BU ALSO TO SET UP A PORTLET ENVIRONMENT
BY WHICH WE CAN PLUG IN PORTLETS AND WE CAN CREATE AN ENVIRONMENT
BY WHICH WE CAN START BUILDING OUT A UNIVERSAL CLIENT
AND HAVE AN ABILITY TO PLUG IN COMPONENTS
AND START MOVING FORWARD.
IT GIVES THE VENDOR COMMUNITY THE ABILITY TO START MOVING FORWARD
IN CREATING MORE CUSTOMIZED COMPONENTS,
AND IT STARTS TO BUILD OUT THAT FRAMEWORK.
WITH THAT SAID, I THINK WE'LL GO AHEAD AND OPEN IT UP FOR QUESTIONS.
AND YOU CAN DIRECT QUESTIONS TO EITHER ONE OF US,
AND I DO WANT TO ACKNOWLEDGE--
I THINK WE HAVE SOME OF THE DEVELOPMENT TEAM HERE.
I WANT TO ACKNOWLEDGE THAT THIS IS A TEAM EFFORT
AND A VERY LARGE TEAM BETWEEN FHA, ONC,
HARRIS, AGILEX.
JUST A NUMBER OF VENDORS, NUMBER OF ORGANIZATIONS
THAT HAVE ALL COME TOGETHER TO DO THIS,
AND AGAIN, THIS IS A GREAT TEAM EFFORT,
AND IT'S BEEN A FUN PROJECT TO BE INVOLVED WITH.
AND WITH THAT, WE'LL GO AHEAD AND TAKE QUESTIONS.
GOOD AFTERNOON. MY NAME'S ALESHA ADAMSON.
I'M THE DIRECTOR OF OPEN SOURCE SOLUTIONS FOR MISYS.
I HAVE 3 QUESTIONS, AND SINCE NOBODY ELSE IS STANDING UP,
I WILL ASK THEM ALL.
MY FIRST QUESTION IS ABOUT DROPPING CODE BOMBS,
AND IF YOU'RE NOT FAMILIAR WITH THAT TERMINOLOGY,
IN OPEN SOURCE, IT'S THE IDEA THAT YOU DROP A CODE BOMB
AND SAY, "TA-DA, WE WROTE SOME CODE, AND IT'S OPEN SOURCE."
I'D LIKE TO HEAR MORE ABOUT YOUR INITIATIVE'S ENDEAVOR
TO ACTUALLY DEVELOP AN OPEN SOURCE,
OPEN IT UP TO THE FORGE
AND HOW YOUR STRATEGY FOR AGILE DEVELOPMENT WILL WORK WITH THAT.
WHO'S YOUR PROJECT DONOR?
HOW ARE YOU GONNA DO YOUR PROJECT PLANNING, YOUR ITERATIONS,
YOUR PRIORITIZATION IN AN OPEN SOURCE ENVIRONMENT?
MAYBE I CAN ADD--AT LEAST START OFF AN ANSWER TO THAT.
ONE OF THE THINGS
THAT WAS REALLY IMPORTANT TO THE FEDERAL AGENCIES
WHEN WE GOT STARTED WITH DEVELOPING CONNECT
WAS THAT THE SOLUTION BEING RELEASED INTO THE COMMUNITY
IS OPEN SOURCE AND AS CODE BOMBS,
AND WHAT YOU'VE HEARD LES TALK ABOUT A LITTLE BIT
IS THE PLANNED RELEASE STRUCTURE FOR CONNECT AS WE MOVE FORWARD.
ONE OF THE THINGS THAT I RECOMMEND, AND WHAT I'LL SAY
IS THAT FHA AND ONC REMAIN COMMITTED
TO MAKING SURE THAT CONNECT IS AVAILABLE TO COMMUNITIES
TO USE UNDER A NON-VIRAL LICENSE SO THEY CAN MOVE THINGS FORWARD.
WHAT I'D RECOMMEND IS MAKE SURE THAT YOU CATCH
WHAT I BELIEVE IS THE LAST PLENARY SESSION TOMORROW
WHERE WE'LL TALK A LITTLE BIT MORE ABOUT
THOUGHTS THAT WE HAVE INTERNALLY ABOUT MOVING FROM THIS
OPEN-SOURCE RELEASE STRUCTURE
TO MORE OF AN OPEN-SOURCE COMMUNITY ENVIRONMENT,
AND IT'S A LOT OF DISCUSSIONS THAT ARE GOING ON INTERNALLY.
I WISH I COULD TELL YOU EXACTLY WHAT IT WAS GOING TO LOOK LIKE,
AND I CAN'T RIGHT NOW--
Adamson: IT'S GOOD TO KNOW THAT Y'ALL ARE THINKING ABOUT IT.
THERE IS A DESIRE TO MOVE IN THAT DIRECTION.
AND LET ME ADD ONE THING TO THAT.
WE RECOGNIZED THE NEED FIRST TO GET SOMETHING OUT THE DOOR,
AND MY EXPERIENCE HAS BEEN
IF YOU WAIT TILL YOU HAVE A PERFECT PRODUCT
BEFORE YOU TELL ANYBODY ABOUT IT, YOU MIGHT AS WELL NOT START.
AND SO, YOU KNOW, THERE ARE LOTS OF ISSUES,
AND I'M SURE AS MORE OF YOU PULL THE SOFTWARE DOWN
AND START PLAYING WITH IT AND USING IT,
YOU'RE GOING TO COME UP WITH QUESTIONS, ISSUES
THAT YOU'RE GOING TO RUN INTO, AND IT'S NOT GOING TO SURPRISE ME
BECAUSE THE IDEA HERE WAS GET SOMETHING OUT THE DOOR
AND THE MORE PEOPLE THAT PLAY WITH IT THE MORE OFTEN,
THE BETTER AND THE FASTER WE CAN GET THERE,
BUT YOU HAVE TO HAVE SOMETHING TO START WITH, AND SO THAT'S WHAT WE HAVE.
I THINK THE COOL PART THAT COULD BE MISSING IS THAT WE ARE DOWNLOADING IT,
WE ARE PLAYING WITH IT, WE'RE INSTANTIATING IT,
AND WOULDN'T YOU LIKE TO KNOW WHAT WE'RE FINDING OUT ABOUT IT?
THAT'S PART OF DEVELOPING THE ECOSYSTEM,
SO I APPRECIATE THAT.
I HAVE ONE MORE QUESTION ABOUT-- YOU HAD INDICATED THAT THERE WERE 4 PARAMETERS
THAT YOU USED IN YOUR MPI. DO YOU HAVE NUMBERS ON THAT?
DID YOU WRITE A PAPER OR LITTLE BLURB--
TONY, DID THE PAPER GET WRITTEN ON IT?
YES. IN FACT, WE FOUND IT WAS SLIGHTLY DIFFERENT
WHEN WE CAME TO REAL PRACTICE.
ORIGINALLY, A LOT OF THIS EXPERIENCE
CAME FROM THE VA/DOD SHARING,
BUT WE WERE INVOLVED WITH
SOCIAL SECURITY NUMBER AND THOSE MATCHING,
AND THAT'S DISAPPEARED,
SO WHAT ACTUALLY HAPPENS NOW
IS THAT YOU NEED MORE THAN THOSE 4.
YOU NEED THE NAME. YOU PREFERABLY NEED--
IT'S ACTUALLY A GIVEN, AND THERE'S THE OTHER ONE.
THERE ARE 2 TYPES OF NAMES HERE.
Adamson: SURNAME?
NO, IT'S NOT SURNAME, NO. THERE'S A FAMILY NAME AND GIVEN NAME.
AND YOU CAN HAVE AS MANY GIVEN NAMES AS YOU LIKE.
THE MORE, THE BETTER.
AND IN FACT, WHAT THE SPEC CALLS FOR
IS AS MUCH AS YOU CAN IN THE NAME.
YOU NEED GENDER, DATE OF BIRTH,
AND IF YOU HAVE ADDRESS AND YOU HAVE TELEPHONE NUMBER,
YOU SHOULD SEND THEM.
AND THE SPEC CALLS FOR THAT.
SO THE SPEC CALLS FOR IF YOU HAVE THAT INFORMATION, YOU NEED IT.
WHEN WE DID THE FIRST ANALYSIS OF THAT
WITHOUT THE SOCIAL SECURITY NUMBER,
IT WAS NOT GONNA GET A MATCH,
BASED ON WHAT WE'RE USING,
WHICH IS PROBABILISTIC MATCHING--
Adamson: AND THAT'S AN NHIN SPECIFICATION
THAT YOU'RE TALKING ABOUT, AND THAT'S PUBLISHED?
YEAH, THE SUBJECT DISCOVERY SPECIFICATION
CALLS OUT WHAT YOU MUST SEND
AND WHAT YOU SHOULD SEND IF YOU HAVE IT.
OK. THANK YOU VERY MUCH FOR YOUR WORK.
[MAN, INDISTINCT]
LET ME REPEAT WHAT HE SAID SO YOU ALL HEAR THAT.
THE MAIN THING TO BE AWARE OF,
AND IT'S GOOD TO UNDERSTAND THIS ABOUT CONNECT, IN GENERAL,
NOT JUST ON THIS PRINCIPLE,
BUT WE REALLY ARE AGNOSTIC ON A LOT OF THESE ISSUES,
AND SO WE PROVIDE THE MECHANISM
BY WHICH YOU DO THE MATCH, BUT WE DON'T SPECIFY
THE CRITERIA BY WHICH YOU DO THE MATCH.
THAT'S UP TO YOU.
THERE ARE OTHER AREAS OF CONNECT THAT FALL IN THE SAME CATEGORY.
AN EXAMPLE OF THAT OF WOULD BE DOCUMENTS.
WHAT KIND OF DOCUMENTS ARE SENT? WE DON'T REALLY CARE
AS FAR AS CONNECT IMPLEMENTATION IS CONCERNED.
WE SEND A PAYLOAD OF THE DOCUMENT.
WHAT'S IN THAT PAYLOAD IS REALLY UP TO YOU.
NHIN RIGHT NOW IS SPECIFYING SOME OF THOSE PAYLOADS,
BUT CONNECT IS AN IMPLEMENTATION.
WE DON'T SPECIFY IT'S A PAYLOAD TO US.
SO THAT'S ANOTHER EXAMPLE OF THAT. GO AHEAD.
HI. TOM DAVIDSON WITH SSA.
I'VE GOT A QUESTION WITH REGARDS TO
WHAT SERVICES ARE AVAILABLE IN YOUR PASS-THROUGH MODE IN VERSION 2.
ARE YOU STILL DOING THE SAML TOKEN CREATION AND DIGITAL SIGNATURES?
WHAT HAPPENS TO AUDITING, OR DOES THAT COMPLETELY GO AWAY
AND THAT BECOMES THE ONUS OF THE ADAPTER
WHO'S INVOKING THAT NEW PASS-THROUGH MODE TO DEAL WITH ALL THAT NOW?
YEAH. THAT'S BEEN A QUESTION THAT HAS COME UP,
AND I'M GONNA SAY THE WRONG ANSWER, I'M SURE,
BECAUSE WE'VE GONE BACK AND FORTH ON THIS.
THE INTENT OF THE PASS-THROUGH MODE IS SIMPLY PASS THROUGH.
WE DON'T DO ANY ORCHESTRATION,
BUT I BELIEVE THAT--AND, JASON, CAN YOU CORRECT ME?
I BELIEVE THAT WE DO SOME LOGGING RIGHT NOW?
[JASON, INDISTINCT]
YOU CAN'T REMEMBER, EITHER.
I HAVE TO GO BACK IN THE CODE AND FIND THAT,
BUT I BELIEVE THAT WAS OUR INTENT IN PASS-THROUGH MODE
WAS THAT IT WAS COMPLETELY UP TO YOU.
OK, AND THE ONE OTHER PART--
[COTHREN, INDISTINCT]
RIM DID A LOT OF OUR SEQUENCE DIAGRAMS,
AND ASKED US A BUNCH OF QUESTIONS OVER THE PAST DEVELOPMENT RELEASE,
AND WHAT HE REMEMBERS IS THAT WE DO PASS THROUGH
ON THE OUTGOING, BUT NOT ON THE INCOMING,
BUT I WOULDN'T RELY ON THAT.
AT THIS POINT, ASSUME THAT ORCHESTRATION,
IF YOU TURN IT OFF, IT'S YOUR BABY, BASICALLY.
Davidson: AND WITH REGARDS TO THE SAML TOKEN CREATION,
IS IT POSSIBLE TO REPLACE THAT MECHANISM
IN ITS ENTIRETY?
RIGHT NOW, WITH THE NEWER API,
THERE'S STILL A SUBSET OF INFORMATION FOR YOU TO CREATE THE SAML TOKEN
OR FOR THE CONNECT GATEWAY TO CREATE THE SAML TOKEN--
- RIGHT NOW, THAT'S NOT... - ...REPLACE ALL OF THAT.
YEAH, RIGHT NOW, THAT'S NOT REPLACEABLE AT THIS POINT.
WE DIDN'T ANTICIPATE THAT TO BE A REPLACEABLE COMPONENT,
BUT OBVIOUSLY WITH OPEN SOURCE, YOU CAN DO WHATEVER YOU WANT
AT WHATEVER LAYER YOU WANT.
BUT ONE OF THE PROBLEMS THAT WE RAN INTO
WITH THE OPEN ESB THAT WE HAD TO DEAL WITH
AND WHY IT TOOK US SO LONG TO BE ABLE TO SOLVE
SOME OF THESE ISSUES WAS SAML-RELATED,
AND WE ACTUALLY HAD TO PUT A WEB SERVICE,
AN EJB WEB SERVICE,
ON THE FRONT FOR ALL NHIN SERVICES,
ONE PER NHIN SERVICE,
TO PICK UP THE SAML INFORMATION AND PROCESS THE SAML,
BECAUSE WE COULDN'T GET IT ALL THE WAY THROUGH THE BPEL,
AND SO WE HAD TO PICK UP SO THAT WE COULD PASS IT ON.
AND SO, RIGHT NOW, THAT SAML IS HAPPENING AT THAT LAYER,
SO YOU COULD REPLACE THAT,
BUT IT'S NOT ONE THAT WE HAD ANTICIPATED BEING REPLACED.
Davidson: AND THEN ONE LAST THING.
I KNOW FOR A FACT THAT SPEC FACTORY'S
CONSIDERING THE ADOPTION OF ASYNCHRONOUS-BASED WEB SERVICES.
I'M CURIOUS TO KNOW WHAT YOU THINK THE IMPACT ON YOUR ORCHESTRATION MODEL
IS GONNA BE GIVEN THE BROADCAST MECHANISM.
I DON'T HAVE AN ANSWER FOR THAT RIGHT NOW.
IN SOME CASES, WE HAVE ASYNCHRONOUS
FROM A STANDPOINT ON THE SUBJECT DISCOVERY.
IN A SENSE, THAT'S ASYNCHRONOUS.
BUT I DON'T HAVE AN ANSWER. WE'RE GONNA HAVE TO DEAL WITH THAT ISSUE.
CAN WE DO IT? YEAH, BUT I DON'T HAVE AN ANSWER.
HI. PAM WATERS, SOCIAL SECURITY.
THAT WAS KIND OF MY QUESTION AS WELL.
GIVEN THE EXAMPLE THAT YOU HAD WITH THE BROADCAST
USING EVERY ENTRY IN THE UDDI CACHE,
IF--IS THAT ASSUMING THAT EVERYBODY THAT'S IN THE UDDI REGISTRY
HAS A SIGNED DURSA?
BECAUSE OTHERWISE, YOU'RE BROADCASTING OUT TO ALL THESE ENTITIES,
AND THEN IT'S UP TO THEIR POLICY WHETHER THEY ANSWER YOU OR NOT,
AND COMING FROM AN AGENCY THAT IS NOT A RESPONDER, IS ALWAYS A REQUESTOR,
WE HAVE THE POTENTIAL TO GET SPAMMED, BASICALLY.
THAT'S MY UNDERSTANDING. RIM, YOU CAN CORRECT ME.
IT'S MY UNDERSTANDING YOU WILL NOT BE IN THE UDDI UNLESS YOU'VE SIGNED A DURSA
AND YOU'VE AGREED WITH ALL THE TERMS
APPROPRIATE TO GET INTO THE UDDI.
THAT'S PART OF WHAT DAVE RILEY HAD TALKED ABOUT
IN HIS PRESENTATION,
SO THE FIRST ANSWER IS, YES, YOU HAVE TO HAVE QUALIFIED
FOR ALL OF THAT IN ORDER TO EVEN GET INTO THE UDDI.
Waters: BUT IS THERE ANY WAY TO PREVENT THAT
OR TO DEFINE THE SERVICES, BECAUSE WE'LL BE IN THERE FOR SUBJECT DISCOVERY,
EVEN THOUGH WE'RE NOT A RESPONDING GATEWAY IN THE 201/302 SCENARIO,
SO THE WEB SERVICE NAME AND THE ENDPOINT IS THE SAME FOR SUBJECT DISCOVERY,
ALTHOUGH WE'RE NOT GONNA BE A RESPONDING GATEWAY.
ANYBODY THAT DOES A BROADCAST, WE'RE GONNA GET SPAMMED,
AND THERE'S NO WAY TO DISABLE THAT.
ONE THING THAT YOU CAN DO ON CONNECT
IS YOU CAN, THROUGH A PROPERTY SETTING ON CONNECT,
YOU CAN TURN OFF AT THAT HIGHEST LAYER
THAT WE'RE NOT ORCHESTRATING THOSE MESSAGES,
SO THAT'S ONE THING WE'VE DONE WITH CONNECT IS MESSAGE BY MESSAGE,
YOU CAN TURN A FLAG ON THAT SAYS, "I SUPPORT THIS MESSAGE,"
OR, "I DON'T SUPPORT THIS MESSAGE."
IT WON'T GET PAST THAT FIRST LAYER IF SOMEONE WAS TRYING TO SPAM YOU
IS YOU TURN THAT SWITCH OFF, AND IT'LL STOP DEAD AT THAT POINT.
IT WON'T GO ANY FURTHER.
Waters: THE OTHER QUICK QUESTION IS,
WHEN DO YOU THAT THE DATE RANGE FEATURE WILL BE IMPLEMENTED
FOR WHEN YOU REQUEST MEDICAL RECORDS
THAT YOU CAN SPECIFY A DATE RANGE?
AS FAR AS CONNECT IS CONCERNED,
WE HAVE THE ABILITY TO SEND THE DATA THROUGH.
THE DOCUMENT QUERY PARAMETERS ALLOW FOR IT,
AND IT'S ONE OF THOSE SIMILAR CASES WHERE WE'RE AGNOSTIC
TO WHAT YOU SEND IN THE PAYLOAD.
WE DON'T CARE WHAT YOU SEND IN THE QUERY.
IT'S WHETHER THE RECEIVING SYSTEM HAS THE ABILITY
TO PROCESS THAT, AND MANY OF THOSE CAN RIGHT NOW.
Waters: AND WHAT IT REALLY MEANS--THE DATES OF SERVICE...
YEAH, AND I'M NOT SURE AT THIS POINT--
DO YOU KNOW WHETHER NHIN'S GOING TO MAKE A DECISION ON--
OR TAKE A STAND ON WHICH--
'CAUSE IN THE NHIN SPEC, THERE ARE MULTIPLE CRITERIA.
THERE'S--I DON'T REMEMBER THE EXACT NAME,
BUT THERE ARE START AND STOP DATES FOR, LIKE,
THE PROCEDURE ITSELF OR THE ORDER ITSELF, ET CETERA.
THERE ARE MULTIPLE STARTS AND STOP DATES,
AND I DON'T KNOW IF ANYTHING'S BEEN DONE TO SPECIFY
WHICH START AND STOP DATES AND WHAT THEY MEAN.
- Cothren: I DON'T KNOW. - THANK YOU.
UH-HUH.
YEAH, BRETT PETERSON, CHIEF ARCHITECT AT VISIONSHARE.
IS THERE A CURRENT REQUIREMENT IN CONNECT
FOR A ONE-TO-ONE MAPPING BETWEEN GATEWAYS AND ADAPTERS,
OR IS THERE ANY POTENTIAL DEPLOYMENT TO DEPLOY--
OR DEPLOYMENT OPTION
TO PUT OUT MULTIPLE ADAPTERS, SAY ONE AT EACH HOSPITAL,
ALL SHARING A COMMON GATEWAY
AND WOULD THEN CONNECT HANDLE THE ROUTING ISSUES THERE?
WE ACTUALLY HAD THAT DISCUSSION, AND EARLY LAST YEAR,
WE HAD TALKED ABOUT THE NEED TO HAVE A MANY TO ONE,
MANY INSTITUTIONS-TO-ONE GATEWAY,
AND OVER TIME, WE DETERMINED THAT WAS MOST LIKELY
NOT GOING TO BE NECESSARY.
IT'S ALWAYS BEEN IN THE BACK OF OUR MINDS,
BUT WE HAVE NOT BUILT FOR THAT YET.
BECAUSE OF THE FACT THAT CONNECT WAS SO EASY
TO PUT THE GATEWAY ON THERE,
OUR INTENT, INITIALLY ANYWAY, IS THAT YOU'D BASICALLY
HAVE 2 INSTANCES OF CONNECT IN THOSE 2 ENVIRONMENTS,
SO RATHER THAN PUTTING ONE ON TOP TO MULTIPLE
OR YOU MIGHT HAVE ONE CONNECT GATEWAY ON FRONT
AND THEN HAVE MULTIPLE CONNECT GATEWAYS ON THE BACK,
SO INVERTING THE GATEWAYS,
SO THERE'S BEEN A NUMBER OF THINGS WE'VE TALKED ABOUT,
BUT NOT ANYTHING THAT'S BEEN DEFINED YET.
OK, THANKS.
DID YOU HAVE ANY MORE ON THAT?
HI. JULIAN KLEIN WITH PORTICO SYSTEMS.
I WAS CURIOUS IN REGARDS TO YOUR UTILIZATION MURAL
WHAT TESTING YOU'VE DONE FROM A LOAD TESTING PERSPECTIVE
AS WELL AS IF YOU COULD TALK TO A LITTLE BIT ABOUT
THE ARCHITECTURAL APPROACH TO ROUTING THE MURAL SERVICES
AND GETTING IT INSIDE CONNECT,
BECAUSE IT SEEMS THERE'S A STRONG EMPHASIS ON STANDARDS
AND TRYING TO GO WITH
SOMEWHAT OF A SERVICE-ORIENTED ARCHITECTURE.
SO YOU HAD MENTIONED EARLIER THERE ARE POSSIBLY OTHER SYSTEMS
THAT COULD BE PUT IN PLACE OF MURAL.
FOR EXAMPLE, I BELIEVE MIRTH
IS WORKING ON A MATCHING SYSTEM CALLED MIRTH MATCH,
SO, YEAH, AND THERE'S SOME OTHER ONES OUT THERE,
INCLUDING PROPRIETARY SYSTEMS, SO AGAIN,
METRICS AROUND LOAD TESTING-- HAVE YOU DONE ANYTHING LIKE THAT?
AND GENERALLY THE APPROACH TO WRAPPING THOSE SERVICES.
OK, SO THE FIRST QUESTION WAS ON THE LOAD TESTING--
WE HAVE NOT DONE A LOT OF LOAD TESTING.
OUR PRIMARY GOAL WAS TO PUSH IT IN AND GET IT TO FUNCTION,
SO THAT HAS BEEN OUR GOAL.
AND THAT'S THE PART THAT WE'VE BEEN WORKING ON.
AS FAR AS HOW TO WRAP IT,
IF YOU COME TO TOMORROW'S SESSION ON THE BUILDING AN ADAPTER,
WHICH WILL BE IN THE AFTERNOON TOMORROW,
WHAT WE'RE ACTUALLY GOING TO DO
IS VERY SIMILAR TO WHAT YOU WOULD DO WITH MURAL
IS YOU'RE GONNA BASICALLY TAKE AND CREATE AN ADAPTER
AT THAT ADAPTER SERVICE BUS LAYER.
YOU'RE GONNA IMPLEMENT AT OUR ADAPTER SERVICE BUS INTERFACE--
YOU'RE GONNA PUT THAT AROUND THE SYSTEM,
AND THAT'S WHAT WE DID FOR MURAL IS WE PUT THAT AROUND THE SYSTEM.
AND SO, FROM THE ADAPTER UP, ALL THROUGH THE GATEWAY,
YOU'VE GOT A SYSTEM THAT TALKS THE SAME,
NO MATTER WHAT SYSTEM WE PLUG IN,
AND BELOW THAT IS WHERE WE WRAP IT.
AND WHAT WE BASICALLY-- IN TOMORROW'S SESSION,
WE'RE GOING TO CREATE AN MPI, AND WE'RE GONNA PLUG IT IN
AND SHOW YOU HOW TO PLUG IT INTO THE ADAPTER
AND REPLACE IT THAT WAY.
Peterson: AND THERE'S A PLAN TO TALK ABOUT
THE DOMAIN MODEL THAT WAS USED AND HOW THAT RELATES
TO THE VARIOUS STANDARDS USED INSIDE,
PASSING DATA TO THE HIGHER-LEVEL SERVICES?
YEAH, WE'LL TALK ABOUT THAT TOMORROW.
ONE OTHER THING THAT WE WERE PLANNING ON THIS RELEASE ON 2.1--
WE WANT TO MAKE SURE THERE'S A CORE GATEWAY
AND THEN THERE'S ADD-ONS.
THE IDEA THAT EVERYBODY'S GONNA WANT MURAL
OR EVERYBODY'S GOING TO WANT A NIST REPOSITORY, ET CETERA,
IS NOT REALITY,
AND SO--AND THE FACT THAT--
ONE OF THE THINGS THAT IF HAVEN'T PICKED UP ON OR HEARD
AS DAVE AND THE REST OF THE TEAMS HAVE BEEN TALKING,
THE IDEA IS THAT THIS IS NOT A FEDERAL GOVERNMENT
TRYING TO BUILD A SYSTEM THAT EVERYBODY USES.
THIS IS CREATING AN ENVIRONMENT
BY WHICH A SYSTEM CAN BE BUILT UPON
BY PRIVATE, FEDERAL, ALL SORTS OF ORGANIZATIONS,
AND SO THE IDEA WHAT WE'VE DONE WITH THE RELEASE ON 2.1
IS YOU'LL BE ABLE TO DOWNLOAD THE CORE GATEWAY
WHICH HAS ALL THE MAIN GATEWAY FUNCTIONALITY,
BUT MURAL IS AN ADD-ON PLUG-IN.
THE NIST REPOSITORY IS A PLUG-IN.
THE POLICY ENGINES ARE PLUG-INS, AND THEY'RE SEPARATE DOWNLOADS,
SO YOU CAN DOWNLOAD THE CORE GATEWAY,
YOU CAN TEST IT ALL OUT WITHOUT THE PLUG-INS,
AND THEN IF YOU WANT TO PULL THE PLUG-IN DOWN FROM MURAL,
YOU CAN PULL THAT ONE DOWN, PLUG IT IN, AND USE THAT ONE.
AND THE IDEA THERE BEING, AS WE MOVE FORWARD,
THERE MAY BE PROPRIETARY PLUG-INS THAT ORGANIZATIONS WANT TO--
MAYBE THERE'S A COMMERCIAL MPI
THAT'S CAPABLE TO BE PLUGGED INTO CONNECT
THAT IS OUT THERE THAT SOMEBODY MAY WANT TO PICK UP.
WE'RE NOT TRYING TO PRECLUDE THAT.
AND SO THE WHOLE IDEA HERE IS TO ENCAPSULATE AND LAYER IT
SO THAT WE CAN HAVE PLUG-INS, WE CAN HAVE THAT CAPABILITY.
OK, GREAT. THANK YOU.
LES OPENED THE DOOR ON SOMETHING I THINK IS REALLY IMPORTANT.
THE GENERAL PHILOSOPHY WE'VE TAKEN WITH ENTERPRISE SERVICE COMPONENTS
IS AGAIN THE FEDERAL GOVERNMENT'S NOT TRYING TO GET INTO
THE SOFTWARE BUSINESS.
THAT THERE ARE OPEN-SOURCE SOLUTIONS OUT THERE,
MURAL PERHAPS BEING ONE,
MIRTH MATCH PERHAPS BEING ONE,
LOOKING AT MPIs IN PARTICULAR,
THAT ARE SEPARATE OPEN-SOURCE COMMUNITIES
AND PROJECTS THAT ARE DEVELOPING GOOD ENTERPRISE CLASS SOLUTIONS.
AND WHAT WE WANTED TO DO WAS START TO MEET THE NEED
OF ORGANIZATIONS THAT MIGHT NOT HAVE AN MPI TODAY
AND WANT TO GET STARTED,
WELL, HERE'S SOMETHING THAT WE'VE ALREADY INTERFACED,
BUT NOT TAKING OWNERSHIP FOR THAT COMPONENT,
SO MOST OF THE TIME, THAT'S WHAT YOU'D EXPECT.
AS WE MOVE MORE INTO AN OPEN-SOURCE COMMUNITY,
WE'RE EXPECTING THAT THE COMMUNITY
WILL MORE AND MORE ADD COMPONENTS LIKE THAT
TO THE CONNECT SOLUTION,
AND SO THERE MAY BE HALF A DOZEN DIFFERENT MPIs
THAT DIFFERENT ORGANIZATIONS HAVE ADDED,
PERHAPS SOME WE'VE ADDED AS WELL
TO MAKE SURE THERE ARE A VARIETY OF POTENTIAL SOLUTIONS.
RIGHT. WELL, THE REASON--
LET ME ADD ONE MORE THING TO THAT.
THE POLICY ENGINE IS A GOOD EXAMPLE OF THAT.
WE REALLY WEREN'T JUST GOING AFTER OpenSSO
JUST BECAUSE IT WAS ON THE STACK THAT WE HAD OR ET CETERA.
WHEN JERICHO CAME UP AND SAID, "WE'D LIKE TO BE PART OF THAT,"
WE FIGURED OUT HOW TO MAKE THAT WORK.
AND THE POINT THERE ON THE FACT THAT WE HAVE 2 IS TO SHOW
THAT WE REALLY DON'T CARE WHICH ONE THERE IS.
AGAIN, IT'S AN AGNOSTIC THING FOR US. WE DON'T CARE.
WE JUST WANTED TO SHOW THE ABILITY TO DO IT.
Peterson: RIGHT. MANY OF THESE COMPONENTS--
THERE ARE ALREADY STANDARDS AROUND HOW THEY OUTPUT DATA,
AND GENERALLY, THEIR APIs OR WHATEVER FORMAT
THEY INTERCHANGE INFORMATION WITH THE REST OF THE COMPONENTS,
BUT THINGS LIKE MURAL, FOR EXAMPLE,
THERE'S NOT NECESSARILY A STANDARD AROUND
THE INPUT OR OUTPUT INTO A SYSTEM LIKE THAT,
SO THAT'S REALLY THE DRIVING FORCE BEHIND MY QUESTIONS.
THANKS.
HI. THIS IS NITIN JAIN WITH IBM.
I WANTED TO UNDERSTAND MORE ABOUT THE RATIONALE
BEHIND CONNECT GATEWAY HOOKING DIRECTLY TO POLICY ENGINE
AND MPI.
IN OUR WORLD, SUPPORTING OTHER HIEs,
WE FEEL THAT THE HIE IS ALREADY TAKING CARE OF AUTHORIZATION
OR MANAGING THE MPI.
AND THE GATEWAY IS KIND OF LIKE A FACADE
OR FRONT LAYER IN FRONT OF THE HIE INFRASTRUCTURE.
SO NOW WE ARE SEEING A DIFFERENT PICTURE HERE
WHERE CONNECT OR THE NHIN GATEWAY
TRYING TO GAIN THAT RESPONSIBILITY
OF MANAGING THE AUTHORIZATION AND ALSO TRYING TO DO
THE MPI VALIDATIONS--
ALL THAT'S GOING TO THE THIRD-PARTY SOFTWARE
LIKE ANY OPEN SOURCE,
BUT THAT DECISION, WHETHER IT HAS A PERFECT MATCH OR NOT,
IT'S BEING DRIVEN BY THE CONNECT GATEWAY.
I JUST WANT TO UNDERSTAND FROM THAT
LIKE WHY DID YOU CHOOSE ON THAT?
RIGHT. YOU'RE ASKING AN IMPORTANT QUESTION,
AND IF YOU LOOK AT THE INITIAL RELEASES OF CONNECT,
YOU'LL SEE THOSE ENTERPRISE SERVICE COMPONENTS AREN'T THERE,
AND IT'S NOT BECAUSE THERE WASN'T TIME NECESSARILY.
IT'S BECAUSE, JUST AS YOU POINT OUT
THAT THE REAL RESPONSIBILITIES AND PRIORITIES
ASSOCIATED WITH CONNECT
WAS TO IMPLEMENT THE NHIN SERVICES
AND ALLOW AN ORGANIZATION TO CONNECT, OK?
THE WHOLE IDEA OF THE ENTERPRISE SERVICE COMPONENTS
ARE FOR THOSE ORGANIZATIONS
THAT ARE ACTUALLY MISSING WHAT ARE IMPORTANT COMPONENTS
THAT MAY NOT EXIST IN THEIR ENVIRONMENT ALREADY.
IN PARTICULAR, LET'S TAKE THE MPI AS AN EXAMPLE,
THERE IS A FEDERAL AGENCY THAT'S INTERESTED IN USING CONNECT
THAT DOESN'T HAVE AN MPI WITHIN THEIR ORGANIZATION NOW,
AND IT'S GONNA HAVE TO STAND ONE UP,
SO THE FIRST QUESTION BECAME,
IS THERE SOMETHING THAT CAN BE ATTACHED TO CONNECT
THAT WOULD MEET THAT NEED FOR US SO WE COULD GET THERE?
THE ANSWER IS, OF COURSE, YES, THERE IS.
THERE ARE ALREADY INTERFACES TO AN MPI
THAT ARE REQUIRED TO MOVE THINGS FORWARD
THROUGH THE ORCHESTRATION OF SUBJECT DISCOVERY,
SO OF COURSE THERE AS SOMETHING WE COULD GO AHEAD AND PLUG IN.
WE ENVISIONED THAT, MOST OF THE TIME, ORGANIZATIONS
ARE NOT GONNA MAKE USE OF THE ENTERPRISE SERVICE COMPONENTS,
BECAUSE, AS YOU POINT OUT,
THEY ALREADY ARE IMPLEMENTING POLICY INTERNALLY.
THEY'RE ALREADY IMPLEMENTING MPIs INTERNALLY.
THEY PROBABLY ALREADY HAVE THEIR HEALTH DATA REPOSITORY.
WHETHER IT IS XDS.b-COMPLIANT OR NOT,
BUT THEY PROBABLY ALREADY HAVE SOMETHING THERE.
SO THEY'RE NOT GONNA NECESSARILY HAVE A NEED
TO IMPLEMENT THE ENTERPRISE SERVICE COMPONENTS,
BUT THIS GIVES A MECHANISM FOR ORGANIZATIONS
THAT MAY NOT HAVE ALL OF THAT TO GET UP AND RUNNING
AND GRADUATE INTO A CIRCUMSTANCE
WHERE THEY MAY BE TAKING THAT RESPONSIBILITY THEMSELVES.
SO IN THOSE CASES, IF YOU HAVE AN MPI,
WE DON'T EXPECT YOU TO BE MAKING USE OF THE MURAL SYSTEM AT ALL.
INSTEAD, YOU'D BE INTERFACING CONNECT TO YOUR OWN EXISTING MPI
AND THAT THAT WOULD BE THE NORMAL CASE.
LET ME ADD TO THAT.
THAT'S THE WHOLE PURPOSE OF THAT ADAPTER LAYER.
THE ADAPTER LAYER IS NOT FOR US TO PROVIDE NECESSARILY
IMPLEMENTATIONS FOR EVERY ONE OF THOSE ADAPTER COMPONENTS.
THAT IS FULLY EXPECTED THAT THOSE ADAPTER COMPONENTS
ARE GOING TO BE IN THE REALM OF THE ORGANIZATION.
BUT IN ORDER TO ORCHESTRATE A MESSAGE THROUGH,
THERE ARE SOME THINGS THAT HAVE TO BE THERE.
FOR EXAMPLE, WE HAVE TO BE ABLE TO FIND OUT
WHETHER A PATIENT IS CORRELATED,
AND WE DON'T HAVE TO MAKE THE DECISION OF WHETHER THEY ARE OR NOT,
BUT ONCE THEY ARE,
WE NEED TO STORE THE CORRELATION INFORMATION
BECAUSE IN ORDER FOR US TO ORCHESTRATE A MESSAGE BACK OUT FOR DOCUMENT QUERY,
WE NEED TO KNOW WHERE THE PATIENT HAS BEEN CORRELATED AT.
AND WHETHER YOU REPLACE THAT COMPONENT
AND WERE CALLING YOUR SERVICE TO DO IT
OR WHETHER YOU ONLY REPLACED THE MPI PIECE
AND WE DO OUR CORRELATION, THOSE ARE IMMATERIAL TO US,
BUT WE DO HAVE TO HAVE THAT IN ORDER TO ORCHESTRATE THE MESSAGE CORRECTLY.
Jain: SO ARE THESE COMPONENTS EASILY CONFIGURABLE ENOUGH
TO TURN OFF AND ON?
YES. IN THE CONNECTION MANAGER THAT I'LL GO THROUGH TOMORROW,
YOU CAN ACTUALLY--
WE CAN TAKE THE INFORMATION FROM UDDI
AND WE CAN ALSO CONFIGURE OUR OWN COMPONENTS
AND IT WILL ALWAYS USE THE ONES THAT WE USE,
THAT WE CONFIGURE LOCALLY FIRST, AND IF WE DON'T HAVE AN ENTRY,
THEN IT USES THE ONE FROM UDDI,
SO YOU CAN CONFIGURE ANY ONE OF THOSE SWAPPABLE COMPONENTS
THAT WE'VE DEFINED IN THE ARCHITECTURE
SIMPLY BY PUTTING IN A NEW URL IN THE CONNECTION MANAGER,
AND THAT'S THE ONE WE USE.
Cothren: THAT IS THE EXAMPLE FOR TOMORROW.
YES, THAT'S WHAT WE'LL DO FOR THE MPI TOMORROW.
Jain: ALL RIGHT, THANK YOU.
YEAH, MIN YA FROM ZGO INFO, MARYLAND.
WE'RE ACTUALLY IN THE GIS DEVELOPMENT, SO--
BUT ANYWAYS, THIS IS A VERY ENLIGHTENING DAY FOR ME.
I THINK I'M GONNA TRY TO MAKE SOME CONFIRMATIONS.
SO THIS CONNECT SOFTWARE, THIS FRAMEWORK.
WE DOWNLOAD, WE PUT IT ON,
AND YOU SAID THE ADAPTER INTERFACE
IS ESSENTIALLY A DEFINING INTERFACE, RIGHT?
I'M LOOKING MORE FOR MESSAGE-DRIVEN, YOU KNOW,
REST KIND OF INTERFACE.
I DON'T HAVE TO DO GLASS, ALL THESE FANCY THINGS.
WE HAVE OUR OWN DEVELOPMENT ENVIRONMENT WE USE,
AND WE'VE BEEN SUCCESSFUL WITH IT. THAT'S ONE THING.
THE OTHER THING IS MORE OF HOW DO YOU EXCHANGE INFORMATION--
2.1 IS MESSAGE-DRIVEN REST INTERFACE.
I SUPPOSE THAT'S ALREADY IN THIS.
2.0 IS AS WELL.
AND THE OTHER THING IS DOCUMENT-DRIVEN.
I'M PASSING A DOCUMENT TO--
AND IT IS--RIGHT NOW, THAT DOCUMENT
HAS BEEN DEFINED AS A C.32 DOCUMENT,
ALTHOUGH IT'S NOT LIMITED TO THAT.
CONNECT ALLOWS YOU TO PASS ANY DOCUMENTS.
BUT THE NHIN, IN THE TRIAL IMPLEMENTATIONS LAST YEAR,
WERE USING C.32 DOCUMENTS.
THERE WERE ALSO C.24 DOCUMENTS.
THERE WERE A NUMBER OF DIFFERENT DOCUMENTS THAT WERE USED,
ALL BASED ON CDA, THE HL7 CLINICAL DOCUMENT ARCHITECTURE,
AND THE CCD, I BELIEVE.
AND SO, YEAH, THE DOCUMENT PAYLOAD--IT COULD BE ANYTHING.
YOU COULD TAKE CONNECT, LITERALLY,
AND USE IT OUTSIDE OF A HEALTH-CARE ENVIRONMENT
IF YOU REALLY WANTED TO.
WE'RE AGNOSTIC TO THE HEALTH CARE.
IT NEEDS TO HAVE AN MPI AND IT NEEDS TO HAVE DOCUMENTS,
BUT I'M GUESSING THERE'S NOTHING THAT WOULD STOP YOU
FROM USING IT OUTSIDE OF HEALTH CARE.
OK, SO THEN IT JUST MAKES ME QUESTION.
IS THERE A SANDBOX TEST ENVIRONMENT
WHERE WE CAN CONNECT TO
THAT WOULD DO SOME OF THESE THINGS?
OR YOU HAVE A SET-UP OF YOUR OWN OR BE CONNECTED TO?
THERE'S A PLAN TO HAVE ONE. THERE'S NOT ONE THERE YET.
BUT PART OF THE SPECIFICATION FACTORY
AND THE WHOLE PROCESS THAT'S BEING WORKED OUT RIGHT NOW
IS THAT AS THE SPECIFICATION
IS ROLLED OUT OF THE SPEC FACTORY,
WE'LL DO AN IMPLEMENTATION AND STAND IT UP
AS A REFERENCE IMPLEMENTATION, NOT ONLY THAT YOU CAN DOWNLOAD,
BUT YOU CAN HIT AGAINST OF THAT SPECIFICATION,
AND THERE'S BEEN A NUMBER OF DISCUSSIONS I'VE BEEN INVOLVED WITH
UP TO THIS POINT ABOUT STANDING THAT UP AND STANDING UP AN ENVIRONMENT,
SO IT'S NOT THERE YET, BUT THERE IS A PLAN TO DO SO.
SO IF WE WANT TO SET SOMETHING UP,
IS THERE SOME GUIDELINES WHAT TO DO?
PROBABLY WHAT I WOULD SUGGEST IS TO GET IN CONTACT WITH ONC
IF YOU WERE INTERESTED AT THAT LEVEL OF SETTING SOMETHING UP.
TO DAVE RILEY AT THAT LEVEL. CONTACT THEM HERE. VANESSA.
AND THEY'D PROBABLY BE ABLE TO AT LEAST
GET YOU TO THE RIGHT PEOPLE TO TALK TO.
THANKS.
HI. MY NAME IS MATTHEW WEAVER. I'M FROM CGI FEDERAL.
I ACTUALLY WAS A DEVELOPER ON THE CARESPARK PROJECT,
WHICH, AS YOU KNOW,
WE USE THE SAME GLASSFISH KIND OF ESB BUILD,
SO I ACTUALLY HAVE 2 QUESTIONS.
ONE--AS YOU GO THROUGH THESE 3-MONTH ITERATIONS
AND RELEASE SOFTWARE EVERY 3 MONTHS,
DO YOU INTEND TO KIND OF UPGRADE TO THE NEWEST ESB
EACH TIME YOU DO IT,
OR ARE YOU GONNA PICK ONE AND KIND OF STICK WITH IT
UNTIL THE TECHNOLOGY THAT IT USES
NO LONGER SUITS YOUR NEEDS?
YEAH, LET ME TALK TO THAT.
ONE OF THE PROBLEMS WE RAN INTO
AND WHY WE'RE MAKING THE CHANGE TO MOVE AWAY FROM THE ESB, IN GENERAL--
I DIDN'T SPECIFY EARLIER, IT WAS ON MY SLIDES--
WAS A VERSIONING ISSUE THAT WE RAN INTO.
GLASSFISH ESB AS A PRODUCT
COMPILES A NUMBER OF DIFFERENT PROJECTS
GLASSFISH, ESB IS OBVIOUS ONES.
Weaver: THE SERVICE ENGINES.
BUT IT PULLS IN A BUNCH OF THEM TOGETHER,
AND THE PROBLEM WE RAN INTO IS THEY'LL TEST IT
WITH ONE VERSION OF EACH OF THOSE PRODUCTS,
AND THEN THEY'LL ROLL THAT OUT, AND NETBEANS, FOR EXAMPLE,
WILL BE 3 RELEASES AHEAD OF THAT, AND WE CAN'T USE THAT
BECAUSE OF THE FACT THAT THEY HAVEN'T TESTED
WITH THAT LATER VERSION OF NETBEANS,
AND SO WHEN WE FOUND BUGS IN NETBEANS
THAT WE HAD TO HAVE FIXED IN ORDER TO MAKE OUR DATES,
THEY'D FIX IT IN THE NEWER VERSION OF NETBEANS,
BUT WE COULDN'T USE IT BECAUSE GLASSFISH ESB WAS OVER HERE.
AND SO OUR INTENT, AS WE GET TO THE POINT
WHERE WE'VE REMOVED THE BPELs AND THE ESB ITSELF,
IS THAT WE'LL BE AUTONOMOUS TO THAT,
SO WE'LL STILL USE THE GLASSFISH AND THE NETBEANS, ET CETERA,
BUT WE'LL BE ABLE TO KEEP UP WITH NEWER REVISIONS OF THAT
SO THAT AS BUG FIXES HAPPEN, WE CAN USE THEM.
SO THE SHORT ANSWER IS WE WANT TO KEEP CURRENT WITH THEM
BECAUSE IT'S VERY PAINFUL TO GET VERY FAR OUT.
WHEN WERE WERE LAST YEAR IN JUNE AND WE MOVED TO DECEMBER,
THAT TOOK US A WHOLE MONTH TO MAKE THAT JUMP
TO THAT NEW VERSION OF GLASSFISH ESB.
WE DON'T WANT TO GET TOO FAR AWAY
BECAUSE THE COST OF THAT IS TOO EXPENSIVE.
THAT'S THE GENERAL ANSWER.
EACH RELEASE I'M SURE WILL HAVE ITS OWN SET
OF WHETHER WE MOVE OR NOT.
THE SECOND QUESTION WAS...
YOU SAID AS YOU'RE GETTING AWAY FROM THE OPEN ESB
AND YOU'RE RELYING MORE JUST ON EJBs AND JAVA CODE,
DOES THAT--DO YOU INTEND TO GO TO...
SOME DIFFERENT APPLICATION SERVERS,
MAYBE SOMETHING THAT JUST IMPLEMENTS EJB AND JSR
SO THAT YOU DON'T NEED GLASSFISH,
OR WILL YOU ALWAYS STAY WITH GLASSFISH?
OBVIOUSLY ONE OF OUR INTENTS OF MOVING THAT DIRECTION
IS TO ALLOW FOR THAT TO HAPPEN.
WE REALLY ARE AGNOSTIC TO THE STACK, WE WANT TO BE,
AND SO AS WE GO THAT DIRECTION,
WHETHER WE PRODUCE ONE THAT'S PART OF THE DOWNLOAD
OR WHETHER OTHER PEOPLE WITHIN THE COMMUNITY TAKE IT
AND DO THE SAME, THAT'S ALWAYS A POSSIBILITY,
AND I DON'T KNOW THAT ANYBODY'S REALLY DECIDED.
I KNOW THAT WE'VE TALKED ABOUT OTHER OPERATING SYSTEMS
THAT WE WANT TO SUPPORT AS AUTOMATIC DOWNLOADS,
BUT WE ALREADY KNOW AT THIS POINT
THAT AT LEAST 1 OR 2 ORGANIZATIONS I'M AWARE OF
HAVE ALREADY PULLED IT DOWN AND PUT IT ON LINUX.
OBVIOUSLY THE SOLARIS DOWNLOAD THAT WE HAVE
AND THE WINDOWS DOWNLOAD THAT WE HAVE--
WE DON'T DO MANY OPERATING SYSTEMS
OR MANY ENVIRONMENTS
JUST BECAUSE, RIGHT NOW, THEY'RE MORE AFTER FEATURES
THAN THEY WANT DIVERSITY,
BUT THAT DOESN'T MEAN THAT THAT WILL CHANGE
AS THE COMMUNITY GETS ESTABLISHED.
THANK YOU.
ONE LAST-- MY NAME IS RAVI MADDURI FROM UNIVERSITY OF CHICAGO
AND NCI.
NO, JUST ONE.
Cothren: SURE, 'CAUSE I THINK YOU TOOK UP YOUR QUOTA
ALREADY THIS--
[MAN, INDISTINCT]
Madduri: SORRY.
I WOULD LIKE TO--
SO THERE ARE REASONS HERE
FOR MOVING AWAY FROM ESB AND BPEL,
AND I WOULD LIKE TO--IS THERE A DOCUMENT THAT TALKS ABOUT THIS
AND IS THERE A DOCUMENT PROCESS FOR CONNECT 2.2 ROAD MAP?
ARE THEY AVAILABLE ONLINE?
THAT'S AGAIN ONE OF THE THINGS THAT WE'VE STARTED TALKING ABOUT
IS MOVING TO AN OPEN-SOURCE COMMUNITY,
THAT THOSE TYPES OF TOOLS ARE GONNA BE MUCH MORE IMPORTANT
TO UNDERSTAND THE REASONINGS BEHIND MAKING CHANGES TO THE ARCHITECTURE
AND CHANGES TO THE IMPLEMENTATION,
THE CONVERSATIONS THAT TOOK PLACE
TO MOVE THOSE THINGS FORWARD
AND MAKING THAT PART OF THE OPEN DISCUSSION.
THAT'LL BE AN IMPORTANT PART OF MOVING TO
AN OPEN-SOURCE COMMUNITY TYPE OF FORUM
RATHER THAN WHERE THINGS ARE NOW.
AND SO, YES, THERE IS A HISTORY OF SOME OF THOSE THINGS
THAT YOU DON'T NECESSARILY FIND ON THE WIKI TODAY,
BUT I THINK THAT WE WILL BE MOVING IN THAT DIRECTION AS WE MOVE FORWARD.
I'D JUST LIKE TO GET THE HANDLE OF THE DOCUMENT
THAT TALKS ABOUT THESE ISSUES HERE.
WE DOCUMENTED THOSE ISSUES FOR FHA WHEN WE MADE THE DECISION,
BUT THAT'S NOT BEEN PUBLICLY POSTED.
I DON'T KNOW IF FHA OR ONC
WOULD WANT TO PUBLISH THAT DECISION OR THAT DOCUMENT.
Cothren: WHY DON'T YOU GIVE ME YOUR BUSINESS CARD,
AND WE CAN TALK OFFLINE ABOUT GETTING YOU MORE INFORMATION.
THANKS.
OK. IF THERE AREN'T ANY OTHER QUESTIONS--
[MAN, INDISTINCT]
HI THERE. WILL MITCHELL WITH NOBLIS.
FIRST I WANT TO THANK YOU FOR YOUR FRANKNESS
ABOUT YOUR EXPERIENCES WITH ESB AND BPEL.
I THINK THERE'S PROBABLY A LOT OF CONFUSION ABOUT THAT
IN THE INDUSTRY.
MY QUESTION IS DO YOU HAVE ANY PLANS
FOR MOVING TO A BUILD SYSTEM
BASED ON MAVEN OR IVY OR ANYTHING LIKE THAT?
THAT'S A GOOD QUESTION.
RIGHT NOW, WE'RE ON A CONTINUOUS BUILD RIGHT NOW,
AND WE HAVE SOME FAIRLY LENGTHY BUILD TIMES.
ONE OF THE FIRST TASKS THAT I ACTUALLY WAS DRIVING
INITIALLY WITH THAT
IS THAT I WANTED TO KEEP THE PROJECT FILES,
THE SCRIPTS, AS CLOSE TO THE NATIVE SCRIPTS AS POSSIBLE
FOR EACH PROJECT,
AND MY REASONING BEHIND THAT
IS IN PREVIOUS EXPERIENCES WITH THAT,
WHEN YOU HAVE A DIFFERENT SET OF BUILD SCRIPTS
THAT ARE USED IN THE I.D.E.
THAN THE ONES THAT ARE USED TO BUILD,
YOU RUN INTO ALL SORTS OF PROBLEMS,
AND SO WE WANTED TO KEEP THEM THAT WAY AS MUCH AS POSSIBLE.
BUT WHAT WE ARE RUNNING INTO NOW IS HORRENDOUS BUILD TIMES
BECAUSE THE WAY THE SCRIPTS ARE THAT COME OUT OF THE I.D.E.,
THEY'RE REBUILDING SOME OF OUR ITEMS AGAIN AND AGAIN AND AGAIN.
AND SO WE'VE ALREADY HAD SOME INTERNAL DISCUSSIONS OF GETTING TO THAT POINT
OF USING EITHER MAVEN OR IVY.
PART OF IT'S BEEN RESOURCING, PART OF IT'S BEEN--
WHERE'S THE PRIORITY TO GET IT DONE?
BUT WE'RE DEFINITELY HITTING A POINT WHERE WE HAVE TO DO SOMETHING
BECAUSE WE'RE SEEING IN OUR CONTINUOUS BUILD ENVIRONMENT
BUILDS TAKING IN EXCESS OF AN HOUR TO BUILD,
AND SO WE'RE ALREADY HITTING THAT POINT,
BUT NOTHING'S HAPPENED TO FIX IT AT THIS POINT.
THANKS.
MY NAME IS...
[MAN, INDISTINCT]
THE ONE QUESTION ABOUT VERSION 2.1
IS ABOUT THE SPRING FRAMEWORK
AS IN TO WHAT EXTENT DO YOU PLAN TO USE THE SPRING FRAMEWORK
GOING FORWARD?
[INDISTINCT]
AS IN DO YOU PLAN TO USE THE AOP FEATURES
OR THE PRESENTATION LAYER FEATURES, IN ANY CASE?
WE'VE TALKED ABOUT THE PRESENTATION LAYER FEATURES
AND HAVE NOT MADE THAT DECISION YET.
THIS NEXT RELEASE, SOME OF THOSE DECISIONS
WILL START TO IRON OUT A LITTLE BIT
AS WE START TO BUILD THE UNIVERSAL CLIENT
AND THE DECISIONS THERE.
SO I REALLY DON'T HAVE AN ANSWER FOR THAT DIRECTION.
RIGHT NOW, WE ARE ONLY USING IT FOR THAT ONE CASE
FOR THE CONNECTION PROXY TO BE ABLE TO MANAGE OUR CLASSES
TO KNOW WHETHER WE'RE CALLING A WEB SERVICE OR NOT.
MY SECOND QUESTION I WILL HAVE
IS DO YOU PLAN TO POST A ROAD MAP
FOR THE NEXT FEW RELEASES SO THE OPEN-SOURCE COMMUNITY
CAN UNDERSTAND WHAT YOU'RE GOING TO PLAN
OR WHAT IS THE PLAN FOR THE NEXT...
WELL, AGAIN, THAT'S-- WE'RE HAVING A LOT OF DISCUSSIONS INTERNALLY
ABOUT HOW WE REALLY MOVE TO AN OPEN SOURCE COMMUNITY,
AND I THINK AN IMPORTANT PART OF THAT IS GONNA BE
ADVERTISING WHAT THE ROAD MAP IS AS WE MOVE THINGS FORWARD
SO THIS COMMUNITY IS INFORMED ABOUT THE DIRECTION.
WE DO PLANNING, OBVIOUSLY,
TO UNDERSTAND MORE ABOUT THE FUTURE RELEASES,
SO THAT'LL BE PART OF IT.
DAVE CLEARLY HAS SOMETHING TO SAY ON THAT MATTER.
[LAUGHTER]
ACTUALLY, WE'LL MAKE SOME ANNOUNCEMENTS ABOUT THAT TOMORROW.
THAT'S THE OPEN-SOURCE FORUM AT THE END OF THE--
BRIAN BEHLENDORF WILL BE LAYING OUT
SOME OF WHAT WE'RE GONNA BE DOING THERE.
ANY OTHER QUESTIONS?
I WANT TO THANK EVERYBODY FOR ATTENDING THE SESSION.
BEFORE YOU LEAVE, LES, DO YOU WANT TO GIVE THEM
JUST AN ELEVATOR SPEECH SNAPSHOT
ON WHAT THEY SEE TOMORROW AT THE TRAIN SESSIONS?
YEAH. TOMORROW, YOU'RE GOING TO BE BORED
IF YOU DON'T LIKE TO SEE SOFTWARE.
BUT WHAT WE'RE GONNA ACTUALLY DO TOMORROW--
I'VE SET UP-- THERE'S 3 DEMONSTRATIONS
OR 3 PRESENTATIONS WE'RE GOING TO DO.
THE FIRST ONE IS GOING TO BE INSTALLING THE SOFTWARE.
WE'RE GONNA ACTUALLY WALK THROUGH AN INSTALLATION
OF CONNECT,
AND BECAUSE THERE ARE SOME ITEMS THAT ARE REALLY SIMPLE
AND I DON'T REALLY NEED TO SHOW YOU
HOW TO INSTALL THE JDK, FOR EXAMPLE,
WHAT I'VE DONE IS I'VE TAKEN AND CREATED VIRTUAL MACHINES
AND SNAPSHOTS IN THE PROCESS SO WE CAN JUMP TO SPECIFIC POINTS
AND DO SOME INSTALLATIONS OF THE THINGS THAT I THINK
HAVE BEEN ISSUES WE'VE SEEN ON THE FORUM
THAT HAVE COME UP.
SO THAT'LL BE THE INSTALLATION PART.
THEN THE SECOND PART WILL BE THE TESTING
USING THE SCRIPTS THAT ARE UP ON THE SITE
TO BE ABLE TO SELF-TEST THE SYSTEM
AND MAKE SURE IT ACTUALLY RUNS.
I'VE GOT SOME VIRTUAL MACHINES SET UP THERE
THAT WE'LL WALK THROUGH.
I'LL SHOW YOU HOW TO DO THE VALIDATE SERVICES TEST
AS WELL AS THE SELF-TEST, AND WE'LL WALK THROUGH THOSE.
AND THEN THE FINAL SESSION WILL BE TO BUILD AN ADAPTER.
WE'LL ACTUALLY CUSTOMIZE THE MPI AND TAKE OUT THE REFERENCE MPI
AND PLUG IN THE DATABASE VERSION OF AN MPI THAT WE BUILT
WITH A MySQL DATABASE.
WE'LL SHOW YOU HOW TO SWAP IN AN ADAPTER.
THE POINT BEING WE'LL SHOW YOU HOW TO GET IT INSTALLED,
SHOW YOU HOW TO GET IT TESTED, AND SHOW YOU HOW TO CUSTOMIZE SOMETHING
IS KIND OF WHAT WE HOPE YOU TAKE AWAY FROM THAT.
THANK YOU VERY MUCH.
WHAT'S THAT?
- CAN I GET A BUSINESS CARD? - YEAH.